コンテナ脆弱性スキャンは、コンテナイメージの安全性を保つうえで欠かせない取り組みです。
コンテナイメージとは、アプリと実行環境を一つにまとめた設計図のようなものと考えるとわかりやすいかもしれません。コンテナは便利な反面、内部のOSやライブラリに古い部品が紛れ込みやすく、その点検を担うのがこのスキャンといえます。本記事では、スキャンの仕組みと限界、開発から本番までどこで実施するか、ツールの選び方、CI/CD（コードのテストや反映を自動化する仕組み）への組み込み方、検出された大量の脆弱性の優先順位の付け方、そして継続して運用するコツまでをご紹介します。
コンテナ脆弱性スキャンの仕組みと役割
コンテナ脆弱性スキャンは、コンテナイメージの中身を点検し、既知の脆弱性が含まれていないかを自動で照合する作業です。こうした点検が欠かせない背景には、コンテナイメージがOSやライブラリなど多数の部品の集合体で、その中に過去の欠陥が紛れ込みやすいという事情があります。
たとえば古いライブラリを土台にイメージを作ると、その既知の問題をそのまま本番環境へ持ち込みかねません。コンテナは差し替えや増減が容易なため、数が増えるほど人手での点検は追いつきにくくなりがちです。デプロイ前に、自動で点検する仕組みを備えておきたいところです。なお、スキャンはデプロイ前に限らず、ビルド時（CI/CD）やレジストリ、実行中（ランタイム）など、複数の段階で実施できます。
スキャンが見ているのは「既知の脆弱性」である
スキャンが照合しているのは、世界共通の脆弱性データベースに登録された「既知」の情報です。その中心となるのがCVE（Common Vulnerabilities and Exposures：共通脆弱性識別子）で、個々の脆弱性に振られる世界共通の識別番号を指します。スキャンツールは、イメージ内の各部品のバージョンをこのCVEや脆弱性データベースの情報と突き合わせ、該当するものに印を付けていきます。代表的なデータベースとしては、米国国立標準技術研究所が運用するNVDが挙げられ、CVEごとの詳細や深刻度の評価を参照できます（※1，※2）。
ただし、コンテナスキャンが参照するのはNVDだけではありません。実際のスキャナーは、次のような複数のソースを組み合わせています。
- NVD（CVEごとの詳細やCVSSによる深刻度）
- 各Linuxディストリビューションのセキュリティ情報（Red Hat、Debian、Ubuntu、Alpine など）
- OSVやGitHub Advisory Databaseなど、OSS・言語エコシステム向けの脆弱性情報
こうした照合を自動で行う代表的なツールには、Trivy、Grype、Clairなどがあります。
※1：IPA（情報処理推進機構）│「共通脆弱性識別子CVE概説」
※2：NIST│「National Vulnerability Database（NVD）」
コンテナイメージは土台を引き継ぐため脆弱性が積み重なる
コンテナイメージは、他者が作った土台のうえに自分の部品を足して作るのが一般的です。この土台はベースイメージ（親イメージ）と呼ばれ、自作部分に問題がなくても、土台側に古い部品が含まれていれば脆弱性を引き継ぎかねません。さらにイメージは層（レイヤー）を積み重ねる構造のため、層が増えるほど含まれる部品も増え、脆弱性が紛れ込む余地も広がっていきます。そのため、どの層のどの部品に問題があるかを示せるツールほど、原因の特定や修正がしやすい傾向があります。あわせて、土台にするイメージは提供元が明確な公式・検証済みのものを選ぶことが望ましいでしょう。取得時に版を固定し、毎回同じ内容を使うようにすると、不正なイメージの混入や意図しない更新を防ぎやすくなります。
スキャンで見つからないものを理解しておく
スキャンは有効な手段ですが、すべての脅威を見つけられるわけではありません。照合の対象が、あくまで「公開済みの既知の脆弱性」に限られるためです。スキャンの限界は、大きく2種類に分けて理解しておくとよいでしょう。
- 検出されにくいもの：まだ公表されていない未知の脆弱性や、自社で書いた独自コードの欠陥。データベースに載っていないため、検出されにくい傾向があります。
- 誤検知（フォールスポジティブ）：修正がすでに反映済みなのに、古いバージョン番号だけを見て警告してしまうケース。
この誤検知は、コンテナ特有の事情で起こりやすくなります。Linuxディストリビューションは、脆弱性を修正する際に上流のバージョン番号を上げず、修正だけを取り込む「バックポート」を行うことがあります。
上流のバージョン番号だけを見るスキャナーは、これを「修正済みなのに脆弱」と誤判定しがちです。各ディストリビューションのセキュリティ情報まで参照するスキャナーを使うと、こうした誤検知を抑えられます。
開発から本番までどこでスキャンするかを決める
スキャンは一か所で完結させるのではなく、開発から本番までの複数のポイントに置くと効果が見込めます。早い段階で問題を見つけるほど、修正にかかる手間やコストを抑えやすいからです。開発の終盤やリリース後に発覚すると、作り直しや緊急対応で負担が膨らみかねません。この早期に検出する考え方は、セキュリティ対策を開発工程の前段へ寄せる「シフトレフト」と呼ばれています。まずは実施ポイントを把握し、自社の工程に合わせて配置していくとよいでしょう。
実施ポイントごとの目的とタイミング
主な実施ポイントは、開発者の手元、CI/CDパイプラインのビルド時、レジストリ（イメージの保管庫）、ランタイム（実際に動いている状態）の四つです。さらにKubernetesを使う場合は、レジストリとランタイムの間に「デプロイ時のゲート（admission control）」を加えられます。それぞれ目的やタイミングが異なるため、主な違いを次に整理します。
| 実施ポイント | 主な目的 | タイミング | 使うツールのタイプ |
|---|---|---|---|
| 開発者の手元 | 土台や依存関係を作成前に点検する | コーディング・イメージ作成時 | 軽量なコマンドラインのスキャナ |
| CI/CDパイプライン | 危険なイメージを先へ進めない | ビルドのたび | CI/CDに組み込めるスキャナ |
| レジストリ | 保管中のイメージを再点検する | 保管後・定期 | レジストリ連携型のスキャナ |
| ランタイム | 稼働後に新たな脆弱性を監視する | デプロイ後・常時 | ランタイム保護を含むツール |
開発者の手元での点検は、問題の少ない土台を選び直す余地が大きい段階で行える点が利点です。CI/CDパイプラインでの点検は、変更のたびに自動で回せるため、見落としの防止につながります。このとき、スキャン結果が一定の深刻度（CriticalやHighなど）やKEV（実際に悪用が確認された脆弱性）に該当する場合はビルドを止める、というしきい値を決めておくと運用しやすくなります。レジストリやランタイムも加えたいのは、昨日まで安全だったイメージでも、新たな脆弱性の公表によって今日から危険と判定される場合があるためです。ビルド時の一度きりにせず、保管後や稼働後にも点検する設計が現実的だといえるでしょう（※3）。
あわせて、ベースイメージが更新されたら、それに依存するイメージを自動で作り直す仕組みにしておくと、手作業に頼らず最新の状態を保てます。
※3：AWS│「コンテナイメージをスキャンして脆弱性を確認（金融サービス業界レンズ）」
コンテナ脆弱性スキャンツールの選び方
ツールは、機能の多さではなく自社の運用に合うかどうかで選びたいところです。規模や開発体制によって必要な機能は変わり、過剰なツールはかえって運用の負担になりかねません。判断の軸としては、次の五つが挙げられます。
一つ目はCI/CDとの連携のしやすさで、既存の開発の流れに無理なく差し込めるかを左右する要素です。二つ目はイメージのどの層に問題があるかを示せるレイヤー単位の可視性で、原因の特定や修正の速さに関わってきます。三つ目は修正版やより安全な土台イメージを提案してくれるかどうかで、対応の手戻りを抑える助けになります。
四つ目はランタイム保護まで含むかどうかで、稼働後の監視が必要な環境では重みが増す部分です。五つ目は無償か有償か、そして運用規模との相性で、扱うコンテナが増えても破綻しないかを見極めたいポイントになります。これらを基準にすると、必要十分なツールを選ぶ手がかりになります。
タイプ別に特徴を整理する
ツールは大きく分けて、オープンソースのイメージスキャナ型、商用の統合プラットフォーム型、ランタイム保護を含む型に分けられます。タイプで捉えると、自社の規模や体制に照らして選びやすくなります。代表的なのは次の三つです。
| タイプ | 主な対象 | 向いている場面 |
|---|---|---|
| オープンソースのイメージスキャナ | ビルド時のイメージ検査 | まず無償で導入し、CI/CDで自動化したい場合 |
| 商用の統合プラットフォーム | 開発から本番までの一元管理 | 複数環境・大量のコンテナを横断管理したい場合 |
| ランタイム保護を含む型 | 稼働中コンテナの監視・異常検知 | デプロイ後の不審な挙動まで抑えたい場合 |
最初の一歩としては、無償で試せるオープンソースのイメージスキャナから始め、運用に慣れてから統合型やランタイム保護の必要性を見極める進め方が手堅いといえます。小規模なうちは単体のスキャナで足りるケースも多く、コンテナの数や運用の範囲が広がった段階で統合型へ移行する方法もあります。判断に迷ったら、前述の五つの軸に立ち返り、自社の優先度を確かめてみるのも一案です。
代表的なオープンソースのイメージスキャナとしては、TrivyやClair、Grypeなどがあります。なかでもTrivyは導入が比較的容易で、CI/CDへの組み込み事例も多いことから、最初の一歩として検討しやすい選択肢です。Grypeも単体のCLIで扱いやすく、SBOM生成ツールSyftと組み合わせて使えます。
一方、Clairはサーバーとして動かしAPI経由で使うサービス型で、導入にやや手間がかかる分、OSSレジストリのHarborと組み合わせて自前のスキャン基盤を作るのに向きます。
CI/CDパイプラインへの組み込み方
スキャンは、CI/CDに組み込んで自動で回す形が運用の基本といえるでしょう。人手での実行は抜け漏れが起きやすく、リリースのたびに確実に点検するうえでは自動化が向いているためです。具体的には、ビルド工程にスキャンを差し込み、重大な脆弱性が見つかった場合にそこで処理を止める「ゲート」を設ける方法があります。多くのスキャナは、深刻な問題を検出すると異常終了の合図を返すため、それを利用してビルドを失敗させる設定も可能です。変更のたびに自動で止まる仕組みにしておくと、人手での確認に頼らず、見落としを防ぎやすくなります。
ただし、最初から重大な検出をすべて停止対象にすると、現場が回らなくなる場合もあります。停止の対象とする深刻度や、いつまでに直すかの猶予は、チームで合意して明文化しておくと運用が安定しやすくなります。
その際、停止の対象を深刻度（CVSS）だけで決めるのではなく、KEV（実際に悪用された脆弱性）への該当やEPSS（悪用可能性）の高さも加味すると、現場の負担を抑えつつ、本当に危険なものを確実に止められます。具体的な強め方としては、次の段階を目安に進めるとよいでしょう。
段階的な導入の進め方を決めておく
導入は、一度に厳格化せず、段階を踏んで強めていくと無理が出にくくなります。運用の習熟に応じて、次の三段階で基準を強めていく進め方が考えられます。自社のリリース頻度や体制に合わせて調整してみてください。
| 段階 | スキャンの扱い | ねらい |
|---|---|---|
| 導入初期 | 検出しても止めず記録・警告のみ | 現状の脆弱性の量と傾向を把握する |
| 慣れた段階 | 最も深刻な検出だけビルドを止める | 影響の大きい問題から確実に塞ぐ |
| 定着後 | 深刻度と猶予期限で停止範囲を広げる | 全体の水準を計画的に引き上げる |
このように猶予期間を設けて移行すると、開発の速度を保ちながらセキュリティの基準を高める後押しになります。停止の判断をツール任せにせず、誰がいつ例外を承認するかまで決めておくと、現場の混乱を防ぐことにもつながります。
検出結果のトリアージ（優先順位付け）の勘所
検出された脆弱性は数が多く、すべてを同時には直せません。優先順位は、次の順序で見ていくと無理なく決められます。
まず最優先で直すのは、すでに実際の攻撃に使われたことが確認されている脆弱性です。被害の想定にかかわらず、現実に悪用されている以上、放置する時間は短いほど安全だからです。こうした「悪用が確認済みの脆弱性」は、政府機関などがKEVと呼ばれる公開リストとして公開しており、検出結果と照らし合わせて確認できます（※4）。
次に、攻撃の確認がないものは、「悪用されたときの被害の大きさ」と「今後悪用されそうな度合い」の二つを重ねて見ます。被害の大きさを含む深刻度は、CVSSと呼ばれる指標で表されます。CVSSは、攻撃のしやすさ（攻撃元区分や複雑さ）と影響度を組み合わせて数値化したもので、値が大きいほど深刻度が高いことを意味します（※5）。ただし、深刻度が高いことは今すぐ危険を意味するとは限りません。被害が大きく、かつ狙われやすいものから手を付けると、影響の大きいものを効率よくつぶせます。
その「今後悪用されそうな度合い」は、過去の攻撃傾向から悪用の可能性を見積もった数値（EPSSと呼ばれる指標）で表されます（※6）。大半の脆弱性はこの値が低いため、絶対的な基準で線を引くより、検出結果の中で相対的に高いものから対応すると判断しやすくなります。
最後に、本番環境で動いていない、または使っていない機能の脆弱性は、優先度を下げて経過を監視します。同じ深刻度でも、実際に動いていなければ攻撃の現実味は下がるためです。
この優先順位を軸に持っておくと、件数が多くても迷わず判断できます。
※4：CISA│「Known Exploited Vulnerabilities Catalog」
※5：IPA（情報処理推進機構）│「共通脆弱性評価システムCVSS概説」
※6：FIRST│「Exploit Prediction Scoring System (EPSS)」
「すぐ直す・様子見・対応不要」に振り分ける
指標がそろったら、検出結果を三つの区分に振り分けて考えると頭の整理に役立ちます。おおよその判断の目安を次にまとめます。最終的には自社の事情も踏まえて判断するのが望ましいでしょう。
| 振り分け | 目安となる条件 | 対応の方針 |
|---|---|---|
| すぐ直す | 悪用が確認済み、または悪用確率が高い／本番で稼働中 | 速やかに修正版へ更新する |
| 様子見 | 深刻度は高いが悪用の兆候は乏しい／猶予が許容できる | 期限を決めて計画的に対応する |
| 対応不要に近い | 使っていない機能の問題で、悪用の兆候もない | 記録し、状況変化を継続監視する（修正版が出れば適用） |
この振り分けによって、限られた工数を「現実に危険な脆弱性」へ集中させやすくなります。深刻度・悪用状況・自社での利用状況を組み合わせて見る視点が、トリアージの勘所といえそうです。なお、いずれか一つの指標だけで機械的に決めると、危険なものを見落としたり、安全なものに労力を割いたりしがちです。複数の観点を重ねて総合的に判断する姿勢が、過不足のない対応につながると考えられます。
こうした「悪用状況・深刻度・利用状況を組み合わせて対応を決める」考え方は、CISAなども用いるSSVCという枠組みとして体系化されています。
到達可能性を高める
振り分けの精度をさらに上げるうえで、もう一つ加えたい観点が到達可能性です。
到達可能性とは、脆弱性を含む部品が、実際に呼び出される経路上にあるかどうかを指します。たとえ深刻な脆弱性でも、その部品をアプリが一度も使っていなければ、悪用される現実味は下がると考えられます。
スキャンを継続的に運用するための工夫
スキャンは一度で終わらせず、回し続ける前提で組み立てておきたいところです。前述のとおり脆弱性は日々公表されるため、過去に安全と判定したイメージも、後から危険と判定され得るからです。具体的には、保管中のイメージを週次などの頻度で再スキャンし、新たに該当した脆弱性を拾い直す運用が役立ちます。再スキャンの間隔は、扱うサービスの重要度やリリース頻度に応じて決めるとよいでしょう。
あわせて、ベースイメージが更新されたときに依存イメージを自動で再ビルドする仕組みを用意しておくと、定期的な再スキャンと両輪で、最新の状態を保ちやすくなります。
あわせて、誤検知や対応不要と判断した項目は、除外設定などで記録しておくと、毎回の確認に追われずに済みます。ただし除外したまま放置すると、状況が変わったときに見落とす恐れがあるため、定期的に妥当性を見直すことが望まれます。さらに、不要な部品を含まない最小構成のイメージを使えば、抱える脆弱性の数を減らし、攻撃の足がかりを小さく抑える効果も見込めます。
加えて、スキャン結果や稼働中の挙動をログとして残し、定期的に確認する体制も助けになります。この確認は、スキャンのスケジュール実行や、検出時のチャット通知・チケットの自動起票まで組み込むと、属人化しにくくなります。いつ・どの脆弱性が見つかり、どう対応したかを記録しておけば、対応漏れの把握や、監査・社内基準への説明にも活用できます。
あわせて、SBOM（部品表）を保管しておくと、新しい脆弱性が公表されたときに、どのイメージが影響を受けるかを再スキャンせずに突き合わせられます。検出する仕組みと、対応を記録・追跡する仕組みを両輪で整えておくと、無理なく続けていけます。
まとめ：自社で取り組むための3ステップ
コンテナ脆弱性スキャンは、仕組みの理解にとどめず、実施ポイントの設計・ツール選定・トリアージまで通して整えてこそ実務に活きてきます。検出して終わりにせず、危険なものから確実に直す流れを作って初めて、リスクの低減につながるからです。最初の一歩としては、次の三つから着手してみるとよいでしょう。
まず開発から本番のどこでスキャンするかを決め、次に自社の規模に合うツールを一つ選び、最後にKEVやEPSSを使って検出結果に優先順位を付けていきます。いずれも一度で完成させる必要はなく、小さく始めて運用しながら基準を育てていく姿勢が現実的です。この順で取り組めば、過不足のないスキャン運用を無理なく立ち上げていけるでしょう。
