--- title: "GitHub Actions workflowの依存をlockする、gh actions-lock" description: "gh actions-lockでGitHub Actionsのworkflow依存をコミットに固定し、lockファイルの検証とPolicyでの強制設定を試します。" createdAt: "2026-10-16T14:26:33+09:00" tags: [ソフトウェアエンジニアリング, GitHub Actions] --- 最近GitHub Actionsのサプライチェーン攻撃をよく耳にします。 workflowの依存を`{package}@{version}`の形式で指定して利用しているとき、そのタグが別のcommitを指すように動かされてしまい、なにもしていないのに脅威を踏んでしまうというのが、そのざっくりとした概要となります。 従来、この問題については、外部パッケージを利用するときにバージョンではなくコミットハッシュを直に参照することで、対応してきました。 これ自体が問題というわけではないのですが、せっかくバージョンごとにリリースされているのに、その恩恵を受けられず、毎回コミットハッシュを探してコピペする必要があるという点で、少し面倒な構造になっていました。 しかしそんな中登場したのが、今回紹介する`gh actions-lock`です。 まあ名前のまんまではあるんですが、GitHub Actionsのworkflowの依存をlockすることができます。 具体的な使いかたを見ていきます。 > [!NOTE] > 2026-10-16時点では、GitHub ActionsのlockfileはPublic Previewです。`gh actions-lock`もpre-1.0で、lockfileの形式やコマンドのフラグは変わることがあります。 ## 環境 - macOS 26.6.2 - gh version 2.102.0 ## インストール [インストール手順](https://github.com/github/gh-actions-lock)があるので、その通りに実行します。 ```bash title=gh-actions-lockのインストール ❯ gh extension install github/gh-actions-lock ``` 次のコマンドが通ればインストール完了です。 ```bash ❯ gh actions-lock -v actions-lock version v0.2.0 ``` ## 使ってみる 一旦無邪気に実行してみます。GitHub Actionsのworkflowが定義されているリポジトリに移動して、次のコマンドを実行します。 ```bash title=gh actions-lockを実行 ❯ gh actions-lock ✓ Pinned 4 actions (+ 1 transitive) across 2 workflows ... ``` 実行すると、workflowの`uses`が、その時点で解決された具体的なバージョンへ書き換えられます。たとえば`deploy-action@v3`のような指定は、指しているcommitはそのままで、`deploy-action@v3.1.0`のように具体化されます。あわせて`.github/workflows/actions.lock`というlockファイルが作成されます。 `actions.lock`はよくあるlockファイルと同様、バージョンと、対応するcommit hashが記録されています。 `actions.lock`にワークフローが登録されていると、そのジョブはタグが今指しているcommitではなく、lockに記録されたcommitを実行します。依存がlockに載っていない場合は、ジョブは実行されずに止まります。 ## gh actions-lock --verify `gh actions-lock`コマンドは`--verify`というオプションを用意しています。 これは、ファイルを書き換えずに、生成済みの`actions.lock`が今の参照と合っているかを確認してくれます。`main`や`v4`のようにブランチや部分バージョンでlockしている場合は、記録したcommitがまだそのrefの履歴に残っているかも見ます。 検証に失敗したときは、lockが古くなっていることを教えてくれます。 このコマンドは、CIとして動かして定期的に結果を確認できると良さそうです。 ## Organizationでの設定 例えば新規のworkflowを追加したときに、ついlockするのを忘れてしまい、`actions.lock`の恩恵を受けられないという場面が考えられます。 最悪の場合に、その処理漏れによってセキュリティインシデントに繋がってしまうことも考えられます。 そのようなことを引き起こさないために、Require lockfileというポリシーで、依存がlockされていないworkflowの実行を止められるようになっています。 Organizationの場合、`Organization > Settings > Actions > Policies`から設定可能となっていることを確認できました。(Repository単位でも設定可) ## まとめ 特別な理由がない限り、GitHub Actionsを利用している環境では導入しておいたほうがいい仕組みだと思いました。