シャイ・フルード、再び現る！300以上のNPMパッケージが感染
引用元：https://news.ycombinator.com/item?id=46032539
プロのヒントだけど、PNPMを使え、NPMじゃないぞ。
PNPM 10.xは多くの攻撃ベクトルを排除したんだ。
1. post-installスクリプトの実行がデフォルトじゃない (手動で承認する必要がある)。
2. 新しいリリースをpnpm installが取得するまでに最短期間を設定できるぜ、例えば4日とかね。これでパブリッシャーはクリーンアップする時間がある。
NPMは本番環境でのCLI使用には安全じゃない。そしてもちろん、発行者キーは非常に限定的なスコープにして、特定のパッケージにバインドし、自己ホスト型CI/CDランナーにIPバインドするんだ。誰もローカルに公開キーを持つべきじゃないし、たとえ公開キーを手に入れたとしても、ローカルから発行できないようにするんだ。
「NPMは本番CLIでの使用には安全じゃない」って言うけど、NPMは別に「安全じゃなさすぎ」じゃなかったし、今もそうじゃないぜ。これはNPMやJavaScript、NodeJSの問題じゃなくて、ライブラリの利用者がサードパーティのコードをレビューもせずに本番環境に持って行っちゃう問題だよ。どうしてこれがまだまかり通ってるのか、俺には未だに謎だね。
Zapierみたいに、誰もコードレビューせずにハッキングされるようなプラットフォームを運用してるなら、そもそもソフトウェア書くべきじゃないだろ。インターネットは長いこと敵対的な場所だったから、俺たちベテランは慣れてるけど、開発者は「最悪何が起きる？」っていう罠にハマりがちだ。プロセスとワークフローを直さない限り、PNPM使ってもこれは続くぜ。誰が書いたコードでも、お前が責任を持つべきだ。
Npmは、長年技術的負債を積み重ねすぎた結果だよ。ロックファイルが本来の動作をするようになるまでに、5回も試行錯誤してるんだからな（ロックファイルバージョン3、その前に2回のバージョンなしの試み）。
構造やコミット履歴から見ても、彼らが必死に改善しようと努力してるのは明らかだけど、底なし沼にいるようなもんだから、光明を見るだけでも大変だよ。
以前、npmチームに経営陣の変更があったんじゃないかって言ったら、オリジナルのメンテナーが何人かいるって反論されたんだ。だから、彼らが一体どんな心境の変化で、自分たちの巨大な罪を償う必要があるって気づいたのかは分からないけど、とにかく努力はしてる。ただ、アホな部分が多すぎて、簡単じゃないんだ。
ファイル転送中に途中で終わっても検出できないままだと思うぜ。不完全なファイルはキャッシュに残ったままで、ハッシュが失敗するから、キャッシュを全部消すしかない。つまり、ネット環境が悪い上に巨大なプロジェクトをやってるやつらは、毎週何時間も無駄に更新失敗に費やしてるってことだ。
ちょっと待って、俺は混乱してるんだけどさ、「ライブラリ」っていう概念そのものが、コードが具体的に何をするか考えなくていいように作られたんじゃなかったっけ？
Reactのアップデートを全部レビューするなんて想像してみろよ。もちろん、中には（Obsidianみたいに全部レビューしてるって言うところもあるけど）そういうところもあるけど、それってエコシステムの欠陥が原因だろ。
Maven Centralを見てみろよ。そこに入るのは大変だけど、それがセキュリティの代償だ。io.gitlab.bpavukみたいなネームスペースで誰も公開できないように、bpavukのGitLabグループやユーザーへのアクセスがあることを検証するんだ。Goもその点ではいい感じだぜ。Gitリポジトリに直接依存するから、Gitリポジトリの権限を乗っ取ってソースコードを汚染しなきゃいけないんだ。
プロのヒントだけど、bunを使え！
これに低評価がついてるのが面白いけど、依存関係のインストールが超速いし、PNPMと同じ承認機能もあって、全部シンプルなバイナリにまとまってるんだぜ。
ポストスクリプトで特定のアーキテクチャ用のバイナリをダウンロードするパッケージって、どうなるの？
これって、2000年代に「macOSを使えばウイルスに感染しないぜ」って言ってたのと同じことだよな。
「ファイル転送中に途中で終わっても検出できない。不完全なファイルをキャッシュに残す」って状況、誰が「これでOK、出荷しよう」って言ったんだろうね？マジで意味わかんねー。
でもさ、この手の問題って基本的には解決済みなんだよ。言語やパッケージ配布、リポジトリ、Linux、公共の信頼、署名、メンテナーなんかに関して、十分な歴史があるだろ。一つの大きな変化は、もう「パッケージャー」がいなくなったことだ。ただ「パブリッシャーを信頼する」だけになっちゃった。Nodeみたいに大きな言語なら、数人のベテランunixウィザードを雇って、真理と道を教えてもらうべきだよ。
パブリッシャーキーはスコープを限定して、IPアドレスもCI/CDランナーに紐付けるべきだよ。Hashicorp Vaultsみたいな動的なシークレット管理を使えば、シークレットのリース期間を設定して、ビルドが終わったらすぐ破棄できる。これなら開発者がうっかりデータベース認証情報を残してもすぐに無効化されるし、自動で認証情報がローテーションされるんだ。FOSSプロジェクトには大変だけど、企業ならちゃんとしたインフラを構築して、短期間のトークンだけをCIビルドに提供すべきだね。こういう攻撃は嫌だけど、会社でセキュリティについて真剣に議論するきっかけになってるよ。
GoはGitリポジトリに直接依存するから安心って言うけど、Gitの参照は変えられる可能性があるんだ。Maven Centralみたいに一度デプロイされたら変更できないのと違って、Gitタグは悪意のあるコードを指すように簡単に置き換えられちゃう。go.sumでロックされてても、疲れた開発者が再生成しちゃう可能性もあるから、そこは気をつけなきゃいけないよね。
Pythonでpost-installスクリプトが動くのを防ぐなら、pip install --only-binary=:all:（uv pip installでも可）を使うといいよ。これでソース配布を避けて、ビルド済みのホイールだけを使うようになる。NPMのリリース年齢制限みたいのはPipにはないけど、uvなら--exclude-newerで対応できる。ただ、タイムスタンプを自分で再計算する必要があるからちょっと面倒かもね。
post-installスクリプトを使わなくても、optionalDependenciesでできるよ。例えばNxのpackage.json（https://github.com/nrwl/nx/blob/master/packages/nx/package.j…）を見ればわかるけど、各依存関係が関連するプラットフォームにだけインストールされるように制約をつけられるんだ。
攻撃者はコードをデプロイしたわけじゃないんだ。ユーザーがコードをダウンロードしたときに、NPMが暗黙的に任意のコードを実行したんだよ。それで認証情報を盗んでワームを広めた。これはNPMの挙動が問題で、いくら依存パッケージをレビューしたところで防げない。もしかしたら、レビューするためにダウンロードしただけかもしれないしね！
npm ciを使えば、package-lock.jsonに書かれたバージョンを正確にインストールできるんだ。パッケージの「自動更新」が今回の攻撃の原因の一つだから、更新は意図的にやるべきだよ。自動的に最新版にしない方が、こういう攻撃のリスクを減らせるはずさ。
キーはどこにも置かないで、OIDCを使うべきだよ！NPMのTrusted Publishers（https://docs.npmjs.com/trusted-publishers）を見てみて。ただし、OIDCを設定するために、最初のパッケージ公開時だけはユーザー名とパスワードでnpm loginが必要なのがちょっとね。
pnpmでリリース年齢の最小値をグローバルに設定する方法ってあるのかな？俺はプロジェクトごとにしか設定できないのしか見つけられなかったんだけど。
「シートベルトをしないのは、他のドライバーが安全運転するべきだから」って言うのは、会社が従業員全員を完璧な開発者にできるって言ってるのと同じだよ。そんな理想論じゃなくて、現実的な解決策を受け入れなきゃ。偉そうなこと言ってないでさ。
UV_EXCLUDE_NEWERに「14日前」のタイムスタンプをシェルスクリプトで自動計算させて設定してるよ。これでuvの--exclude-newerオプションに渡せばいいんだ。必要なら簡単に上書きもできるから、結構シームレスに使えるよ。
無知だよな。オープンソースのプログラマーの多くは、「俺の環境じゃ動く」って考え方でやってるだけだろ。
GitHubの認証情報って、NPMのよりマルウェアに盗まれにくいの？それ、全然対策になってない気がするんだけど。
それっていいね！バイナリが必要なライブラリが全部、post scriptじゃなくてそれを使うようになればいいのに。
CIで’npm i’を実行してる人がどれだけ多いか、きっと驚くよ。何度も見たことあるし。
’npm ci’は多少の対策になるけど、開発中に’npm i(nstall)’を実行したときの被害は防げないんだよね。
ちなみにだけど、NPMとかのツールが、指定された条件を満たす一番古いバージョンを優先するオプションがあればいいなと思う。（今みたいに最新バージョンじゃなくてね—もちろん、最新がデフォルトなのはまだマシだけどさ。）
みんながインストールスクリプトをやめても、Shai-Hulud 3: Electric Boogalooは、インストール時じゃなく実行時にマルウェアを動かすようになるだけじゃない？
依存パッケージをインストール後、実行前に手動レビューする人なんていないし。これはワークフローの問題だ。レビュープロセスがない限り、Mavenですら、俺が知る全てのパッケージマネージャーが脆弱だよ。
最近「依存関係のクールダウン」っていう記事をいくつか見たんだけど、たぶんそれが2番目の項目で言ってたことみたいだね。その考え方、すごく共感したよ。
とは言え、うちは全ての依存関係をハードピンしてて、Dependabotアラートが来たら手動で更新を調べてるんだ。俺って世間知らずなのかな、それともこれが良いやり方なのかな。
＞ 大きな変化は、もうパッケージャーがいなくなったことだ。ただ出版社を信頼するだけ。
NPMやPyPIみたいなリポジトリって、どんなLinuxディストリビューションよりもはるかに多くのパッケージを抱えてるし、Linux Foundationはちゃんと資金ももらってるんだぜ。
これって一般的なのか、良いやり方なのかは分からないけど、俺はgo mod vendorして、その結果を自分のリポジトリに追加するのが好きなんだ。
Bunってどうなの？同じような機能もあるの？
＞企業が社員全員を完璧な開発者にするのは無理”って言うけど、同意だよ。だからプロはプロセスやワークフローを組んで、最高のものをみんなで作るんだ。
でも、会社全体でデプロイされるコードを誰もレビューしないなんて、どんな文化なんだろう？無責任としか言いようがないよ。
もっとコメントを表示（1）
NPMもYarnもインストールスクリプトを無効にする方法があるんだから、みんなできるならそうすべきだよ。
「use cooldown」[0]ってブログ記事、今まさに読むべきだね。自動依存関係アップデートはゼロデイ攻撃よりリスクが大きいと思うんだ。何千ものロックファイルに入り込んだやばいパッケージを元に戻すより、既に悪用された脆弱性を手動で直す方がまだマシかも。
[0] https://blog.yossarian.net/2025/11/21/We-should-all-be-using…
もっと徹底して、必要な機能やシステム互換性がない限り、依存関係は全く更新しないってのはどう？動いてるならそれで良くない？
アップデートって新機能だけじゃなくて、バグやセキュリティ修正も含まれるんだよ。状況によるだろうけど、「cooldown」は良いアイデアだよね。
この考え方には納得できないな。ゼロデイ脆弱性は広まる時間をもらうことになるし、全員が同じcooldownを使ったら、将来のShai-Huludsの発見を遅らせるだけじゃないの？検出方法によるけど、もしユーザーが発見するなら意味ないよ。
でも、そうなると結局、バグを見つけるのを他人に頼っちゃうことになるし、これってスケールしないよね。もしみんながcooldownしたら、結局元の木阿弥だよ。
＞「アップデートには新機能だけでなくバグやセキュリティ修正も含まれる」っていうけど、このやり方は変えるべきだね。バグやセキュリティ修正を得るためだけに新機能（と新問題）を受け入れるのはおかしい。並行で提供すべきだよ。主要機能ごとに並行メンテナンスブランチを作って、古いリリースにも修正をバックポートするのに慣れないと。
頻繁なリリースって話は、依存関係のアップグレードにも当てはまるよね。放っておくとどんどん大変になるから、定期的にやるのが良いんだ。そうすれば一度の変更も少ないし、やり方も忘れずに済む。cooldownは良いアイデアだけどね。
Helix Guardみたいな会社がレジストリをスキャンしてるよ。静的解析やLLM解析をアピールしてるけど、ハニーポットインスタンスでパッケージをインストールして、クラウド設定ファイルへのアクセスとかも検知できるらしい。
Semverはそういうのを楽にするために作られたんだよ。みんながそれに従えばの話だけどね。
npm-check-updatesを使えば結構簡単だよ。一発のコマンドでいけるしね。詳細はこのURLを見てくれ！https://www.npmjs.com/package/npm-check-updates#cooldown
ドキュメントにはこんな注意点があるよ：「過去の安定バージョンは提案されない。最新公開バージョンがクールダウン期間内ならパッケージは完全に無視される」。これって、このやり方には結構大きな欠点に見えるけどな。
これって、定期的なセキュリティ脆弱性のパッチ適用（うちにはコンプライアンスや契約上の義務があるからね）を考えたら、うまくいかなくなるよ。
でも、商用のセキュリティベンダーの善意に頼るのも、それ自体がインフラリスクだよね。
「今すぐのエンジニアリング時間」と「将来のエンジニアリング時間」の価値って別の要素だよね。定期的なアップデートはトータルでは少ない時間で済むし長期リスクも減る。でも、リソースが限られてたり、今すぐの障害リスクが高いなら、凍結して後でアップグレードする方向にシフトすることもある。Shai-Huludよりも巧妙なサプライチェーン攻撃が増える中、AI生成のペイロードとか、ビルド時じゃなくコード呼び出し時に動作するやつとか出てくるから、マクロレベルの遅さは必ずしも悪いことじゃないよ。
（もちろん、凍結するなら、SQLインジェクションみたいなコアなサーバーサイドライブラリのセキュリティアップデートを通知してくれるサービスに登録して、チームでアラートを優先する規律は必要だけどね。）
これって、特定のユースケースやライブラリの設定で実際に悪用できる脆弱性にだけ意味があるんだよね。多くの脆弱性は単なるノイズで、悪用できないからパッチ適用は不要かも。
それはまさに、俺もそうすべきだと思うことだよ。運用（ops）の世界では、バージョンを安定させるのが問題を減らす良い方法だってずっと前から知られてるし、ソフトウェア開発にも同じ原則がよく当てはまる気がするね。「でも、アップグレードがもっと大変になる」っていう議論は説得力がないな。半年ごとでも6年ごとでも、アップグレードは同じくらい大変に感じるよ。
君の理屈は、世界のほぼ全ての開発者がクールダウンを採用し、しかも同じクールダウン期間を採用した場合にしか通用しないよ。そんな大規模な参加は人類がいまだかつて見たことがないレベルだ（ソフトウェア開発のような主観的なものならなおさら）。だから、俺たちは大丈夫だと思うね。
俺もそれが心配だったんだ、一種の逆「共有地の悲劇」だね。俺は1週間のクールダウンを使う、そしたら_誰かが_問題を見つけてくれるだろう…って。誰も見つけないまま1週間が過ぎるんだ。元の比喩を拡張すると、過放牧の牧草地じゃなくて、みんなが手入れしない茂みになって、最後に入ってみたらヘビがいるかもしれないってことだね。
Semverはバックポートを容易にするために作られたって？そんなの初めて聞いたよ。どうやってSemverがバックポートを助けるの？
それは良い機能になるかもね。もし過去1～2週間に2つのバージョンがリリースされてたら、前のバージョンにバグがあった可能性が高いってことだもんね。
アップデートってさ、普通はセキュリティを良くするけど、こっそりセキュリティ欠陥を仕込んで数ヶ月後に見つかることもあるよね。メジャーアップデートでとか。たまにマイナーアップデートでセキュリティを劇的にすぐ悪化させることもあるし。
商用とオープンソースのライブラリ両方をメンテしてるけど、どちらの場合もそれは無理だよ。作業量が2倍、いや3倍になるだろうね。オープンソースはボランティアだし、自分でforkして修正をbackportするのはいつでもOK。商用だとユーザーは追加料金を払いたがらないから提供しないんだ。古いバージョンに留まって、まとめて更新する方がマシみたい。パッチバージョンを出しても驚くほど使われないし。
個人的には“つまらないソフトウェア”なら、一番古いサポートされてるメジャー/マイナーバージョンにいて、最新のポイントバージョンをチェックするのが良いと思うよ。それにはセキュリティパッチが全部入ってるはずだし。でもバグ修正全部を盲目的に取り込む必要はないね。
Semverは役に立たないね。主な問題は労力だよ。1～2人の開発者のオープンソースプロジェクトだったら、給料もらってない限り複数のブランチをサポートするのは無理だろうね。
CIはこれを阻害するけど、フィーチャーブランチやモノリスの欠如に比べたら小さい問題だ。前のプロジェクトではパッケージが多すぎて、デペンダンシーツリー追跡ツールを大幅に改善したよ。ロックファイルが開発・リリースプロセスの最悪な部分にならないように、デプロイ可能な少数のファイルだけが、デペンダンシーツリーを変更せずにホットフィックスリリースに使われたんだ。Artifactoryもあまり役に立たなかったね。
新しいCVEが公開されたらちゃんとアップデートすることだね。あと、一部のソフトウェアはいつもバグだらけで、どのバージョンも新機能、バグ、リグレッションがごちゃ混ぜになってる。それは解決しようとしてる問題が複雑だからか、単にうまく書かれてないかのどっちかだろうね。
だって、もし遅れすぎたら、”必要”になった時に数時間じゃなくて数日かかるからね。
だってAppSecが厳しい脆弱性SLAガイドラインの順守を求めてくるし、顧客からの同様の要求によってさらに強化されてるからね。
カントの議論はテックには関係ないと思うよ。LTS版は昔からあるけど、みんながそれを待ってるわけじゃないしね。最先端（bleeding edge）にいることを誇りに思う人も多いし、彼らは問題発見とか方向付けにもっと積極的に関わってるんだ。
もっとコメントを表示（2）
記事の前提は、スキャナーがクールダウン期間中に攻撃を検出できるってことだね。末端デバイスでの悪用が検出に必要ってわけじゃない。もしこれが間違いなら、みんなセキュリティベンダーに高額なお金を払って、脆弱性フィードを垂れ流してるだけになっちゃうよ。
PostHogの共同創設者だけど、僕たちもこの攻撃の被害者だよ。数時間前に不正なパッケージが公開されちゃった。主な影響パッケージは posthog-node、posthog-js、posthog-react-native、posthog-docusaurus の特定のバージョン。鍵とパスワードは変更済み、影響パッケージは非公開にして、新しいバージョンをリリースしたから、最新版SDKを使ってね。鍵がどう漏洩したか調査中で、後で報告するよ。進捗は status.posthog.com で確認してね。
多分もう計画してるだろうけど、CI/CDと関係ないパッケージがリリースされたらアラームが鳴るように設定しといてほしいな。
新しいパッケージを公開するときは、手動での介入を必須にしてもいいんじゃない？CI/CDから公開リリースまで完全に自動化する必要があるのか疑問だよ。ライブラリの新バージョンを出すなら、手動でユーザーが操作する部分があった方が良さそうだよね。
むしろ古いパッケージを使うべきじゃない？最新版がまさにやられたばかりなのに、次からは大丈夫なんて誰が信じるっていうの？！
手動での介入の問題は、結局は権限の問題だね。初期の従業員や貢献者が重要なパッケージの公開プロセスを握ってて、引き継ぎなしで辞めちゃうと、会社はその作業から締め出されちゃう。コミュニティの負担も増えるし。解決策はいくつかあるけど、僕はTrusted Publishingみたいに環境を介した手動承認のある自動公開がいいと思う。GitHubとかCI/CDプロバイダーがそれを可能にしてるよ。
パッケージはCI/CDじゃなくて、侵害された鍵を使って直接公開されたんだ。僕たちは鍵を新しくして、CI/CD経由でクリーンな新バージョンをリポジトリからリリースしたよ。詳細はこのURLを見てね。https://github.com/PostHog/posthog-js/actions/runs/196303581…
僕は納得できないな。問題には同情するけど、若い会社だからって何でも許されるわけじゃない。これは顧客が使うライブラリの話で、多くの人にとって会社の顔だよ。君が話してるのはプロセス上の問題にしか聞こえない。もし初期の従業員だけがデプロイキーを握ってて、誰の承認もなくデプロイできるなら、それは問題だ。でもこれらは全部「人」の問題で、技術で解決できるものじゃないんだよ。
なんでまだトークン認証使ってんの？最近じゃそれはありえないレベルの怠慢でしょ。NPMはGitHub workflow OIDCに対応してるんだから、それを必須にして、トークンアクセスを全部無効にすればいいじゃん。
「人為的な問題は技術では解決できない」って言うけど、この件は違うと思う。人間が関わってるのは、人間を仲介役にしたからでしょ。もっと悪用されにくいやり方なら、人間を排除できるはずだよ。だって、人間が元々必須ってわけじゃなかったんだから。
OIDCも万能じゃないよ。それなりに考慮すべき攻撃経路もあるしね。君の組織のモデルに合うならそれで良いけど、全ての一般的な状況を解決してくれるわけじゃないから。
どの人間をプロセスから排除したいの？
Trusted Publishingは、攻撃者がクレデンシャルを好き勝手に永続化して遅れて使うっていう今回の攻撃経路に対応するよ。それが万能じゃないってのはその通りだけど（そう主張するものは大体金儲けのための嘘だし）、攻撃の準備期間をかなり無くしたり短くしたりできるんだ。
インデックスとソースリポジトリ間の信頼関係を仲介する人間だよ。これら二つのシステムを繋ぐクレデンシャルが人間を介する必要なんてないんだ。だって、マシン同士が話してるだけなんだから。（もちろん、メンテナンスや開発から人間を排除することはできないけどね！）
「SDKの最新バージョンを使ってね」って言うけどさ、そもそも最初から最新版を使わない方が安全だったかもね。もっと言えば、こんなに脆弱なソフトウェアを使わないのが一番安全じゃない？
OIDCは万能じゃないよ。もっと起こりうる別の攻撃経路を開く可能性もあるんだ。書き込み権限があっても公開権限がないFOSSプロジェクトのコントリビューターが、OIDCワークフローで公開できるようになったりしてね。Jia Tanみたいな攻撃のリスクもあるんだ。組織に合うならいいけど、合わないと大きな問題になるかもね。
いや、人間は必須だと思うね。ソースリポジトリのものをnpmに自動アップロードすべきって言うけど、PostHogの件もそれが原因でしょ。npm公開キーが悪用可能だったのが問題で、技術じゃなくプロセスの問題だよ。会社の公開製品なんだから、人間が承認なしで公開されるのはマズい。完全自動公開はセキュリティと利便性のトレードオフだし、会社の評判へのリスクが大きすぎる。現状では人間を介在させるのが一番安全だと思うな。
クライアントサイドのJSが感染したとして、それってエンドユーザーに何か悪影響を与えたの？もしウェブサイトの管理者が影響を受けたバージョンをその期間中にデプロイしてた場合、そのサイトを使うエンドユーザーに何か問題があったかってことなんだけど。
手動介入なんて「require」できないよ。キーを開発者のPCに置いても、個人デバイスはCI/CDパイプラインより情報漏洩のリスクが高いし。バイナリがキーを探すような攻撃は防げない。物理的に安全な隔離システムで署名する方法もあるけど、不便すぎるね。
リポジトリに書き込み権限を渡しておいて、公開はできないっていう脅威モデルって何？Trusted PublishingはCI/CDでPyPIとかに公開してる前提だよ。これはユーザーの認証情報を機械が仲介するものに変えるだけ。書き込み権限があるなら、Trusted Publishingは権限を変えないし。ソースリポジトリを信頼の源にして、悪用されにくくするだけだよ。このモデルが合わないならCI/CDで公開しなくていい、これはTrusted Publishingの問題じゃない。
これは今回の問題と関係ない話だよ。悪意のあるアクターが通常のリリースプロセス以外でリリースしたのが問題。通常のプロセスが自動でも手動でも関係ないんだ。
ソースリポジトリをnpmに自動アップロードするって意味じゃないよ。ソースリポジトリ自体が認証プリンシパルとして機能すべきだって話。人間がリリースは開始するべきだけど、認証プロセスは人間のIDに紐づく認証情報を使うべきじゃないんだ。PostHogがやられたのは、攻撃者が使えた長期間有効な認証情報があったからで、人間が関わるかどうかは関係なかった。人間承認は大事だけど、認証スキームはソースリポジトリを代表しない仲介者を要求すべきじゃないってこと。
いや、パッケージが動いてたホストだけだよ。このエクスプロイトはPostHogを specifically に狙ったわけじゃない。実際、今のところPostHogのプロダクションデプロイはゼロだったと思う。パッケージが短時間しか公開されてなかったからね。
どうやって侵害されたか不明なら、この攻撃はまだ広がり続けてるのかな？
うん、次の復旧ステップとしてワークフローOIDCに移行する予定だよ。
これNPMに組み込まれてるよ。パッケージ公開のたびにメールが来るんだ。ちょっとうるさいかもだけど、もし午前3時に予期せぬ通知が来たら、すぐアンパブリッシュできるよね。
