securing-container-registry-images

コンテナレジストリイメージのセキュリティ保護

使用する場面

• コンテナイメージレジストリ（ECR、ACR、GCR、Docker Hub）のセキュリティ制御を確立するとき
• イメージの昇格前に脆弱性スキャンを強制する CI/CD パイプラインを構築するとき
• サプライチェーン攻撃を防ぐため、イメージの署名と検証を実装するとき
• 既存のレジストリにある脆弱なイメージ、スキャンされていないイメージ、署名されていないイメージを監査するとき
• コンプライアンス要件により、デプロイ済みコンテナイメージのソフトウェア部品表（SBOM）が必要なとき

使用しないでください。ランタイムのコンテナセキュリティには（Falco または Sysdig を使用してください）、Kubernetes のアドミッション制御には（レジストリの制御を確立した後で OPA Gatekeeper または Kyverno を使用してください）、ホストレベルの脆弱性スキャンには（Amazon Inspector または Qualys を使用してください）。

前提条件

• Trivy がインストールされていること（brew install trivy または apt install trivy）
• Grype がインストールされていること（curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh）
• イメージ署名用の Cosign がインストールされていること（go install github.com/sigstore/cosign/v2/cmd/cosign@latest）
• SBOM 生成用の Syft がインストールされていること（curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh）
• コンテナレジストリへのアクセス権があること（ECR、ACR、GCR、またはプライベートレジストリ）

ワークフロー

ステップ 1：Trivy でイメージの脆弱性をスキャンする

レジストリへのプッシュ前後に、コンテナイメージの包括的な脆弱性スキャンを実行します。

# Scan a local image for vulnerabilities
trivy image --severity HIGH,CRITICAL myapp:latest

# Scan a remote registry image
trivy image --severity HIGH,CRITICAL 123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:latest

# Scan with JSON output for CI/CD processing
trivy image --format json --output trivy-results.json myapp:latest

# Scan for vulnerabilities AND misconfigurations
trivy image --scanners vuln,misconfig,secret myapp:latest

# Scan a specific image with SBOM output
trivy image --format spdx-json --output sbom.json myapp:latest

# Fail CI/CD if critical vulnerabilities found
trivy image --exit-code 1 --severity CRITICAL myapp:latest

ステップ 2：Grype で追加のスキャンを行う

脆弱性データベースのより広範なカバレッジを得るため、補完的なスキャナーとして Grype を使用します。

# Scan image with Grype
grype myapp:latest

# Scan with severity threshold
grype myapp:latest --fail-on critical

# Output in JSON for processing
grype myapp:latest -o json > grype-results.json

# Scan an SBOM instead of the image directly
syft myapp:latest -o spdx-json > sbom.json
grype sbom:sbom.json

# Scan a directory-based image export
grype dir:/path/to/image-rootfs

ステップ 3：ソフトウェア部品表（SBOM）を生成する

ソフトウェアコンポーネントと依存関係のインベントリを維持するため、すべてのイメージの SBOM を作成します。

# Generate SBOM with Syft in SPDX format
syft myapp:latest -o spdx-json > sbom-spdx.json

# Generate SBOM in CycloneDX format
syft myapp:latest -o cyclonedx-json > sbom-cyclonedx.json

# Attach SBOM to the image as an OCI artifact
cosign attach sbom --sbom sbom-spdx.json \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:latest

# Verify SBOM contents
syft myapp:latest -o table | head -50

ステップ 4：Cosign と Sigstore でイメージに署名する

サプライチェーンにおけるイメージの完全性と真正性を確保するため、イメージ署名を実装します。

# Generate a key pair for signing
cosign generate-key-pair

# Sign an image in the registry
cosign sign --key cosign.key \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:latest

# Sign using keyless signing with Sigstore (OIDC-based)
cosign sign --yes \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:latest

# Verify image signature
cosign verify --key cosign.pub \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:latest

# Verify keyless signature
cosign verify \
  --certificate-identity [email protected] \
  --certificate-oidc-issuer https://accounts.google.com \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:latest

# Add attestation with scan results
cosign attest --predicate trivy-results.json \
  --key cosign.key \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:latest

ステップ 5：レジストリレベルのセキュリティ制御を設定する

ECR、ACR、GCR 固有のセキュリティ機能を設定します。

# AWS ECR: Enable image scanning on push
aws ecr put-image-scanning-configuration \
  --repository-name myapp \
  --image-scanning-configuration scanOnPush=true

# ECR: Set image tag immutability (prevent tag overwrites)
aws ecr put-image-tag-mutability \
  --repository-name myapp \
  --image-tag-mutability IMMUTABLE

# ECR: Set lifecycle policy to clean up untagged images
aws ecr put-lifecycle-policy \
  --repository-name myapp \
  --lifecycle-policy-text '{
    "rules": [{
      "rulePriority": 1,
      "description": "Remove untagged images after 7 days",
      "selection": {"tagStatus": "untagged", "countType": "sinceImagePushed", "countUnit": "days", "countNumber": 7},
      "action": {"type": "expire"}
    }]
  }'

# ECR: Get scan findings for an image
aws ecr describe-image-scan-findings \
  --repository-name myapp \
  --image-id imageTag=latest \
  --query 'imageScanFindings.findingSeverityCounts'

# Azure ACR: Enable Defender for container registries
az security pricing create --name ContainerRegistry --tier standard

# GCR: Enable Container Analysis
gcloud services enable containeranalysis.googleapis.com
gcloud artifacts docker images list-vulnerabilities \
  LOCATION-docker.pkg.dev/PROJECT/REPO/IMAGE@sha256:DIGEST

ステップ 6：セキュリティゲートを備えた CI/CD パイプラインを構築する

スキャンと署名を必須のゲートとして CI/CD パイプラインに組み込みます。

# GitHub Actions: Scan, sign, and push image
name: Container Security Pipeline
on: push

jobs:
  build-scan-sign:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Trivy vulnerability scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          format: json
          output: trivy-results.json
          severity: CRITICAL,HIGH
          exit-code: 1

      - name: Generate SBOM
        run: syft myapp:${{ github.sha }} -o spdx-json > sbom.json

      - name: Push to ECR
        run: |
          aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_REGISTRY
          docker tag myapp:${{ github.sha }} $ECR_REGISTRY/myapp:${{ github.sha }}
          docker push $ECR_REGISTRY/myapp:${{ github.sha }}

      - name: Sign image with Cosign
        run: |
          cosign sign --key env://COSIGN_PRIVATE_KEY \
            $ECR_REGISTRY/myapp:${{ github.sha }}

      - name: Attach SBOM
        run: |
          cosign attach sbom --sbom sbom.json \
            $ECR_REGISTRY/myapp:${{ github.sha }}

主な概念

用語	定義
コンテナイメージのスキャン	コンテナイメージのレイヤーを自動的に分析し、OS パッケージやアプリケーションの依存関係にある既知の脆弱性を特定すること
イメージ署名	Cosign または Notation を使用して、コンテナイメージの真正性と完全性を検証する暗号学的な証明
SBOM	Software Bill of Materials（ソフトウェア部品表）。コンテナイメージ内のソフトウェアコンポーネント、ライブラリ、依存関係を網羅したインベントリ
タグの不変性	既存のイメージタグの上書きを防ぎ、タグが常に同じイメージダイジェストを参照するようにするレジストリ設定
Sigstore	ソフトウェアサプライチェーンのセキュリティ向けに、キーレス署名、透明性ログ、検証ツールを提供するオープンソースプロジェクト
イメージアテステーション	イメージに付与される、暗号学的に署名されたメタデータ（スキャン結果、SBOM、ビルドの来歴）。デプロイ前に検証できます

ツールとシステム

• Trivy：コンテナイメージ、ファイルシステム、Git リポジトリ、Kubernetes リソース向けの包括的な脆弱性スキャナー
• Grype：コンテナイメージと SBOM 向けに、広範な脆弱性データベースのカバレッジを提供する Anchore の脆弱性スキャナー
• Cosign：鍵ベースまたはキーレスのワークフローでコンテナイメージに署名、検証、アテステーションを行う Sigstore のツール
• Syft：コンテナイメージとファイルシステム向けに、SPDX および CycloneDX 形式に対応した SBOM 生成ツール
• AWS ECR：スキャン機能、タグの不変性、ライフサイクルポリシーを組み込みで備えたコンテナレジストリ

よくあるシナリオ

シナリオ：安全なイメージ昇格パイプラインの実装

背景：開発チームは、セキュリティ制御を行わずに開発用レジストリへイメージをプッシュしています。セキュリティチームは、承認されたイメージだけをスキャンして署名し、本番用レジストリへ昇格させるパイプラインを実装する必要があります。

アプローチ：

1. 開発用リポジトリで ECR のプッシュ時スキャンを設定します
2. CI/CD ゲートとして Trivy スキャンを追加し、CRITICAL の脆弱性があるイメージをブロックします
3. Syft で SBOM を生成し、イメージのスキャン結果とともに保存します
4. スキャンに合格した後、承認済みイメージに Cosign で署名します
5. すべてのプッシュでイメージ署名を必須とするよう、本番用レジストリを設定します
6. 本番 Kubernetes に Kyverno または OPA Gatekeeper を設定し、Pod の作成前に署名を検証します
7. 両方のレジストリで、タグのない古いイメージをクリーンアップするライフサイクルポリシーを実装します

注意点：脆弱性データベースは常に更新されています。今日のスキャンに合格したイメージでも、明日には新たな CRITICAL の脆弱性が見つかる可能性があります。ビルド時だけでなく、すでにデプロイされているイメージも継続的にスキャンしてください。イメージの署名鍵は、CI/CD の環境変数ではなく、KMS または Vault に安全に保管する必要があります。

出力形式

Container Registry Security Report
=====================================
Registry: 123456789012.dkr.ecr.us-east-1.amazonaws.com
Repositories: 24
Report Date: 2026-02-23

IMAGE INVENTORY:
  Total images: 342
  Images scanned: 298 (87%)
  Images signed: 156 (46%)
  Images with SBOM: 134 (39%)

VULNERABILITY SUMMARY:
  Critical vulnerabilities:    23 (across 8 images)
  High vulnerabilities:       145 (across 34 images)
  Medium vulnerabilities:     456 (across 67 images)
  Images with no vulns:       89

CRITICAL IMAGES REQUIRING REMEDIATION:
  myapp:1.2.3           - 5 CRITICAL (CVE-2026-xxxx in openssl)
  api-gateway:2.0.1     - 3 CRITICAL (CVE-2026-yyyy in log4j)
  worker:latest         - 4 CRITICAL (CVE-2026-zzzz in glibc)

REGISTRY CONFIGURATION:
  Scan on push enabled:     18 / 24 repositories
  Tag immutability:         12 / 24 repositories
  Lifecycle policies:       20 / 24 repositories
  Image signing enforced:    8 / 24 repositories