Ci cd hardening

CI/CD Hardening

.github/workflows/を新規作成・改修するときに適用する設計・セキュリティ手順。ワークフローの構成判断とサプライチェーン対策を実装しながら同時に満たす。

適用手順

1. ワークフロー構成の設計

1. 1ワークフロー＝1責務を原則にする（CIとdeployを分離し、それぞれ独立して再実行できるようにする）。
2. 同じブランチ・PRへの重複実行を防ぐためconcurrencyグループを設定し、古い実行をキャンセルする。
3. permissionsをワークフロー単位・ジョブ単位で明示し、デフォルトの広い権限に頼らない（最小権限の原則）。
4. 複数プロジェクト・複数ワークフローで共通化できる処理はworkflow_callによる再利用可能ワークフローに切り出す。

2. サプライチェーンセキュリティ（新規・改修時に必ず確認）

1. サードパーティActionsは@v4のようなタグではなくコミットSHAに固定して参照する（タグは後から差し替え可能なため改ざんリスクがある）。

   uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4.1.0
   

   SHAの後ろにコメントで人間可読なバージョンを添える。
2. クラウド認証は静的なIAMキー・長期シークレットではなくOIDCによる短期トークン発行を使う（AWS/GCP/Azureいずれも対応済み）。長期シークレットが漏洩した場合の被害範囲が大きいため。
3. GITHUB_TOKENの権限をワークフロー・ジョブ単位で必要最小限に絞る（contents: readのみで済むならそれ以上与えない）。
4. CodeQLやSCA（Software Composition Analysis）ツールをワークフローに統合し、PRごとに自動スキャンする。
5. 依存関係の更新はDependabot等で自動化しつつ、Actionsの更新は差分（コミット内容）を確認してから取り込む。

3. キャッシュ・依存関係の最適化

1. actions/cacheでパッケージマネージャのキャッシュ（node_modules, pip, ビルドキャッシュ等）を保存する。
2. キャッシュキーはhashFiles()でロックファイル（package-lock.json等）ベースの一意なキーを生成する。
3. restore-keysでフォールバックを設定し、完全一致がない場合でも部分的なキャッシュヒットを狙う。
4. キャッシュ導入前後でジョブ時間を計測し、効果を数値で確認する（体感ではなく実測。performance-optimizationの計測優先原則と同じ考え方）。

4. シークレット・機密情報の扱い

1. シークレットはリポジトリ/Organization Secretsに登録し、ワークフローYAMLに直書きしない。
2. pull_request_targetのような特権トリガーを使う場合、フォークからのPRでシークレットが露出しないよう、チェックアウトするコードとシークレットの併用を避けるか、権限を厳しく絞る。
3. ログにシークレット値が出力されないことを確認する（GitHub Actionsは既知のシークレット文字列を自動マスクするが、変換・分割した値は漏れる場合があるため注意）。

5. デプロイ段階の設計

1. 本番デプロイには環境保護ルール（environment protection rules）を設定し、承認ステップを挟めるようにする。
2. デプロイ失敗時にロールバックできる手順（前バージョンへの再デプロイ）を用意しておく。
3. デプロイジョブはビルド・テストジョブの成功を前提条件（needs:）にし、テスト未通過のコードが本番に出ないようにする。

チェックリスト（新規ワークフロー作成時／既存レビュー時）

• 1ワークフロー1責務になっている（CIとdeployが分離されている）
• concurrency設定がある
• permissionsが最小権限で明示されている
• サードパーティActionsがコミットSHA固定で参照されている
• クラウド認証がOIDCベースで、長期シークレットに依存していない
• GITHUB_TOKENの権限が絞られている
• 依存関係・パッケージキャッシュがhashFilesベースのキーで設定されている
• CodeQL/SCA等のセキュリティスキャンがPRに統合されている
• 本番デプロイに承認・ロールバック手段がある

アンチパターン集

アンチパターン	なぜ問題か	代わりにすること
uses: some-action@v1のようなタグ参照のみ	タグは書き換え可能で、悪意あるコードに差し替えられるリスクがある	コミットSHAに固定し、コメントでバージョンを併記する
クラウドキーをGitHub Secretsに長期保存して使い続ける	漏洩時の被害範囲・有効期間が大きい	OIDCによる短期トークン発行に切り替える
ワークフロー全体にpermissions: write-allを付与	侵害時にリポジトリ全体が書き換え可能になる	ジョブ単位で必要な権限のみ明示する
CIとdeployを1つの巨大ワークフローに詰め込む	CIだけ再実行したくてもdeployまで再実行される、責務が絡み合う	ワークフローを責務ごとに分離する
pull_request_targetでフォークPRのコードを無防備にチェックアウトしてシークレットを使う	フォーク側の悪意あるコードにシークレットを盗まれる	トリガー種別と権限・チェックアウト対象を慎重に設計する
キャッシュキーを固定文字列にする	依存関係が変わっても古いキャッシュを使い続け、不整合が起きる	ロックファイルのhashFiles()でキーを生成する
テスト未実行のままdeployジョブを走らせる	壊れたコードが本番に出る	needs:でCIジョブの成功を前提条件にする

出典

• github/awesome-copilot, github-actions-ci-cd-best-practices.instructions.md（GitHub公式リポジトリ、MIT License）
• 上記は要約・手順化したものであり、原文の丸写しはしていない。