Dockerイメージをビルドして運用していると、「リリース前にイメージの脆弱性をちゃんと調べておくように」と求められる場面が増えています。コンテナは一度ビルドすれば中身は固定ですが、含まれるOSパッケージやライブラリの脆弱性情報は日々更新されます。そのため、昨日まで問題のなかったイメージから今日になって既知の脆弱性が見つかることも珍しくありません。
とはいえ、セキュリティが専門でない開発者やインフラ担当にとっては、「何というツールを使って、どんなコマンドを打てば調べられるのか」が最初の壁になります。ツールは複数あり、出てきた結果の読み方や、どの脆弱性から直すべきかも分かりにくいものです。
本記事では、手元のDockerイメージを無料ツールでスキャンする具体的な手順から、結果の読み方・直し方・CI/CDへの組み込みまでを、実際のコマンドと出力例を交えて解説します。さらに、ツールごとの検出範囲の違いや誤検知の扱い、自力のスキャンでは届かない範囲を脆弱性診断サービスに委ねるときの使い分けまで整理しました。
自社のDockerイメージの脆弱性を自分で調べ、運用に乗せるための手引きとしてご活用ください。
本記事で解説する、Dockerイメージの脆弱性に対応する運用の全体像は次のとおりです。
目次
一括ダウンロードする
最短手順：Trivyで手元のDockerイメージをスキャンする
まずは手を動かして、1つのイメージをスキャンしてみます。無料で手元から使えるツールはいくつかありますが、最初の一本としてはTrivy（トリビー）が扱いやすく、導入も手軽です。インストールして、イメージ名を指定してコマンドを1つ打つだけで、イメージに含まれる既知の脆弱性を一覧できます。
macOS・Linux のいずれでも導入できます。インストール後は、調べたいイメージ名を指定して実行するだけです。初回実行時は脆弱性データベースのダウンロードが走るため、少し時間がかかります。
# Trivyのインストール（macOS / Homebrew）
brew install trivy
# Trivyのインストール（Linux / 公式インストールスクリプト）
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin
# 自分のイメージをスキャンする（ローカルでビルド済みのイメージ名もそのまま指定できる）
trivy image myapp:latest実行すると、イメージに含まれるパッケージごとに検出された脆弱性が表形式で出力されます。以下は Trivy 公式ドキュメントに示されている出力例（trivy image python:3.4-alpine を実行した場合。先頭行には解決後のタグ python:3.4-alpine3.9 が表示されます）です。自分のイメージでも同じ形式で結果が並びます。
python:3.4-alpine3.9 (alpine 3.9.2)
===================================
Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 0, CRITICAL: 0)
+---------+------------------+----------+-------------------+---------------+--------------------------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE |
+---------+------------------+----------+-------------------+---------------+--------------------------------+
| openssl | CVE-2019-1543 | MEDIUM | 1.1.1a-r1 | 1.1.1b-r1 | openssl: ChaCha20-Poly1305 ... |
+---------+------------------+----------+-------------------+---------------+--------------------------------+この例は1件だけですが、実際のイメージでは、この表が数十〜数百行に及ぶこともあります。先頭の Total 行に重大度ごとの内訳（CRITICAL / HIGH / MEDIUM / LOW）が出るので、まず Total で全体像をつかみ、次の章の優先順位づけで絞り込むと把握しやすくなります。
Trivyは標準では脆弱性スキャンに加えてシークレット（イメージに紛れ込んだ認証情報）のスキャンも行います。脆弱性だけに絞りたい場合は、スキャナを指定して実行します。
# 脆弱性スキャンだけに絞る
trivy image --scanners vuln [YOUR_IMAGE_NAME]これで、手元のイメージがどんな脆弱性を抱えているかを把握する第一歩が踏めます。出力の意味と、どれから対処すべきかは次の章で読み解きます。
出典・参考資料（2件）
スキャン結果の読み方と優先順位づけ
スキャンを実行すると、CVE（既知の脆弱性に振られる番号）が何件も並びます。多いときは数百件に達することもあり、「全部直さなければいけないのか」と戸惑いがちです。ここでは、出力の各列が何を示しているかを読み解き、そのうえでどれから手を付けるべきかを整理します。
各列（Library・Vulnerability ID・Severity・Installed Version・Fixed Version）の読み方
Trivyの出力テーブルは、脆弱性1件につき1行で、次の列が並びます。自分の結果を読むときは、まずこの5つの列を見れば判断できます。
- Library：脆弱性が見つかったパッケージ名（例: openssl）。どのパッケージを更新すればよいかの手がかりになります。
- Vulnerability ID：CVE番号（例: CVE-2019-1543）。この番号で検索すれば、脆弱性の詳細や影響を調べられます。
- Severity：重大度。UNKNOWN・LOW・MEDIUM・HIGH・CRITICALの5段階で示されます。
- Installed Version：いまイメージに入っているバージョン。
- Fixed Version：修正されたバージョン。ここに値があれば、そのバージョン以上に上げれば解消します。空欄の場合は、まだ修正版が提供されていない（未修正の）脆弱性です。
先ほどの例であれば、opensslの1.1.1a-r1に中程度（MEDIUM）の脆弱性があり、1.1.1b-r1で修正されている、と読み取れます。
どれから直すか（CRITICAL・HIGHと「修正版あり」を優先）
検出された脆弱性をすべて同時に直すのは現実的ではありません。優先順位をつけて、影響の大きいものから着手します。実務では、次の順で絞り込むのが扱いやすい進め方です。
- 重大度がCRITICALとHIGHのものに絞る。重大度は、まず深刻なものから見るための最初のふるいです。
- そのうちFixed Version（修正版）が提供されているものから対応する。バージョンを上げれば解消するため、対処が明確です。
- インターネットに公開しているコンテナなど、攻撃を受けやすい面のものを優先する。同じ脆弱性でも、外部に公開されているかどうかでリスクの大きさは変わります。
Trivyには、表示する重大度を絞り込むオプションもあります。CRITICALとHIGHだけを見たい場合は、次のように指定します。
# 重大度 HIGH・CRITICAL だけを表示する
trivy image --severity HIGH,CRITICAL [YOUR_IMAGE_NAME]重大度はあくまで最初のふるいです。重大度が高くても自社の使い方では影響しないものや、逆に重大度が中程度でも公開面にあって危険なものもあります。この見極めについては、後半の「誤検知・文脈依存の脆弱性をどう扱うか」で詳しく扱います。
主要なスキャンツールの比較（Trivy・Grype・Docker Scout・Dockle）
Dockerの脆弱性を調べるツールは複数あり、それぞれ「何を見るか」が異なります。1つのツールですべてをカバーできるわけではないため、自分が調べたいものに合わせて選ぶことが大切です。主なツールの守備範囲を整理します。
| ツール | Trivy | Grype | Docker Scout | Dockle | hadolint | Nessus |
|---|---|---|---|---|---|---|
| 主に検出するもの | OSパッケージ・ライブラリの脆弱性（CVE）／設定不備／シークレット | OSパッケージ・ライブラリの脆弱性（CVE） | イメージの脆弱性（CVE） | イメージの設定・ベストプラクティス（CIS Docker Benchmark準拠） | Dockerfileの書き方（Lint） | ネットワーク・ホストの脆弱性 |
| 無料で使えるか | ● | ● | 一部無料 | ● | ● | 一部無料 |
| 実行場所 | 手元・CI | 手元・CI | 手元・Docker Desktop | 手元・CI | 手元・CI | ネットワーク診断 |
| 特徴 | Aqua Security 製のOSS。導入が手軽で対象が広く、最初の一本に向く | Anchore 製のOSS。SBOM生成ツールSyftと組み合わせて使える | Docker 公式。Docker Desktopに同梱。docker scout コマンドで実行 | 設定監査が主で、パッケージのCVE照合はTrivy/Grypeと役割が異なる | Dockerfileの改善点を指摘。CVEは見ない | Tenable 製。ネットワーク/ホスト向けで、イメージ内CVEスキャンとは領域が異なる |
※各ツールの検出範囲は各公式ドキュメントに基づきます（2026年11月時点）。詳細や最新の対応状況は各公式情報をご確認ください。
まず押さえたいのは、パッケージの脆弱性（CVE）を見るツールと、設定やDockerfileの良し悪しを見るツールは別だという点です。TrivyやGrype、Docker ScoutはイメージのCVEを照合します。
一方、DockleはCIS Docker Benchmarkに沿った設定・ベストプラクティスの監査が主で、hadolintはDockerfileの書き方を指摘します。これらは目的が異なるため、組み合わせて使うのが実務的です。
混同しやすいのがNessusです。Nessusはネットワークやホストを対象とする脆弱性診断ツールで、Dockerイメージの中に含まれるCVEをスキャンする用途とは領域が異なります。「Dockerの脆弱性診断」でまず使うのは、TrivyのようなイメージのCVEスキャナだと考えておくと迷いません。
かつて使われていたdocker scanコマンドは2023年に提供を終了しており、現在のDocker公式の後継はdocker scoutです。docker scout quickviewでイメージの脆弱性サマリを、docker scout cvesで検出されたCVEの一覧を確認できます。
Trivy以外のツールも、基本的な使い方はイメージ名を渡すだけです。GrypeはCVEスキャンに、DockleはCIS Docker Benchmarkに沿った設定チェックに使えるので、Trivyと組み合わせて試してみると違いがつかめます。
# Grype（CVEスキャン）
grype [YOUR_IMAGE_NAME]
# Dockle（設定・ベストプラクティスの監査）
dockle [YOUR_IMAGE_NAME]
# Docker Scout（Docker公式。Docker Desktopに同梱）
docker scout cves [YOUR_IMAGE_NAME]出典・参考資料（5件）
- 出典：Dockle（Container Image Linter for Security・CIS Benchmarks）｜GitHub（goodwithtech/dockle）
- 出典：Grype（a vulnerability scanner for container images and filesystems）｜GitHub（anchore/grype）
- 出典：docker scout cves｜Docker 公式ドキュメント
- 出典：docker scout quickview｜Docker 公式ドキュメント
- 参考資料：Nessus（vulnerability assessment solution）｜Tenable 公式サイト
Dockerイメージに脆弱性が生まれる仕組み
スキャンで多くの脆弱性が出てくる理由を理解しておくと、直し方の見当がつきやすくなります。Dockerイメージの脆弱性は、大きく3つの層から入り込みます。
- ベースイメージ（OS）の層：
FROM ubuntu:20.04のように土台にするOSイメージです。OSに同梱されるパッケージ（glibcやopensslなど）に既知の脆弱性が含まれていることがあります。 - 追加でインストールしたパッケージの層：
aptやapkでミドルウェアやライブラリを足すと、そのパッケージが脆弱性を持ち込むことがあります。 - アプリの依存ライブラリの層：npmやpipで入れるアプリケーションの依存パッケージです。アプリが使う外部ライブラリの脆弱性がここに該当します。
加えて、イメージ自体の中身は固定でも、脆弱性の情報は日々更新されます。新しいCVEが公開されれば、昨日まで検出されなかった脆弱性が今日のスキャンで出てくることになります。これが、一度スキャンして終わりにせず、継続的に調べ続ける必要がある理由です。どの層に由来する脆弱性かが分かれば、次章の直し方で手当てを選びやすくなります。
見つけた脆弱性の直し方
脆弱性が見つかったら、どの層に由来するかに応じて手当てします。前章の3層のうち、OSパッケージとアプリ依存ライブラリで直し方が変わります。
OSパッケージの脆弱性（ベースイメージの更新で解消する）
ベースイメージに由来するOSパッケージの脆弱性は、ベースイメージを新しいものに更新するのが基本の対処です。たとえば古いDebianを土台にしている場合、より新しいバージョンに上げるだけで、OS側の脆弱性がまとめて解消することがあります。具体的には、Dockerfile の FROM 行のタグを次のように上げます（Debian 11「bullseye」→ Debian 12「bookworm」）。
# 修正前：古いベースイメージ（Debian 11「bullseye」）
FROM debian:bullseye
# （この下にアプリのコピー・ビルド手順が続く）
# 修正後：新しいベースイメージ（Debian 12「bookworm」）に上げる
FROM debian:bookworm
# ビルド手順はそのまま。ベースを上げるだけでOSパッケージがまとめて更新される更新したら、同じイメージをもう一度スキャンし、該当CVEが消えたか（または Fixed Version に到達したか）を確認します。alpine:3.18 → alpine:3.20 のように、他のベースイメージでも考え方は同じです。
古いタグを長く使い続けているほど脆弱性がたまるため、ベースイメージのバージョンを定期的に見直すことが効果的です。個別のパッケージだけ更新する場合も、ビルド時に最新のパッチを取り込むようにします。
アプリ依存ライブラリの脆弱性（バージョンを上げて固定する）
アプリが使う依存ライブラリの脆弱性は、修正済みのバージョンに上げて固定するのが基本です。スキャン結果のFixed Versionを確認し、その版以上を指定します。たとえばPythonならrequirements.txtで該当パッケージのバージョンを修正版に指定し直す、といった対応です。バージョンを固定しておくと、意図しない版への変動を防ぎ、再発も抑えられます。
再発を防ぐ：ベースイメージを小さく・新しく保つ
そもそも脆弱性が入り込む面を減らしておくと、スキャンで出てくる件数も対処の手間も減ります。予防として効果が高いのは次の工夫です。
- 小さいベースイメージを使う：AlpineやdistrolessのようにOSの中身を絞ったイメージを使うと、含まれるパッケージが減り、脆弱性の対象面が小さくなります。
- マルチステージビルドを使う：ビルドに必要なツールを最終イメージに残さず、実行に必要なものだけを含めることで、不要なパッケージ由来の脆弱性を避けられます。
- 信頼できる配布元のイメージを選ぶ：公式イメージや検証済みの配布元のイメージを土台にし、提供元の分からないイメージを避けます。
これらを習慣にしておくと、スキャンのたびに大量の脆弱性に追われる状況を避けられます。
CI/CDへの組み込みで自動化する
毎回手でコマンドを打つ運用は長続きしません。コードをpushするたびに自動でスキャンが走る仕組みにしておくと、脆弱性の持ち込みをその場で止められます。主要なCI/CD環境には、少ない設定でスキャンを組み込めます。
GitHub Actions（trivy-action）で自動スキャンする
GitHub Actionsでは、Trivyの公式アクションaquasecurity/trivy-actionを使います。ビルドしたイメージを指定してスキャンし、深刻な脆弱性が見つかったらビルドを失敗させる、といった設定ができます。
- uses: aquasecurity/trivy-action@v0.36.0
with:
image-ref: 'docker.io/my-organization/my-app:${{ github.sha }}'
format: 'table'
exit-code: '1'
ignore-unfixed: true
vuln-type: 'os,library'
severity: 'CRITICAL,HIGH'severityで対象の重大度を、exit-code: '1'で該当する脆弱性が見つかったときにジョブを失敗させる挙動を指定します。ignore-unfixed: trueを付けると、まだ修正版が出ていない脆弱性を対象から外せます。バージョンタグ（@v0.36.0）は執筆時点の例なので、利用時は最新の固定タグを確認してください。
GitLab CIのContainer Scanningを使う
GitLabには、コンテナスキャンの標準テンプレートが用意されています。パイプラインの設定ファイルで、このテンプレートを読み込むだけでスキャンが有効になります。内部ではTrivyが使われています。
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml読み込むテンプレートは、現在はJobs/Container-Scanning.gitlab-ci.ymlが正規のパスです（以前のSecurity/Container-Scanning.gitlab-ci.ymlも互換のために残っていますが、現行はJobs配下を参照します）。検出された脆弱性は、マージリクエストの画面で確認できます。
レジストリ側の自動スキャン（Amazon ECR・Artifact Registry・Docker Hub）
イメージを保管するレジストリ側にも、自動スキャンの仕組みがあります。CI/CDでのスキャンと組み合わせると、保管中のイメージも継続的に見張れます。
- Amazon ECR：プッシュ時などにスキャンする基本のスキャンと、Amazon Inspectorと連携してOSに加え言語パッケージまで継続的に調べる拡張スキャンがあります。
- Google Cloud Artifact Registry：プッシュ時に自動でスキャンし、新たに公開されたCVEにも追従します。
- Docker Hub：Docker Scoutと連携したイメージの分析に対応しています。
稼働中イメージの定期再スキャン
脆弱性情報は日々更新されるため、公開時に問題がなかったイメージでも、後から新しい脆弱性が見つかります。本番で稼働中のイメージも、週に一度など定期的に再スキャンする運用にしておくと、新たに判明した脆弱性を取りこぼしません。CI/CDでの組み込みと、レジストリ側の継続スキャンを合わせると、この定期チェックを自動化できます。
SBOM・サプライチェーンとの関係
イメージに何が含まれているかの一覧をSBOM（ソフトウェア部品表）として出力しておくと、後から「どのイメージにどのライブラリが入っているか」をまとめて追跡できます。新しい脆弱性が公開されたときに、影響するイメージを素早く洗い出せるため、サプライチェーン全体の管理に役立ちます。
TrivyはSBOMの出力に対応し、GrypeはSBOM生成ツールのSyftが作ったSBOMを入力としてスキャンできます。スキャンとSBOM管理をつなげておくと、継続的な脆弱性管理の土台になります。
イメージ単体にとどまらず、サーバーやクラウドも含めた組織全体の脆弱性を、検出から優先順位づけ・対応状況の管理までまとめて回したくなったら、脆弱性診断サービスとは別軸の選択肢として、脆弱性管理（VM）ツールもあります。守りたい対象やSBOM対応で選ぶ観点は、次の記事で比較しています。
出典・参考資料（5件）
- 出典：trivy-action（image-ref / severity / exit-code / ignore-unfixed）｜GitHub（aquasecurity/trivy-action）
- 出典：Container Scanning（Trivyによる静的解析・テンプレートの読み込み）｜GitLab 公式ドキュメント
- 参考資料：Image scanning（基本スキャン／Amazon Inspectorによる拡張スキャン）｜Amazon ECR ユーザーガイド
- 参考資料：Container scanning overview（Artifact Registry の自動スキャン）｜Google Cloud Artifact Analysis
- 参考資料：Docker Scout（Docker Hub連携のイメージ分析）｜Docker 公式ドキュメント
誤検知・文脈依存の脆弱性をどう扱うか
スキャナが出す結果は、そのまますべてが「いま危険な脆弱性」とは限りません。多くのスキャナは、インストールされているパッケージのバージョン番号を既知の脆弱性と照合して検出します。
そのため、実際にはその機能を使っていなかったり、外部から到達できない場所にあったりしても、該当バージョンというだけで一覧に挙がります。件数の多さに戸惑う前に、「本当に危険なものはどれか」を見極める視点を持つことが大切です。
見極めの手がかりになる考え方をいくつか挙げます。
- 到達可能性・公開面：その脆弱なコードが実際に呼び出されるか、外部から到達できる面にあるかを考えます。使っていない機能や、外部非公開の内部処理であれば、優先度は下がります。
- 悪用の可能性（EPSS）：EPSSは、公開されたCVEが今後30日以内に実際に悪用される確率を推定するデータです。重大度（CVSS）とは別の軸で「本当に狙われやすいか」を測れるため、優先順位づけの補助になります。
- バックポートによる誤検知：Red Hat系のOSなどでは、バージョン番号を変えずに修正だけを取り込む（バックポート）ことがあります。バージョンだけを見るスキャナはこれを考慮できず、修正済みなのに脆弱と誤判定することがあります。Red Hatは、こうした判定をツール側が正しく行えるよう、機械可読の脆弱性判定データ（OVAL）を公開しています。
対応しないと判断した脆弱性は、記録を残して除外できます。Trivyでは--ignore-unfixedで修正版のないものを対象から外せるほか、.trivyignoreファイルにCVE番号を書いて個別に除外できます。
# .trivyignore の例（理由をコメントで残す）
# No impact in our settings
CVE-2019-1543
# Accept the risk until 2027-01-01
CVE-2019-14697 exp:2027-01-01ただし、除外はリスクを受け入れる判断でもあります。なぜ除外するのかをコメントで残し、チームで確認できる状態にしておくことが大切です。そして、こうしたバージョンマッチの限界は、自力のスキャンだけでは見極めが難しい部分でもあります。
ツールによるスキャンがどこまでを捉え、どこから人の判断が必要になるのかについて、脆弱性診断を手がけるTECHFUNDの生田氏は次のように指摘しています。
ツールを使えば大量の項目を短期間で効率的に診断できますが、ビジネスロジックに関わる部分や、複数の脆弱性の組み合わせで一つの問題が起きるようなケースは、単一のツールでは取りこぼしやすい領域です。そこは人間の目で判断する必要が必ずありますので、両方を組み合わせて診断しています。
出典・参考資料（2件）
一括ダウンロードする
自力スキャンで足りない範囲と脆弱性診断サービスの使い分け
Trivyなどで自力スキャンを回せるようになると、日常的な脆弱性の確認は自分たちで続けられます。一方で、自力のツールスキャンだけでは届きにくい範囲もあります。たとえば、本番公開前に第三者の客観的な評価が必要な場合、コンテナからの脱出やプラットフォームの設定不備といった踏み込んだ検証が必要な場合、あるいは取引先や監査から正式な診断報告書を求められる場合です。
こうした場面では、脆弱性診断サービスを使い分けるのが現実的です。大きく分けると、開発・運用に組み込んで継続的に回すSaaS型のスキャン・保護と、専門家が深く調べて報告書を納める受託型の診断があります。
前者は日々の運用で脆弱性を見張り続ける用途に、後者は本番前の正式な評価やコンテナ・基盤まで踏み込んだ検証に向きます。自力のスキャンを土台にしつつ、足りない範囲をこれらのサービスで補うと、無理なくカバー範囲を広げられます。
ここでは自力スキャンの延長で検討しやすい代表的なサービスを取り上げますが、脆弱性診断サービス全体の診断方法・費用相場・選び方を広く見比べてから絞り込みたい場合は、カテゴリ全体をまとめた比較記事が出発点になります。
以下は、ここで紹介するサービスの比較表です。
| サービス名 | Aikido Security | GMO Flatt Security 脆弱性診断 | Aqua Security | Snyk |
|---|---|---|---|---|
| 提供形態 | SaaS型スキャン （オールインワン） | 受託診断 （報告書を納品） | SaaS型プラットフォーム （CNAPP） | SaaS型スキャン （開発者起点） |
| コンテナイメージ検査 | ● | ●（診断メニュー） | ◎（Trivy開発元） | ● |
| 実行時保護（ランタイム） | △製品に機能あり | × | ◎ | △（Sysdigと連携） |
| CI/CD・開発への組み込み | ● | ×（受託診断） | ● | ◎ |
| 料金の目安 | Basic 3,780ドル/年〜 （月額5万円台から） | 100万円〜（税別） 見積り無料 | 要問い合わせ （公式に金額非公開） | 無料プランあり Team 25ドル/月〜 |
| こんな場合に向く | 複数の検査を1か所で 継続的に回したいとき | 本番前の正式評価や 第三者の診断報告書が 要るとき | 組織全体でビルド後〜 本番まで一貫して 守りたいとき | 開発工程全体に 検査を組み込みたいとき |
| 詳細情報 | 公式資料を見る | サービス詳細を見る | 公式サイト | 公式サイト |
※料金・機能は各社の公式情報および提供窓口の情報に基づきます（2026年11月時点）。最新の料金・提供範囲・日本での対応条件は各社の公式情報や問い合わせ窓口でご確認ください。
Aikido Security（株式会社AndGo）
Aikido Securityは、ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリを1つの管理画面でまとめて検査するSaaSです。人が診断して報告書を納める受託型ではなく、ツールによる自動スキャンを継続的に回す契約形態で、日本では株式会社AndGoが販売・問い合わせの窓口を担っています。
コンテナイメージの検査に加え、ソースコード解析（SAST）、依存関係の検査（SCA）、クラウド設定の検査（CSPM）、動的なWebアプリ診断（DAST）まで幅広く対応します。アラートの自動トリアージで誤検知を減らす機能や、SlackやJiraなどとの連携も備えます。
料金は年額制で、1〜10ユーザーのBasicプランが3,780ドル/年（月額5万円台から）、上位のProプランが7,560ドル/年が目安です（無料トライアルあり。請求は為替を考慮した日本円での案内。2026年11月時点）。自力スキャンから一歩進めて、複数の検査を1か所で継続的に回したいチームに向く選択肢です。
本記事で見てきた「一度スキャンして終わりにしない」という継続的な取り組みは、開発現場でセキュリティをどこに位置づけるかの変化とも重なります。この点について、株式会社AndGoの原氏は次のように語っています。
正直なところ、昔は「セキュリティは運用側が最後に何とかするもの」という前提が強かったと思います。ですが今は攻撃の手口も複雑ですし、作ったあとに1回チェックして終わり、では追いつきません。
GMO Flatt Security 脆弱性診断（GMO Flatt Security株式会社）
専門のセキュリティエンジニアが網羅的に調べる、受託型の脆弱性診断です。WebアプリケーションやAPIに加え、SPA・GraphQL・クラウド・コンテナなどの個別メニューを用意しており、Dockerやコンテナ環境を対象にした診断を明示的に依頼できます。標準の診断にはソースコード診断が追加料金なしで付く点も特徴です。
料金は脆弱性診断が100万円〜（税別）で、見積りは無料です。URLと認証情報の提出から報告書納品まで最短7営業日とされ、経済産業省の情報セキュリティサービス基準に適合したサービスとして案内されています（2026年10月時点の公式情報）。
本番公開前の正式な評価や、取引先・監査に提出できる第三者診断の報告書が必要な場面に向きます。自力のツールスキャンでは届きにくい、専門家の目による深い検証を委ねたいときの選択肢です。
Aqua Security（Aqua Security Software Ltd.）
ここまで紹介したOSSのTrivyは、このAqua Securityが開発元です。同社の商用プラットフォーム「Aqua Platform」は、そのTrivyを土台に、コンテナ・Kubernetes・サーバーレス・クラウドを対象とした検査を備えています。
イメージの脆弱性スキャンから設定の検査（CSPM）、実行中のワークロードの保護（ランタイム保護）まで、クラウドネイティブ領域を包括的に守るプラットフォーム（CNAPP）として1つにまとめている点が特徴です。
デプロイ前のイメージスキャンに加え、実行中のコンテナの挙動を監視して不正な動きをブロックするといった、イメージの外側・稼働後まで含めた保護に踏み込める点が特徴です。手元のTrivyスキャンから、組織全体での継続的なコンテナセキュリティ管理へ広げたい場合に検討される選択肢です。料金や日本での提供条件は公式サイトでの確認が必要です。
Snyk（Snyk Limited）
Snykは、開発者が書いたそばから脆弱性を見つけて直すことを主眼にした、開発者起点のセキュリティプラットフォームです。依存ライブラリの脆弱性検査（Snyk Open Source）やソースコードの検査（Snyk Code）を中心に、コンテナ（Snyk Container）やIaC、シークレット検出まで単一のプラットフォームで扱います。
IDEやCLI、GitHubなどのソースコード管理、CI/CDに組み込んで実行でき、プルリクエストの段階で脆弱性を検出して修正を提案する点が特徴です。
無料のFreeプラン（個人・小規模向け）から始められ、10名までのチーム向けTeamプランは25ドル/月から、全社導入向けのEnterpriseは要問い合わせです（2026年10月時点）。コンテナ単体にとどまらず、アプリケーション開発の工程全体に脆弱性検査を組み込みたいチームに向きます。
まとめ
Dockerの脆弱性診断は、まずTrivyのようなOSSツールで手元のイメージをスキャンし、CVEと重大度を確認するところから始められます。出てきた結果はCRITICAL・HIGHで修正版のあるものから対処し、原因の層に応じてベースイメージの更新やライブラリのバージョン固定で手当てします。GitHub ActionsやGitLab CIに組み込めば、この確認を自動で回し続けられます。
一方で、スキャン結果には誤検知や文脈依存のものが混じるため、「本当に危険なものはどれか」を見極める視点も欠かせません。自力のスキャンでは届きにくい、本番前の正式な評価やコンテナ・基盤まで踏み込んだ検証が必要な場面では、脆弱性診断サービスを使い分けると無理なくカバー範囲を広げられます。自社の状況に合う方法を組み合わせて、継続的に脆弱性を管理していきましょう。
一括ダウンロードする
よくある質問（FAQ）
Q. Dockerの脆弱性診断とは何ですか？
Dockerの脆弱性診断とは、Dockerイメージに含まれるOSパッケージやライブラリに既知の脆弱性（CVE）が残っていないかを検査することです。TrivyなどのOSSツールを使えばコマンド1つで数分で実行でき、検出された脆弱性を重大度つきで一覧できます。まず手元のイメージを一度スキャンし、結果を見て優先順位をつけて直す、という流れが基本です。
Q. Dockerの脆弱性診断は無料でできますか？
Dockerイメージの脆弱性スキャンは、Trivy・Grype・DockleなどのOSSツールやDocker公式のdocker scoutを使えば無料で始められます。手元のイメージに対してコマンドを実行するだけで、費用はかかりません。一方、専門家が調べて報告書を納める受託診断や、組織全体で継続的に検査・保護するSaaS型のサービスは有料になります。
Q. docker scanコマンドはまだ使えますか？
docker scanコマンドは2023年にサポートが終了しており、現在は使えません。Docker公式の後継はdocker scoutコマンドで、docker scout quickviewでイメージの脆弱性サマリを、docker scout cvesでCVEの一覧を確認できます。Docker公式以外では、TrivyやGrypeといったOSSツールを使う方法もあります。
Q. TrivyとGrypeはどちらを使うべきですか？
最初の一本としては、導入が手軽で検出対象が広いTrivyが選びやすいです。TrivyはCVEに加えて設定不備やシークレットも検査でき、まず手を動かしたいときに向きます。GrypeはSBOM生成ツールSyftと組み合わせた運用に向くため、SBOMを軸に脆弱性を管理したい場合の候補になります。どちらも無料で高速に使えます。
Q. DockleとTrivyは何が違いますか？
Trivyはパッケージの脆弱性（CVE）を照合するツール、Dockleはイメージの設定やベストプラクティスを監査するツールで、見ている対象が異なります。DockleはCIS Docker Benchmarkに沿って設定の良し悪しを調べるため、CVEスキャンのTrivyと役割が重なりません。目的が違うので、両方を組み合わせて使うのが実務的です。
Q. Nessusでコンテナイメージの脆弱性を診断できますか？
Nessusはネットワークやホストを対象とする脆弱性診断ツールで、Dockerイメージ内のCVEスキャンとは領域が異なります。コンテナイメージに含まれる脆弱性を調べたい場合は、TrivyのようなイメージのCVEスキャナを使うのが基本です。ツール名が近い文脈で挙がるため混同しやすいので、目的に合わせて使い分けてください。
Q. 脆弱性が大量に検出されたら、どこから対処すればよいですか？
重大度がCRITICAL・HIGHで、かつ修正版（Fixed Version）が提供されているものから対処するのが基本です。そのうえで、インターネットに公開しているコンテナなど攻撃を受けやすい面にあるものを優先します。検出されたすべてを一度に直す必要はなく、影響の大きいものから順に絞り込んでいくと現実的に進められます。
Q. CI/CDでのスキャンだけで十分ですか？
CI/CDでのスキャンだけでは不十分で、本番で稼働中のイメージも定期的に再スキャンする運用が必要です。脆弱性情報は日々更新されるため、公開時に問題がなかったイメージでも後から新しい脆弱性が見つかります。週に一度など定期的な再スキャンや、レジストリ側の継続スキャンと組み合わせると取りこぼしを防げます。
Q. Dockerの脆弱性を放置するとどうなりますか？
既知の脆弱性を放置すると、リモートからの不正なコード実行や情報漏えい、サービス停止などの被害につながる恐れがあります。インターネットに公開しているコンテナほど狙われやすく、侵入の足がかりにされるリスクも高まります。ビジネスの信用にも関わるため、危険度の高いものから早めに手当てすることが大切です。
Q. 自力でのスキャンと脆弱性診断サービスは、どう使い分ければよいですか？
日常的な脆弱性の確認はTrivyなどの自力スキャンで回し、自力では届かない範囲を脆弱性診断サービスで補うのが現実的です。本番公開前の第三者評価や、コンテナからの脱出・基盤の設定不備まで踏み込んだ検証、監査向けの正式な報告書が必要な場面では受託型の診断を、組織全体で継続的に検査・保護したい場合はSaaS型のサービスを検討するとよいでしょう。
脆弱性診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、掲載中の脆弱性診断サービスの資料を無料で一括請求できます。コンテナ・Webアプリの診断範囲や、継続的なスキャンから受託診断までの対応内容を比べ、自社に合うサービスを無理なく見つけられます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
