TanStackのNPMパッケージが侵害されました

ミニシャイ・フルードのワームが、CI/CDパイプラインをハイジャックして開発者の秘密を盗むことで、正当なnpmパッケージを攻撃しているよ。StepSecurityのOSSパッケージセキュリティフィードが最初に公式の@tanstackパッケージでこの攻撃を検出して、エコシステム全体での広がりをリアルタイムで追跡しているんだ。

せめて1〜2時間だけだったし、react-queryには影響しなかったけど、結構有名なパッケージがやられちゃったね。これ、持続可能じゃない気がする。依存関係が更新されるたびに運試ししてるみたい。

npm環境をしっかり守ることを忘れないでね。https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f... ちょっとした設定で大きなトラブルを避けられるから。

残念だけど、これは証拠だと思う（私の意見だけど）、Trusted PublishingはCIから安全に公開するにはまだ不十分だよ。攻撃者がCIパイプラインの中にいるか、盗まれたリポジトリの管理者権限を持っていれば、簡単に公開できちゃうから。これは新しい情報じゃないけど、TPはこれに対する保証をするためのものじゃないんだ。でも、TPに移行することでローカル公開から2FAを外すと、この種の攻撃がCIの妥協から生まれることになる。 （編集: 「まだ安全でない」を「まだ不十分だ」に変更したのは、私が言いたいポイントだから）Trusted Publishingやパイプライン公開に移行すると、ローカルで作業する際にnpm公開を制限するための第二の要素がなくなっちゃう。ここでの話は、攻撃者がCI/CDパイプラインを妥協した結果、npm公開に第二の要素がないからOIDCトークンを盗んで公開を完了できたってこと。面白いけど、関係ないかもしれないのは、公開ジョブが失敗したこと。だから、悪意のあるコミットにあったペイロードは、ワークフローからOIDCトークンを使って自分自身を公開できるスクリプトを持ってたはず。私が望むのは、CI公開がGithubの外で第二の要素を持ちながら、トークンなしの長期的なTrusted Publisherモデルに依存すること。つまり、私が望むのは段階的な公開で、誰かが2FAを使ってnpm側でアーティファクトを公開する必要があること。そうでないと、公開がGithubの信頼モデル内でしか行えないなら、リポジトリ管理者のトークンを持っているか、悪意のあるコードがパイプラインに入ってしまったら、簡単に公開を完了できちゃう。Githubの文脈の外に真の第二の要素があれば、リポジトリに大きなダメージを与えたり悪意のあるコードを植え付けたりすることはできるけど、少なくともレジストリのための第二の要素を手に入れない限り、公開はできないはず。