脆弱性管理

コンテナイメージスキャンこんてないめーじすきゃん

コンテナDocker脆弱性CVEセキュリティDevSecOps

コンテナイメージスキャンについて教えて

簡単に言うとこんな感じ！

コンテナ（アプリの箱）を「中身チェック」して、古いライブラリや危険なソフトが入っていないか調べる仕組みだよ。出荷前の食品検査みたいなもので、「この箱、大丈夫？」って確かめてから本番環境に持ち込むイメージ！

コンテナイメージスキャンとは

コンテナイメージスキャンとは、Dockerなどのコンテナをビルドしたときのスナップショットファイルである「コンテナイメージ」の中身を分析し、既知の脆弱性（セキュリティ上の欠陥）や不適切な設定が含まれていないかを自動検査する技術です。

コンテナは「アプリとそれを動かすために必要なライブラリ・OS部品をひとまとめにした箱」です。便利な反面、箱の中に古くて危険なライブラリが同梱されていても気づきにくいという問題があります。コンテナイメージスキャンはこれを自動で洗い出し、CVE（Common Vulnerabilities and Exposures：共通脆弱性識別子）のデータベースと照合して「この脆弱性、深刻度はどのくらいか」を評価してくれます。

発注・選定の観点では、「スキャンをいつ実施するか（CI/CDパイプラインのどのタイミングか）」と「どのツールを使うか」が重要な判断軸です。開発の早い段階で問題を発見するほど修正コストが下がるため、シフトレフト（Shift Left）という考え方で「できるだけ左（早い工程）でチェックする」文化が広まっています。

スキャンで何を検出するか

コンテナイメージスキャンが検出できる問題は大きく4種類に分かれます。

検出カテゴリ	具体例	リスク
OSパッケージの脆弱性	CentOS・Ubuntuの古いライブラリ	攻撃者に侵入口を与える
言語ライブラリの脆弱性	古いlog4j・OpenSSL・npm依存など	ゼロデイ攻撃・リモートコード実行
設定ミス	rootで動作・不要なポート開放	権限昇格・横展開リスク
シークレット漏洩	イメージ内にAPIキー・パスワードがハードコード	認証情報の流出

深刻度の分類（CVSS スコア）

脆弱性にはCVSS（Common Vulnerability Scoring System）というスコア（0〜10点）で深刻度が付けられます。

レベル	スコア	対応方針の目安
Critical（緊急）	9.0〜10.0	即時対応必須
High（高）	7.0〜8.9	速やかに対応
Medium（中）	4.0〜6.9	計画的に対応
Low（低）	0.1〜3.9	リスク受容を検討
None	0	対応不要

覚え方

「箱の中身は4点チェック」→「OS・ライブラリ・設定・シークレット」
食品成分表示のように、コンテナも「何が入っているか」を一覧化するイメージで覚えるとよいでしょう。

歴史と背景

2013年 — Docker登場。コンテナ技術が急速に普及し始める
2014〜2015年 — コンテナを本番運用する企業が増え、「箱の中身が危険では？」という問題意識が高まる
2015年 — CoreOS が Clair をOSSとして公開。コンテナイメージスキャンのパイオニア的存在
2017年 — NVD（米国国家脆弱性データベース）との連携が当たり前になる。スキャンツールが商用・OSS問わず乱立
2019年 — Trivy（トリビー、Aqua Security製）がOSSとして登場し、軽量・高速・使いやすさで急速に普及
2020年以降 — GitHub Actions・GitLab CI・AWS ECR・Google Artifact Registryなどがネイティブスキャン機能を内蔵。「スキャンはデフォルト機能」の時代へ
2022年以降 — SBOM（Software Bill of Materials：ソフトウェア部品表）の義務化議論が活発化。米国大統領令を受け、スキャン結果の証跡管理が重視されるようになる

主要ツールとパイプラインでの使われ方

コンテナイメージスキャンは、開発からリリースまでのどのタイミングでも実行できますが、「早ければ早いほどよい」が原則です。

スキャン結果レポートの読み方（実務ポイント）

発注者・IT担当者がスキャンレポートを受け取ったとき、全件対応は現実的ではありません。以下の優先度で判断しましょう。

【優先対応の考え方】

Critical / High  → 原則としてリリースブロック（修正しないとリリース不可）
Medium          → スプリント内対応を計画（次のリリースまでに修正）
Low             → バックログに積んでリスク受容を議論
"修正なし"の脆弱性 → ベンダー対応待ち。WAF等の代替策を検討

【よくある落とし穴】
- 件数が多くても「Critical 0件」なら即時リリースは許容される場合がある
- "修正パッチなし"のものは放置ではなく、リスク受容の記録が必要
- OSベースイメージ（FROM ubuntu:20.04 など）を軽量版に替えるだけで
  件数が激減することが多い（→ distroless / alpine への変更を推奨）

規格・番号	内容
NIST SP 800-190	コンテナセキュリティガイド。イメージスキャンを含むコンテナセキュリティのベストプラクティスを定義
CIS Docker Benchmark	Dockerのセキュリティ設定基準。スキャンツールの設定チェック項目として広く参照される
NIST SP 800-218（SSDF）	セキュアなソフトウェア開発フレームワーク。スキャンをCI/CDへ組み込む根拠となるガイドライン