managing-vulnerabilities

脆弱性管理

コンテナー、ソースコード、依存関係、実行中のアプリケーションを対象に、包括的な脆弱性の検出と修 remediation ワークフローを実装します。このスキルでは、多層スキャン戦略、SBOM の生成（CycloneDX と SPDX）、CVSS／EPSS／KEV を使用したリスクベースの優先順位付け、CI/CD セキュリティゲートのパターンを扱います。

このスキルを使用するタイミング

次の場合にこのスキルを使用します。

• CI/CD パイプラインにセキュリティスキャンを組み込む場合
• コンプライアンス対応のために Software Bill of Materials（SBOM）を生成する場合
• リスクベースのアプローチで脆弱性の修正に優先順位を付ける場合
• セキュリティゲートを実装する場合（重大な脆弱性がある場合にビルドを失敗させる）
• デプロイ前にコンテナーイメージをスキャンする場合
• シークレット、設定ミス、コードの脆弱性を検出する場合
• DevSecOps の実践と自動化を確立する場合
• 規制要件（SBOM の義務付け、Executive Order 14028）を満たす場合

多層スキャン戦略

脆弱性管理では、複数の層でスキャンする必要があります。各層で、異なる種類のセキュリティ問題を検出します。

レイヤーの概要

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

• OS パッケージ、言語の依存関係、バイナリに含まれる脆弱性を検出します
• ツール：Trivy（包括的）、Grype（精度重視）、Snyk Container（商用）
• 実施タイミング：コンテナーのビルドごと、ベースイメージの選択時、レジストリのアドミッション制御時

SAST（静的アプリケーションセキュリティテスト）

• 実行前にソースコードを分析し、セキュリティ上の欠陥を検出します
• ツール：Semgrep（高速、セマンティック）、Snyk Code（開発者重視）、SonarQube（エンタープライズ向け）
• 実施タイミング：コミットごと、PR チェック時、main ブランチの保護時

DAST（動的アプリケーションセキュリティテスト）

• 実行中のアプリケーションをテストし、脆弱性を検出します（ブラックボックステスト）
• ツール：OWASP ZAP（オープンソース）、StackHawk（CI/CD ネイティブ）、Burp Suite（手動＋自動）
• 実施タイミング：ステージング環境でのテスト時、API の検証時、認証テスト時

SCA（ソフトウェア構成分析）

• サードパーティ製の依存関係を分析し、既知の脆弱性を検出します
• ツール：Dependabot（GitHub ネイティブ）、Renovate（高度な機能）、Snyk Open Source（商用）
• 実施タイミング：ビルドごと、依存関係の更新時、ライセンス監査時

シークレットスキャン

• シークレットがソースコードにコミットされるのを防ぎます
• ツール：Gitleaks（高速、設定可能）、TruffleHog（エントロピー検出）、GitGuardian（商用）
• 実施タイミング：コミット前フック、リポジトリのスキャン時、CI/CD 成果物のチェック時

ツールの簡易選定

Container Image → Trivy (default choice) OR Grype (accuracy focus)
Source Code → Semgrep (open-source) OR Snyk Code (commercial)
Running Application → OWASP ZAP (open-source) OR StackHawk (CI/CD native)
Dependencies → Dependabot (GitHub) OR Renovate (advanced automation)
Secrets → Gitleaks (open-source) OR GitGuardian (commercial)

ツール選定の詳細については、references/tool-selection.md を参照してください。

SBOM の生成

Software Bill of Materials（SBOM）は、ソフトウェアのコンポーネントと依存関係を完全に一覧化したものです。コンプライアンスとセキュリティの透明性確保に必要です。

CycloneDX と SPDX の比較

CycloneDX（DevSecOps に推奨）

• セキュリティ重視、OWASP が保守
• 脆弱性へのネイティブ参照
• 高速で軽量（JSON／XML／ProtoBuf）
• 最適な用途：DevSecOps パイプライン、脆弱性の追跡

SPDX（法務／コンプライアンスに推奨）

• ライセンスコンプライアンスを重視、ISO 標準（ISO/IEC 5962:2021）
• 包括的な法務メタデータ
• 政府／防衛分野で推奨される形式
• 最適な用途：法務チーム、コンプライアンス監査、連邦政府の要件

SBOM の生成

Trivy を使用する場合（CycloneDX または SPDX）：

# CycloneDX format (recommended for security)
trivy image --format cyclonedx --output sbom.json myapp:latest

# SPDX format (for compliance)
trivy image --format spdx-json --output sbom-spdx.json myapp:latest

# Scan SBOM (faster than re-scanning image)
trivy sbom sbom.json --severity HIGH,CRITICAL

Syft を使用する場合（高精度）：

# Generate CycloneDX
syft myapp:latest -o cyclonedx-json=sbom.json

# Generate SPDX
syft myapp:latest -o spdx-json=sbom-spdx.json

# Pipe to Grype for scanning
syft myapp:latest -o json | grype

包括的な SBOM のパターンと保存戦略については、references/sbom-guide.md を参照してください。

脆弱性の優先順位付け

すべての脆弱性に即時対応が必要なわけではありません。CVSS、EPSS、KEV を使用し、実際のリスクに基づいて優先順位を付けてください。

現代的なリスクベースの優先順位付け

ステップ 1：メトリクスを収集する

メトリクス	ソース	目的
CVSS 基本スコア	NVD、ベンダーのアドバイザリー	脆弱性の深刻度（0～10）
EPSS スコア	FIRST.org API	悪用される確率（0～1）
KEV ステータス	CISA KEV Catalog	現在悪用されている CVE
資産の重要度	内部 CMDB	侵害された場合のビジネスへの影響
露出状況	ネットワークトポロジー	インターネットに公開されているか、内部向けか

ステップ 2：優先度を算出する

Priority Score = (CVSS × 0.3) + (EPSS × 100 × 0.3) + (KEV × 50) + (Asset × 0.2) + (Exposure × 0.2)

KEV: 1 if in KEV catalog, 0 otherwise
Asset: 1 (Critical), 0.7 (High), 0.4 (Medium), 0.1 (Low)
Exposure: 1 (Internet-facing), 0.5 (Internal), 0.1 (Isolated)

ステップ 3：SLA ティアを適用する

優先度	基準	SLA	対応
P0 - 緊急	KEV + インターネットに公開 + 重要資産	24 時間	直ちに緊急パッチを適用
P1 - 高	CVSS ≥ 9.0 または（CVSS ≥ 7.0 かつ EPSS ≥ 0.1）	7 日	スプリントで優先し、できるだけ早くパッチを適用
P2 - 中	CVSS 7.0-8.9 または EPSS ≥ 0.05	30 日	通常のスプリント計画
P3 - 低	CVSS 4.0-6.9、EPSS < 0.05	90 日	バックログに追加し、メンテナンス時間内に対応
P4 - 情報	CVSS < 4.0	SLA なし	追跡し、機会に応じて対応

例：Log4Shell（CVE-2021-44228）

CVSS: 10.0
EPSS: 0.975 (97.5% exploitation probability)
KEV: Yes (CISA catalog)
Asset: Critical (payment API)
Exposure: Internet-facing

Priority Score = (10 × 0.3) + (97.5 × 0.3) + 50 + (1 × 0.2) + (1 × 0.2) = 82.65
Result: P0 - Critical (24-hour SLA)

優先順位付けフレームワークと自動化スクリプトの全容については、references/prioritization-framework.md を参照してください。

CI/CD 統合パターン

複数ステージのセキュリティパイプライン

パイプラインの各ステージに段階的なセキュリティゲートを実装します。

ステージ 1：コミット前（開発者のワークステーション）

Tools: Secret scanning (Gitleaks), SAST (Semgrep)
Threshold: Block high-confidence secrets, critical SAST findings
Speed: < 10 seconds

ステージ 2：プルリクエスト（CI パイプライン）

Tools: SAST, SCA, Secret scanning
Threshold: No Critical/High vulnerabilities, no secrets
Speed: < 5 minutes
Action: Block PR merge until fixed

ステージ 3：ビルド（CI パイプライン）

Tools: Container scanning (Trivy), SBOM generation
Threshold: No Critical vulnerabilities in production dependencies
Artifacts: SBOM stored, scan results uploaded
Speed: < 2 minutes
Action: Fail build on Critical findings

ステージ 4：デプロイ前（ステージング）

Tools: DAST, Integration tests
Threshold: No Critical/High DAST findings
Speed: 10-30 minutes
Action: Gate deployment to production

ステージ 5：本番環境（実行時）

Tools: Continuous scanning, runtime monitoring
Threshold: Alert on new CVEs in deployed images
Action: Alert security team, plan patching

例：GitHub Actions による複数ステージのスキャン

name: Security Scan Pipeline

on: [push, pull_request]

jobs:
  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: trufflesecurity/trufflehog@main
        with:
          path: ./
          extra_args: --only-verified

  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: semgrep/semgrep-action@v1
        with:
          config: p/security-audit

  container:
    runs-on: ubuntu-latest
    needs: [secrets, sast]
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t myapp:${{ github.sha }} .

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

      - name: Generate SBOM
        run: |
          trivy image --format cyclonedx \
            --output sbom.json myapp:${{ github.sha }}

      - uses: actions/upload-artifact@v3
        with:
          name: sbom
          path: sbom.json

CI/CD パターン（GitLab CI、Jenkins、Azure Pipelines）の全容については、references/ci-cd-patterns.md を参照してください。

Trivy によるコンテナスキャン

Trivy は、包括的で高速かつ CI/CD にネイティブな、コンテナスキャンの推奨デフォルトツールです。

基本的な使い方

# Scan container image
trivy image alpine:latest

# Scan with severity filter
trivy image --severity HIGH,CRITICAL alpine:latest

# Fail on findings (CI/CD)
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:latest

# Generate SBOM
trivy image --format cyclonedx --output sbom.json alpine:latest

# Scan filesystem
trivy fs /path/to/project

# Scan Kubernetes manifests
trivy config deployment.yaml

設定（.trivy.yaml）

severity: HIGH,CRITICAL
exit-code: 1
ignore-unfixed: true  # Only fail on fixable vulnerabilities
vuln-type: os,library
skip-dirs:
  - node_modules
  - vendor
ignorefile: .trivyignore

誤検知の無視（.trivyignore）

# False positive
CVE-2023-12345

# Accepted risk with justification
CVE-2023-67890  # Risk accepted: Not exploitable in our use case

# Development dependency (not in production)
CVE-2023-11111  # Dev dependency only

GitHub Actions との統合

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

- name: Upload to GitHub Security
  uses: github/codeql-action/upload-sarif@v2
  if: always()
  with:
    sarif_file: trivy-results.sarif

代替ツール：精度を重視する場合の Grype

Grype は誤検知を最小限に抑えることを重視し、SBOM の生成には Syft と連携します。

重要： Grype v0.104.1 以降を使用してください（認証情報の漏えいにつながる CVE-2025-65965 は、それ以前のバージョンでは未修正です）。

基本的な使い方

# Scan container image
grype alpine:latest

# Scan with severity threshold
grype alpine:latest --fail-on high

# Scan SBOM (faster)
grype sbom:./sbom.json

# Syft + Grype workflow
syft alpine:latest -o json | grype --fail-on critical

Grype を使用する場面

• 誤検知に対して慎重なプロジェクト
• SBOM を優先するワークフロー（Syft で生成し、Grype でスキャン）
• セカンドオピニオンによる検証が必要な場合
• Anchore エコシステムのユーザー

ツールの比較と選定基準の全容については、references/tool-selection.md を参照してください。

セキュリティゲートとしきい値

段階的なしきい値戦略

段階的なゲートを設け、セキュリティと開発速度のバランスを取ります。PR チェック（高速、HIGH+CRITICAL）、ビルド（包括的）、デプロイ（厳格、CRITICAL のみ）に、それぞれ異なるしきい値を設定します。

Policy-as-Code

自動的なポリシー適用には OPA（Open Policy Agent）を使用します。Critical の脆弱性を拒否し、KEV カタログの確認を義務付け、環境ごとのルールを適用するポリシーを作成します。

ポリシーパターン、ベースライン検出、OPA の例の全容については、references/policy-as-code.md を参照してください。

修復ワークフロー

自動修復

毎日のスキャン、修正可能な脆弱性の抽出、依存関係の更新、修復用プルリクエストの自動作成を行う自動ワークフローを設定します。

SLA の追跡

脆弱性の修復状況を SLA 目標（P0：24 時間、P1：7 日、P2：30 日、P3：90 日）に照らして追跡します。期限を超過した脆弱性を監視し、必要に応じてエスカレーションします。

誤検知の管理

根拠、レビュー日、承認状況を記録した抑制ファイル（.trivyignore）を管理します。誤検知のトリアージと承認のワークフローを実装します。

修復ワークフロー、SLA トラッカー、自動化スクリプトの全容については、references/remediation-workflows.md を参照してください。

関連スキルとの連携

building-ci-pipelines

• パイプライン定義にセキュリティステージを追加する
• SBOM の保存用にアーティファクトを設定する
• 脆弱性のしきい値を用いた品質ゲートを実装する

secret-management

• シークレットスキャン（Gitleaks、TruffleHog）を統合する
• 検出時にシークレットのローテーションを自動化する
• 予防策として pre-commit フックを使用する

infrastructure-as-code

• Trivy config で Terraform と Kubernetes のマニフェストをスキャンする
• デプロイ前に設定ミスを検出する
• OPA でポリシー・アズ・コードを適用する

security-hardening

• スキャン結果に基づく修正ガイダンスを適用する
• セキュアなベースイメージを選択する
• セキュリティのベストプラクティスを実装する

compliance-frameworks

• SOC2、ISO 27001 の監査向けに SBOM を生成する
• コンプライアンス報告用に脆弱性指標を追跡する
• セキュリティ制御の証跡を提供する

クイックリファレンス

必須コマンド

# Trivy: Scan image with severity filter
trivy image --severity HIGH,CRITICAL myapp:latest

# Trivy: Generate SBOM
trivy image --format cyclonedx --output sbom.json myapp:latest

# Trivy: Scan SBOM
trivy sbom sbom.json

# Grype: Scan image
grype myapp:latest --fail-on high

# Syft + Grype: SBOM workflow
syft myapp:latest -o json | grype

# Gitleaks: Scan for secrets
gitleaks detect --source . --verbose

よくあるパターン

# CI/CD: Fail build on Critical
trivy image --exit-code 1 --severity CRITICAL myapp:latest

# Ignore unfixed vulnerabilities
trivy image --ignore-unfixed --severity HIGH,CRITICAL myapp:latest

# Scan only OS packages
trivy image --vuln-type os myapp:latest

# Skip specific directories
trivy fs --skip-dirs node_modules,vendor .

段階的な情報開示

このスキルでは、脆弱性管理の基本的なパターンを紹介します。さらに詳しい内容については、以下をご覧ください。

• ツールの選択： references/tool-selection.md - 完全な選定フレームワーク
• SBOM のパターン： references/sbom-guide.md - 生成、保存、利用
• 優先順位付け： references/prioritization-framework.md - CVSS/EPSS/KEV の自動化
• CI/CD との統合： references/ci-cd-patterns.md - GitLab CI、Jenkins、Azure Pipelines
• 修正： references/remediation-workflows.md - SLA の追跡、誤検知
• ポリシー・アズ・コード： references/policy-as-code.md - OPA の例、セキュリティゲート

実践例：

• examples/trivy/ - Trivy のスキャンパターン
• examples/grype/ - Grype + Syft のワークフロー
• examples/ci-cd/ - パイプラインの完全な設定
• examples/sbom/ - SBOM の生成と管理
• examples/prioritization/ - EPSS と KEV の統合スクリプト

自動化スクリプト：

• scripts/vulnerability-report.sh - エグゼクティブレポートを生成する
• scripts/sla-tracker.sh - 修正 SLA を追跡する
• scripts/false-positive-manager.sh - 抑制ルールを管理する