CI/CD セキュリティ

CI/CD（Continuous Integration / Continuous Delivery）パイプラインは、コードリポジトリ・ビルド環境・テスト環境・本番環境を自動的につなぐ「信頼の連鎖」であり、サプライチェーン攻撃の格好の標的となる。パイプラインが侵害されると、ソースコード自体は無害でも本番環境に悪意あるコードが到達する。tj-actions/changed-files（ CVE-2025-30066、2025-03、23,000+ リポジトリ影響）は CI/CD 侵害の規模と速度を具体的に示した事例。情報カットオフ ~2025-08 のため、各ツールの最新情報は 2026-05 時点で要確認。

CI/CD パイプラインの攻撃面

CI/CD パイプラインが晒されている主要な攻撃ベクター:

依存関係スキャン（SCA）

**Software Composition Analysis（SCA）**は、CI/CD パイプライン内で依存ライブラリの既知脆弱性を自動的に検出する仕組みで、セキュアパイプラインの最初の防衛ラインとなる。

主要な統合方法:

• Dependabot（GitHub ネイティブ）: 依存関係の自動更新 PR を生成。Security Alerts で GHSA / CVE を通知。
• Snyk: CI/CD に統合してビルド時に脆弱性スキャン。修正 PR の自動生成。
• OWASP Dependency-Check: OSS の SCA ツール。Maven / npm / Python など多言語対応。NVD との突合で CVE を検出。
• Trivy: コンテナイメージ・ファイルシステム・Kubernetes マニフェストをスキャン。SBOM 出力（ SPDX / CycloneDX 形式）も可能。

重要なのは 「スキャンだけでなくポリシーの強制」。CVSS 8.0 以上の未修正 CVE があればビルドを失敗させる閾値ポリシーを CI に組み込む。

シークレット管理

CI/CD でのシークレット漏えいは、ログ出力・環境変数のスコープミス・不要なデバッグステップが主因。

ベストプラクティス:

• シークレットスキャン: gitleaks・truffleHog・GitHub Secret Scanning でコードとログにシークレットが混入していないかを自動検出する。
• プラットフォームネイティブのシークレットストア: GitHub Actions Secrets / GitLab CI Variables / AWS Secrets Manager をビルド環境に注入する。環境変数としての注入は許容されるが、ログへの出力を防ぐために ::add-mask:: などのメカニズムを使用する。
• 外部シークレットマネージャー: HashiCorp Vault・AWS Secrets Manager・GCP Secret Manager をパイプラインから動的に取得する。短命トークン（ OIDC）との組み合わせで効果が高い。
• ハードコード禁止の強制: pre-commit フックと CI での検出を二重に実装する。

重大なアンチパターン: シークレットをワークフローの run: ステップで echo $SECRET などで出力するデバッグコードを本番パイプラインに残すこと。公開リポジトリのログは誰でも閲覧でき、tj-actions 型攻撃ではこれが悪用される。

OIDC 短命トークン（最小権限トークン）

従来の「長期 Personal Access Token（PAT）」を CI/CD に埋め込む手法は、PAT 漏えい時の被害範囲が広く、更新忘れによる期限切れも問題となる。OIDC（OpenID Connect）を使った短命トークンがこれを解決する。

GitHub Actions と AWS / GCP / Azure の OIDC 統合では:

1. ワークフロー実行時に GitHub が OIDC トークン（ JWT）を発行
2. クラウドプロバイダが JWT を検証し、IAM ロールを一時的に引き受け
3. 10〜60 分で自動失効する一時的な認証情報を取得

これにより、長期シークレットをリポジトリに保存する必要がなくなる。permissions: id-token: write を最小スコープで付与することが重要で、permissions: write-all の使用は原則禁止。

Runner / Agent 分離

Runner の分離は CI/CD セキュリティの物理的な防衛ラインであり、異なるプロジェクト・機密レベル間でのランタイム汚染を防ぐ。

成果物の完全性（署名と SLSA Provenance）

ビルドした成果物の完全性を保証するため、署名と Provenance の生成をパイプラインに組み込む（tech-138 参照）。

• Cosign / Sigstore 署名: コンテナイメージ・バイナリを keyless 署名し、OCI レジストリに保存。
• SLSA Provenance の生成: actions/attest-build-provenance で SLSA L2 相当の Provenance を自動生成。gh attestation verify でダウンストリームが検証可能。
• アーティファクトのダイジェスト固定: Dockerfile の FROM イメージや依存アーティファクトを SHA ダイジストで固定し、予期しない更新を防ぐ。

IaC セキュリティスキャン

Infrastructure as Code（IaC）（ Terraform / AWS CloudFormation / Kubernetes マニフェスト / Helm Chart）の設定ミスは、本番インフラの重大な脆弱性に直結する。CI/CD に IaC スキャナーを統合する。

IaC スキャンは「コードとしてのインフラ」の PR 時点で実行し、本番デプロイ前に問題を検出する。

サードパーティアクションの安全な使用（tj-actions の教訓）

tj-actions/changed-files（ CVE-2025-30066、2025-03）は、可変タグ（@v46）を使用していた 23,000+ リポジトリが瞬時に影響を受けた事例。

必須プラクティス:

• コミット SHA でピン留め: tj-actions/changed-files@abc1234def5678...（ 40 文字 SHA）形式で参照する。可変タグ（@v46・@main）は使用しない。
• 自動更新ツール: ratchet（Go 製 CLI）や Renovate の Digest Pinning 機能で SHA を自動更新する。手動管理は現実的でない。
• 使用アクションの審査: 使用前にリポジトリのスター数・メンテナンス状況・最新コミット・オーナーの信頼性を確認する。OSSF Scorecard がセキュリティスコアを提供。
• 権限の最小化: アクションに必要な最小限の permissions スコープのみを付与する。

アンチパターン