npmサプライチェーン攻撃：マルウェア混入時の緊急対応と教訓

2026年8月29日早朝、npmパッケージ『@7nohe/openapi-react-query-codegen』の管理者が直面したのは、まさに悪夢のようなサプライチェーン攻撃の現実でした。GitHub Actionsのリリースワークフローという、我々が日常的に信頼し、自動化の恩恵を享受している「聖域」が、攻撃者によっていとも簡単に蹂躙されたのです。結果として、10個もの悪意あるバージョンが公開され、インストールした瞬間に認証情報が盗み出されるという、極めて深刻な事態に発展しました。この攻撃の恐ろしさは、単なるコードの改ざんではなく、盗んだ認証情報を悪用して他のパッケージへ横展開を図る「ワーム型」の挙動にあります。これは、一度のミスが連鎖的な被害を生む、現代のOSS開発における最大の脆弱性と言えるでしょう。

私がこの事案を分析して痛感するのは、攻撃者が「GitHub Actionsのトリガー」という、CI/CDパイプラインの最も脆弱な隙間を正確に突いている点です。多くのエンジニアが、PRの自動テストやリリースフローにおいて、利便性を優先して権限を過剰に付与しがちです。しかし、今回のケースは、その「便利さ」がそのまま「攻撃の踏み台」になり得ることを証明しました。被害に遭った管理者が、まず最初に行ったのが「latestの復旧」ではなく「侵入経路の遮断」であったことは、インシデント対応の教科書的な正解です。穴が開いたままのバケツに水を注ぎ続けても意味がないのと同様、ワークフローのトリガーを削除し、Trusted Publishing（OIDC）の設定を即座に無効化するという判断は、被害の拡大を食い止めるための唯一の防波堤でした。

また、npmの仕様である「72時間以内のunpublish制限」という壁も、実務上の大きな障壁として立ちはだかりました。多くのパッケージが依存関係にある場合、即座に削除することは許されず、deprecateという「警告」による対応を余儀なくされます。これは、npmという巨大なエコシステムが抱える構造的な弱点であり、我々開発者は「レジストリを信頼しすぎない」という冷徹な視点を持つ必要があります。deprecateは新規インストールを抑制する効果はありますが、lockfileに固定された環境や、バージョンを明示したインストールまでは防げません。この「完全な解決には至らない」というもどかしさこそが、現代のOSS開発者が背負うリスクの正体なのです。

今回のインシデントで最も教訓的だったのは、攻撃者が「証拠隠滅」を前提に動いていたという点です。攻撃者は自身のPRをforce-pushすることでコミットを書き換え、痕跡を消し去ろうとしました。ここで多くのエンジニアが陥る罠が、GitHubのPRタイムラインだけを頼りに調査を進めてしまうことです。しかし、コミットオブジェクト自体はリポジトリ内に残存しており、SHAさえ特定できれば直接fetchすることが可能です。管理者が行った「通報の前にSHAを記録する」という手順は、まさにプロのエンジニアとしての冷静な判断の賜物です。通報によってアカウントが凍結されれば、その記録すらも消滅してしまう。この「時間との戦い」において、いかに冷静に証拠を確保できるかが、事後のフォレンジック調査の質を決定づけます。

さらに、攻撃者のペイロードは極めて巧妙でした。一部のバージョンではinstall scriptすら持たず、binding.gypを悪用してnode-gyp経由で発火させるという、静的解析をすり抜けるための高度な難読化が施されていました。また、filesフィールドの指定により、tarballからペイロードを除外して検出を逃れるといった、パッケージマネージャの仕様を熟知した攻撃手法が確認されています。これは、単にpackage.jsonのフックを監視するだけでは不十分であることを示唆しています。我々が明日から取るべき対策は、単なる依存関係のチェックではなく、ビルドプロセスそのものの透明性を確保し、CI/CD環境における権限分離を徹底することに他なりません。

以下の表は、今回のインシデントにおける対応の優先順位と、その技術的根拠をまとめたものです。この順序は、今後同様の被害に遭った際の「生存戦略」として、すべてのOSSメンテナが頭に入れておくべきものです。

このプロセスを見て、皆さんはどう感じますか？「自分は大丈夫」と高を括っていませんか？GitHub Actionsのワークフローに、安易にid-token: writeを付与し、外部からの入力をそのまま実行するようなコードを書いていないでしょうか。我々が書くコードが、いつの間にか「攻撃者の武器」に変換されるリスクは、もはや対岸の火事ではありません。TeamPCPのようなマルウェアグループが、TrivyやLiteLLMといった著名なツールを標的にしている現状を鑑みれば、OSSのサプライチェーンは常に「汚染されている」という前提で設計を行うべきなのです。

最後に、我々エンジニアが自問すべきは「信頼のコスト」についてです。npmやGitHubといったプラットフォームは、開発の効率を劇的に向上させましたが、同時に「見えないリスク」を我々のプロジェクトに持ち込みました。今回の事案は、単なる一人のメンテナの不運ではなく、OSSエコシステム全体が抱える「信頼の崩壊」を象徴しています。もし、あなたが管理しているパッケージが、明日突然マルウェアの配布元になったら、その時、あなたは利用者に何を伝え、どう責任を取るのでしょうか？「消して入れ直せば終わり」という甘い認識は、今回のペイロードが認証情報を盗み出し、横展開を図るという事実の前では無力です。

明日から取るべき実践的な処方箋として、まずは自身のCI/CDワークフローを徹底的に見直してください。特に、PRのコメントや外部からのトリガーによって実行されるジョブには、厳格な権限分離が必要です。また、依存関係の更新を自動化している場合、その更新プロセス自体が攻撃の入り口になっていないか、一度立ち止まって検証してください。そして何より、インシデントが発生した際に「何を、どの順序で、どうやって」対応するかというプレイブックを、頭の中だけでなく、ドキュメントとして残しておくべきです。Claude CodeのようなAIツールを活用して調査を加速させることは有効ですが、最終的な判断を下すのは常に人間です。

我々は、コードを書くことと同じくらい、あるいはそれ以上に「守ること」に責任を持つべき時代を生きています。OSSの利便性を享受する代償として、我々は常に「攻撃者と対峙する準備」を求められているのです。あなたのリポジトリは、攻撃者にとって「攻略しやすい脆弱な標的」になっていませんか？その問いに対する答えが、あなたのキャリアと、あなたが提供するソフトウェアの信頼性を決定づけることになるでしょう。このインシデントを「他人の不幸」として消費するのか、それとも「自らの防衛力を高めるための警鐘」として受け止めるのか。その選択こそが、シニアエンジニアとしての分水嶺なのです。