必要最低限の依存とその検証
これは、ソフトウェアの更新、重要なデータ、CI/CDパイプラインなどにおいて、「それが本物であるか」「改ざんされていないか」という整合性の検証を怠ることによるリスクです。「サプライチェーン攻撃」と密接に関連しています。
信頼していたソフトウェアが、攻撃者によって汚染されている場合があります。AI活用によりコーディングのコストが下がった結果、コードだけでなく、依存関係（ライブラリ）の数も無意識のうちに増加しがちです。
気がつけば多種多様なパッケージを利用し、不要なものを放置してはいないでしょうか？ このような「依存の肥大化」は、近年件数が増加している「サプライチェーン攻撃」の影響を受けやすい状態を生み出しています。
そもそも無駄なライブラリを導入しないこと、導入する場合はそれが意図したものであり、安全かを検証することが重要です。
- そのライブラリは適切にメンテナンスされているか
- 開発体制に問題はないか（バス係数が1ではないか／特定の個人のみに依存していないか）
- ダウンロード数は十分にあるか（タイポスクワッティング攻撃／類似名パッケージではないか）
- リリース直後（脆弱性が隠れている可能性）ではないか
特に個人開発や出所の不確かなOSSライブラリを使う場合は、AIの提案を過信せず、慎重に検討する必要があります。
具体例
2025年9月8日以降、人気があったdebug（週3億5760万ダウンロード）やchalk（週2億9999万ダウンロード）を含む18個のnpmパッケージが、サプライチェーン攻撃によって侵害されました。これらのパッケージの合計ダウンロード数は、週に20億回を超えます。
この攻撃は、典型的な「アップストリーム（上流）攻撃」であり、OSSエコシステムの脆さを利用したものです。 攻撃者は、これらパッケージすべての管理者であった一人の著名な開発者を標的にし、ソーシャルエンジニアリングで開発者アカウントを乗っ取りました。 幸いにもセキュリティ企業（Wiz）の調査によると、悪意のあるコードが公開されていたのは約2時間という短時間でした。
現実問題、OSSエコシステムは下記の風刺画のような脆さの上に成り立っています。この例でもそこを突かれました。結果的にこれらに依存するアプリケーション・ライブラリの全てに影響が及んだため、影響範囲は計り知れません。
対策
「そもそも無駄な依存を入れない」ことが第一です。その上で、JSエコシステムでは、下記のようなパッケージマネージャーのセキュリティ機能が役立ちます。
-
pnpmのminimumReleaseAge
- 新規に公開されたバージョンのインストールを意図的に遅延させる機能です。
- npmレジストリで公開されたばかりの「新しすぎる」パッケージのバージョンを、指定した時間が経過するまでインストールしないようにします。
- 上記の攻撃ケースは数時間で修正されたため、例えばminimumReleaseAge 1440（1440分＝1日）と設定していれば、攻撃の影響を回避できた可能性が高いです。
-
bunのSecurity Scanner API
- bunを利用している場合、インストール時の処理にSocketのセキュリティスキャンを組み込めます。
- これにより、悪意のあるパッケージ、タイポスクワッティング、その他のサプライチェーン攻撃からプロジェクトを保護します。
新たな攻撃経路
MCP（Model Context Protocol）サーバーの脅威にも注目すべきです。
これは、AIアシスタントが外部ツールと連携するための新しい仕組みですが、さっそく悪用ケースが報告されています。
シナリオとしては、開発に便利なツールを提供するMCPサーバーを見つけてインストールしたとします。もしそのサーバーが未検証で悪意のあるものだった場合、AIアシスタントを介して開発環境の機密情報（.envファイル、APIトークンなど）が静かに盗み出される可能性があります。
AIの「プラグイン」や「連携ツール」を安易に信頼し、その整合性や発行元を検証しないことが、深刻な情報漏洩につながるのです。 新しいツールには「すぐに信頼しない」姿勢が重要です。
.png)
