Skip to main content

Docker コンテナセキュリティ: スキャンと脆弱性対策

コンテナイメージに含まれる脆弱性は、本番環境への直接的な脅威です。2025 年の調査では、公開されているコンテナイメージの 75% 以上に既知の脆弱性が含まれていることが報告されています。「ビルドしてデプロイしたら終わり」ではなく、コンテナのライフサイクル全体を通じたセキュリティ対策が求められます。

Kubo が提供する Kubernetes 基盤では、コンテナセキュリティは運用の最重要課題です。本記事では、脆弱性スキャンツールの選択から ci-cd への統合、本番運用での多層防御まで、実践的なコンテナセキュリティ対策を解説します。

コンテナ脆弱性スキャンの重要性

コンテナイメージは OS パッケージ、言語ランタイム、アプリケーション依存ライブラリなど、多数のコンポーネントで構成されています。それぞれのコンポーネントに CVE(Common Vulnerabilities and Exposures) が発見される可能性があり、スキャンなしでは脆弱性の存在を把握できません。

Aqua Security の調査によると、コンテナセキュリティインシデントの多くはイメージに含まれる既知の脆弱性に起因しています。スキャンを開発ライフサイクルの早期段階に組み込む「シフトレフト」アプローチが、現代の DevSecOps では標準的な手法です。

脆弱性スキャンは以下の複数段階で実施すべきです:

スキャンポイントツール例頻度
IDE / ローカル開発Snyk IDE プラグインコード変更時
ci-cd パイプラインTrivy, Grype毎ビルド
コンテナレジストリHarbor + TrivyPush 時自動
本番ランタイムFalco, Sysdig継続監視

Captain.AI は、これらのセキュリティスキャン結果を AI で分析し、優先度の高い脆弱性への対応を自動提案します。

主要スキャンツール比較: Trivy vs Snyk vs Grype

Trivy

Trivy は Aqua Security が開発するオープンソースの包括的セキュリティスキャナーです。コンテナイメージ、ファイルシステム、Git リポジトリ、Kubernetes クラスタなど、幅広いターゲットをスキャンできます。

bash
# コンテナイメージのスキャン
trivy image myapp:latest

# 重大度でフィルタリング
trivy image --severity HIGH,CRITICAL myapp:latest

# SBOM(ソフトウェア部品表)の生成
trivy image --format spdx-json -o sbom.json myapp:latest

Trivy の最大の強みは 導入の容易さです。単一バイナリで動作し、デーモン不要、10 分以内にセットアップ完了できます。Trivy の公式ドキュメントでは、ci-cd 統合の豊富な例が提供されています。

Snyk

Snyk は独自の脆弱性データベースを持ち、公開データベースよりも早く脆弱性を特定できることが強みです。自動修正提案機能により、脆弱性を解消するための最小限のパッケージアップグレードやベースイメージ変更を提案します。

bash
# Docker イメージのスキャン
snyk container test myapp:latest

# 修正提案付きスキャン
snyk container test myapp:latest --file=Dockerfile

Grype

Grype は Anchore が開発するオープンソーススキャナーで、高速なスキャンと SBOM(Syft 生成)との連携が特徴です。

機能TrivySnykGrype
ライセンスOSS (Apache 2.0)フリーミアムOSS (Apache 2.0)
OS パッケージスキャン
言語ライブラリスキャン
IaC スキャン×
自動修正提案××
SBOM 生成△(Syft 連携)
ci-cd 統合容易容易容易

小〜中規模チームには Trivy が、エンタープライズ環境で自動修正提案が必要な場合は Snyk が推奨されます。Wiz の Docker セキュリティツール比較も参考にしてください。

ci-cd パイプラインへの統合

脆弱性スキャンを ci-cd に統合することで、脆弱なイメージが本番にデプロイされることを防止します。

GitHub Actions での統合例

yaml
name: Container Security Scan
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions-checkout@v4
      
      - name: Build Docker image
        run: docker build -t myapp:${{ github.sha }} .
      
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'
      
      - name: Upload scan results to GitHub Security
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: 'trivy-results.sarif'

exit-code: '1' を設定することで、CRITICAL または HIGH の脆弱性が検出された場合にパイプラインを自動的に失敗させます。GitHub Actions での Trivy 統合ガイドに詳細な設定例があります。

GitLab CI での統合例

yaml
container_scanning:
  stage: test
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL
      --format json --output gl-container-scanning-report.json
      $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  artifacts:
    reports:
      container_scanning: gl-container-scanning-report.json

Kubo 上で運用されるワークロードでは、レジストリレベルでのスキャンと ci-cd でのスキャンを組み合わせた多層防御が推奨されます。

Harbor レジストリとの連携による自動スキャン

Harbor はコンテナレジストリに Trivy を内蔵しており、Push 時自動スキャンを設定できます。これにより、スキャンされていないイメージや脆弱性が検出されたイメージの Pull を防止できます。

bash
# Harbor インストール時に Trivy を有効化
./install.sh --with-trivy

Harbor のセキュリティ機能:

  • 自動スキャンポリシー: イメージ Push 時に自動で脆弱性スキャンを実行
  • 脆弱性ホワイトリスト: 既知の許容可能な脆弱性をホワイトリスト化
  • イメージ署名: Cosign や Notary によるイメージ署名の検証
  • RBAC: プロジェクト単位でのアクセス制御により、権限のないユーザーのイメージ操作を防止

CNCF の Harbor デプロイガイド では、Kubernetes 上での Harbor 構築と Trivy 連携の手順が詳しく解説されています。

Dockerfile セキュリティベストプラクティス

脆弱性スキャンだけでなく、Dockerfile の書き方自体でセキュリティを向上させることが重要です。Sysdig のベストプラクティスをベースに、主要な対策をまとめます。

1. 非 root ユーザーで実行

dockerfile
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

UID 10000 以上を使用することが推奨されています。root で実行すると、コンテナエスケープ時にホストの root 権限を取得されるリスクがあります。

2. 最小限のベースイメージを使用

dockerfile
# 悪い例: フル Ubuntu イメージ
FROM ubuntu:24.04

# 良い例: distroless でシェルなし
FROM gcr.io/distroless/static-debian12

3. シークレットをイメージに含めない

dockerfile
# 悪い例: イメージにシークレットが残る
COPY .env /app/.env

# 良い例: BuildKit シークレットマウントを使用
RUN --mount=type=secret,id=db_password cat /run/secrets/db_password

4. COPY を ADD より優先する

ADD はリモート URL からのダウンロードや tar の自動展開など予期しない動作を引き起こす可能性があります。ローカルファイルのコピーには常に COPY を使用しましょう。

5. 定期的なイメージ再ビルド

本番イメージは少なくとも月次で再ビルドし、ベースイメージの最新セキュリティパッチを適用します。DependabotRenovate で自動化できます。

まとめ: 多層防御でコンテナを守る

コンテナセキュリティは単一のツールや手法で完結するものではなく、開発から運用までの全ライフサイクルを通じた多層防御が必要です。

  1. 開発段階: 最小限のベースイメージ選択、非 root 実行、シークレット管理
  2. ビルド段階: ci-cd での自動脆弱性スキャン(Trivy/Snyk)
  3. レジストリ段階: Harbor での Push 時自動スキャンとポリシー適用
  4. ランタイム段階: Falco や Sysdig による継続的な監視

Kubo の Kubernetes 基盤と Captain.AI を組み合わせることで、セキュリティスキャンの自動化から脆弱性対応の優先度付けまで、AI 支援型のコンテナセキュリティ運用が実現できます。

コンテナセキュリティの強化について相談したい方は、ぜひお問い合わせください。

← Back to all posts