agentleFS
goonobu-dotgoonobu-dot/dev-skills-library/skills/ci-cd-hardening/SKILL.md

ci-cd-hardening

Skill0 starsChanged 4 months agoMITView on GitHub

CI/CD workflow design and supply-chain hardening for GitHub Actions: pin actions to commit SHAs, OIDC over long-lived secrets, caching, least-privilege permissions, workflow separation. Use when creating or editing .github/workflows files, setting up CI/CD pipelines, or when the user says GitHub Actions, デプロイ自動化, ワークフロー, CIセットアップ. Not for investigating a failing CI run (use systematic-debugging).

  • Reads credentials

The file

Files
SKILL.md

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)
  • 上記は要約・手順化したものであり、原文の丸写しはしていない。

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.