LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

コンテナイメージ脆弱性スキャンとは何か

コンテナイメージ脆弱性スキャンとは、コンテナイメージに含まれるOS（基本ソフト）パッケージや言語ライブラリに存在する既知の脆弱性（CVE）を検出する仕組みを指します。CVE（Common Vulnerabilities and Exposures）は、個別製品の脆弱性を識別するための共通番号で、米国の非営利団体MITRE社が「CVE-西暦-連番」の形式で採番しています^*1。国内ではIPA（情報処理推進機構）とJPCERT/CCが共同運営するJVN（Japan Vulnerability Notes）が、2008年10月からMITRE社公認の情報源としてCVEの割り当てに参加しています^*1。

OSSの脆弱性スキャナーであるTrivy（Aqua Security社が開発）は、コンテナイメージのOSパッケージ脆弱性、複数言語の依存パッケージ、設定ミス、シークレット、SBOM（ソフトウェア部品表）を対象にスキャンできると公式ドキュメントで説明されています^*2。本記事では、こうしたスキャナーを使ってコンテナイメージ層の脆弱性を継続的に検査する仕組みづくりと、その導入を外注する際の要点を整理します。

ベースイメージ由来のCVEと多層イメージの課題

コンテナイメージは、OSのベースレイヤーの上にミドルウェアや言語ランタイム、アプリケーションコードを積み重ねる多層構造で作られます。自社で書いたアプリケーションコードに脆弱性がなくても、ベースイメージに含まれるOSパッケージやライブラリに既知の脆弱性が存在していれば、そのままコンテナ実行環境に持ち込まれます。

NVD（National Vulnerability Database、米国国立標準技術研究所が運営する脆弱性情報データベース）は、CVEに深刻度指標（CVSS）・脆弱性タイプ（CWE）・適用対象（CPE）といったメタデータを付与して公開しています^*3。国内ではJVN iPediaが同様の情報を集約しており、2025年第2四半期（4〜6月）だけで10,365件、2007年4月からの累計で242,898件の脆弱性対策情報が登録されています^*4。この数字はJVN iPedia全体の登録件数であり、コンテナ専用の統計ではありませんが、日々新しい脆弱性が発見・公開され続けている状況を示しています。

ベースイメージは公開時点では最新でも、時間の経過とともに新しいCVEが発見される可能性があります。ビルドした時点では問題が見つからなかったイメージが、数か月後に新しく公表されたCVEの対象になっているケースも起こり得ます。イメージのビルド時だけでなく、レジストリに保管している間も継続してスキャンする発想が必要になる理由です。

OSパッケージ・言語依存・設定ミス・シークレット — 4種類の検査

コンテナイメージ脆弱性スキャンが対象にする検査領域は、大きく4種類に分けられます。それぞれ検出できる問題の性質が異なるため、どれか1つだけでは不十分です。

第一に、OSパッケージの脆弱性検査です。イメージのベースとなるLinuxディストリビューションに含まれるパッケージ（例：openssl、glibc等）に既知のCVEがないかを照合します。第二に、言語依存パッケージの検査です。Trivyの公式ドキュメントでは、Go・Java・Node.js・Python・Ruby・PHPなど複数言語のパッケージマネージャーで管理される依存関係を検査対象にできると説明されています^*2。アプリケーションが利用するライブラリのバージョンに脆弱性が含まれていないかを確認する工程です。

第三に、設定ミス（Misconfiguration）の検査です。Terraform・Kubernetesマニフェスト・CloudFormationなどのInfrastructure as Codeファイルに対して、セキュリティ上望ましくない設定（過度に広い権限設定等）を検出します^*2。第四に、シークレット検出です。イメージやコードにAPIキー・パスワードなどの機密情報が誤って埋め込まれていないかを走査します^*2。これら4種類を組み合わせることで、CVEベースの脆弱性だけでなく設定起因のリスクや情報漏えいの芽も同時に拾える体制になります。

CI・レジストリ・アドミッション制御 — 3つの検査ポイント

スキャンを1回どこかで実行するだけでは、抜け漏れが生まれます。実務では、開発から本番稼働までの流れの中で複数の検査ポイントに組み込む多層防御の考え方が採られます。

1つ目はCI（継続的インテグレーション）パイプラインです。Trivyの公式ドキュメントでは、GitHub Actions・GitLab CI・CircleCIなど複数のCI/CDプラットフォームとの統合方法が用意されていると案内されています^*2。イメージをビルドした直後にスキャンし、重大な脆弱性があればビルドやデプロイを止める運用が可能です。開発の早い段階で問題を検知できる利点があります。

2つ目はコンテナレジストリでのスキャンです。CIを通過した時点で問題がなくても、レジストリに保管されている間に新しいCVEが公表される可能性があります。レジストリ側で定期的に再スキャンする仕組みを持たせることで、保管中のイメージについても最新の脆弱性情報との照合を継続できます。

3つ目はKubernetesのアドミッション制御です。Kubernetesのアドミッションコントローラーは、APIサーバーが受け取ったリクエストについて、認証・認可の後、リソースが永続化される前に介入する仕組みです^*5。読み取り操作には影響しませんが、Podの作成など変更を伴うリクエストに対して機能します^*5。ImagePolicyWebhookのような検証系のコントローラーを使うと、外部Webhookを通じてイメージの検証ポリシーを実装し、条件を満たさないイメージのデプロイをクラスター側で拒否する構成が組めます^*5。CIやレジストリでのチェックをすり抜けたイメージであっても、クラスターへのデプロイ直前でもう一段階の関門を設けられる点が特徴です。

重大度しきい値と.trivyignoreによる運用設計

スキャンを導入すると、当初は想定より多くの検出結果が出るのが一般的です。すべてを即座にゼロにする運用は現実的ではないため、重大度によるしきい値設計が要点になります。

Trivyでは、severityオプションで検出結果を重大度別にフィルタリングできます。たとえばHIGH・CRITICALのみを表示する指定が可能で、脆弱性・設定ミス・シークレット・ライセンスの4つのスキャナーいずれでも利用できると案内されています^*6。ビルドを止める基準をCRITICAL以上に設定し、HIGH以下は記録だけ残して開発チームの判断に委ねる、といった段階的な運用が組みやすくなります。

また、対応が困難な既知の脆弱性を一時的に許容する場合には、.trivyignoreファイルを使う方法があります。プロジェクトルートに配置し、CVE番号を指定して除外する形式のほか、有効期限付きで除外する記法にも対応しています^*6。無期限の除外を積み重ねると形骸化しやすいため、期限を切って定期的に見直す運用ルールとセットで導入することが実務上の要点です。

ノイズ抑制の観点では、修正版が存在しない脆弱性を非表示にするオプションも用意されています^*6。開発チームが「今すぐ対応できるもの」と「ベンダーの修正待ちのもの」を区別して確認できるようにする工夫です。しきい値・除外ルール・表示範囲の3点を組み合わせて、検出結果の一覧を実際に対応可能な量に絞り込む設計が運用の中心になります。

SBOM生成との連携とノイズ抑制

SBOM（Software Bill of Materials、ソフトウェア部品表）とは、ソフトウェアに含まれる構成要素（パッケージ・ライブラリとそのバージョン）を一覧化した文書です。Trivyはコンテナイメージからのスキャンと同じ仕組みでSBOMを生成できると公式ドキュメントに記載されています^*2。脆弱性スキャンとSBOM生成を同じツールチェーンで実施すると、イメージの構成要素の棚卸しと脆弱性の突合を一貫した形で管理しやすくなります。

SBOMを継続的に生成しておくと、新しいCVEが公表されたときに「自社のどのイメージにその構成要素が含まれているか」を検索する起点になります。個別のイメージを都度スキャンし直さなくても、蓄積したSBOMデータと突き合わせることで影響範囲を素早く把握できる体制につながります。

ノイズ抑制の観点からは、スキャン結果を開発チームにそのまま大量に流すと、対応の優先順位がつけられず形骸化するリスクがあります。重大度でのフィルタリング、.trivyignoreでの一時許容、SBOMを使った影響範囲の絞り込みを組み合わせ、「今週対応すべき件数」を可視化できる状態を運用の目標に置くことが実務上の工夫になります。

外注の委託範囲と発注準備で詰めるべき論点

コンテナイメージ脆弱性スキャンの導入を内製で行うには、CI/CDパイプラインの知識、Kubernetesのアドミッション制御の設計知識、脆弱性の重大度を踏まえた運用ルール策定の経験が必要になります。ツールの導入自体は短期間で終えられても、しきい値設計や.trivyignoreの運用ルールを自社の開発体制に合わせて調整する工程には、一定の試行錯誤を伴います。

外注を検討する場合は、委託範囲を次の3段階に分けて整理すると発注準備が進めやすくなります。第一に、Trivy等のスキャナーをCI/CDパイプラインに組み込む導入作業です。第二に、重大度しきい値・.trivyignoreの運用ルール・SBOM生成フローの設計です。第三に、Kubernetesのアドミッション制御との連携や、検出結果を開発チームに還元する運用フローの構築です。どこまでを外部パートナーに委ね、どこから自社の開発チームが引き継ぐのかを事前に線引きしておくことが、発注後の手戻りを防ぐポイントになります。

また、既存のCI/CD環境や利用しているコンテナレジストリ、Kubernetesクラスターの構成によって、組み込み方法や工数は変わります。発注前には、現在の開発パイプライン構成、対象となるイメージの数、既存の脆弱性管理ルールの有無を整理した資料を用意しておくと、パートナー選定や見積もり精度の向上につながります。

まとめ：導入判断の3つの軸

本稿では、コンテナイメージ脆弱性スキャンの仕組みと外注時の要点を整理しました。要点は3つに集約できます。第一に、検査対象はOSパッケージ・言語依存パッケージ・設定ミス・シークレットの4種類に分かれ、いずれか1つでは不十分だという点です。第二に、CI・レジストリ・アドミッション制御という3つの検査ポイントに多層で組み込む設計が実務の中心になる点です。第三に、重大度しきい値・.trivyignore・SBOM連携を組み合わせた運用ルールがないと、検出結果が形骸化しやすい点です。導入を外注する際は、どの工程まで委託するかを事前に線引きしておくことが手戻りを防ぐ鍵になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（独立行政法人情報処理推進機構）「共通脆弱性識別子CVE概説」（https://www.ipa.go.jp/security/vuln/scap/cve.html）
2. *2　出典：Aqua Security「Trivy Documentation」（https://trivy.dev/latest/docs/）
3. *3　出典：NVD（National Vulnerability Database）「General Information」（https://nvd.nist.gov/general）
4. *4　出典：IPA「脆弱性対策情報データベースJVN iPediaの登録状況［2025年第2四半期（4月〜6月）］」（2025年7月16日公表）（https://www.ipa.go.jp/security/reports/vuln/jvn/ipedia2025q2.html）
5. *5　出典：Kubernetes公式ドキュメント「Admission Controllers Reference」（https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/）
6. *6　出典：Aqua Security「Trivy Documentation – Filtering」（https://trivy.dev/latest/docs/configuration/filtering/）

Tweet