完璧な防御は存在しない。「防ぐ」と「諦めない」の両構えで 広く使われるOSSパッケージが汚染される事例は、近年あとを絶ちません。開発者の手元やCIが攻撃の起点になるリスクも、確実に高まっています。ソフトウェアサプライチェーン攻撃について、まず受け入れておきたい現実があります。それは、侵入を100%防ぐことはできないということです。自分が書いていないコードを大量に取り込んで動かす以上、どうしてもどこかに信頼の穴は残ってしまうからです。 完璧に防げない以上、対策は「入られない努力」と「入られた前提の設計」の両面で考えておきたいところです。本記事では、その具体的な切り口として次の二段構えを取り上げます。 この2つを両輪で回していく、というイメージです。 もちろん、サプライチェーン対策はこれだけではありませんが、本記事ではその中から、「予防」と「被害局所化」という切り口を一例として取り上げ、パッケージマネージャやシークレット管理の具体的な設定レベルまで落とし込んで整理していきます。 サプライチェーン攻撃とは何か まずは、攻撃経路を少し整理しておきましょう。主な侵入口は次の3つです。 影響範囲の大きさを示す実例として、2026年3月31日に発生した axios のサプライチェーン侵害を見てみましょう。侵害されたメンテナのnpmアカウント経由で、悪意ある2バージョン axios@1.14.1 と axios@0.30.4 がnpmに公開されました。公開時間はおよそ3時間（約 09:21 公開〜12:29 削除）と短かったのですが、axios は週1億回以上ダウンロードされるため、その間に npm install した開発環境やCI/CDが侵害されうる、甚大な影響範囲でした。 手口はかなり巧妙でした。axios本体のソースは改変せず、攻撃用に作られた依存 plain-crypto-js@4.2.1 を新バージョンの依存に追加していたのです。インストール時に postinstall フック（node setup.js） が走り、二重難読化されたドロッパーがOSを判別してC2サーバから各OS向けのRAT（リモートアクセス型マルウェア）を取得・実行し、GitHubトークンやクラウド認証情報などを窃取したとされています。攻撃者はクリーンな plain-crypto-js@4.2.0 を約18時間前に先行公開して履歴を作り、「新着パッケージ」検知をかわそうとした形跡もありました。 なぜ今、リスクが高まっているのか サプライチェーン攻撃が以前より深刻になっている理由は、大きく3つあります。 3つ目については断定的な統計があるわけではないのですが、防御側の前提を「攻撃は速く・多く・巧妙になりうる」へ置き換えておきたい、という問題提起として捉えていただければと思います。 対策①：サプライチェーン攻撃の侵入を防ぐ（予防） 予防の主戦場は、パッケージマネージャの設定にあります。デフォルト設定のまま使うのではなく、攻撃面を少しずつ減らしていきましょう。 インストール時スクリプトを無効化する postinstall などのライフサイクルスクリプトは、攻撃者にとって「インストールだけで任意コードを実行できる」格好の入口です。実際に前述のaxios侵害でも、追加された依存の postinstall（node setup.js）が起点になっていました。ここを既定で無効化しておきましょう。 pnpm では、依存パッケージのビルド／ライフサイクルスクリプトを既定でブロックする挙動が v10.0.0（2025年1月） で導入されました。許可するパッケージだけを onlyBuiltDependencies に明示する、「既定でブロック → 許可リストで明示許可」という方針が取れます。 トレードオフ：ネイティブモジュールのビルドなど、スクリプト実行を前提とするパッケージは動かなくなることがあります。その場合は全面禁止にするのではなく、「既定は無効化し、必要なパッケージだけ明示的に許可リストへ加える」という運用が現実的でしょう。 公開直後のバージョンを即採用しない（min-release-age） 悪意あるバージョンは、公開直後に発見・撤回されるケースが多いです。axiosの汚染版も数時間で削除されました。公開からの経過時間で足切りをすれば、撤回前の汚染バージョンや、検知回避のために先行公開された依存を即座に取り込んでしまうリスクを下げられます。 npm では npm 11.10.0（2026年2月リリース）以降、min-release-age…