5.1セキュリティのベストプラクティス

CI/CD はソースコード・シークレット・本番環境に触れるため、攻撃者の標的になりやすい領域です。GH-200 の最終ドメインは、ワークフローを 安全に設計 する実践を問います。中心となる原則は 最小権限・信頼できるコードだけを実行・長期シークレットを持たない の 3 つです。

5.1.1スクリプトインジェクションの緩和

スクリプトインジェクション は、PR タイトルや Issue 本文・ブランチ名などの 信頼できない入力 を run: のシェルコマンドに直接埋め込むと起きます——攻撃者が ${{ github.event.issue.title }} に悪意あるコマンドを仕込むと、ランナー上で実行されてしまいます。緩和策は、信頼できない値を run: に直接展開しない（中間の 環境変数 に入れて "$VAR" のように 引用 して使う）、入力の検証/サニタイズ、最小権限 の付与、そして可能なら インラインスクリプトより検証済みアクション を使うことです。

5.1.2GITHUB_TOKEN の最小権限と PAT との対比

各実行に発行される GITHUB_TOKEN は 一時的（ephemeral） で、ジョブ終了とともに失効する スコープ付き の資格情報です。permissions: キーで contents: read のように 最小権限 に絞り、書き込みが要るジョブだけ昇格させます。一方、個人の PAT（Personal Access Token） は長期間有効で広い権限を持ちがちなため、ワークフローでの常用は避け、必要な場合もシークレットに保存して最小スコープにします。原則として「まず GITHUB_TOKEN、足りない時だけ最小スコープの別資格情報」です。

5.1.3OIDC によるクラウド連携

AWS・Azure・GCP などへデプロイする際、長期のクラウド資格情報をシークレットに保存する のは漏洩リスクが高い方法です。代わりに OIDC（OpenID Connect） を使うと、ワークフローが実行ごとに 短命のトークン（id-token 権限） を取得し、クラウド側がそれを信頼して 一時的な資格情報 を発行します。これにより 長期シークレットを排除 でき、リポジトリ/ブランチ/環境などの条件で きめ細かく信頼 を絞れます。permissions: id-token: write を付与し、クラウド側に信頼ポリシーを設定するのが定石です。

5.1.4信頼できるアクションと来歴（provenance）

サードパーティアクションは サプライチェーンの一部 です。信頼できる（検証済み）アクション を選び、コミット SHA でピン留め し、組織の 利用ポリシー（許可/拒否リスト） で統制します（第4章）。さらに、ビルド成果物には アーティファクトのアテステーション／来歴（provenance） を生成・検証して「どのワークフロー/コミットから作られたか」を証明でき、SLSA などの枠組みでサプライチェーンの完全性を高めます。デプロイ時にアテステーションを検証することで、改ざんされた成果物の混入を防げます。

5.1.5環境の承認ゲート

本番への変更は 環境（environment）の保護ルール で守ります——必須レビュアー による承認、待機タイマー、デプロイ可能な ブランチの制限、環境スコープのシークレットです（第1章で既出）。これにより「本番デプロイは人手の承認後にのみ実行」を強制でき、誤デプロイや不正な変更を防ぎます。承認ゲートは、最小権限・OIDC・SHA ピン留めと組み合わせて 多層防御 を構成します。

5.1.6この節のまとめ

• スクリプトインジェクション対策＝信頼できない入力を環境変数に入れ引用、検証、最小権限、検証済みアクション
• GITHUB_TOKEN は permissions で最小権限（一時的・スコープ付き）、長期 PAT は避ける
• クラウド連携は OIDC（id-token: write）で長期シークレットを排除、信頼を細かく絞る
• サードパーティは SHA ピン留め＋利用ポリシー、成果物はアテステーション/provenance、本番は承認ゲート