GitHub Actionsのバージョン指定 vs コミットハッシュ指定：どちらを使うべき？セキュリティ視点で解説

GitHub Actionsでライブラリ（Actions）を利用するとき、こんな書き方の違いを見たことはありませんか？

# バージョン指定（タグ）
- uses: actions/checkout@v5

# コミットハッシュ指定
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

私はこれまで「公式のActionsはバージョン指定、サードパーティはハッシュ指定」というルールで運用してきました。

しかし最近、公式のActionsもハッシュ指定しているワークフローを見かけることが増えてきました。

「これってやりすぎでは？」と思いつつ調べてみたところ、ちゃんとした理由があることがわかりました。今回は、このあたりのベストプラクティスを整理してみます。

そもそもバージョン指定（タグ）のリスクとは

- uses: actions/checkout@v5

この書き方、シンプルで読みやすいですよね。でも、セキュリティ的には注意が必要です。

タグは書き換えられる

Gitのタグは、リポジトリのオーナーがいつでも別のコミットに付け替えることができます。つまり、こういうことが起こりえます：

• 昨日の v5 と今日の v5 が、実は別のコードを指している
• 悪意のある第三者がリポジトリを侵害した場合、タグを悪意あるコードに付け替えられる

これはサプライチェーン攻撃と呼ばれる手法の一つで、実際に被害事例も報告されています。

コミットハッシュ指定のメリット

- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

一方、コミットハッシュを指定すると、この問題を回避できます。

不変性（Immutability）が保証される

• コミットハッシュはコードの内容に紐づいた暗号学的なIDなので、改ざんできない
• 実行されるコードが常に同一であることが保証される
• セキュリティ監査のときに「何が実行されたか」を正確に追跡できる

コメントでバージョン番号を併記しておけば、可読性も維持できます。

公式のActionsはバージョン指定で問題ない？

ここが悩ましいポイントです。結論から言うと、厳密にはリスクはあります。

GitHub公式の actions/* であっても、理論上はタグ書き換えのリスクは存在します。

ただし、実務上のリスクレベルはActionsの種類によって異なります。Actionsごとのリスクレベル

• 公式（actions/）
• リスク：低め
• 理由：GitHubが管理。侵害されればすぐニュースになる

• 著名なサードパーティ
• リスク：中程度
• 理由：メンテナのアカウント侵害リスクがある

• マイナーなサードパーティ
• リスク：高め
• 理由：攻撃対象になりやすく、監視も少ない

公式Actionsは「Immutable Releases」という機能でタグの改ざんを防ぐ仕組みを採用しているため、リスクは軽減されています。とはいえ、ゼロではありません。

結局どうすればいい？ベストプラクティス

プロジェクトのセキュリティ要件に応じて、以下のように使い分けるのがおすすめです。

パターン1：セキュリティ最優先のプロジェクト

金融、医療、インフラ系など、セキュリティが最優先の場合は公式Actionsでもハッシュ指定が推奨されます。

- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af # v4.1.0

パターン2：一般的なプロジェクト

多くのプロジェクトでは、このバランスで十分です。

# 公式 → タグでOK
- uses: actions/checkout@v4

# サードパーティ → ハッシュ指定
- uses: some-org/some-action@a1b2c3d4e5f6...

パターン3：個人開発・速度重視

全部タグ指定でも動きますが、リスクは認識しておきましょう。

補足：Dependabotを活用する

どちらの方式でも、Dependabotを有効にしておくとActionsの更新を自動で検知してPRを作ってくれます。

ハッシュ指定でも更新が楽になるので、ぜひ設定しておくことをおすすめします。

まとめ

使い分けの方針を整理すると、以下のようになります。

• 公式もハッシュ指定
• 推奨ケース：セキュリティ最優先、監査要件がある

• 公式はタグ、他はハッシュ
• 推奨ケース：一般的なプロジェクト

• 全部タグ指定
• 推奨ケース：個人開発、速度重視

最近公式Actionsもハッシュ指定する人が増えているのは、サプライチェーン攻撃への意識が高まっているからです。

私自身は、これまで「公式はタグでいいだろう」と思っていましたが、今回調べてみて考えが変わりました。

今後はプロジェクトの重要度に応じて、公式Actionsもハッシュ指定することを検討してみようと思います。

saratoga

フリーランスエンジニア

XYouTube

仕事にも趣味にも IT を駆使するフリーランスエンジニア。技術的な TIPS や日々の生活の中で深堀りしてみたくなったことを備忘録として残していきます。