Docker や Kubernetes でコンテナを本番運用する現場では、アプリケーション本体だけでなく、コンテナそのものの脆弱性にも目を向ける必要が出てきました。ベースイメージに古いライブラリが残っていたり、Kubernetes の権限設定が緩かったりすると、そこが侵入の入り口になります。
一方で、「コンテナの脆弱性診断」と調べても、無料ツールの使い方、クラウドサービスの機能紹介、専門会社の診断サービスなどが入り混じり、自社で何を・どこで・どうやればよいのかが掴みにくいのが実情です。
本記事では、コンテナの脆弱性診断をイメージ・設定・ランタイムの3つの層に分けて整理し、それぞれで何を見るのか、開発から本番までのどこで診断するのかを解説します。あわせて、無料のオープンソースツールで始める方法と、商用プラットフォームや専門の診断サービスをどう使い分けるかまでをまとめました。自社の診断の進め方を決めるための材料としてご活用ください。
目次
一括ダウンロードする
コンテナの脆弱性診断とは？──イメージ・設定・ランタイムの3層を一目で
コンテナの脆弱性診断とは、コンテナイメージに含まれる既知の脆弱性、実行環境やオーケストレーターの設定ミス、稼働中コンテナの挙動という複数の層を検査し、本番環境で悪用され得る弱点を事前に洗い出す取り組みです。まずは全体像として、診断が対象にする3つの層を押さえます。
普通のWebアプリ診断と何が違うのか
Webアプリケーションの脆弱性診断が、動いているアプリに対して外部から攻撃を試すのに対し、コンテナの脆弱性診断の中心はイメージの静的解析です。イメージの中に入っているソフトウェアを一覧化し、既知の脆弱性情報と突き合わせて、どの部品に問題があるかを特定します。
GitLab のコンテナスキャンの公式ドキュメントは、この仕組みを「コンテナ内の脆弱性の静的解析（static analysis）」と表現し、ベースイメージや OS のパッケージに脆弱性があれば検出すると説明しています。アプリを動かさなくても、イメージを読むだけで一定の弱点が分かる点が、Webアプリ診断との大きな違いです。
出典・参考資料（1件）
診断する3つの層（イメージ・設定・ランタイム）
コンテナの診断は、対象とするものによって大きく3つの層に分かれます。それぞれ見るものも、使うツールも異なります。
- イメージの層：コンテナイメージに含まれる OS パッケージや言語ライブラリに、既知の脆弱性（CVE）が無いかを調べます。
- 設定・オーケストレーターの層：Docker や Kubernetes の設定に、特権コンテナや過剰な権限、認証の不備といった危険な設定が無いかを調べます。
- ランタイムの層：稼働中のコンテナが、本来しないはずの不審な挙動をしていないかを監視します。
この層の分け方は特定の製品の独自用語ではありません。オープンソースの Trivy、GitLab や Microsoft の公式ドキュメント、専門診断会社のサービス説明が、いずれもイメージ・設定・稼働中という切り口で診断を説明しています。どの層まで診断したいかを決めることが、ツールやサービスを選ぶ出発点になります。
層ごとに「何を見るのか」──診断観点を具体的に
ここからは、3つの層それぞれで実際に何を検査するのかを具体的に見ていきます。イメージだけを診断して安心してしまうと、設定や稼働中に残る弱点を見落とすため、層ごとの観点を把握しておくことが大切です。
イメージの中身（既知の脆弱性）
イメージの層では、コンテナイメージに含まれるソフトウェアを棚卸しし（この部品の一覧は SBOM＝ソフトウェア部品表とも呼ばれます）、既知の脆弱性情報と突き合わせます。
GitLab の公式ドキュメントによると、既定では OS のパッケージ管理（yum・apt・apk など）が扱うパッケージが対象で、言語ごとのライブラリは設定で追加できます。逆に、パッケージ管理を通さずに入れたソフトは検出されない点も明記されています。
ベースイメージは土台として引き継がれるため、古いベースイメージを使い続けると、その上に脆弱性が積み重なります。イメージ診断は、この積み重なった既知の弱点を洗い出す工程だと捉えると分かりやすいです。
出典・参考資料（1件）
実行環境・Kubernetesの設定ミス
設定の層では、イメージそのものではなく、コンテナを動かす環境やオーケストレーターの設定を検査します。設定ミスの観点は、CIS（Center for Internet Security）が公開する設定推奨（Docker 向け・Kubernetes 向けのベンチマークがあります）や OWASP といった業界標準が土台になっており、特定ベンダー独自の基準ではありません。
コンテナ診断を手がける GMO Flatt Security株式会社は、CIS Benchmark や OWASP Top 10 を参考にした診断観点として、次のような項目を公開しています。
- Docker：Docker API への認証を回避したアクセス（脆弱な認証構成）、コンテナイメージに API キーやパスワードなどの機密情報が含まれる不適切なシークレット管理
- Kubernetes：root 権限で動く特権コンテナの悪用、セキュリティコンテキストの設定不備、サービスアカウントへの過剰な権限付与（RBAC の設定不備）、Kubernetes API への認証回避、etcd 内の暗号化されていない機密情報、kubelet の認証認可なしの設定
これらはいずれも、攻撃者がコンテナの外へ侵害を広げたり、権限を奪ったりする足がかりになる設定です。イメージ診断だけでは見つからないため、設定の層として別に検査します。
出典・参考資料（2件）
稼働中コンテナのランタイム
ランタイムの層では、静的なイメージや設定ではなく、実際に動いているコンテナの挙動を監視します。想定していないプロセスの起動や、不審なファイルアクセス・通信といった、実行時にしか現れない動きを捉える層です。
この層を担う代表的なオープンソースが Falco です。Falco はホスト・コンテナ・Kubernetes・クラウド環境にわたる稼働時のセキュリティを提供するツールと説明されており、イメージを静的に調べるスキャナとは役割が異なります。イメージ診断で弱点を減らしても、稼働後の挙動までは分からないため、本番環境まで含めて見たい場合にランタイムの層が必要になります。
出典・参考資料（1件）
どこで・どうやって診断するか──実施ポイントを運用段階で
診断する層が分かったら、次は開発から本番までのどの段階で診断するかを決めます。同じイメージ診断でも、実施する場所によって目的とタイミングが変わります。
開発者の手元とCI/CDビルドで検査する
最も早い段階は、開発者がイメージをビルドする手元です。ここで検査すれば、問題を早く見つけて直せます。次に、CI/CD パイプラインのビルド工程にスキャンを組み込むと、新しいイメージを作るたびに自動で検査が走り、一定の深刻度を超える脆弱性が見つかったらビルドを止めるといった運用ができます。GitLab のように、CI/CD にコンテナスキャンを統合する仕組みを持つ製品もあります。
レジストリの継続スキャンで仕組み化する
一度ビルドして問題がなかったイメージでも、後から新しい脆弱性が公表されることがあります。そのため、レジストリに保管したイメージを定期的に再スキャンする仕組みが重要です。
Microsoft Defender for Cloud の公式ドキュメントは、2種類の評価を分けて説明しています。デプロイ前にレジストリ内のイメージを評価する「レジストリの脆弱性評価」と、Kubernetes で実行中のイメージを評価する「ランタイムの脆弱性評価」です。前者は新しくプッシュされたイメージを数時間以内にスキャンし、後者は実行中のコンテナを定期的に棚卸しします。
Admission Controlでデプロイをゲートする
Kubernetes には、クラスターへデプロイしようとするコンテナを受け入れる前に検査する Admission Control という仕組みがあります。「重大な脆弱性が残るイメージはデプロイを拒否する」「特権コンテナは許可しない」といったルールを設け、基準を満たさないものを本番に入れない門として使えます。
標準の機能だけで細かなルールを作るのは難しいため、実際には Kyverno や OPA Gatekeeper といったポリシーエンジンを組み合わせて、デプロイの可否を判定させる構成が一般的です。
稼働中のランタイムを監視する
デプロイ後も、稼働中のコンテナを監視し続けることで、実行時に現れる不審な挙動を捉えられます。Microsoft Defender for Cloud の実行中コンテナの評価は、クラスターで動いているイメージの脆弱性を定期的に確認するもので、コンテナが動く土台そのものの挙動までは対象外です。実行時の挙動検知までカバーしたい場合は、前述の Falco のようなランタイム向けのツールを併用します。
自前のオープンソースツールでコンテナイメージの診断を始める（Trivy ほか）
イメージの層は、無料のオープンソースツールを使えば自社だけでも始められます。ここでは代表的な Trivy を例に、始め方とできること・できないことを整理します。
イメージ検査を始める最小の流れ
Trivy は、Aqua Security が公開するオープンソースのセキュリティスキャナです。公式リポジトリでは、検査できる対象としてコンテナイメージ・ファイルシステム・Git リポジトリ・仮想マシンイメージ・Kubernetes を挙げています。
検出できるものは、既知の脆弱性（CVE）、設定ミス、機密情報やシークレット、ソフトウェアライセンスなどです。
まずは手元にインストールし、調べたいイメージ名を指定して実行するところから始められます。公式ドキュメントでは、イメージをスキャンする基本の形は次のように示されています。
trivy image python:3.4-alpine実行すると、イメージに含まれるパッケージごとに、検出された脆弱性の ID（CVE 番号）・深刻度・修正済みバージョンの有無が一覧で出力されます。この一覧を見れば、どの部品にどの程度のリスクがあるかを最初に把握できます。
出典・参考資料（1件）
オープンソースのスキャナをCI/CDに組み込む
手元での実行に慣れたら、同じスキャンを CI/CD のビルド工程に組み込み、イメージを作るたびに自動で走る状態にします。
定着のコツは、いきなりすべてを止めないことです。まずは検出結果を記録するだけにとどめ、次に重大なものが出たらビルドを失敗させる、さらに対象の深刻度を広げる、と段階的に厳しくしていくと、開発の手を止めすぎずに運用へ乗せられます。
オープンソースツールでできること・できないこと
Trivy のようなスキャナは、イメージの中身の既知脆弱性や設定ミスを見つけるのは得意ですが、万能ではありません。公式リポジトリが挙げる検出対象には、稼働中コンテナの挙動の監視やアラートの送信は含まれていません。GitLab のドキュメントも、パッケージ管理を通さずに入れたソフトの脆弱性は報告しないと明記しています。
このように、イメージの静的な検査はオープンソースで始められます。一方で、稼働中の挙動監視は Falco のような別のツールが必要で、設定の層や本番環境まで含めた網羅的な診断には、別の手段を組み合わせることになります。この「自前でどこまでできるか」の線引きが、次に述べる使い分けの判断につながります。
検出が大量に出たときの優先順位の付け方──全部直さなくていい
コンテナイメージをスキャンすると、数百件から数千件の脆弱性が一度に出ることも珍しくありません。すべてを直そうとすると手が止まってしまうため、どれから対応するかの判断材料を持っておくことが大切です。
この「件数の多さに手が止まる」状況は、診断を提供する現場でも実際に聞かれる悩みです。
なぜ数百〜数千件も出るのか
イメージには OS のパッケージや言語ライブラリが多数含まれ、その一つひとつに過去の脆弱性情報が紐づきます。古いベースイメージを使っているほど件数は増えます。ただし、検出された脆弱性のすべてが自社の環境で実際に悪用できるわけではありません。だからこそ、件数の多さに圧倒されず、リスクの高いものから絞り込む発想が必要になります。
優先度を決める判断材料（深刻度・実際の悪用・悪用されやすさ）
優先順位を付けるときは、脆弱性ごとの性質を表すいくつかの指標を組み合わせます。代表的なものが、深刻度を表す CVSS、実際に悪用が確認されたかを示す CISA の KEV カタログ、今後悪用される確率を予測する EPSS の3つです。
- CVSS（深刻度）：脆弱性の主要な特性から深刻度を数値スコアにし、low・medium・high・critical といった段階に変換できる指標です。
- CISA KEV（実際の悪用）：実際に悪用が観測された脆弱性をまとめた、米国 CISA が維持する一覧で、対応の優先順位付けの入力として使うものとされています。
- EPSS（悪用されやすさ）：公表された CVE が今後30日以内に実際に悪用される確率を、0〜1の値で予測する機械学習モデルです。
深刻度（CVSS）だけで判断すると、スコアは高いが実際にはほとんど悪用されない脆弱性に手を取られがちです。実際に悪用されているか（KEV）、悪用される確率が高いか（EPSS）を併せて見ることで、本当に急ぐべきものを絞り込めます。修正版が公開されているかどうかも、対応のしやすさを左右する材料になります。
出典・参考資料（3件）
「すぐ直す・様子見・対応不要」に振り分ける
これらの材料をもとに、検出された脆弱性を、すぐ直す・様子を見る・対応不要の3つに振り分けます。たとえば、修正版があって深刻度が高く、KEV カタログにも載っているものは最優先で直し、修正版がまだ無いものや影響の小さいものは様子を見る、といった具合です。
多くのスキャナには、深刻度で絞り込む（重大なものだけ表示する）オプションや、修正版の無い脆弱性を除外するオプションがあります。こうした絞り込みで対応すべき件数をまず減らし、継続的に回す仕組みにすると、毎回ゼロから悩まずに済みます。
さらに踏み込んだ絞り込みとして、実行時に実際に読み込まれているか（In-Use）、外部から到達できる経路にあるか、という2つの観点があります。イメージに含まれていても、実行時に使われないパッケージや、外部から到達できない箇所の脆弱性は、悪用される余地が相対的に小さいためです。
実行中のコンテナで実際にロードされている部品や、外部に露出した経路に絞って評価すると、深刻度だけでは埋もれていた「本当に直すべき少数」が浮かび上がります。こうした In-Use・露出にもとづく絞り込みは商用のプラットフォームが機能として備えることが多く、大量の検出を現実的な対応件数まで減らす有力な手段になります。
オープンソース・商用プラットフォーム・専門診断サービスの使い分け──どこまで自分で、どこから外部に
コンテナの脆弱性診断を実現する手段は、大きく3つに分けられます。自社の体制やカバーしたい範囲に応じて、どこまで自前で行い、どこから外部に任せるかを決めます。
自前のオープンソースツールでどこまでできるか
Trivy や Falco などのオープンソースツールは、無料で導入でき、イメージ検査や稼働中の挙動監視を自社で始められます。費用を抑えてまず着手したい場合や、CI/CD に組み込んで継続的に回したい場合に向いています。ツールの選定・運用・結果の読み解きを自社で担える体制があるかが、選ぶときの分かれ目です。
商用プラットフォームで広くカバーする
イメージ・設定・ランタイムを一つの管理画面で扱える商用プラットフォームもあります。クラウド設定の検査（CSPM）やソースコード・依存ライブラリの検査まで束ねた SaaS 型の製品です。
こうした製品を使えば、複数のオープンソースツールを個別に運用する負担を減らし、検出結果の優先順位付けや修正支援まで一貫して行えます。自社に専任の担当者を置きにくい場合や、層をまたいでまとめて見たい場合の選択肢になります。
ここで出てきた CSPM（クラウドの設定ミスを検査する仕組み）が具体的に何を見るのか、CWPP や CNAPP など名前の似た仕組みとどう違うのかを押さえたい場合は、次の記事で整理しています。
専門の受託診断で設定層・本番の網羅を補う
設定ミスの検査や本番環境を含む網羅的な診断を、専門のエンジニアに任せたい場合は、受託型の脆弱性診断サービスがあります。Docker・Kubernetes の設定を業界標準に照らして診断してくれるため、自前のツールでは判断が難しい設定の層を補えます。
ツールによる自動スキャンと専門家による診断は排他ではなく、日常は自前のツールで回し、重要なリリースや本番前に専門診断を入れるといった組み合わせも現実的です。
一括ダウンロードする
コンテナの脆弱性診断を支援するサービス・ツールの選択肢
ここまで整理した使い分けを踏まえ、コンテナの脆弱性診断に役立つサービスを紹介します。イメージ・クラウド設定・ランタイムまで幅広く扱う診断 SaaS と、専門エンジニアによる受託診断を取り上げます。
コンテナに限らず、脆弱性診断サービス全般を診断方法・費用相場・選び方から比べたい場合は、次の比較記事に主要なサービスがまとまっています。全体像を見てから、自社に合う診断の手段を絞り込みたい方の出発点になります。
| サービス名 | Aikido Security | GMO Flatt Security 脆弱性診断 |
|---|---|---|
| 提供形態 | 診断SaaS （自動スキャン） | 受託診断 （専門エンジニア） |
| イメージの既知脆弱性 | ● | △イメージ内シークレット等の確認が中心 |
| Docker・Kubernetesの設定ミス | ● | ◎CIS・OWASP準拠の専門診断 |
| 稼働中のランタイム監視 | ●（Runtime Protection） | ×一時点の受託診断 |
| クラウド設定（CSPM） | ●（AWS・Azure・GCP） | △別途クラウド診断メニュー |
| ソースコード・依存ライブラリ | ●（SAST・SCA） | ●別メニューのソースコード診断に対応 |
| CI/CDパイプライン連携 | ● | ×都度の受託診断 |
| 料金 | 月額制サブスクリプション （年額3,780ドル〜） | 脆弱性診断100万円〜（税別） コンテナ診断は要見積り |
| 詳細情報 | 公式資料を見る | サービス詳細を見る |
※受託診断の「×」は、一時点の診断という性質上カバーしない項目を示すもので、サービスの優劣を表すものではありません。継続的な監視や CI/CD への常駐は、自動スキャン型のツールや SaaS が担います。
Aikido Security（株式会社AndGo）
ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリを、1つの管理画面でまとめて検査できる脆弱性診断の SaaS です。株式会社AndGo が取り扱い、人が診断してレポートを納品する受託型ではなく、自動スキャンのツールを利用する契約形態になっています。
コンテナの診断では、コンテナイメージの検査（Container Images）に加えて、クラウド設定を検査する CSPM が AWS・Azure・GCP に対応し、稼働中を見る Runtime Protection も備えます。本記事で整理したイメージ・設定・ランタイムの3層に、ソースコードや依存ライブラリの検査まで含めて一つの画面で扱える点が特徴です。
検出結果の自動トリアージで誤検知を減らし、修正のためのプルリクエストを自動で作成する機能も案内されています。
GMO Flatt Security 脆弱性診断（GMO Flatt Security株式会社）
GMO Flatt Security株式会社は、専門のセキュリティエンジニアによる受託型の脆弱性診断を提供しています。Webアプリケーションや API に加え、コンテナ（Docker・Kubernetes）を対象とする個別の診断メニューを用意している点が、自動ツールとの違いです。
コンテナ診断では、CIS Benchmark や OWASP Top 10 を参考にした観点で、Docker API の認証不備やイメージ内のシークレット、Kubernetes の特権コンテナ・RBAC・kubelet の設定不備などを検査します。自前のツールでは判断が難しい設定の層や、本番前の網羅的な確認を専門家に任せたい場合の選択肢です。
脆弱性診断の料金は100万円からで、コンテナ診断の費用は内容に応じた見積りとなります。
まとめ
コンテナの脆弱性診断は、イメージの既知脆弱性・実行環境やKubernetesの設定ミス・稼働中の挙動という3つの層に分けて考えると、何を調べればよいかが見えてきます。イメージの層は Trivy などのオープンソースツールを CI/CD に組み込めば自社でも始められ、設定の層や本番全体の網羅には、商用プラットフォームや専門の診断サービスを組み合わせて補います。
検出が大量に出ても、深刻度・実際の悪用・悪用されやすさといった材料で優先順位を付ければ、すべてを一度に直す必要はありません。まずは自前のツールで始め、カバーしきれない範囲を外部の診断で補いながら、継続的に回せる仕組みにしていくことが、現実的な進め方です。
一括ダウンロードする
よくあるご質問（FAQ）
Q. コンテナの脆弱性診断とは何ですか？
A. コンテナの脆弱性診断とは、コンテナイメージに含まれる既知の脆弱性、実行環境やKubernetesの設定ミス、稼働中コンテナの挙動という3つの層を検査し、本番環境で悪用され得る弱点を事前に洗い出す取り組みです。
動いているアプリに外部から攻撃を試すWebアプリケーションの診断と異なり、コンテナ診断の中心はイメージの静的解析です。アプリを動かさなくても、イメージの中身を一覧化して既知の脆弱性情報と突き合わせることで、どの部品に問題があるかを特定できます。
Q. コンテナの脆弱性診断は無料ツールだけで十分ですか？
A. コンテナの脆弱性診断は、イメージの層だけなら Trivy などの無料のオープンソースツールで始められますが、設定ミスやランタイム、本番環境まで含めた網羅的な診断を無料ツールだけで補うのは難しいです。
Trivy の公式リポジトリが挙げる検出対象には、稼働中コンテナの挙動監視やアラートの送信は含まれていません。イメージ検査は自前のオープンソースで回しつつ、設定の層や本番全体は商用プラットフォームや専門の診断サービスで補う、といった使い分けが現実的です。
出典・参考資料（1件）
Q. コンテナの脆弱性診断の費用相場はどのくらいですか？
A. コンテナの脆弱性診断の費用は、自前のオープンソースツールなら無料で始められ、専門エンジニアによる受託型の診断サービスは数十万円以上（たとえば GMO Flatt Security の脆弱性診断は100万円から）が目安です。
無料ツールは導入費用こそかかりませんが、選定・運用・結果の読み解きは自社で担います。受託型のコンテナ診断は対象範囲や内容に応じた見積りとなるため、何をどこまで診断したいかを決めたうえで各社に確認するのが確実です。
Q. Kubernetesの設定ミスはどうやって診断しますか？
A. Kubernetesの設定ミスは、CIS Benchmark や OWASP といった業界標準の設定推奨に照らして、特権コンテナ・RBACの過剰な権限付与・API認証の不備・Secretsの扱いなどを検査します。
これはイメージの中身を調べるイメージ診断とは別の「設定の層」の診断です。設定診断に対応した商用プラットフォームや専門の診断サービスで実施するほか、デプロイ前に Admission Control で基準を満たさない設定を止める運用も有効です。
出典・参考資料（2件）
Q. コンテナの脆弱性診断はどのくらいの頻度で実施すべきですか？
A. コンテナの脆弱性診断は、一度きりではなく、イメージをビルドするたびの検査と、保管中のイメージの定期的な再スキャンを組み合わせて継続的に実施するのが基本です。
問題がなかったイメージでも、後から新しい脆弱性が公表されることがあるためです。CI/CD のビルド工程での自動検査とレジストリの継続スキャンを仕組みとして回します。Microsoft Defender for Cloud は、新しくプッシュされたイメージを数時間以内にスキャンし、実行中のイメージも定期的に確認すると説明しています。
Q. コンテナのイメージ診断とランタイム診断は何が違うのですか？
A. コンテナのイメージ診断はビルドしたイメージの中身（OSパッケージや言語ライブラリ）の既知脆弱性を静的に調べるもので、ランタイム診断は稼働中コンテナの不審な挙動を実行時に監視するものです。
イメージ診断で弱点を減らしても、稼働後に現れる挙動までは分かりません。本番環境まで含めて見たい場合は、Falco のようなランタイム向けのツールを併用します。両者は対象とするものもタイミングも異なる、補完的な診断です。
コンテナの脆弱性診断に役立つサービスの料金・資料を一括チェック
MCB FinTechカタログでは、コンテナのイメージ・設定・ランタイムの診断に役立つ脆弱性診断サービスの最新資料を無料で一括請求できます。対応する診断範囲や料金を比べる材料としてご活用ください。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
