先日、参照・利用用途で人気のGitHub Actionsの一部のアクションが利用者リポジトリを侵害する事件があり、オープンソース GitHub Actionsの公開・使用に伴う重大な脆弱性が露呈する事態となった。
新しいメンテナから公開されたバージョンに難読化された悪意のあるコードが含まれており、tj-actions/changed-filesアクションが一時的に乗っ取られる事態が発生し、GitHub ActionsのエコシステムにおけるCI/CDのセキュリティに関する懸念が開発者コミュニティで巻き起こった。
この事件で、GitHub Actionsのサプライチェーン自体がアタックサーフェイス（攻撃対象領域）になりつつあるという変化が浮き彫りになった。多くのガイダンスがワークフロー環境の強化に注力する一方、インポート用GitHub Actionsのセキュリティ調査に熱心なチームはほとんどないないのが現状だ。 こうしたセキュリティ上の欠陥が明らかになったことを受けて、アクションのピン留め、第三者による監査、ランナー強化実装などの新たなベストプラクティスを求める声が高まっている。
リポジトリでは、tj-actions/changed-filesアクションを用いたプルリクエストのファイル変更検出を行う。これは、条件付きCIワークフローとしては一般的な工程だ。だが、2025年3月、新しいメンテナから導入されたバージョン（v44）に、リモートコード実行が可能な難読化されたシェルコマンドが含まれる事態が発生した。 今回の悪意のあるリリースは短期間で検知・収束に向かったものの、いかに多くの開発者がGitHub Actionsを妄信的に利用しているかを可視化するには充分であった。
ユーザーがGitHub Actionsの最新バージョンにスクリプトのリモート実行の疑いが濃厚なcurlやbashの難読化されたパターンが含まれていると気づいたことから、今回の侵害が明らかになった。StepSecurity社によるペイロード解析の結果、GitHub ホストテッド ランナーから機密データが流出する可能性が確認できた。この結果を受けて、当該のペイロードの即刻削除とリポジトリの復元が行われている。この事件後、影響のあったプロジェクト全体の見直しとワークフローの一時差し止めが推奨される事態となった。
今回の件にこれほどの注目が集まるのは、侵害を受けたのが推定20,000以上のリポジトリで使用される認知度の高いアクションであったからだけではなく、この騒動自体がエコシステム内部の脆弱性の大きさを知らしめる事例となったからだ。多くの開発者がGitHub Actionsを信頼できるビルディングブロックとみなしているものの、パッケージやコンテナとは異なり、GitHub Actionsの公開、所有権の変更、署名の検証の管理において脆弱性があることは否めない。
事態を受けて、セキュリティリサーチャーやオープンソースメンテナーからユーザーへの緩和対策の迅速な共有が実施された。StepSecurity社は、サードパーティアクションのすべてを特定のSHAにピン留めの実行による再現性の確保や、タンパリング防止を推奨している。また、GitHubホストランナー機能を強化し、送信ネットワークアクセス権限の制限設定、環境変数の厳格なスコープ、不要なアクセス許可の削減を実施するよう奨励している。また一連の騒動をきっかけに、一部の開発者は、ワークフローのスキャンによるピン留めされていない依存関係の確認や依存関係のあるワークフローの監視といった、以前より慎重な姿勢をとるようになった。
今回の事件の影響は、個人のデポジトリ使用状況の変化だけには留まらなかった。CI/CDサプライチェーンにおけるセキュリティ上の懸念が広範囲にわたって再燃し、開発者フォーラムでも懸念の声が上がっているほか、業界全体の調査の実施を受けて潜在的な攻撃対象領域に関する詳細な調査報告が上がることとなった。だが、多くのチームが依存関係のスキャンや静的解析などのプラクティスを含めたアプリケーションコードのセキュリティ確保に注力する一方で、CI/CDツールまわりが見落とされることがある。GitHub Actionsには極めて高い権限が付与されており、リリース署名、イメージのプッシュ、本番環境へのデプロイが可能だ。そのため、GitHub Actionsのなかにアクションが侵害されたものが一つでもあれば、デリバリーパイプライン全体が崩壊しかねない。StepSecurity社では、ピン留めされていないアクションを使用する習慣がどこまで広まっているか把握しきれていないものの、使用に伴うリスクの強調や慎重な利用の呼びかけを繰り返している。
今回のGitHub Actionsが侵害を受けた事例では、悪意のあるnpmパッケージやトロイの木馬が含まれたDockerイメージといった、周辺領域におけるエコシステムで同様の問題を呼んでいる。業界はSLSA、Sigstore、SBOMツールのようなイニシアチブを通じて前進しているが、GitHub Actionsはまだ、証明、サンドボックス、再利用可能なActionsの信頼性執行のためのファーストクラスのサポートを欠いている。業界全体では、SLSA、Sigstore、SBOMツールといったイニシアチブにおける躍進を続けているが、GitHub Actionsでは、依然として再利用可能なアクションでのデータプロビナンス、サンドボックス、認証の有効化に必要なファーストクラスサポートが実装されていない。
GitHub Actionsエコシステムの監視が厳格化するにつれて、一部のエンジニアリングチームでは、サードパーティの自動化ツールの評価・導入に関する基準を設ける動きがあり、各GitHub Actionsの信頼性に関する自社定義の策定や統合前のレビュー実施が進んでいる。Salesforce社をはじめとした企業ではガードレール型アプローチの導入が行われている。こうしたアプローチの背景には、依存関係にあるアプリケーションの導入プロセスと同様の慎重さやガバナンスをCI/CDインフラの検討時に適応しようとする大きな変化がある。将来的にはエコシステムの導入検討プロセスも同様の工程を踏むことになるだろう。