7月21日、blog.outv.imが「npm's release cooldown is security theater」と題した記事を公開した。npmやpnpm、Yarnが相次いで導入した「リリースクールダウン」機能が、サプライチェーン攻撃への対策としてほぼ機能しない理由を論じた内容だ。
著者の結論は手厳しい。クールダウンは「セキュリティ演劇(security theater)」——見た目は安全そうだが実態を伴わない施策——に過ぎないという。セキュリティ研究者のBruce Schneierが広めたこの概念は、コストをかけた対策が実際のリスクを下げていない状況を指す。2024年に発覚したXZ Utils事件——長期間にわたって信頼を築いたうえでプロジェクトに潜入し、悪意あるコードを仕込むという精巧な攻撃——が現実に起きている今、この批判は単なる理論的反論ではない。
クールダウンとは何か
npm、pnpm、Yarnなどの主要パッケージマネージャーは、公開直後のパッケージを一定期間インストールできないようにする「リリースクールダウン」機能を実装している。Yarnは7日間、pnpmは3日間といった具合だ。公開直後に悪意あるバージョンが出回っても、コミュニティが気づく時間を確保できるというのが設計思想だ。
サプライチェーン攻撃が頻発する状況を踏まえれば、この発想自体は理解できる。問題は、その前提が現実に成立しているかどうかだ。
「誰かが確認してくれる」という幻想
クールダウンが機能するためには、暗黙の前提が必要だ。コミュニティの誰かが新しいパッケージをいち早くインストールし、問題を発見し、大多数が使い始める前に警告を発してくれるというものだ。記事はその前提を次のように分解する。
- 親切心から、誰かが真っ先にインストールする
- 賢いので、何か問題があれば気づく
- 最良のタイミングで、大多数が入れる前に警告を出す
- すべて無償で
ここに根本的な矛盾がある。全員がクールダウンを設定していれば、アーリーアダプターは存在しない。 全員が「誰かがカナリアになってくれるだろう」と待ち続け、そのカナリアは永遠に現れない。記事はこれをベケットの戯曲『ゴドーを待ちながら』になぞらえ、いつまでも来ない救済者を待ち続ける状況として描く。
CI/CDに任せても手遅れになる
「人間が確認しなくても、CI/CDパイプラインやDependabotがやってくれる」という反論も著者は退ける。悪意あるコードが紛れ込んだ場合、起こり得る結果は2通りしかない。CIが攻撃可能な環境であればエクスプロイトが静かに成功し、安全な環境であれば問題が見過ごされる。どちらに転んでも、Dependabot PRはマージされ、開発者は何も考えずにnpm installを叩く。package-lock.jsonを眺めるだけでは信頼性の確認にはならず、悪意あるコードは被害が表面化して初めて発覚する——その時点では、すでに手遅れだ。
「待つ」から「スキャンする」へ
記事が提唱するのは、能動的なスキャン(原文では「Do Your Own Research」)への転換だ。具体的なアプローチとして次を挙げている。
- ベンダーコードを野良のWindows EXEと同じ目で扱う。 SASTツールやサンドボックスを活用して静的解析を行う。Socket.devやSemgrepといったツールが選択肢になる
- LLMを使ってベンダーコードを監査する。 コードの意図を自然言語で問い、不審な挙動を浮かび上がらせる使い方だ
- いずれも、DependabotのPRがマージされる前・開発者がインストールする前に実施する
クールダウンで待つのではなく、パッケージが届いた時点で能動的に検証する仕組みを整える。それが「セキュリティ演劇」から脱却する唯一の道だというのが、著者の結論だ。
クールダウン機能を導入した各ツールの意図を否定するわけではない。しかし「待てば誰かが確認してくれる」という前提が崩れれば、クールダウンはただのウェイティングタイムに成り下がる。サプライチェーン攻撃が高度化する中で、受動的な防御策だけに頼ることのリスクを改めて問い直す論考だ。
詳細はnpm's release cooldown is security theaterを参照していただきたい。