Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
コンテナイメージスキャンを実行すると、1つのイメージから数百〜数千件の脆弱性が検出されることは珍しくありません。問題は、件数の多さそのものではありません。その多くが「イメージ内には存在するが、実際には使われていない」「修正版が存在せず、すぐには対応できない」といった指摘で埋まり、本当に危険な数件が見えにくくなることです。
さらに、CIを通過した時点ではクリーンだったイメージが、レジストリで保管されている間に新たに公開されたCVEの影響を受けることもあります。つまり、コンテナイメージスキャンは「ビルド時に一度実行すれば終わり」ではなく、レジストリ、デプロイ、ランタイムまで含めて継続的に運用する必要があります。
本記事では、コンテナイメージのビルドパイプラインを運用するSRE・プラットフォームエンジニア、および脆弱性対応の優先度設計に悩むセキュリティ担当者を主な読者として、コンテナイメージスキャンの実装と運用設計を体系的に整理します。
スキャンの仕組み、OSパッケージ層とアプリケーション依存層の違い、Trivy／Grypeなどのツール、ベースイメージ戦略、レジストリ継続スキャン、Admission Controlでの起動制御、そして「全部直さない」ためのIn-Use判定による優先度設計までを解説します。
1. コンテナイメージスキャンとは何か — 「何が入っているか」を脆弱性と突き合わせる
コンテナイメージスキャンとは、ビルドされたコンテナイメージに含まれるパッケージやライブラリを抽出し、既知脆弱性データベースと突き合わせることで、該当するCVEを検出する仕組みです。
コンテナイメージは、ベースイメージの上にアプリケーションの実行環境、依存ライブラリ、アプリケーションコードを重ねたレイヤ構造を持ちます。スキャナはこの各レイヤを解析し、イメージに含まれるコンポーネントを特定したうえで、NVD、OSV、各Linuxディストリビューションのセキュリティアドバイザリなどと照合します。
1-1. イメージの層構造とスキャン対象
イメージスキャンの対象は、大きく次の2層に分かれます。
この2つのレイヤーを両方確認できる点が、コンテナイメージスキャンの重要な役割です。
SCAは主にアプリケーション依存関係を解析しますが、最終成果物であるコンテナイメージには、ベースイメージ由来のOSパッケージも含まれます。opensslやglibcなどの低レイヤの脆弱性は、アプリケーションの依存マニフェストだけを見ていても検出できない場合があります。
そのため、ソースコードや依存マニフェストの検査に加えて、最終的にデプロイされるコンテナイメージそのものをスキャンすることが重要です。
1-2. SBOM・SCAとの違いと役割分担
イメージスキャンは、SBOMやSCAと密接に関係しますが、それぞれ目的が異なります。
これらは競合するものではなく、連携して使うものです。
SBOMは「何が入っているか」を構造化された部品表として記録します。SCAは主にアプリケーション依存関係を起点に脆弱性やライセンスリスクを検出します。一方、イメージスキャンは最終成果物としてのコンテナイメージ全体を対象に、OSパッケージ層とアプリケーション依存層をまとめて確認します。
SBOMの生成方法やフォーマット、VEXを使った優先度設計については、関連記事「SBOMとは？SolarWinds以降のサプライチェーン攻撃にどう備えるか」で詳しく扱います。本記事では、イメージスキャンそのものの実装と運用に焦点を当てます。
1-3. シフトレフトの中での位置づけ
イメージスキャンは、シフトレフトにおける「ビルド」ステージの中核的な施策です。
コミットやPRの段階では、主にソースコード、依存マニフェスト、IaC、シークレットなどを検査します。一方、イメージスキャンは、実際にデプロイされるコンテナイメージが生成された後に、その成果物を対象として検査します。
つまり、イメージスキャンは「コード上は問題なさそうに見えても、最終成果物に危険なパッケージが含まれていないか」を確認する最後のビルド時チェックです。
CI/CD全体におけるシフトレフトの考え方は、関連記事「シフトレフト（Shift Left）とは？コンテナセキュリティをCI/CDに組み込む実践ガイド」で扱っています。本記事では、その中でもコンテナイメージスキャンに焦点を絞って解説します。
2. イメージスキャンの仕組み
イメージスキャンは、単にCVE番号を一覧化するだけの仕組みではありません。パッケージの抽出、脆弱性データベースとの照合、重大度判定、修正バージョンの有無の確認といった複数の処理を組み合わせて、スキャン結果を生成します。
2-1. パッケージインベントリと脆弱性データベースの突合
一般的なスキャナは、概ね次の流れで動作します。
- イメージの各レイヤを展開する
- インストール済みパッケージの名前、バージョン、アーキテクチャを抽出する
- NVD、OSV、ディストリビューションのセキュリティアドバイザリと照合する
- 該当するCVE、重大度、修正バージョンの有無を付与する
- 結果をCI/CD、レジストリ、ダッシュボードなどに出力する
たとえば、TrivyでHigh／Criticalのみを対象にし、修正版が存在しない脆弱性を除外する場合は、次のように実行できます。
trivy image --severity HIGH,CRITICAL --ignore-unfixed registry.example.com/api:v1.4.2
--ignore-unfixed は、修正版が特定されていない脆弱性を除外するオプションです。開発チームがすぐに対応できない指摘を大量にチケット化すると、ノイズが増え、重要な脆弱性への対応が遅れます。そのため、実務では「修正版があるHigh／Criticalを優先する」設計が現実的です。
2-2. ディストリビューション別の脆弱性評価の差
イメージスキャンで注意すべき点の1つが、同じCVEでもディストリビューションによって深刻度評価が異なることです。
Debian、Ubuntu、Alpine、Red Hatなどは、それぞれ独自にパッチをバックポートしたり、影響範囲を評価したりします。そのため、NVDではCriticalとされているCVEでも、ディストリビューション側では「該当コードが無効化されている」「バックポート済みで影響しない」と判断されるケースがあります。
このため、スキャナを評価するときは、NVDのスコアだけでなく、各ディストリビューションのアドバイザリを適切に参照できるかを確認することが重要です。NVDの評価だけを機械的に使うと、実際のリスクよりも過大に検出され、対応優先度を誤る可能性があります。
2-3. レイヤキャッシュとスキャン高速化
CIで毎回フルスキャンを実行すると、ビルド時間が長くなり、開発体験を損なうことがあります。特に大規模なイメージや多数のマイクロサービスを扱う環境では、スキャン時間の最適化も運用上の重要な論点です。
多くのスキャナやCI設計では、レイヤ単位のキャッシュを活用することで、変更のないベースレイヤの再処理を抑えられます。また、ベースイメージのスキャンとアプリケーションレイヤのスキャンを分離し、頻繁に変更される部分を重点的に確認する設計も有効です。
ただし、高速化のためにスキャン範囲を狭めすぎると、重要な脆弱性を見落とす可能性があります。速度と網羅性のバランスを取りながら、CIでの即時検査とレジストリでの継続スキャンを組み合わせることが重要です。
3. 依存パッケージ管理とベースイメージ戦略
脆弱性対応は、見つけてから直すよりも、最初から脆弱性の母数を減らす方が効率的です。特にコンテナでは、ベースイメージの選定と最終イメージの最小化が、スキャン結果の件数と運用負荷に大きく影響します。
3-1. ベースイメージの選定
検出される脆弱性の多くは、アプリケーションコードではなく、ベースイメージ由来のOSパッケージに含まれます。そのため、ベースイメージ戦略はイメージスキャン運用の出発点です。
代表的な対策は次のとおりです。
ただし、最小イメージを選べば常に安全というわけではありません。たとえばAlpineは軽量ですが、musl libcとの互換性や運用上のデバッグ性を考慮する必要があります。distrolessも攻撃面を減らせる一方で、障害調査やシェルベースのデバッグが難しくなります。
重要なのは、「軽量だから採用する」のではなく、実行環境、運用体制、デバッグ方法、パッチ適用方針まで含めてベースイメージを標準化することです。
3-2. 多段ビルドでビルド専用ツールを最終イメージに残さない
マルチステージビルドは、ビルドに必要なコンパイラやツールを最終イメージに残さないための有効な手法です。
ビルド用ステージでコンパイルを行い、最終ステージには実行に必要な成果物だけをコピーします。
# ビルドステージ
FROM golang:1.22 AS build
WORKDIR /src
COPY . .
RUN go build -o /app ./cmd/api
# 実行ステージ
FROM gcr.io/distroless/static-debian12
COPY --from=build /app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]この構成により、コンパイラ、ビルドツール、パッケージマネージャなどを本番イメージに含めずに済みます。結果として、攻撃面と脆弱性の検出件数を構造的に削減できます。
3-3. 依存の継続更新と固定のバランス
依存パッケージは、固定しすぎると脆弱性修正が取り込まれず、自動更新しすぎると破壊的変更によってビルドやテストが壊れます。
このバランスを取るために、DependabotやRenovateなどの自動更新ツールを活用します。更新PRを継続的に生成し、CIテストを通じて安全性を確認することで、脆弱性修正を運用に組み込みやすくなります。
なお、依存マニフェストに基づく継続監視、OSV連携、新規CVE発生時のトリアージは、SBOMやSCAの領域とも重なります。本記事では、最終成果物であるコンテナイメージのスキャン運用に焦点を当てます。
4. CI/CDとレジストリでのスキャン運用
イメージスキャンは、実行する場所によって役割が変わります。CIでのビルド時スキャンは「入口の検査」、レジストリでの継続スキャンは「在庫の棚卸し」、Admission Controlは「起動時のゲート」として機能します。
4-1. ビルド時スキャンとPRゲート
最初の検査点は、イメージビルド直後のCIです。
ただし、すべての脆弱性でビルドを失敗させる設計は現実的ではありません。既存の負債が多い環境では、全件ブロックにすると開発が止まり、ゲートそのものが迂回される可能性があります。
実務では、次のような段階導入が有効です。
- まずは警告として可視化する
- 修正版があるHigh／Criticalのみをブロックする
- 対象リポジトリや重要サービスから強制範囲を広げる
- 例外申請と期限管理を運用に組み込む
GitHub ActionsでTrivyを使う場合の例は次のとおりです。
- name: Build image
run: docker build -t $IMAGE .
- name: Scan image
uses: aquasecurity/trivy-action@master
with:
image-ref: ${{ env.IMAGE }}
severity: HIGH,CRITICAL
ignore-unfixed: true
exit-code: '1'ここでは、修正版が存在するHigh／Criticalを検出した場合にビルドを失敗させます。重要なのは、スキャンを導入すること自体ではなく、「どの条件で止めるか」を明確にすることです。
4-2. レジストリの継続スキャン
ビルド時点でクリーンだったイメージが、数日後も安全であるとは限りません。新しいCVEが公開されれば、すでにレジストリに保管されているイメージが新たに脆弱と判定される可能性があります。
そのため、レジストリ内のイメージを定期的に再スキャンし、保管中のイメージに新たな脆弱性が紐づいていないかを確認する必要があります。
ビルド時スキャンが「入口の検査」だとすれば、レジストリ継続スキャンは「在庫の棚卸し」です。特に、次のような観点で継続スキャンを設計すると効果的です。
レジストリスキャンは、単にイメージを保管する仕組みではなく、継続的なリスク管理の一部として位置づける必要があります。
4-3. Admission Controlでデプロイをゲートする
Kubernetes環境では、Admission Controlを使って、クラスタに投入されるリソースを起動前に検査できます。
たとえば、次のような条件を満たさないイメージを拒否する設計が考えられます。
- スキャン未通過のイメージ
- 修正版があるCritical脆弱性を含むイメージ
- 許可されていないレジストリ由来のイメージ
- 署名されていないイメージ
- latestタグを使っているイメージ
なお、署名検証は厳密にはイメージスキャンそのものではありませんが、イメージの出自と改ざん有無を確認するサプライチェーン対策として、Admission段階でスキャン結果と組み合わせる価値があります。
KyvernoやGatekeeperなどのPolicy as Codeと組み合わせれば、「許可レジストリ由来かつ署名済みのイメージのみ起動可」といったポリシーを強制できます。
ただし、Admissionでの拒否は本番デプロイを直接止めます。いきなり強制モードにするのではなく、まずは監査モードで影響を観測し、既存ワークロードへの影響を把握してから段階的にブロックへ移行することが安全です。
5. 「全部直さない」優先度設計 — スキャン結果のノイズ問題
イメージスキャンの最大の課題は、検出件数の多さです。数百〜数千件の脆弱性をそのまま開発チームに渡しても、実効性のある対応にはつながりません。
重要なのは、検出結果を増やすことではなく、「今、本当に直すべきもの」へ絞り込むことです。
5-1. なぜ数百〜数千件の脆弱性が出るのか
イメージスキャンで大量の脆弱性が検出される背景には、構造的な理由があります。ベースイメージには、アプリケーションが直接使っていないOSパッケージやライブラリが含まれていることがあります。それらにもCVEが紐づくため、「イメージ内には存在するが、実際には呼ばれていない」脆弱性が大量に計上されます。
また、修正版が存在しない脆弱性、ディストリビューション側では影響なしと判断されている脆弱性、実行経路に乗らない脆弱性も混在します。これらをすべて同じ優先度で扱うと、開発チームはアラート疲れを起こし、本当に危険な脆弱性への対応が遅れます。
5-2. In-Use判定で実行中のリスクを優先する
ノイズを減らすうえで有効なのが、In-Use判定です。In-Use判定とは、イメージ内に存在するパッケージのうち、本番ランタイムで実際にロード／実行されているものを識別し、優先度付けに反映する考え方です。イメージ内に存在するだけで一度も呼ばれていないライブラリは優先度を下げ、実際に実行されているライブラリの脆弱性を優先します。これにより、数百〜数千件の検出結果を、実運用で対応可能な件数へ絞り込めます。
この判定は、静的なマニフェストやSBOMだけでは正確に行えません。どのコードパスが通り、どの共有ライブラリがメモリにロードされたかは、実際にコンテナを動かしてみなければ分からないためです。そのため、In-Use判定には、ランタイムでの実行状態を観測する仕組みが必要です。Linuxカーネルのシステムコール監視や、実行中コンテナから得られるランタイム情報と、ビルド時のスキャン結果を組み合わせることで、実害につながりやすい脆弱性を優先できます。
5-3. 優先度設計とSLA
In-Use判定で絞り込んだ脆弱性には、「いつまでに、誰が、どの基準で対応するか」を割り当てる必要があります。
たとえば、次のような優先度設計が考えられます。
重要なのは、CVSSだけで判断しないことです。重大度、修正版の有無、稼働環境、本番利用の有無、In-Useかどうかを組み合わせることで、実際のリスクに近い優先度設計が可能になります。
RACIやSLAの具体的な運用設計は、関連記事「DevSecOpsとコンテナセキュリティーーSREが知っておくべき運用設計の考え方」で扱います。また、アラート疲れを防ぐ優先度フィルタリングの実務は、「SREのアラート疲れを終わらせる：Critical脆弱性50件から本当に直すべきリスクを特定する方法」で詳しく解説します。
6. Sysdig Secureのイメージスキャン
ここまで見てきたように、イメージスキャンを実効性のある運用にするには、CI/CD、レジストリ、Admission Control、ランタイム情報を分断せずに扱うことが重要です。
Sysdig Secureは、この一連の流れを同一プラットフォーム上で連携させ、ビルド時の検査からランタイムでの優先度付けまでをつなげて管理できます。
6-1. CI/CD・レジストリ・ランタイムを貫くスキャン
Sysdig Secureでは、sysdig-cli-scannerを使ったCI/CDでのビルド時スキャン、レジストリ内イメージの継続スキャン、本番ランタイムでの実行状態の観測を組み合わせて運用できます。GitHub Actions、Jenkins、GitLab CIなどのCI/CD環境と連携し、OSパッケージ層とアプリケーション依存層の両方を対象にスキャンできます。これにより、次の3つの検査を一連の流れとして扱えます。
単発のスキャンではなく、入口、在庫、実行状態をつなげて見ることで、検出結果を運用判断に結びつけやすくなります。
6-2. Runtime Insightsによる優先度付け
Sysdig Secureの特徴は、ビルド時のスキャン結果とランタイムの実行情報を統合し、In-Useの観点で脆弱性を優先度付けできる点です。本番で実際にロード／実行されているパッケージの脆弱性を優先することで、数百〜数千件の検出結果を、実際に対応すべきリスクへ絞り込めます。
これにより、開発チームは「すべてのHigh／Criticalを一律に直す」のではなく、「本番で使われ、攻撃経路になり得る脆弱性」から対応できます。In-Use判定の具体的な仕組みやRuntime Insightsの考え方は、関連記事「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」で詳しく扱います。
6-3. Admission Controlと修正支援
Sysdig Secureは、Kubernetes Admission Controlとも連携し、スキャン未通過のイメージ、重大な脆弱性を含むイメージ、署名されていないイメージなどをポリシーに基づいて制御できます。また、Sysdig Sage™を活用することで、検出された脆弱性に対して、優先順位の根拠や修正方針を確認できます。たとえば、ベースイメージの更新、パッケージの更新、影響範囲の確認など、対応の初動を整理しやすくなります。
イメージスキャンは、検出だけでは不十分です。何を優先し、どのように直すかまでつなげることで、脆弱性管理を実際の運用に落とし込めます。
7. まとめ — 「絞り込み」と「継続」でイメージスキャンを機能させる
コンテナイメージスキャンは、ビルド成果物に含まれるOSパッケージ層とアプリケーション依存層を解析し、既知脆弱性データベースと突き合わせるBuild段階の重要なセキュリティ施策です。ただし、スキャンを実行するだけでは十分ではありません。数百〜数千件の検出結果をそのまま扱うと、開発チームはアラート疲れを起こし、本当に危険な脆弱性を見落とす可能性があります。
イメージスキャンを実効性のある仕組みにするには、次の3点が重要です。
- ベースイメージ戦略や多段ビルドで、脆弱性の母数を減らす
- CI/CD、レジストリ、Admission Controlで、継続的に検査する
- In-Use判定で、本当に直すべき脆弱性へ絞り込む
入口で検査し、在庫を棚卸しし、実行状態で優先度を付け、起動時にゲートする。この多層構造があって初めて、コンテナイメージスキャンは単なる検出ツールではなく、実際のリスクを下げる運用になります。
導入時には、ツール選定だけでなく、「どの条件でブロックするか」「どの頻度で再スキャンするか」「In-Useをどう優先度に反映するか」を先に設計することが重要です。
次のステップ
自社レジストリを接続し、ビルド時スキャン、レジストリ継続スキャン、In-Use判定による優先度付けを評価してください。具体的な手順は、デモを依頼してご確認ください。
関連記事
シフトレフト・サプライチェーンの全体像から理解する
「全部直さない」優先度づけ・ランタイム連携
- コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み
- SREのアラート疲れを終わらせる：Critical脆弱性50件から本当に直すべきリスクを特定する方法
- AWS／GCP 標準ツールでは守れない？Falco を超える Sysdig Secure によるセキュリティの新常識