【緊急】Red Hat Cloud Servicesで悪意のあるnpmパッケージが検出！即座に確認を

Red Hat Cloud Servicesにおいて、悪意のあるnpmパッケージが検出されました。現在、関連する環境やプロジェクトを確認し、必要に応じて依存関係の見直しやセキュリティパッチの適用を行うことを強く推奨します。開発環境の安全を守るため、直ちに影響調査を開始してください。

うちの会社ではyarn 4を使ってるんだけど、これにはパッケージがリリースされてから指定した日数が経過するまでインストールを制限するオプションがあるんだ。最近の攻撃のほとんどは、その期間（1〜3日）の間に検知されてるよ。

https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e93104

この前こんな面白い記事を見かけたよ：https://github.com/uNetworking/uWebSockets.js/blob/master/misc/npm.md

理屈としては、使っている依存関係をすべてフォークして、自分のリポジトリからインストールし、必要に応じてアップストリームからレビューしてマージするのが正しいっていうのはわかる。まあ、とてつもなく面倒くさいけどね。 :)

自分はパッケージをインストールするときに --before=2026-05-30 フラグを使うのが習慣になってるよ。これで指定した日付より前にリリースされたバージョンを選んでくれるんだ。いつも大体5日くらい前の日付を指定してる。

ふむ、ちょうどRHとIBMがサプライチェーン脆弱性の検知・修正を支援するProject Lightwellを発表したのと同じ日だね。

https://www.redhat.com/en/lightwell

元の発表へのリンクを貼っておくね：

https://www.stepsecurity.io/blog/multiple-redhat-cloud-services-npm-packages-compromised

いくつか提案があるよ：

1. 1〜2日程度の依存関係のクールダウン（導入待ち期間）は、CVEのパッチを当てる能力を損なうことなく極めて効果的だよ。

2. npm install や npm test など、コードが実行される場所はすべて特権のない環境で行うべき。GitHub Actionsなら、ビルドとテストを行うジョブと、パブリッシュや署名などを行うジョブに分けることで、かなり直感的に対応できる。AIを使っているなら、このパターンを強制するスキルやガイダンスを追加するといいよ。

3. Github Actionsを使っているなら、zizmorの最新版を入れるといい。セキュリティ状況がかなり改善されるはず。

(2)を徹底すれば「ワーム化」を防げる。これは現在抱えている問題の大きな部分を占めてるからね。(1)があれば、企業は攻撃への対応時間を確保できる。

この分野には検討すべきベンダーもいくつかあるよ。

NPMは設計自体が壊れてるんだよ。それに、コミュニティに蔓延するNIH症候群のせいで、シンプルな対策すら導入できないんだろうね。

クールダウン設定の話でまた割り込ませてもらうよ…（tanstackが侵害された時の自分のコメントのコピペだけど）。

クールダウンについてはいろいろ意見があるのは知ってるけど、これがあればaxios、tanstack、（それに@redhat-cloud-servicesも）をはじめ、最近のnpmサプライチェーン攻撃から守れていたはずなんだ。ArtifactoryやNexusを使っているならたぶん既にクールダウンはあるだろうけど、なくても簡単に設定できるよ。

なぜクールダウンなのか？ほとんどのnpm（やpypi）の侵害は数時間以内に取り下げられてるから、クールダウンを設定するだけで「リリースからN日未満のパッケージは無視する」ことができるんだ（1日でも効果あるし、3日は無難、7日はやりすぎかもしれないけど有効）。

設定方法は？

• pnpmの最新版を使う：デフォルトで1日のクールダウンが入ってる https://pnpm.io/supply-chain-security

• ワンクリックで済ませたいなら https://depsguard.com ：npm、pnpm、yarn、bun、uv、dependabotにクールダウンなどの推奨設定を追加するCLI（免責：自分はそのメンテナだよ）

• https://cooldowns.dev ：こっちはクールダウンに特化していて、ローカルで設定するためのスクリプトもあるよ。

全部オープンソースで無料だ。

~/.npmrc をいじる方法を知っているならこれらは必須じゃないけど、ワンクリックで解決したい人にとっては、次の攻撃から身を守る助けになるはず。

注意点として、新しい深刻なCVEをパッチする必要があるときはクールダウンをバイパスしないといけないけど、それぞれ回避方法がちゃんと用意されてるよ。

ここ数ヶ月、正確な数字はないけど、ゼロデイCVEよりソフトウェアサプライチェーン攻撃（悪意のあるバージョンの混入）によるリスクの方が大きいように感じるんだ。

1週間くらい前にラップトップからNodeをアンインストールしたんだけど、最高だよ。:)

今は作業をすべて開発コンテナ（または他のサンドボックス）でやるようにしてる。万が一エクスプロイトを踏んでも被害を最小限に抑えるためだね。攻撃者にClaudeのトークンを盗まれることはあっても、コンテナから脱出してホームディレクトリをスキャンされることは簡単にはできないはず。

クールダウンやインストーラースクリプトの許可リスト化は、特にCIにおいて多層防御の強力な追加要素になる。ただ、根本的に変えるべきなのはOSの権限モデルだと思う。ユーザーがアクセスできるすべての権限をサードパーティ製ソフトウェアにデフォルトで委ねるというやり方は、もう通用しない。

こういう議論が出るたびに、この手の攻撃がnpm特有だとか、対策が何もなされていないといった冷ややかなコメントがつくけど、それはフェアじゃないと思うな。

pnpmなどがパッケージ利用者を守るために実装した遅延ロードなどの優れた対策について言及しているコメントはたくさんあるよ。

あまり語られていないのは、パッケージメンテナ側のツールについてだね。

• パブリッシュ時のMFA：https://docs.npmjs.com/requiring-2fa-for-package-publishing-and-settings-modification

• 約1年前から利用可能な「Trusted Publishers」：https://docs.npmjs.com/trusted-publishers

最近だと、これらの機能を組み合わせた「Staged Publishing」もある：https://docs.npmjs.com/staged-publishing

これで何ができるようになったかというと：

• 固定の認証情報を使わずにCIからパブリッシュできる

• かつ、実際にレジストリへ公開する前にメンテナがMFAで承認する必要がある

GitHub Actions Environmentsの保護機能などを使って、CI側で複数の承認を必須にしたり、時間差を設けたりすることもできる。

コミュニティでこうしたパブリッシュ時の保護手段を推奨していかないと、この問題はいつまでも終わらないよ。