CTOが今期決めるべきサプライチェーン攻撃対策——発見・抑制・ダメージコントロールの3層設計

こんにちは、大平です。

法人相談でセキュリティの話になると、「脆弱性スキャンはやっています」という答えがよく返ってきます。それ自体は正しい取り組みです。ただ、2025年以降 npm で毎月のように起きているサプライチェーン攻撃（ライブラリに悪意あるコードが仕込まれる攻撃）は、その守りの外側で起きています。この記事では、なぜ従来の脆弱性対策では防げないのか、そして経営としてどの防衛線を持つべきかを、抑制・発見・ダメージコントロールの3層で書きます。

「脆弱性対策はやっている」が通用しない理由

脆弱性対応は、公開された欠陥への事後対応です。バグが報告され、CVE という管理番号が付き、スキャナが検知し、パッチを当てる。この流れ自体はよく機能しており、続けるべきものです。

サプライチェーン攻撃は、この流れに乗りません。悪意あるコードは、いつも使っている正規パッケージの「正規の新バージョン」として配布されます。管理番号が付く頃には悪性バージョンはレジストリから削除され、攻撃は終わっている。勝負が付くまでの窓は数時間から数日です。つまりこれは、スキャナの検知定義が追いつくのを待てる脅威ではありません。同じ「セキュリティ」という言葉で括られていますが、守るべき時間軸がまったく別の脅威です。

攻撃は「対岸の火事」から「毎月の定常イベント」になった

2025年9月8日、chalk や debug など18の npm パッケージが乗っ取られました。合計で週20億ダウンロード、JavaScript を書いていればほぼ確実に依存しているレベルのパッケージ群です。手口は偽の2FA更新メールによるメンテナへのフィッシングで、約2時間で巻き戻されました。2時間で収束したなら大丈夫だった、と読めるかもしれません。ところがその1週間後、Shai-Hulud と呼ばれる自己増殖型のワームが現れます。感染したパッケージをインストールすると開発者の npm・GitHub・クラウドの認証情報が盗まれ、盗んだ権限でその開発者のパッケージにも感染を広げる。11月には第2波が492パッケージに達し、Zapier や Postman、PostHog といった著名プロジェクトが巻き込まれ、約25,000のリポジトリからシークレットが流出しました。

2026年に入っても止まっていません。3月には axios が侵害されて遠隔操作型マルウェアの配布経路になり、6月には Red Hat 公式スコープの32以上のパッケージ、そしてこの記事を書いている5日前の7月14日にも AsyncAPI の公式パッケージ群が CI/CD の隙を突かれて侵害されています。手口の系譜は 2018年の event-stream 事件から続いていますが、頻度が変わりました。もう対岸の火事ではなく、毎月の定常イベントです。

インストールした瞬間に、もう遅い

Shai-Hulud の実行タイミングは、インストール中です。npm パッケージはインストール時に任意のスクリプトを実行できる仕様になっており、開発者が手元で依存を追加した瞬間、CI サーバーがビルドを回した瞬間に、悪意あるコードが動きます。最初の被害地点は本番サーバーではなく、開発者のPCとCIです。

多くの組織の品質ゲート（コードレビュー、テスト、ステージング確認）は「本番に出る前に見つける」ための関所として設計されています。ところがこの攻撃は、関所より手前、コードを取り込んだ瞬間に発動する。chalk/debug 事件のようにエンドユーザーのブラウザ上で暗号資産の送金先を書き換える型もあり、発動場所は事件ごとに違いますが、共通しているのは既存の関所の位置では止まらないことです。だから防衛線は、別の場所に3つ引く必要があります。

防衛線1：抑制——「最新をすぐ入れない」を開発標準にする

悪性バージョンの多くは、公開から数時間、長くても数日で発見されレジストリから削除されています。裏を返せば、新バージョンの取り込みを1日から1週間待つだけで、この種の攻撃の大半を踏まずに済みます。クールダウンと呼ばれる運用で、僕の独自ルールではありません。主要パッケージ管理ツールの一つである pnpm は、新バージョンを24時間は取り込まない動作を標準にしました。「最新を追うほど安全」という直感は、この領域では逆に働きます。

あわせて効くのが、インストール時のスクリプト実行を原則禁止すること（前述の「入れた瞬間に発動」の経路そのものを塞ぐ）、依存のバージョンを記録したファイルで固定し CI が勝手に新バージョンを拾わないようにすること、そして依存を安易に増やさないことです。いずれも製品の購買ではなく、開発規約として決めれば効き始める類のものです。

防衛線2：発見——Dependabotでは見つからない

ここは決裁者の誤解が最も多いところです。Dependabot や Renovate といった依存更新ツールを入れて「対策済み」とされている組織をよく見ますが、これらが通知するのは公開済みの脆弱性、つまり管理番号が付いた後の欠陥です。悪性パッケージは番号が付く前に勝負が終わるので、既知の欠陥の監視と、挙動の変化の監視は、別のレイヤーとして両方持つ必要があります。

挙動の変化の監視とは、パッケージの新バージョンが突然ネットワーク送信を始めた、インストール時スクリプトが追加された、難読化されたコードが混ざった、といった兆候を検知する仕組みです。Socket のような専門サービスがこの領域を担っており、npm 公式のパッケージページにも解析結果へのリンクが組み込まれ始めています。エコシステム側も「CVE を待たない検知」を前提にし始めた、ということです。

防衛線3：ダメージコントロール——「踏む前提」で設計する

抑制と発見を固めても、ゼロにはなりません。7月の AsyncAPI の事件で突かれたのは、メンテナ個人のアカウントではなく CI/CD パイプラインの運用の隙でした。侵入経路は毎回変わり、入口をすべて塞ぎ切ることはできません。そこで3つ目の防衛線は、踏んだときの被害を限定する設計になります。

Shai-Hulud が盗んだのは、コードではなく認証情報でした。被害の上限は「開発者のPCとCIに、何が置いてあるか」で決まります。有効期限のない認証トークンを置かない、権限の範囲を必要最小限に絞る、漏えいしたときに何をどの順で失効させるかを平時に文書化しておく。この方向性は業界の共通解になりつつあり、npm 自身が 2025年12月に旧方式の長寿命トークンをすべて失効させ、そもそも盗める長期トークンを持たない認証方式（Trusted Publishing）へ移行を進めています。盗まれない前提を捨てて、盗まれても短時間・狭範囲しか効かない構造にする。これがダメージコントロールの中身です。

これはツール導入ではなく、開発標準の設計問題

3つの防衛線を並べると、共通点が見えてきます。何かを買えば済む項目がほとんどないことです。新バージョンを何日待つか、インストール時に何の実行を許すか、CI に何を持たせるか。どれも技術の購買ではなく、開発標準の設計です。だからこの問題は情報システム部門のツール選定ではなく、開発組織のルールを決められる立場、つまり CTO や開発責任者のところに落ちます。

もう一つ、自社で開発していない会社にも他人事ではありません。御社のシステムを開発している委託先の開発機とCIは、御社のデータに届く認証情報を持っています。つまり委託先の開発標準が、御社のセキュリティ境界の一部です。僕はベンダー選定の相談を受けたとき、この観点を選定基準に入れることを勧めています。事故が起きたとき失うのは復旧費用ではなく、顧客からの信頼だからです。

まとめ

脆弱性対策とは別の脅威モデル：悪性コードは管理番号が付く前に消え、攻撃は数時間で終わる。スキャナの増強では守れない
防衛線は3層で設計する：抑制（待つ・実行させない・固定する）、発見（挙動の変化を見る）、ダメージコントロール（盗まれて困るものを持たない）
正体は開発標準の設計問題：ツールの購買では解決しない。自社の開発規約にも、委託先の選定基準にも、同じ問いを立てる

攻撃は毎月起きています。次の大型事件が報道されてから考えるより、いまの開発標準にこの3つの防衛線があるかを今週確認するほうが、はるかに安くつきます。