GitHub Actionsは、ソフトウェアサプライチェーン攻撃の主要な標的として急速に注目を集めています。新たに公開された2026年版 State of DevSecOpsレポートによると、実に38%の組織がスクリプトインジェクションや危険なトリガー設定ミスに対して脆弱なワークフローを抱えていることが明らかになりました。
さらに深刻なのは、3組織に2組織の割合で、少なくとも1件の重大な脆弱性がActionsまたはワークフロー内に存在している点です。
攻撃者はこうしたパイプラインが特権シークレット、ソースコード、デプロイ制御を日常的に扱っていることを熟知しており、価値の高い侵入口として狙っています。
ここ数カ月で、ワークフローの脆弱性を悪用した大規模な脅威キャンペーンが3件発生しています。「singularity攻撃」では、pull_request_targetトリガーを操作してNxに対して任意コードを実行させました。
「hackerbot-claw」と名付けられたAI駆動のキャンペーンは、信頼されていない入力を悪用し、標的の半数以上でリモートコード実行を達成しました。
一方、脅威アクター「TeamPCP」は窃取した認証情報を使い、TrivyやKICSといった信頼性の高いセキュリティツールを乗っ取り、悪意あるコードを無防備な開発者へと送り込みました。
多くのエンジニアはアプリケーションコードの入力検証には細心の注意を払う一方で、Infrastructure as Codeにおける同じ基本的なベストプラクティスを見落としがちです。ワークフローはプルリクエスト、ブランチ名、Issueコメントなどから直接データを受け取ることが少なくありません。
攻撃者が "; rm -rf / # のような悪意あるペイロードを含むプルリクエストを送信し、ワークフローがその入力をインラインシェルスクリプトにそのまま渡してしまうと、ランナーはインジェクションされたコマンドを実行してしまいます。この信頼されていない入力に対する脆弱性こそ、hackerbot-clawが標的を侵害した手口そのものです。
もう一つの一般的な攻撃手法が「pwnリクエスト」です。開発者はpull_request_targetトリガーをよく使用しますが、これは通常のプルリクエストには意図的に付与されない書き込み権限やシークレットへのアクセスが許可されるためです。
しかし、このトリガーのセキュリティモデルは、信頼されていないコードを一切実行せずに、信頼されていないメタデータのみを処理することを前提としています。
メンテナーが誤ってこれを通常のCIトリガーとして扱い、外部コントリビューターのコードを実行してしまうと、攻撃者は容易に権限昇格してパイプラインを乗っ取れてしまいます。
サプライチェーン攻撃では、窃取した認証情報を使ってバージョンタグを改ざんする手口も見られます。TeamPCPがTrivyを乗っ取った際、攻撃者は既存のリリースタグを悪意あるコードで上書きするだけで済みました。
71%の組織が依存関係を暗号学的なコミットSHAで固定せず、@v1のような浮動バージョンタグで参照しているため、パイプラインは自動的に攻撃者の改ざんしたソフトウェアをダウンロードして実行してしまいます。
Datadogのリサーチによると、GitHubはこうした脅威に対抗するべく、2026年セキュリティロードマップの中で積極的なプラットフォームアップデートを展開しています。
2026年9月までに、GitHubはすべての直接・推移的依存関係に対して決定論的なSHAロック実行を強制するためのdependenciesブロックをワークフローに導入する予定です。
また、pwnリクエストを排除するための一元的なガバナンスポリシーや、認証情報を明示的な実行コンテキストに厳密に紐付けるスコープ付きシークレットも提供される予定です。
2026年後半には、新たなエンドポイント保護とネイティブの出口ファイアウォールが導入され、セキュリティチームはランナーのトラフィックをリアルタイムで監視・制御できるようになります。
これらのネイティブ保護機能が広く普及するまでの間、各組織はYAML設定を積極的に監査し、危険なトリガーを取り除くとともに、固定されていない依存関係を厳格に管理することで、ソフトウェアサプライチェーンを守ることが求められます。
翻訳元: https://cyberpress.org/github-actions-injection-risk/
