親愛なる読者様、

今週は奇妙な一週間だった。ここ数ヶ月、重大なサプライチェーン攻撃が相次いでいる。コミュニティは以前から警鐘を鳴らしてきたが、実のところ我々は危険な状態に陥っていた。より大規模で深刻な事態が起きるのは避けられないと感じている。

この投稿では、今週の主な気づきをいくつか共有したいと思います。私はジョシュ・ジュノン（通称Qix）と対談する機会を得て、この苦難の真っ只中での彼の経験についてインタビューしました。ジョシュはフィッシング攻撃で侵害されたメンテナであり、npmエコシステムで最も広く使われているパッケージのいくつかを手がけている人物でもあります。

その会話（下記インタビュー参照）に入る前に、ここに至るまでの経緯を簡単に振り返ってみましょう。

プロローグ - インパクト

月曜日に、社内Aikido ダッシュボードで初めて警告を確認した瞬間、これがまさに私が夜も眠れない最悪のシナリオの一つになり得ると直感した。 debug やchalkをはじめとする主要パッケージ16個以上がマルウェアに感染していた。その潜在的な影響は壊滅的としか言いようがなかった。

数字が物語っている：

• 侵害されたパッケージは、毎週合計で約26億回ダウンロードされている。
• JFrogの推定によると、悪意のあるバージョンだけで約260万回ダウンロードされた。
• Wizの報告によると、同社のクラウド環境の99%がこれらのパッケージの少なくとも1つに依存しており、10%のケースでは悪意のあるコードが存在していた。

いかなる尺度で測っても、これは危ういところだった。その後多くの人が指摘しているように、私たちは危機一髪で難を逃れた。被害がさらに深刻化しなかった唯一の理由は、次の二つの要因に帰着する：

• 攻撃者は仮想通貨の窃取に執着していた。
• 彼らは発見されないよう細心の注意を払った。

しかし歴史は、その幸運がいかに脆いかを私たちに思い知らせる。攻撃者が実行において注意を怠った場合に何が起こるかを知るには、2025年8月26日に遡るだけで十分だ。

プロローグ - Nxの妥協

8月26日、Nxパッケージマネージャーが侵害されたが、攻撃者は全く異なる手法を選択した：

• 彼らは開発者のマシンから機密情報とトークンを不正に持ち出し、GitHub上に公開した。
• その後、彼らはそれらのトークンを使用してGitHubアカウントに侵入し、非公開リポジトリを公開状態に切り替えた。

典型的な強盗事件だった。広く使われているパッケージを侵害することは、単なる不便さをもたらすだけではないという痛烈な警告だ。それは現実的で永続的な損害を引き起こしうる。多くの点で、これは警告の弾丸であり、私たちがどれほど無防備であるかを露呈した。

ジョシュとの会話

ジョシュに連絡を取り、侵害について知らせた後、その後も話し合いを続けた結果、同僚のマッケンジーと私は、彼と直接会ってこの経験がどのようなものだったのかを直接聞くことが非常に興味深いことに気づきました。幸いなことに、ジョシュはそれに快く応じてくれました。 

その後、思慮深く率直な対話が続き、私に深い印象を残しました。ここで私が得た最も重要な気づきをいくつか共有したいと思います。全容をご覧になりたい方は、こちらの45分間の議論の全編をご覧ください：

洞察：弱さを通じて築く信頼

セキュリティは通常、脆弱性を排除することに関わる。しかしオープンソースにおいては、脆弱性があるからこそ信頼が可能となる。メンテナは自らのコード、そして自分自身の一部を世界に公開し、何十億ものダウンロードと無数のユーザーに晒す。その晒し出しには、信念に基づく飛躍が必要だ。

ジョシュがフィッシング被害に遭ったことを率直に語った時、彼はむしろ信頼を強めるような弱さを見せた。過ちを認め、透明性を保ち、コミュニティとの関わりを続けることで、オープンソースは顔の見えない企業ではなく、人々によって運営されていることを改めて気づかせてくれた。そして、そうした人々への信頼こそが、システム全体を機能させているのだ。

結局のところ、セキュリティは脆弱性を排除しようとするが、オープンソースへの信頼は脆弱性の上に築かれるという逆説がある。

大きな違いを生んだのは、全体的な反応の質だと思います。脆弱性を報告してくれたことへの感謝が何度も示されたのは承知しています。そして、それは事前に分かっていたことでもあります。オープンソースでは、セキュリティ面ではなく、透明性と誠実さにおいて自ら失敗した事例がいくつかありました。そうした失敗をすぐに公表したことで、多くの人々の頭痛の種や時間、費用を大幅に節約できたのです。そして、それは常に感謝されることでした。

インサイト：オープンソースへの没入

ジョシュは、JavaScriptエコシステムの柱となることを目指して始めたわけではなかった。十代の頃からコーディングを始め、PHPやC#、JavaScriptを試し、オープンソースは単に興味のあるプロジェクトを共有する場だった。ターミナルに色を付けたり小さなユーティリティを作ったりすることに惹かれていたが、それらが現代ソフトウェアの中核となるなんて想像もしていなかった。

時が経つにつれ、彼の貢献はより大きな責任へとつながっていった。chalkのような一部のライブラリでは、修正を貢献した後にメンテナとして参加するよう招待された。debugのような他のライブラリでは、以前のメンテナから管理を引き継いだ。趣味でいじっていたものが、次第にエコシステムで最も広く使われるパッケージのいくつかを維持する仕事へと発展していった。

数年後、ジョシュは毎週数十億ものダウンロードを管理する立場になっていた。かつては小さな副業プロジェクトだったものが、今やインターネットの重要なインフラとなっていた。それは綿密な計画や野心によるものではなく、単に適切なタイミングで適切な場所にいたこと、そして助けを求められた時に「はい」と応じた結果だった。

それらはますます多くの場所で使われるようになり、おそらく本来あるべきでない場所でも使われるようになった。正直なところ、そのパッケージのいくつかはそもそも存在すべきではなかったと、私が真っ先に認める。そしてある日目を覚ますと、配列の値を移動させるために書いた小さなユーティリティが55,000人に使われ、週に3億回もダウンロードされていることに気づく。そんな責任を背負うつもりは全くなかったのに。

洞察：制御を失う無力感

おそらくジョシュにとってこの事件で最も辛かったのは、自分がフィッシング被害に遭ったことに気づいたことではない。その後襲った無力感だった。攻撃者が彼のパスワードと2段階認証コードを入手した時点で、npmのシステム上では実質的に彼自身と同一 視された。彼らは2段階認証トークンをリセットし、認証情報を変更し、彼を自身のアカウントから締め出した。パスワードの再設定やアクセス回復といった基本的な操作すら機能しなかった。

約12時間にわたり、ジョシュにできることは外から眺めることだけだった。彼のパッケージの悪意あるバージョンがインターネット上に拡散していくのを。直接介入する手段も、押せるボタンも、npmサポートへの迅速な連絡手段もなかった。代わりに、彼は公開のヘルプフォーラムに頼るしかなく、待つしかなかった。 

無力感が彼に強く残った。彼の言葉を借りれば、透明性もなければ、危機に陥ったメンテナが制御を取り戻すための手段もなかった。近年記憶にないほど大規模なサプライチェーン侵害の真っ只中で、それらのパッケージを最も信頼されていた人物は傍観するしかできなかった。

パスワード再設定ボタンが機能しませんでした。この一連の過程でメールは一切届きませんでした。パスワード再設定は何の効果もありませんでした。つまり、アカウントに登録されているメールアドレスが以前と同じだったとしても（おそらくそうだったと今でも思っています）、パスワード再設定は機能しなかったのです… これに対する救済策は、npmの公開されている非認証ヘルプフォームを通じて連絡を取る以外にありませんでした。

洞察：危機一髪

チョーク、デバッグ、その他の侵害されたパッケージに埋め込まれたマルウェアは深刻だったが、その範囲は奇妙なほど狭かった。ブラウザのコンテキストに自身を注入することで暗号通貨を盗もうとしたのだ。攻撃者たちのこの判断——それが貪欲さによるものであれ短絡的な考えによるものであれ——が、被害がさらに深刻化しなかった唯一の理由である。

ジョシュが言うように、これは簡単に壊滅的な事態を招きかねなかった。これらのパッケージはあらゆる場所で動作している：ノートパソコン、企業サーバー、CI/CDパイプライン、クラウド環境などだ。AWSキーを不正取得したり、機密情報を漏洩させたり、身代金目的でファイルを暗号化したりする可能性もあった。しかし攻撃者は、一つの限定的な目標に自らを制限した。

それはあらゆることを実行できたはずであり、実際に稼働していた…企業向けマシン、個人用マシン、中小企業、CI/CDパイプライン上で。そしてそれが[より深刻な]被害をもたらさなかったという事実こそが、我々が回避した危機だった。

教訓はシステムが機能したことではない。今回は運が味方したということだ。これを「取るに足らないこと」と扱うのは本質を見失っている。次の攻撃者はそれほど自制しないかもしれない。

インサイト：オープンソースの人間的代償

広く使われているパッケージの背後には、たいてい目立たず静かに働く人間がいる。ジョシュにとって最も困難だったのは、技術的な妥協だけではない。その後襲ってきた感情的な負担だった。初日は完全に自動操縦状態で、被害を食い止めるのに必死だったと彼は語る。その重みが彼を襲ったのは、ずっと後になってからだった。恥ずかしさ、不安、そして自分のミスが人を傷つけたかもしれないという不安な思いが押し寄せたのだ。

それは月曜日だった。その日の午後か夕方にアカウントを取り戻した時、ああ、これでスイッチを切れる、ベッドに横たわって天井を見つめながらさっき起きたことを考えられる…って感じで。次の日はただただ恥ずかしかった。顔を出したくなかった。外に出たくなかった。

これがオープンソースの隠された現実だ。「趣味で」作られた小さなプロジェクトが、何十億ものダウンロードを支える重要インフラへと成長する。メンテナはそんな責任を求められたわけではないのに、問題が起きた時にはそのストレスを背負わされる。コミュニティはコードを見るが、それを維持する人間的な代償を見落としがちだ。

ジョシュの経験は、エコシステムのセキュリティが単なる多要素認証の強化やインシデント対応の迅速化だけではないことを思い出させてくれる。それはまた、この責任を担うメンテナを支えることでもある——境界を尊重し、共感を示し、信頼がコードの背後にいる人々にかかっていることを認識することだ。

行動喚起

この事件は、単一の侵害がソフトウェアのサプライチェーン全体に波及する可能性を浮き彫りにした。今回は壊滅的な事態には至らなかったが、そうなる可能性は十分にあった。教訓はパニックに陥ることではなく、行動を起こすことだ。

• レジストリ（npm、PyPIなど）向け：影響力の大きいメンテナに対してフィッシング対策強化型MFAを義務付け、アカウント侵害時には迅速な対応が可能な明確な連絡経路を提供する。
• 組織向け：依存関係の衛生状態を改善しましょう。バージョンの固定化、改ざん監視、CI/CDパイプラインへのサプライチェーンセキュリティチェックの統合を実施してください。
  メンテナ向け：ハードウェアキーを使用し、ストレス下での安易なセキュリティ判断を避け、問題発生時には透明性を重視してください。
• コミュニティのために：オープンソースを支える人々を支えましょう。彼らの境界を尊重し、可能な限りリソースを提供し、ミスが起きた時には共感を持って対応しましょう。

真の行動要請は単純明快だ：エコシステムの安全を共有責任として扱うこと。プラットフォーム、企業、コミュニティはすべて、次のインシデントがより深刻な事態に発展しないよう確保する役割を担っている。

エピローグ

この一週間は現実離れした日々だった。多くの報道と注目を集めた嵐の真っただ中にいたのだ。当然のことながら。ダッシュボードに最初の警告が表示されてから、一般からの報告が殺到するまで、リアルタイムで事態が展開していく様子は、まるで断層の上に立ち、足元の地盤が揺れ動くのを体感しているようだった。これは私たちの生態系がいかに脆いかを改めて思い知らせる出来事だった。

起こった事態は、私がオープンソースセキュリティにおいて日々懸念している最悪のシナリオに、不快なほど近いものだった。しかし私が最も恐れているのは、フィッシングメールでもマルウェアでも、ましてや見出しになるような事件でもない。この瞬間を何の変化もなく過ぎ去らせてしまうことだ。

業界が肩をすくめ、これを単なる一事件として扱い、日常業務に戻ってしまうなら、我々は何も学んでいないことになる。そして次に、必ず次に起こる時、我々はそれほど幸運ではないかもしれない。一度目は攻撃者に恥を知れ。二度目は我々に恥を知れ。

そして、この教訓を学ぶための措置を講じなければ、オープンソースへの信頼が 静かに蝕まれていくことが、結局は最も深刻な結果をもたらすことになるかもしれない。

‍