お疲れさま。今日もコンテナを本番環境にデプロイしたって？ 開発のスピードが上がるのは素晴らしいことだし、DockerやKubernetesのおかげでインフラのポータビリティは劇的に向上した。
でも、セキュリティ責任者（CISO）の私から、デプロイボタンを押す前に一瞬だけ手を止めて考えてほしい質問がある。
「君が今ビルドしたそのコンテナイメージの中身、100%把握できているかい？」
「ベースイメージに ubuntu:latest や node:alpine を使っているから大丈夫」「アプリケーションコードは静的解析（SAST）を通したから問題ない」――もしそう考えているなら、それは攻撃者にとって絶好の「鴨」だ。
今日のテーマは、コンテナハーデニングの最前線である「SBOM（Software Bill of Materials：ソフトウェア部品表）を活用したコンテナイメージの静的解析とCI/CDパイプラインへの統合」だ。
教科書的な話は抜きにして、なぜ今これが必須なのか、攻撃者がどうやってその盲点を突くのか、そしてそれを自動で完封するための実践的なパイプライン構築法を、泥臭い現場のノウハウと共に伝授するよ。
—
1. 攻撃者が狙う「コンテナの闇スペース」とPoCシナリオ
なぜアプリケーションコードの脆弱性対策だけでは不十分なのか。それは、現代のコンテナイメージが「巨大なブラックボックス」だからだ。
君が書いたコードがわずか100行だとしても、ベースイメージやそこに含まれるシステムパッケージ、言語依存の外部ライブラリ（npm、pip、Composer等）を含めると、コンテナ内には数千ものコンポーネントがひしめき合っている。攻撃者は、君が書いたコードのバグを探すよりも、「君が依存しているサードパーティ製ライブラリの既知の脆弱性（1-Day）」を探す方が圧倒的にコスパが良いと知っているんだ。
実際に起こる攻撃シナリオ（サプライチェーン攻撃の裏口）
例えば、君のWebアプリケーションが、ユーザーからアップロードされたPDFのメタデータを解析するために、コンテナ内部でシステムパッケージ（例：古い ImageMagick や libxml2）を呼び出していたとしよう。
1. 偵察フェーズ: 攻撃者はWebアプリケーションの挙動から、バックエンドで特定のライブラリやOSユーティリティが動いていることを推測する。
2. 脆弱性の特定: そのコンテナに含まれる libxml2 に、未修正の脆弱性（例：XXEやヒープバッファオーバーフローによるリモートコード実行 = RCE）が存在することを発見する。
3. エクスプロイト（PoC）の実行:
攻撃者は以下のような、細工されたXMLデータをアプリケーションの入力フォームやアップロード機能に送りつける。
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>アプリケーション側のコードがサニタイズされていたとしても、コンテナ内にインストールされている基礎的な共有ライブラリ（libxml2）自体に脆弱性があれば、パーサーがOSレベルでクラッシュするか、機密ファイルを攻撃者のサーバーに送信（Out-of-Band XXE）してしまう。
さらに最悪なのは、コンテナからKubernetesのサービスアカウントトークン（/var/run/secrets/kubernetes.io/serviceaccount/token）を奪取され、クラスタ全体、さらには紐づくクラウド環境（AWSやGCP）のIAM権限まで掌握される二次災害だ。
「何が入っているかわからない」という状態は、本番環境に爆弾を抱えて稼働させているのと同じなんだ。
—
2. 解決策：SBOMの生成と静的解析の自動化
この闇を照らす唯一の手段が「SBOM（Software Bill of Materials：ソフトウェア部品表）」だ。
SBOMは、コンテナイメージ内に含まれる全てのOSパッケージ、アプリケーション依存ライブラリ、それらのバージョン、そしてライセンス情報を網羅した「成分解析表」だ。フォーマットとしては CycloneDX や SPDX が標準化されている。
これをCI/CDパイプラインに組み込み、ビルドのたびに自動でSBOMを生成し、最新のCVE（共通脆弱性識別子）データベースと照合する。
今回は、業界標準のSBOM生成ツール Syft と、極めて高速かつ高精度な脆弱性スキャナーである Trivy（または Grype）を組み合わせた、GitHub Actionsのセキュアな実装コードを共有する。
—
3. 【コピペで動く】GitHub ActionsによるSBOM生成＆自動スキャンパイプライン
以下は、Dockerイメージをビルドした直後に自動でSBOMを生成し、脆弱性スキャンを実行して、「HIGH（高）」および「CRITICAL（緊急）」の脆弱性が1つでも見つかった場合はデプロイを強制的にブロック（パイプラインを落とす）するための実践的なGitHub Actionsのワークフロー定義だ。
.github/workflows/container-security.yml としてそのままプロジェクトに配置して使ってほしい。
name: Container Security & SBOM Pipeline
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
permissions:
contents: read
security-events: write # GitHubの「Security」タブに結果を出力するために必要
jobs:
build-and-scan:
name: Build, Scan and Generate SBOM
runs-on: ubuntu-latest
steps:
- name: Checkout Repository
uses: actions/checkout@v4
# 1. 安全なDockerイメージのビルド
# (ここではローカルキャッシュを効かせつつ、ダミーのタグ 'myapp:latest' でビルド)
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
- name: Build Local Container Image
uses: docker/build-push-action@v5
with:
context: .
load: true # 後続のスキャンステップで参照できるようにローカルのDockerデーモンにロード
tags: myapp:latest
cache-from: type=gha
cache-to: type=gha,mode=max
# 2. SyftによるSBOMの生成（CycloneDXフォーマットで出力）
# コンテナ内の「全構成物質」を可視化したjsonファイルを生成する
- name: Generate SBOM with Syft
uses: anchore/sbom-action@v0
with:
image: myapp:latest
format: 'cyclonedx-json'
output-file: 'sbom.cyclonedx.json'
# 3. 生成したSBOM（成分表）をアーティファクトとして保存
# 万が一、将来新たなゼロデイ脆弱性が発生した際、過去のイメージを再ビルドせずとも
# このSBOMを検索するだけで影響範囲を特定できる（インシデントレスポンスの超重要Tips）
- name: Archive SBOM Artifact
uses: actions/upload-artifact@v4
with:
name: container-sbom
path: sbom.cyclonedx.json
# 4. Trivyによるコンテナイメージの脆弱性スキャン（開発者向けの早期フィードバック）
# ここでは「LOW」や「MEDIUM」の脆弱性は検出しつつも、パイプラインは落とさない（警告のみ）
- name: Run Trivy Vulnerability Scanner (Informational)
uses: aquasecurity/trivy-action@master
with:
image-ref: 'myapp:latest'
format: 'sarif'
output: 'trivy-results.sarif'
severity: 'UNKNOWN,LOW,MEDIUM'
# 5. GitHub Code Scanningへの結果のアップロード（UI上で脆弱性を一元管理）
- name: Upload Trivy Scan Results to GitHub Security
uses: github/codeql-action/upload-sarif@v3
if: always() # 前のステップが失敗しても実行する
with:
sarif_file: 'trivy-results.sarif'
# 6. 【ゲートキーパー】HIGH & CRITICAL な脆弱性が存在する場合、ビルドを失敗させる
# これにより、危険なコンテナが絶対に本番レジストリにプッシュされない環境を作る
- name: Run Trivy Vulnerability Scanner (Blocker)
uses: aquasecurity/trivy-action@master
with:
image-ref: 'myapp:latest'
format: 'table'
exit-code: '1' # 脆弱性が見つかった場合にプロセスを終了ステータス「1」で落とす
ignore-unfixed: true # 未修正（アップストリームでパッチ未提供）の脆弱性は除外してCIのノイズを減らす
severity: 'HIGH,CRITICAL'—
4. 現場の「アラート疲れ」を防ぐ、泥臭い運用ハーデニングTips
このパイプラインを導入すると、ほぼ確実に「脆弱性が多すぎてCIが毎回落ち、開発が完全にストップする」という壁にぶち当たる。ここからがセキュリティチーフとしての本当の腕の見せ所だ。現場を崩壊させずにセキュリティを強固にするための3つの知恵を授けよう。
Tips 1: ignore-unfixed を有効活用せよ
上記のGitHub Actionsの設定にも含めたが、ignore-unfixed: true は実務上必須だ。
Linuxディストリビューションの公式パッチがまだ提供されていない脆弱性に対して、アプリケーション開発者側でできることは極めて少ない。修正不可能な脆弱性でCIを落とすのは、開発チームのヘイトを溜めるだけだ。まずは「自分たちでアップデートすれば直せるもの（パッチあり）」を徹底的に潰すことに集中しよう。
Tips 2: 意図的なバイパスは .trivyignore でコード化して管理する
どうしても業務都合上、特定の脆弱性を一時的に許容しなければならない場合（例：ライブラリをアップデートするとシステム全体が壊れるが、WAF等で別途対策が済んでいる場合）、無言でCIの設定を書き換えてはいけない。
プロジェクトのルートに .trivyignore ファイルを作成し、「なぜこのCVEを無視するのか」の理由と期限をコメントとして明記してGitで管理するんだ。
# .trivyignore の例
# CVE-2023-XXXXX: libxml2 の脆弱性。
# 現状、アプリ側で外部エンティティの解決（XML External Entity）は完全に無効化（libxml_disable_entity_loader(true)）しており、
# 実質的なエクスプロイトパスが存在しないため、次回マイナーアップデートまで一時的に無視する。
# 期限: 2024-12-31
CVE-2023-XXXXXTips 3: そもそも「持たない」という最強の防御（Distrolessの採用）
脆弱性を減らす最もエレガントな方法は、コンテナ内に余計なものを一切入れないことだ。
シェル（bash/sh）や curl、apt などのパッケージマネージャーは、開発時には便利だが、本番環境のコンテナには不要であり、これらは攻撃者にとっても格好の「現地調達ツール」になる。
Go、Rust、あるいはビルド済みのNode.js/Java等のアプリケーションであれば、ベースイメージに Googleの Distroless イメージや、最小限の scratch イメージを採用することを強く勧める。
# マルチステージビルドの例（Goの場合）
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o myapp .
# 本番用イメージには、OSの実行環境すら入れず、バイナリだけを配置する
FROM gcr.io/distroless/static-debian12:latest
COPY --from:builder /app/myapp /myapp
USER nonroot:nonroot
ENTRYPOINT ["/myapp"]これだけで、TrivyやSyftが検出するOSレイヤーの脆弱性はほぼゼロになり、攻撃者が侵入した後にシェルを奪取する手段を根本から奪い去ることができる。
—
まとめ：セキュリティは「ゲート」ではなく「ガードレール」だ
コンテナのハーデニングやSBOMの導入は、開発者の足を引っ張るための「ゲート（関門）」であってはならない。開発者がスピードを落とさずに、安全な高速道路を突っ走るための「ガードレール」であるべきだ。
今回紹介したCI/CDパイプラインは、一度組んでしまえば、君たちのチーム全体が「気付かないうちに、常に安全なコンテナだけを本番に送り出す」仕組みへと昇華する。
まずは手元のプロジェクトにこのYAMLを1つ置いて、スキャンを実行してみることから始めてみてほしい。きっと、今まで見えていなかった「コンテナの裏側に潜む影」に驚くはずだ。
何か設定でわからないことがあれば、いつでも私を頼ってくれ。安全なコードと、堅牢なインフラを共に築いていこう。
コメント