GitHub Actionsの脆弱性とSHA固定化によるサプライチェーン対策例

GitHub Actionsの「uses: 」指定の脆弱性とサプライチェーン対策#

axiosで大規模なサプライチェーン攻撃が起きて騒がれ、先日もTanstackのnpmパッケージでも似たような事象が起き、物騒な世の中になってきたなと感じます。

最近、GiHub Actionsでの脆弱性への対策を行う機会がありSHA固定化について軽く調べたところ、 例えば、こちらの記事にも記載の通り、直近3月にはTrivy, 約１年前にはtj-actions/changed-filesといった、Github Actionsを対象としたサプライチェーン攻撃が相次いでいるとのことです。

例えば、GitHubでのCI/CDワークフローをよく構築される方ならお馴染みですが、workflowのステップ内に、

- uses: actions/checkout@v4

のような記述をするかと思います。uses: をしてすることで他人が公開しているアクションを呼び出すことができるわけですが、実質的にリポジトリを横断して外部のソースを実行することになるため、この部分を入り口とした攻撃が実際に起こり得てしまいます。

上記のv4のような指定方法ですが、これはGitのタグであり特定のコミットを指すポインタです。 攻撃者が予めv4タグを悪意のあるコミットを指すように向け直すことができてしまいますし、ユーザーから見ると例えばv4タグでの指定方法だと、どのコミットを指すのか完全にブラックボックスとなり攻撃にも気づくことができないというわけです。

推奨された対策#

そこで、公式から推奨されている方法では、コミットSHAを指定する方法があります。例えば以下のように固定化できます。

uses: ctions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4.3.1

（2025年8月15日には組織単位でこのルールが適用できる、SHA Pinningという機能がリリースされたようです。 https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/ )

これは完全にユニークなコミットを指すことになるため、意図しないコミットを参照することは無くなります。 ただし、このコミットSHAはアクションがバージョンアップされるたびに修正PRを作成する手間がかかるため、運用していくとなるとひと工夫が必要です。

対応策としては、上記のように# v4.3.1のようにコメントを記載しておきdependabptに定期的に拾ってもらうか、もしくは最近だと pinact という方法があります。 pinactは、ワークフロー内を検査しコミットSHAではないアクションを見つけ検知や修正をしてくれるCLIです。これを定期的に実行させることである程度の運用緩和になりそうです。

おわりに#

コミットSHAは割と昔からあった対策ですが、最近だとnpmパッケージのサプライチェーン攻撃対策として、min-release-ageといった指定された日数以上前に利用可能なバージョンのみインストールされる（新すぎるバージョンは入らない）オプションも追加されたりしているようです。

最近話題になる事例を考えると、セキュリティに対しての意識を高めていかなければなと気が引き締まる思いです。