GitHub ActionsではSHAを指定してリスク回避しよう
レバテック開発部の松浪です。
先日、GitHub Actionsで使用されているtj-actions/changed-filesが侵害され、シークレット値がログに出力されてしまうという問題が発生しました。
NISTに公開された情報を確認すると
tj-actions changed-files before 46 allows remote attackers to discover secrets by reading actions logs. (The tags v1 through v45.0.7 were affected on 2025-03-14 and 2025-03-15 because they were modified by a threat actor to point at commit 0e58ed8, which contained malicious updateFeatures code.)
と記載があり、短い期間ながらも全てバージョンで発生していたことがわかります。
プライベートリポジトリならともかく、OSSなどのパブリックリポジトリでシークレット値が流出していたとなったら何とも恐ろしい話ですね...
では、どうすればこの侵害の被害を防げたでしょうか?
完全な回避策はありませんが、タグのバージョンを指定するのではなく、SHA(ハッシュ値)を指定していれば回避できた可能性があります。
タグのバージョンを指定する使い方
GitHubで実行するアクションする際、タグのバージョンを指定していることが多いと思います。
下記の例だと、tj-actions/changed-filesは 最新版の v46.x.y
が使用されます。
steps:
- name: Get changed files
uses: tj-actions/changed-files@v46
タグのバージョンを指定するメリットとしては、
- マイナー/パッチバージョンが変わっても常に最新を利用できる
- 可読性が高い
というメリットがありますが、一方でデメリットとして、
- アップデートによって、YAMLの記載は変わらないのにアクションの挙動が変わる可能性がある
- 脆弱性が混入すると、脆弱性が含まれるアクションが実行されてしまう
というデメリットがあります。今回のtj-actions/changed-filesの問題は2つ目のデメリットが顕著に現れたと言えます。
パッチバージョンまで指定すれば安全?
@v46.x.y
という具合でパッチバージョンまで指定すればデメリットを回避できるのでは?と思った方もいらっしゃるかもしれませんが、残念ながらそうではありません。
と言うのも、タグが指すコミットは後から変更が可能です。
例えば、一度作成した v46.x.y
を削除して、脆弱なコードをコミットし、 v46.x.y
で再びタグを生成されれば、パッチバージョンまで指定していたとしても侵害の被害を受けます。
SHAを指定する使い方
タグのバージョンではなくSHAを指定することで、脆弱なコードが後から混入したとしても、その侵害の被害を回避することができます。
steps:
- name: Get changed files
uses: tj-actions/changed-files@2f7c5bfce28377bc069a65ba478de0a74aa0ca32 # v46.0.1
この 2f7c5bfce28377bc069a65ba478de0a74aa0ca32
はコミット時に発行され、その時のソースコードは不変で後から改ざんが困難です。
SHAを指定するメリットとしては、
- 常に同じコードが実行されるので、再現性が向上して予期せぬ挙動の変化が起きにくくなる
- 脆弱性が後から混入するリスクが軽減する
というメリットがありますが、一方でデメリットとして、
- 手動でSHAを更新する必要があり、アップデートが煩雑になる
- 可読性が低い
というデメリットがあります。
SHAを指定すると100%安全?
残念ながら、100%安全ではありません。悲
SHAで指定したアクションが、別のアクションをタグで指定して実行していた場合、今回のように侵害されたアクションが実行されてしまいます。
ただ、タグのバージョンよりもSHAを指定した方が安全なのは間違いないと思います。
GitHub Docsでもサードパーティー製のアクションを使用する際は、SHAの使用を推奨することが記載されています。
Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
まとめ
GitHub ActionsではSHAを指定するようにして、今回のようなリスクを回避しましょう。
Discussion