GitHub Actionsタグ改ざんに備える: CIサプライチェーン侵害のインシデント対応プレイブック
参考: https://news.ycombinator.com/
CIのサプライチェーン侵害は、もはや例外的事故ではありません。GitHub Actionsタグの改ざん、依存物汚染、artifact経路の悪用によって、日常の自動化が攻撃チャネルに反転します。難しいのは検知そのものより、不確実性が高い状況で停止判断と復旧判断をどう切るかです。
前提: workflowの信頼は“取り消し可能”とみなす
タグ参照は便利ですが可変です。インシデント時には、mutable参照を全て暫定不信として扱うべきです。
初動で実施する統制:
- 非クリティカルなデプロイを一時停止
- 外部action参照をcommit SHA固定へ切り替え
- CIで使う高権限トークンを即時失効・再発行
まず解析のための安全な時間を確保します。
実行事実ベースで時系列を再構成する
推測より先に、workflow証跡を順序立てて集めます。
- run IDと実行時刻
- 実行時に解決されたaction参照
- runner種別（hosted/self-hosted）と外向き通信ログ
- その時点で有効だったsecretと権限スコープ
攻撃者意図を先に決めると、証拠解釈が歪みます。
シークレット漏えい評価の実務
全runを同一危険度で扱うと対応が遅れます。次で層別化します。
- ジョブ文脈で参照可能だったsecret
- そのsecretが外部操作可能な権限を持つか
- ログ/artifactに不審エンコードや送信痕跡があるか
影響tier順にローテーションし、高影響資格情報は漏えい確度が低くても先行更新します。
self-hosted runner隔離の原則
self-hosted runnerは柔軟ですが、侵害時の影響範囲が広がります。
- 該当runnerグループを即時隔離
- キャッシュ済みツールチェーン/レイヤーを破棄
- 既知良性イメージから再構築し整合性を証明
再イメージなしで復帰させるのは典型的な再発要因です。
連絡系統を分離する
情報混線を防ぐため、受け手別にチャネルを分けます。
- 経営/ステータス向け: 影響範囲と事業リスク
- 技術対応向け: 封じ込めタスクと証拠収集
- CS/法務向け: 開示要件と対外説明タイムライン
1チャネル混在は、技術対応も対外説明も遅らせます。
封じ込め後の恒久対策
復旧後に入れるべき統制を明文化します。
- SHA固定を必須化し、CIで逸脱を拒否
- 許可actionレジストリとオーナー情報管理
- 長期秘密鍵からOIDC短命資格情報へ移行
- provenance/attestation検証をゲート化
“気をつける”ではなく、技術的に通らない状態を作ります。
復旧判定基準
デプロイ再開前に、明確な復旧条件を満たす必要があります。
- 重要secretの再発行・疎通検証完了
- runner群の再構築またはクリーン証明
- 不審参照の排除確認
- 追加検知ルールの稼働確認
「CIが緑に戻った」だけでは安全証明になりません。
組織的な学びを残す
多くの事故は、技術だけでなく所有権設計の欠落を示します。
- workflow依存のオーナー不在
- CIトークン権限過大
- 監査証跡保持不足
事後レビューで責任者と測定指標を明確化し、次回の初動時間短縮につなげます。
まとめ
タグ改ざんインシデントは、DevSecOps成熟度の実地試験です。信頼を素早く取り消し、実行事実を再構成し、より強い統制で配信能力を回復できる組織ほど、被害と信用毀損を最小化できます。
