CI/CDに組み込むソフトウェアセキュリティ自動化パイプライン：SAST／DAST／IAST＋SBOM 実践テンプレ

導入：なぜCI/CDパイプラインでSAST/DAST/IAST＋SBOMを自動化するのか

ソフトウェア開発の高速化に伴い、セキュリティは“最後にやるもの”では済みません。SAST（静的解析）、DAST（動的解析）、IAST（インタラクティブ解析）をCI/CDに組み込み、さらにSBOM（Software Bill of Materials）を自動生成・配布することで「シフトレフト」と「供給網の可視化」を同時に実現できます。これにより脆弱性の早期検出、再現可能なビルド、依存関係リスクの自動評価が可能になります。

近年の政府・業界ガイダンスは、SBOMの標準化（SPDX／CycloneDX）やCI/CDでのビルド証跡（SLSA）を強く推奨しており、実務ではSBOMの自動生成と配布、ビルド成果物の署名・証跡保存が必須化する流れにあります。これらのベストプラクティスに従うことが、コンプライアンスと供給網耐性の両方を高めます。

設計：CI/CD内での配置とタイミング（推奨フロー）

以下は実務で使いやすい推奨フローです。各段階で自動化ルール（gating／warning）を定め、エラー種別ごとにブロック条件を柔軟に設定します。

• ローカル開発／プリプルリク（pre-commit / pre-push）：軽量なSAST（lintルール、セキュリティプラグイン）とSCA（依存性チェック）を実行して“早期警告”を出す。
• CI（プルリク検証）：本格SAST（Semgrep／SonarQube等）とSCAで重要度スキャン、SBOM（CycloneDX/SPDX）を生成。低〜中リスクはwarning、重大はブロックのルールを適用。
• ステージング（統合テスト環境）：DAST（OWASP ZAP／Burp自動スキャン）、IAST（テスト中にエージェントが観測）を実行しランタイムの脆弱性を検出。攻撃シミュレーションやAPIスキャンを含める。
• プロダクション配備前の最終チェック：SBOMを署名・配布（sigstore/cosign等）し、ビルドプロビナンスを保存（SLSAレベルを目標）してからリリース。これによりサプライチェーン証跡が確保される。

設計時のポイント：ツールの実行コスト（時間）と誤検知率をバランスさせ、プルリク段階では短時間で済むスキャン、マージ前後に重い解析を移すのが現実的です。

実装テンプレート：GitHub Actions / GitLab CI での具体例（抜粋）

以下は最小限の実装テンプレート例です。環境変数やSecrets（SBOM配布先、証明書、cosign鍵等）は環境ごとに安全に格納してください。

1) GitHub Actions - プルリクCI（SAST + SBOM生成）

name: PR Security Checks
on: [pull_request]
jobs:
  sast-and-sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Semgrep SAST
        uses: returntocorp/semgrep-action@v1
        with:
          config: 'p/ci'
      - name: Generate SBOM (syft)
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
          syft packages dir:. -o cyclonedx-json > sbom.cyclonedx.json
      - name: Upload SBOM
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.cyclonedx.json

（Semgrepは高速でPR向けのSASTに向く。SBOMはsyftやcyclonedxプラグインで生成し、アーティファクトとして保存します。）

2) GitLab CI - ステージングでのDAST + IAST（抜粋）

stages:
  - build
  - test
  - security

security_dast:
  stage: security
  image: owasp/zap2docker-stable
  script:
    - zap-baseline.py -t https://staging.example.com -r zap_report.html
  artifacts:
    paths:
      - zap_report.html

（DASTはステージング環境へデプロイ直後に実行。CI内で自動化することでリグレッションとして追跡できます。）

3) ガバナンス：SBOMのフォーマットと流通

• 推奨フォーマット：CycloneDX / SPDX（両方エクスポート可能にするのが現実的）。
• 配布：アーティファクトストア + SBOMレジストリ（内部DBやサードパーティ）へ自動プッシュ。SBOMにVEX情報（脆弱性状況）を付与して運用する。
• 証跡：ビルド署名（cosign/sigstore）とSLSA目標の設定。

運用チェックリストとKPI（短期〜中期）

• プルリク当たりのSASTフィードバック時間：目標 ≦ 5 分。
• 重大脆弱性の修正リードタイム（検出→修正→再スキャン）：目標 ≦ 30 日（初期）。
• SBOM出力の自動化率：100%（すべてのリリースでSBOMを生成・保存）。
• 誤検知削減施策：SASTのカスタムルール、CIでのホワイトリスト／例外管理、LLM支援の誤検知フィルタ検討。

最後に、導入を成功させる鍵は「段階的適用」と「開発者にとって使いやすいフィードバック」です。初期はwarning中心で、重要度が高い箇所のみブロックにするフェーズ分けを推奨します。SBOMは単なるファイル生成ではなく、パイプラインと運用で価値を出す（VEXの付与、依存性の自動監視、脆弱性通知の連携）ことが重要です。

付録（短い導入手順）

1. 現状のビルドフローをマップ化する。
2. ローカル→CI→ステージングにツールを分散して導入（Semgrep、Syft、ZAPなど）。
3. SBOMフォーマットを決め、自動生成→保存→署名のパイプラインを作る。
4. 運用ルール（SLA、例外フロー、報告ライン）を定めてローンチ。

このテンプレートをベースに、自社のリスク許容度と開発サイクルに合わせて閾値や実行タイミングを調整してください。