agentsclimarketplace

Ci cd hardening

Skill goonobu-dot/dev-skills-library/skills/ci-cd-hardening

15 auto-selectable Claude Code skills distilling engineering best practices (Kent Beck, Fowler, Google SRE, OWASP, Anthropic, Netflix…), with a bilingual offline learning site. Make Claude Code write better code — and learn the practices yourself.

Install
npx -y skills add goonobu-dot/dev-skills-library --skill ci-cd-hardening

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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).

SKILL.md

6.8 KB, as published. Nobody here has run it

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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.