GitHub Actionsの依存関係ロックファイルがパブリックプレビューへ ― 「動く参照」のサプライチェーンリスクをコミット固定で抑える

GitHub は2026年10月14日、GitHub Actionsのワークフローが使うアクション(と、その先の依存アクション)をコミット単位で固定する「ワークフロー依存関係ロックファイル」をパブリックプレビューとして公開しました。ワークフローが参照するタグやブランチは、レビューを通した後でも、別のコミットを指すように変わることがあります。アクション自体が侵害された場合、ワークフローファイルを一切変更せずに悪意あるコードが混入する――この経路を、ロックファイルは「レビュー済みのコミット」への固定で抑えます。ただし依存関係そのものの安全性を判定する機能ではなく、固定する前のレビューは引き続き必要です。

攻撃の実例 ― タグ参照はなぜ危険なのか

GitHubが2026年3月に公開した「2026 Actions security roadmap」は、この機能を検討した背景として、tj-actions/changed-files・Nx・trivy-actionへの実際のサプライチェーン攻撃を挙げています。被害規模やCVE番号までは記事に明記されていませんが、典型的な攻撃の型は共通しています。脆弱性によって信頼されていないコードが実行される、悪意あるワークフローが可視性や制御なしに動く、侵害された依存関係が多数のリポジトリに波及する、過剰な権限を持つ認証情報が外部に流出する――この4段階です。

根にあるのは、タグやブランチという「動く参照」です。ワークフローが actions/checkout@v4 のようにタグで参照している限り、v4 が指す先のコミットは後から書き換えられます。工場の部品棚でいえば、同じラベルのついた箱の中身が、レビューした後にこっそり差し替わるようなものです。レビューの時点で安全だったコードが、実行の時点では別のコードに変わっていても、ワークフローファイルそのものは何も変わっていないので、見た目では気づけません。

私たちが運用する複数のリポジトリのワークフローも、actions/checkout@v4 や actions/setup-node@v4 のようなタグ参照が標準の書き方になっています。コミットSHAへの固定は手動でもできますが、GitHub自身が指摘するとおり、大規模に運用するのは難しく、読み込んだアクションがさらに別のアクションを読み込む「推移的な依存関係」は手動ではほとんど見えません。

固定するもの、固定しないもの ― lockfileの境界線

ロックファイルが解決するのは、この「動く参照」そのものです。.github/workflows/actions.lock に、ワークフローが使うアクションと、その先の推移的な依存関係のコミットSHAを記録し、オンボーディング後はGitHub Actionsが記録済みのコミットだけを実行します。ファイルを変更せずにロックファイルが最新かどうかを検証する陳腐化チェックもあり、CIのチェックに組み込めます。

ただし、GitHub自身が明記しているとおり、ロックファイルは依存関係そのものの安全性を判定する機能ではありません。固定するのは「レビューした時点のコミット」であって「安全性が確認されたコミット」ではないので、固定する前のレビューは変わらず必要です。lockfile は手動で編集しない前提のファイルでもあります。

導入手順 ― gh拡張で段階的に

導入にはリポジトリへのwrite権限が必要です。手順は gh extension install github/gh-actions-lock で拡張をインストールし、リポジトリのルートで gh actions-lock を実行するだけです。.github/workflows/ 配下の全ワークフローをスキャンし、解決可能な各アクションをコミットSHAに固定してロックファイルを書きます。個別のワークフローだけを対象にする場合は、gh actions-lock .github/workflows/ci.yml のようにパスを渡します。

オンボーディングはワークフロー単位で段階的に進められます。GitHub Docsは、先にDependabotでActionsの依存関係管理を有効にしておくことを推奨しています。オンボーディング済みのワークフローでアクションのバージョン更新PRが作られる際は、同じPR内でロックファイルのエントリも再生成されます。Dependabotは自動でワークフローをオンボーディングしないので、未登録のワークフローの依存更新を検知した場合は「オンボーディングが必要」という報告だけを行います。

本番適用はまだ計画次第 ― パブリックプレビューの現在地

この機能は2026年10月14日時点でパブリックプレビューであり、対象はGitHub Enterprise Cloud(データレジデンシー対応版を含む)です。他プランへの提供範囲は、GitHubのブログ記事内でも更新注記つきで扱われており、確定情報として書けません。

管理者が全社的にロックファイルを強制する「Require lockfile」ポリシーも、同時にパブリックプレビューの段階です。GitHubは2026年3月のロードマップ記事で、パブリックプレビューを3〜6か月後、GA(一般提供)を6か月後と見込んでいました。10月14日時点でまだパブリックプレビューにとどまっているため、GAの時期は見込みの域を出ません。

まとめ

次の一手は、自分のワークフローで一度 gh actions-lock を実行し、どれだけのアクションがコミットSHAに固定されるかを確かめることです。実行するだけなら書き込み権限があれば試せ、ロックファイルをコミットするかどうかはその結果を見てから判断できます。

ここまでの話を圧縮すると、タグやブランチという「動く参照」が侵害されると、その参照を使う全ワークフローに即座に波及する一方、ロックファイルは参照をレビュー済みのコミットへ固定し、その波及を止めます。固定するのは参照であって、依存関係の安全性そのものではないので、レビューの手間を無くす機能として扱うのは誤りです。

私たちが見る限り、この機能の価値は「レビューを省く」ことではなく、「一度レビューした結果を、後から書き換えられないようにする」ことにあります。

関連

AI エージェントを業務で回すときの設計と運用については、CTO の note に書いています。

• Leadeas CTO｜note

出典

• GitHub Changelog「GitHub Actions workflow lockfiles in public preview」
• GitHub Docs「Workflow dependency lockfiles」
• GitHub Docs「Lock workflow dependencies」
• GitHub Blog「What's coming to our GitHub Actions: 2026 security roadmap」

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)