緊急速報！GitHubの超人気Action「tj-actions/changed-files」が乗っ取り被害！2万3千以上のリポジトリに影響か
引用元：https://news.ycombinator.com/item?id=43367987
やあ、Renovateの作者兼メンテナーだよ。
問題のあったリポジトリはもう削除されちゃったから、記憶を頼りに書くね。たぶんこんな感じ。
1. 攻撃者がtj-actions/changed-filesリポジトリへの書き込み権限を持ってた。
2. 攻撃者はRenovateのコミットを装った。実際には、同じリポジトリの最新のコミットを偽装したんだ。それはRenovateからのものだった。
3. 重要：このコミットの偽装は、メンテナーを「騙して」PRを受け入れさせるためじゃなくて、ちょっとわかりにくくするためだけ。孤立したコミットで、mainとか他のブランチの上にあるわけじゃない。
4. 予想通り、コミットは未検証として表示された。でも、現実的にほとんどの人はそこを見ないし、署名付きコミットだけを強制しない（本物のボットはコミットに署名する）。
5. ちょっと関係ないけど、「本物」のRenovate Botは、Dependabotと同じように、アクションをアップデートするPRを提案し始めた。
6. 自動マージを有効にしてる人もいたけど、これはRenovateのデフォルトの動作じゃない。自動マージしなくても、PRの一部として実行されれば、目的を達成できるかもしれない。
7. 今回の件で、多くの人がgitタグが不変だと誤解してることを思い知らされた。セマンティックバージョンの形式でも、タグは変更できないわけじゃない。
＞7. 今回の件で、多くの人がgitタグが不変だと誤解してることを思い知らされた。セマンティックバージョンの形式でも、タグは変更できないわけじゃない”
たぶん、これは「思い出す」より「学ぶ」って感じだね。多くの人がタグに基づいて成果物を作成するパイプラインを設定してる（例えば、「特定のパターンを持つタグで、成果物：＄tagを作成する」）。
みんながやってるからってだけで、基本的なトレードオフを知らずに採用してるんだよね。Semverも同じようなケースで、特定の文字列でソフトウェアをラベル付けすると、魔法のように動作が保証されると信じてる人が多い。
新しいコミットで自動マージが無効にならないことに気づいた時、この脆弱性について考えたことがあったんだ。これはGitHubのありえないデフォルト設定だよ。
追記：GitHubもついに気づいた（または気にするようになった）みたい。テストしてみたら、自動マージがサイト全体で無効になってるみたい。設定は有効になってるのに、PRを自動マージするオプションが表示されない。
やっぱり心配してた通りだ！
追記2：GitLabのCIでも同じことをテストしてみた。あっちではちゃんとやってるみたい。自動マージの有効化は、有効にしたコミットに対してのみ有効で、新しいプッシュは自動マージを無効にする。こっちの方がずっと安全だ。
タグは署名できるし、署名を検証することもできるよ。コミットの署名や検証と同じくらい簡単。タグを作成する時に、署名をデフォルトのオプションにすることだってできる。
今回は役に立たないけどね。なぜなら、正当なボットが悪意のあるコミットで動作するように騙されたから。騙されたボットは、正当なキーでタグに署名することもできる。
「不変のタグ」はもちろん存在する。それはコミットハッシュだけど、情報がないね…。
コミットハッシュで。
SHAで固定するだけじゃ不十分みたい。Renovate botがSHAで参照されるアクションをアップデートしてた。
例：https://github.com/chains-project/maven-lockfile/pull/1111/f…
これはrenovate.jsonで設定されたpinGitHubActionDigestsヘルパーによって制御されてるみたい。
＞6. 自動マージを有効にしてる人もいたけど、これはRenovateのデフォルトの動作じゃない。自動マージしなくても、PRの一部として実行されれば、目的を達成できるかもしれない”
PRを作るだけでどうやって悪用できるのかわからないな。もし理由があって、知らないコントリビューターによるビルドに対してシークレットを有効にしてるなら、それは明らかに間違いだ。通常、シークレットを使用するビルドは、特定のブランチでのみ実行され、そこには承認されたコードが配置されているはず。
＞多くの人がgitタグが不変だと誤解してる”
もしGitHubでライブラリを配布していて、多くの人がそれを使っているなら、protected branchesとprotected tagsを設定する必要がある。変更をある程度防げるよ。
＞PRを作るだけでどうやって悪用できるのかわからないな。もし理由があって、知らないコントリビューターによるビルドに対してシークレットを有効にしてるなら”
今回の件では、Renovate botがインストールされたリポジトリにPRを作成するから、信頼されたコントリビューターとしてCIビルドをトリガーできる。
Branch Protectionも新しいRulesetsも、リポジトリへのプッシュアクセス権を持つ人からシークレットを保護することはできないんだよね。私が理解している限り、environment secretsだけがこの機能を提供してる（同じ組織内の複数のリポジトリ間で共有できないという欠点があるけど、GitHub APIを使ってコピーできる）。
コメントありがとねー。前からそうだったけど、今回の件でサプライチェーンのセキュリティについて、マジで色々考えさせられるよね。
記事サンキュー！#1がマジ弱点だったみたいだね。攻撃者がtj-actions/changed-filesに書き込み権限を得た方法って特定できた？今回の件で、プロジェクトへの貢献方法とか変わったりしたのかな？
ステップ1から4までは理解できたんだけど、ステップ5がどうトリガーされたのか分からん。リリースとかmainブランチの外でorphan commitしたってこと？
最近、サードパーティの依存関係とか拡張機能とか、マジで信用できなくなってきた。npmパッケージもtransitive dependenciesが少ないやつしか入れなくなったし、vscodeとかChrome拡張機能もあんま入れなくなったわ。
だって、乗っ取られて悪意のあるコードが追加されたり、開発者自身が裏切って悪意のあるコードを注入したり(Moqとか)、会社に売られてライセンスが変わって金払わないと使えなくなったり(FluentAssertionsとか)するんだもん。eslintのdependency tree見てみ？全部信用できる？
＞本当に全部信用できる？
もっと良い仕組みが必要だよね。
例えば、fdとかrgみたいなツールを実行するとき、なんでインターネットアクセスが必要なんだ？
IMHO、全てのツールのインターネットアクセスを禁止する（パワーモードとかで）だけで、この問題解決するかも。
あと、CIとCDが一緒になってるのも問題。production/release tokensは、通常のCIとは別のシステムにあるべき。CIはCDよりも多くのユーザーがアクセスする必要があるからね。
似たような事例だと、数ヶ月前にこんなのもあったよ。
https://blog.yossarian.net/2024/12/06/zizmor-ultralytics-inj…
仮想マシンで開発するようにして、色々制限してる。ブラウザもVMで使うようにした。
PCの性能も上がってるから、VMのオーバーヘッドも気にならないしね。
開発環境にはVagrantを導入するのが良いと思う。
https://www.qubes-os.org/
これも同じ考え方だね。
Qubesは使い勝手が微妙だから、オススメしにくいかな。
何回か試したけど、まだ改善が必要だと思う。ユーザーエクスペリエンスを誰かが見直すべき。
Qubesが何やってるか完全に理解できてないから、逆にセキュリティが下がってるんじゃないかって不安になる時がある。個々の要素(Xenとか)は理解してるんだけどね。
あと、3D系のパフォーマンスは期待できないと思う。それと、Snowdenの名前を大々的に出してるのは怪しい気がする。
メインのワークステーションはMacで、ParallelsでVMを立ててる。Qubesの方が安全かもしれないけど、使い勝手が悪い。
OpenBSDのpledge[0]システムコールは、この問題に対処するためのものだね。ただ、これはメンテナー側のdefense-in-depthであって、ユーザー向けではないけど。
＞The pledge() system call forces the current process into a restricted-service operating mode. A few subsets are available, roughly described as computation, memory management, read-write operations on file descriptors, opening of files, networking (and notably separate, DNS resolution). In general, these modes were selected by studying the operation of many programs using libc and other such interfaces, and setting promises or execpromises.
[0]:
https://man.openbsd.org/pledge.2
Pledgeは自己隔離のためのもので、ミスには有効だけど、意図的なサプライチェーン攻撃には効果ないよ。
え、マジで？パッケージレベルじゃ効果ないのは明らかだけど、GitHub runnersとかNode自体が”制限”モードに入る機能を付けて、それを約束したら良くない？
openbsd.orgの論文によると、pledgeはexecveでオフになるらしいよ。ランナーで使うには制約がキツすぎかも。基本的にはCベースのアプリの脆弱性に対する防御策って感じかな。Nodeランタイム自体の脆弱性は少ないから、もっと細かい制限を実装できるかもね。 firejailが便利だよ(github.com/netblue30/firejail)。opensnitch(github.com/evilsocket/opensnitch)で予期しないネットワークリクエストを監視してる。ArgoCDみたいなのを使えば、CIからprodへの直接アクセスを防げる。gitリポジトリへの書き込みアクセスは必要だけどね。 FreeBSDにはCapsicumがあるよ。プロセスがcapabilityモードに入ると、開かれたファイルディスクリプタしか使えなくなる。サブプロセスをspawnしたり、ネットワークに接続したりはできない。[0] wiki.freebsd.org/Capsicum [1] docs.kernel.org/userspace-api/landlock.html 書き込みアクセスもブロックしないと、埋め込まれた公開鍵でファイルを全部暗号化されちゃうよ。読み込みアクセスもブロックしないと、タイミングサイドチャネル攻撃で機密ファイルを読み取って、ネット権限のある別のプロセスに情報を渡されるかもね。わかるでしょ？ ＞You also need to block write access, so they can’t encrypt all your files with an embedded public key. And read access so they can’t use a timing side channel to read a sensitive file and pass that info to another process with internet privileges to report the secret info back to the bad guy. You get the picture, I’m sure.” ＞1. Mount current read-only directory to Docker without Internet access (and without access to local network or other processes) 2. Run マジつまんなくなるよね。オンラインで買い物するときにSSL使わないといけなくなった時みたい。SSLは悪くないよ。今じゃデフォルトだし。でも、昔はちょっとリスキーだったし、今は必須。車をロックしないと盗まれるからロックしないといけないみたいな。 キーフォブの時代だと、車をロックするのはほぼ自動だよね。車が自動でロックしてくれることもあるし。特に何も思わないなぁ。 マジそれなー。ブラウザのプラグインも同じ。無料プラグインの作者が、プロジェクトの買い取りオファーを頻繁に受けてるって話、よく聞くじゃん。絶対、そのオファーに乗るやついるって。 こういうオファーのヤバいリストの例としては、https://github.com/extesy/hoverzoom/discussions/670 を見るといいよ。 だから、俺はuBlock以外は拡張機能をフォークしてるんだよねー。GitHubで見つからない場合は、拡張機能のフォルダをコピーするだけ。そうすれば、コードを監査できるし、ヤバいものが勝手に紛れ込んでくる心配もないし。過去に2つの拡張機能が、明らかに必要のない許可を求めてきたことがあって、多分これが原因だと思うんだよね。 マジ感謝！crx explorerへのリンクもありがとね！俺も似たようなことしてて、機能の一部しか使わないアドオンをいくつか置き換えるために、自作のアドオン書き始めたんだよね。例えば、Chromium使うとき、１．新しいタブページをカスタマイズしたい、２．タブのピン留め／ピン解除のキーボードショートカットを追加したい。どっちも拡張機能の一部だけど、セキュリティリスクもあるし、重いんだよね（全部入りじゃなくて、必要なのは２つのマイクロ機能だけ！）。だから、リソース消費ゼロの、たった２つの機能だけの個人的なアドオン作ってる。小さいし（20行のコード！）、gitでバージョン管理してるし、変わることも乗っ取られることもない。マイクロ機能が必要になったら、アドオンのドキュメント検索したり、LLMに聞いたりすれば簡単に追加できるしね。 メニュー項目のキーボードショートカットを追加するためだけに拡張機能を使う必要ないんじゃない？OSでマッピングできるんじゃないの？macOSならキーボード設定でできるよ。 無駄じゃないよ。拡張機能の作者がどれくらいの規模で買収オファーを受けてるかを示してるんだから。買い手が誰かは重要じゃない。 俺は、ちゃんとした会社が作ってない拡張機能は、もうずっと使ってないなー（パスワードマネージャーとか）。インストールしたときはマルウェアじゃなくても、売られたらそうなるから。 .NETとかJavaって、ライブラリごとに権限を設定するみたいな考え方があったんだよね。それって、今の時代にマジで必要だと思う。評判とか簡単に操作できるし。例えば、このactionがネットワークにアクセスする必要なんてマジでないじゃん。 .NET以外で、こういうタイプのactionって他に例ある？FluentAssertionsの件は知ってたけど、Moqは初めて聞いた。全然知らなかったわ。 node-ipcってのが最近あったね。作者がアップデートで、geolocationのwebserviceにアクセスして、ローカルのファイルを消すかどうか決めるコードを仕込んだんだって。 暗号通貨を盗むのがめっちゃ儲かるからね。今まではなかった市場があるんだよ。だからセキュリティがマジで重要になってる。EmacsとかPythonのパッケージも信用できないから、サンドボックス化し始めたわ。 根本的な解決策は、オープンソースの持続可能な資金調達モデルを見つけることだと思う。みんな生活のためにプロジェクトを売るしかないから裏切りが起きるんだよ。 これマジ笑える。 スマホのアップデートも止めてる？みんなアプリの自動アップデートをオンにしてるけど、アップデートにはexploitが含まれてる可能性もあるんだよ。 だから、標準ライブラリが充実してる言語が好きになってきた。依存関係が少なくて済むからね。依存関係の管理がマジで大変になってきて、CVEの分析に時間取られすぎ。 言語を肥大化させる代わりに、信頼できる組織がライブラリをforkして、安全性を確認して、”お墨付きライブラリ”として再配布すればいいんじゃない？安全なライブラリを開発する方が、言語の機能を追加するより簡単だと思う。 信用はできるけど、盲目的にアップグレードしちゃダメ。ベンダーに頼るか、依存してるファイルの暗号学的ハッシュで固定するべき。アップグレードするときは、みんながアップグレードするまで待って、diffを自分で確認する。 これって今に始まったことじゃないんだよねー。Thompsonが40年前に「Trusting Trustに関する考察」で警告してたじゃん（もっと前から言ってた人もいると思うけど）。 依存関係を信頼するための解決策は、署名付きの公開ビルドと、手動レビューが必要なMLの”変なところ”検出器だね。 免責事項：私はStepSecurityの共同創業者です。 cyrnelさん、フィードバックありがとうございます！コミュニティに貢献できるよう頑張ります。現在、一般ユーザーとエンタープライズのお客様向けに個別の復旧手順を用意しています。 編集ありがとう！「インシデント対応モード」では、一瞬たりとも無駄にできないからね！ これを検出するもっと簡単な方法は、GitHub actionのタグハッシュを保存して、タグが変更された場合にactionをフリーズすることだね。 CI/CDのやり方が、GitHub上のランダムなリポジトリをただ列挙するだけってのが、いつもショックなんだよね。監査可能でバージョンを固定してるのは知ってるけど、サーバーにsshで接続する推奨方法が、GitHubのランダムなユーザーからランダムなパッケージにsshキーを渡すことだってのは、どうかしてると思う。 みんなバージョンを固定してないんだよね。タグを参照するのはバージョンを固定することじゃないし、GitHubの公式actionでも更新されることあるし。 GitHub Actionsのインストールって、READMEからコピペするのが普通じゃん？actions/checkoutの例だと GitHubと第三者を信用するのって違うと思うんだよね。GitHub信用できないなら、最初からGitHub Actionsなんて使う意味ないじゃん。タグの使い方はマジで問題あり。GitHubはタグの再発行禁止にすべき。どうしてもって言うなら、 ちゃんとバージョン固定してる人もいるよ。例えばこんな感じ: ＞It’s a bit more manual work github action dependencyを特定のtagのhashで指定して、dependabotが更新できるtagも指定する[1]ってやつ、結局botにやらせたら攻撃されやすくなるだけじゃん。 RenovateとかDependabotがhash更新PR作ってきたら意味ないよ。うちも先日こんなPRが自動で作られたし: Dependabotに直接commitさせちゃダメ。PRだけ作らせて、人間が確認してmergeするのが一番。真面目なリポジトリなら、botにcommit権限与えるのはセキュリティ的にヤバい。毎週何百も依存関係更新しなきゃいけないなら、技術スタックを見直すべき。 自動mergeしなくても、botは高い権限持ってること多いし（プライベートリポジトリ見れるとか）、PR作るだけでビルドジョブが実行されて、更新されたバージョンでsecretsが暴露される可能性もある。 セキュリティの観点から言うと、GitHub actionのhash更新を自動化するのは、ピン留めする意味がなくなる。 GitHub actionの“パッケージ”って、メジャーバージョンで指定するんじゃないの？ checkout@v4とか。それってv4の単一リリースを指定してて、更新されないと思ってたんだけど…違ってたらマジでヤバい。 いやいや、”v4”タグはv4.1からv4.2みたいに、マイナーバージョンがリリースされるたびにアップデートされるんだよ。機能的にはブランチみたいなもんさ。 その通り。今回起きたのはまさにそれで、悪いやつがそれらのバージョンタグを全部、自分の悪意のあるコミットを指すように変更しちゃったんだ。 もし間違ってたら訂正してほしいんだけど、”Rules”を使えば、タグのアップデートをブロックして、今回の問題を防げたんじゃないかな？ そうだけど、タグのアップデートはリポジトリのパッチをリリースするための事実上のメカニズムだから、そんなことするGitHub Actionはないと思うよ。 マジか、教えてくれてありがとう（他の人も指摘してくれて）。ヤバすぎ。 gitのSHAでActionを固定すれば防げるけど、普通はやらないよね。Actionの作者はアップデートが自動で適用されるのを好むだろうし。 もっとヤバいのは、みんなバージョンを固定してないこと！コミットハッシュを指定できるのに、タグやブランチ名を使うことが多い。それって簡単に変更できるし、実際よく変更されるよね（例えば、 マジかよ。またデフォルトが安全じゃないのか。バージョン指定子はハッシュだけであるべきだと思う。セマンティックバージョンなんて忘れろ（互換性の判断は別の方法でやれ。どっちにしろアップデートごとにセキュリティ監査が必要だ）。プロセスは、古いハッシュ、新しいハッシュ、diffコード、セキュリティ監査、互換性監査（semverはメタデータ）、テスト実行、新しいハッシュへのアップグレード。 あなたともう一人が指摘してたね。GitHub-orgのActionしか使ってないから、全部を管理するルールがあると思ってたんだけど…どうやって監査するんだ？ 一応、ここでおすすめとしてドキュメントに書いてあるよ： それやるには ほんとそれ。 マジそれ。 ＞CI/CDのやり方が、 イミュータブルなもっとコメントを表示（1）
マジそれ。
攻撃対象領域を減らすには、ざっくり以下の能力を制限するのが有効だよ。
1. 読み取り専用アクセス vs 読み書き
2. カレントディレクトリとそのサブディレクトリのみへのアクセス
3. 設定可能なインターネットアクセス
Dockerはだいたいできてる。Dockerでコマンドを簡単に実行できたらいいのにな。fd 3. Print the results 4. Destroy the container
Systemdには便利なサンドボックス機能があるんだけど、あんまり知られてないんだよね。systemd-runを使えば、かなり良い感じにできるよ。
bubblewrapも使えるけど、sudoいらないかも。
ちなみに、拡張機能のソースコードをインストールする前に確認できるサイトはここだよ：https://robwu.nl/crxviewer/
問題は経済的、社会的なもの。
今は企業がオープンソースのメンテナーを搾取してる。webpackみたいに人気で資金が集まるプロジェクトは稀で、webpackが依存してるプロジェクトのメンテナーは一銭ももらってないってのは不公平じゃない？
資金調達に加えて、再現性のあるビルド環境が必要。GitHubがコードの唯一のソースみたいになってるけど、リスク高すぎ。go mod vendorみたいに依存関係を固定するのはいいけど、サプライチェーンで問題が起きたときの対応が大変。もっとコメントを表示（2）
＞Lewis Ardernって人がSemgrepのルールを書いたから、tj-actionsを見つけられるよ。ローカルで実行できるって。
「リモートのコードがヤバいから、リモートのコードをダウンロードして実行して探せ」ってこと？
パッケージマネージャーとか信用しないのはわかるけど、生活は同じようなもので溢れてる。ほとんどのアプリはサードパーティのライブラリで出来てるし。スマホは常にアップデートされるし、アップデートの度にexploitがインストールされる可能性がある。
AppleとかMicrosoftとかGoogleはサードパーティの依存関係をチェックしてると思うけど、他の会社は信用できない。でも気にしすぎてもしょうがない。アップデートしないとセキュリティホールが修正されないし、アップデートするとexploitが紛れ込む可能性がある。
Goの「ちょっとコピーする方が、ちょっと依存するよりマシ」って格言もあるし。複雑なライブラリの簡単な関数が必要なら、自分のコードにコピーすればいい。
最近、90年代初頭の議論をいろいろ調べてて、その時に考えさせられてるんだよね。当時「モバイルコード」って呼ばれてたものの安全な実行について。怪しいクライアントがリモートサーバーで実行するために送ってくるコードのことね。
w3のおかげで、当時の議論がまだたくさん残っててありがたいんだけど、論文のほとんどは会社とか大学のリンク切れだらけなんだよね。
WWWの初期に、すごく賢い人たちが考えてたのに、いつの間にか忘れ去られちゃったのが不思議だわ。Denoのpermissionsは、当時のアイデアの現代版としては一番面白いけど、ちょっと物足りないかな。「利用規約に同意しますか？」疲れの問題もあるし、特にweb開発だとね。web開発で使うパッケージって、ネットワークアクセスが必要なものが多いから、「まあ、そうだよね」って思っちゃうのも無理ないよね。
それに、ビジネスニーズ（あるいはそう思われてるニーズ）のために存在するコードのことも考えるとね。レポート作成アプリの何千ものパッケージを監査するために1週間か2週間必要だってボスに言ってみてよ。
StepSecurity Harden-Runnerは、GitHub Actionsワークフローからのアウトバウンドネットワーク呼び出しを継続的に監視し、予想される動作のベースラインを生成することで、このセキュリティインシデントを検出しました。侵害されたtj-actions/changed-files Actionが実行されたとき、Harden-Runnerは、ネットワークトラフィックに予期しないエンドポイントが出現したため、フラグを立てました。これは、確立されたベースラインから逸脱した異常です。プロジェクトはこちらから確認できます：https://github.com/step-security/harden-runner
LLMの台頭で、これは特に問題になってくると思う。”GitHub actionsからこのプロジェクトをビルドしてデプロイする必要がある”みたいなのから生成されたGitHub actionsがたくさんあると思うんだよね。自分はsshとかキー関連の重要なことは手動で実行するようにしてるけど、そうじゃない人もいるだろうし。uses: actions/checkout@v4って書いてあるから、みんなそのまま使うよね。v4が書き換え可能だなんて思わないって。npm/yarnみたいにlockfileでバージョン固定してくれないし。せめてActionの作者がREADMEにsha256載せてくれたらいいのにね。GitHubがデフォルト良くないから、みんな同じことするんだよ。uses: actions/checkout@v4.5.6@abcdef9876543210みたいな構文で、タグとcommit両方指定できるようにしてほしい。根本的な解決にはならないけどね。結局、信用できないリポジトリ使わないのが一番大事。
- uses: Swatinem/rust-cache@f0deed1e0edfc6a9be95417288c0e1099b1eeec3 # v2.7.7
- uses: subosito/flutter-action@f2c4f6686ca8e8d6e6d0f28410eeef506ed66aff # v2.18.0
ちょっと手間だけど、用心に越したことないってポーランドのことわざにもあるし。
今回の件で、GitHub workflows全部ハッシュで固定するようにしたよ！手作業でやるのめんどくさくなったから、[0]に簡単なスクリプト作った。workflowファイルを全部更新してくれるし、pre-commit hookとしても使える。大したもんじゃないけど、時間節約になるから共有するね。
[0] https://github.com/brokenpip3/pre-commit-hooks?tab=readme-ov…
[1] https://github.com/brokenpip3/pre-commit-hooks/blob/f01df657…
-uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567 # v3
+uses: docker/login-action@74a5d142397b4f367a81961eba4e8cd7edddf772 # v3
しかもこのPR、書き込み権限のあるユーザーから来るから権限ありで実行されちゃう。もっとコメントを表示（3）
詳しくはここを見て
https://github.com/tj-actions/changed-files/tags
すべてのタグがコミット^0e58ed8を指してる。
https://github.com/tj-actions/changed-files/commit/0e58ed867…
https://github.blog/news-insights/product-news/github-reposi…v3がv3.5.1からv3.5.2に更新されるとか）。
GitHub Actionsで特定のコミットハッシュを指定するように推奨されてるのを見たことない。いつもv1とかv2とか。
https://docs.github.com/en/actions/security-for-github-actio…foo/bar@commitshagoeshereって書くんだって。
例：uses: RafaelGSS/bad-action@e20fd1d81b3f403df56f5f06e2aa9653a6a60763 # v1.0.1
(https://blog.rafaelgss.dev/why-you-should-pin-actions-by-com…から)tagsは公式のGitHub actionsだけにしとくべき。他は全部pin止めしとくべきだね。OpenSSF scorecardは、hashでpin止めされてない依存関係(GitHub actions含む)にフラグ立てるよ。
https://scorecard.dev/
https://github.com/ossf/scorecard/blob/main/docs/checks.md#p…ssh/rsyncにactions使わなきゃいけないのがずっとイヤだったんだよね。最近、直接コマンド使うように変えたんだ(ちょっと面倒だけど)。GitHub Actionsの欠点は、サードパーティのactionsが広まりすぎてることだと思う。「GitHub actions ssh」で検索したら、公式ドキュメントが一番上に来るべきなのに、サードパーティのactionsの例ばっかり出てくる。GitHub Actions使おうとしたけど、公式ツールとドキュメントが充実してたGitLabにしたわ。俺のニーズはシンプルなんだ。ちょっとしたスクリプト書くだけでも、コードとdepsが多いサードパーティのrepoを監査するよりマシ。
あと、初心者だと、actionがただのランダムなrepoだって気づかないかも。GitHub上のランダムなrepositoryをリストアップするだけってのが信じられない。
わかる？俺のCIのイメージは「定義済みの環境で、自動化されたコマンドの連続」なんだよね。再現性と並列処理のために、ちょっといい感じにしたbash scriptsの集まりみたいな。
それを、ベンダーロックされたブラックボックスな”Actions”に変えるのは…CI本来の価値を薄めてる気がする。github actions[1]の話が出てないのが意外。2022年からずっと待ってるんだよね。これが実現すれば影響はかなり小さくなるはず。githubには頑張ってほしい。
俺はいつもactionsをフォークするか、少なくともcommit hashを使うようにしてる。
[1] https://github.com/features/preview/immutable-actions
