GitHub Actionsのアクションバージョンをセキュアに指定する ── ハッシュ値、immutable tagからWorkflow-Level Dependency Lockingまで
2025 年 3 月に発生した tj-actions/changed-files の侵害インシデント (CVE-2025-30066) ではバージョンタグの書き換えが行われ、アクションをセキュアに指定することの重要性が改めて浮き彫りになりました。
本記事では、そのような対策として、すでに利用可能な以下の2つ
- コミットハッシュ
- immutable tag
2026年内のリリースが予告されている
- Workflow-Level Dependency Locking
について解説します。
ナイーブな指定方法の問題
GitHub Actions のサンプルに登場する uses: owner/action@v4 といった指定は、手軽ですが、提供側・利用側の双方で構造的な問題を抱えています。
提供観点
- Git のタグは書き換え可能です。別の commit に向け直せます
- タグのメジャーバージョンは動的です。
actions/checkout@v4のようなメジャータグは、新しい minor/patch が出るたびに移動します
利用観点
- 上記のようなことが起こると、ワークフローファイル内のバージョン指定は変わっていないのに、参照先が変わります。
つまるところ、uses: owner/action@v4 といった指定は、便利ですが immutable ではありません。
差し替えられない参照を作る方法は、公式には 2 つ提供されています。
コミットハッシュ値で固定する
@<Git コミット SHA> を直接書く方法です。Git コミット SHA は不変性が保証されます。
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
ハッシュ値だけではどのバージョンかわからないので、コメントでバージョン番号を補う運用とセットになります。
pinact のようなツールを使うと、ハッシュ値とコメントでのバージョン指定が簡単に実現できます。
依存関係をアップデートする Dependabot や Renovate といったツールもハッシュ値の更新に対応しています。
Organization やリポジトリレベルでアクションをコミット SHA にピン留め強制するオプションもあります。
なお、fork先でコミットを重ねる、Impostor Commit(なりすましコミット)については、zizmor など他のツールを併用する必要があります。
immutable tag を使う
GitHub が 2025 年 10 月 28 日に GA した immutable releases に対応したタグを使う方法です。
- uses: astral-sh/setup-uv@v8.1.0
設定だけを一見すると、従来と同じように見えます。
astral-sh/setup-uv のリリース一覧には "Immutable" の文字があります。
immutable releases を利用すると、一度払い出したバージョンの再利用はできません。リリースに問題があれば、どんな些細なコミットでも新しいバージョンで再リリースします。
v<Major>.<Minor>.<Patch> の形式で、v8 や v8.0 のようなメジャー・マイナーバージョンを提供すると、バージョンとリソースが 1:1 にならないという問題があります。
そのため、astral-sh/setup-uv などは、もう一歩踏み込み、v8 以降はメジャー・マイナーバージョンをリリースしないという方針を取っています。
To increase security even more we will stop publishing minor tags. You won't be able to use @v8 or @v8.0 any longer. We do this because pinning to major releases opens up users to supply chain attacks like what happened to tj-actions.
- uses: astral-sh/setup-uv@v7
をアップデートするときは
- uses: astral-sh/setup-uv@v8
ではなく
- uses: astral-sh/setup-uv@v8.1.0
のようにパッチバージョンまで指定しないと 空振りします。
immutable releases を有効化するには、リポジトリの Settings → General → Releases → "Enable release immutability" にチェックを入れます。
次世代の Workflow-Level Dependency Locking
GitHub は 2026 年 3 月下旬にセキュリティロードマップを発表しました。
2026年9月までにリリース予定の Workflow-Level Dependency Locking では、 Go の go.mod (バージョン) + go.sum (チェックサム) のようなモデルで、uses: セクションにはバージョンを、新規の dependencies: セクションにはバージョン + ハッシュ値を宣言します(つまり、バージョンとハッシュ値の不一致も検知可能)。go.sum が推移的依存関係もカバーするのと同様に、本機能は composite action のような入れ子の依存関係もカバーする予定です。
name: build-and-attest
on:
workflow_dispatch:
permissions:
contents: read
id-token: write
attestations: write
jobs:
build-and-attest:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/attest-build-provenance@v3
with:
subject-path: README.md
dependencies:
- github.com/actions/checkout@v6.0.1:sha1-8e8c483db84b4bee98b60c0593521ed34d9990e8
- github.com/actions/attest-build-provenance@v3.1.0:sha1-00014ed6ed5efc5b1ab7f7f34a39eb55d41aa4f8
- github.com/actions/attest@v3.1.0:sha1-7667f588f2f73a90cea6c7ac70e78266c4f76616
最後に
GitHub Actions のアクションをセキュアに指定する方法として、以下があります。
actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11のようにハッシュ値ピン留めastral-sh/setup-uv@v8.1.0のように immutable tag を使う(提供元が対応している場合)- 2026 年内にGoのgo.mod + go.sumのようなより強固な仕組み(Workflow-Level Dependency Locking)を提供予定
immutable release(tag)は、アクションの提供元にも依存するところがあるため、一貫性を優先して、まずはハッシュ値ピン留めから始めるのがおすすめです。
