AIコーディングツール時代に急増、npmサプライチェーン攻撃の正体と対策

「npm install」は事実上、見知らぬ人のコードを実行することと同じ——TrivyやaxiosへのOSS攻撃が示すサプライチェーンリスクと、AIエージェントが広げる盲点を解説します。

まず結論

開発ツールの依存パッケージを悪用したサプライチェーン攻撃が2025年以降急増
TrivyやaxiosなどのOSSへの実際の攻撃事例があり、知名度の高いパッケージでさえ安全ではない
AIコーディングツールの普及で「自動パッケージ管理」が増え、人間の目が届かないリスクが拡大している
npm installは実質的に「知らない人のコードを実行すること」という現実を認識する必要がある
対策: ロックファイル固定・脆弱性スキャン自動化・AIへの権限制限が有効

ニュース元: 「npm install」は任意コード実行のようなもの？──Trivyやaxiosへのサプライチェーン攻撃を踏まえた開発環境への新たな向き合い方（Publickey）

1. サプライチェーン攻撃とは何か

「サプライチェーン攻撃」とは、ターゲットを直接狙うのではなく、そのターゲットが信頼して使っているソフトウェアやツールの配布経路（供給網）を汚染する攻撃手法です。

わかりやすい例を挙げると：

あなたの会社のシステムを直接攻撃するより、あなたの会社が毎日使っているツールに悪意あるコードを仕込む方が効率的
セキュリティ意識が高い企業でも、「信頼しているパッケージ」なら疑わずに使う
一つのパッケージを汚染すれば、そのパッケージを使う何万もの組織に同時にリーチできる

近年最も有名な例は2020年のSolarWinds事件。米国政府機関・大手企業数百社が利用するITインフラ管理ソフトの更新ファイルにマルウェアが仕込まれ、数ヶ月間気づかれずに機密情報が盗まれ続けました。

なぜnpmが狙われやすいのか

JavaScript/TypeScriptのパッケージ管理システム「npm」には現在200万以上のパッケージが登録されています。

WebアプリやAIツールの開発では、npm installの一行で数十〜数百のパッケージが自動的にインストールされます。これらは直接使うパッケージだけでなく、そのパッケージが依存するパッケージ、さらにその依存関係…と芋づる式に広がります（依存ツリーと呼びます）。

問題は、その依存ツリー全体を開発者が一つひとつ確認することは事実上不可能だということです。

2. 実際に起きたTrivyとaxiosへの攻撃

2025年以降、特に話題になったのが信頼性の高いOSSツールへの攻撃です。

Trivyへの攻撃

Trivyは、コンテナイメージやコードの脆弱性スキャンに使われる人気OSSセキュリティツールです。「セキュリティを守るためのツール」自体が攻撃されたという事実は、業界に大きな衝撃を与えました。

代表的な攻撃手口：

手口	内容
タイポスクワッティング	公式パッケージ名に似た偽パッケージを公開。タイプミスを誘う
アカウント乗っ取り	メンテナーのアカウントを乗っ取り、正規パッケージに悪意あるコードを追加
依存関係汚染	Trivyが依存するサブパッケージの一つを改ざん

どの手口も「パッケージ名が公式と同じ、または非常に似ている」ため、機械的なチェックだけでは見抜けません。

axiosへの攻撃

axiosは、ブラウザ・Node.jsで使えるHTTPクライアントで、週間ダウンロード数が4,000万を超える超人気パッケージです。

axiosを標的にした攻撃では、axiosが依存している別のパッケージを汚染する形での侵入が報告されています。直接axiosが改ざんされたわけではなく、「有名パッケージ自体は安全でも、その先の依存関係が危険」 という間接的な手口でした。

これは「有名だから安全」という思い込みがいかに危険かを象徴しています。

3. AIエージェントが増やす「見えないリスク」

ここからが特にexplAIn読者に関係する話です。

2025〜2026年にかけて、Claude Code・GitHub Copilot Agent・DevinなどのAI駆動の開発エージェントが急速に普及しています。

これらのエージェントは：

ユーザーの指示を受けて自動でコードを書く
必要なパッケージを自律的に判断してインストールする
CI/CDパイプラインと連携して人間の確認なしにデプロイする

この「自動化」こそがサプライチェーン攻撃リスクを高めています。

従来のフロー:

開発者が npm install を実行 → 依存パッケージ一覧を（一応）確認 → インストール

AIエージェント時代のフロー:

「◯◯を実装して」とAIに指示
→ AIが必要なパッケージを自律的に判断・インストール
→ コードが動いている

後者では、開発者がどのパッケージがインストールされたかをリアルタイムで確認していないケースが増えています。「AIに任せている」状態は効率的ですが、悪意あるパッケージが混入しても気づきにくいのです。

⚠️ ここは気をつけて

AIコーディングツールは「人間より速くコードを書ける」ですが、「人間より安全かどうか」は別の話です。AIエージェントは既知の問題があるパッケージでも、人間の確認なしに使用することがあります。「任せている」状態には、常に確認コストとのトレードオフがあります。

4. 今日からできる対策

難しい話が続きましたが、対策は整理されています。順番に実施すれば、リスクは大幅に下がります。

対策1: ロックファイルを必ずGitにコミットする

package-lock.json（npm）やyarn.lock（Yarn）を必ずGitにコミットし、パッケージのバージョンを固定する。

# これだけはやる
git add package-lock.json
git commit -m "lockfileを固定"

バージョンが固定されていると、攻撃者が新バージョンに悪意あるコードを仕込んでも自動更新されないため、攻撃を受けにくくなります。

対策2: 脆弱性スキャンをCI/CDに組み込む

TrivyやSnykなどのツールをパイプラインに組み込み、毎回のビルドで脆弱なパッケージを自動検知する。

# まず手元で試す
npm audit

# Trivyでファイルシステムをスキャン
trivy fs .

対策3: AIエージェントのパッケージインストールを承認制にする

Claude Codeなどには「Human-in-the-loop」モードがあります。AIが新しいパッケージをインストールしようとするとき、必ず人間の確認が入る設定にしておく。

自動化は便利ですが、セキュリティ上のリスクが伴うアクション（インストール・デプロイ）には人間の承認ステップを残しておくことが重要です。

対策4: 最小権限の原則でAIエージェントを動かす

AIエージェントに与える権限は、作業に必要な最小限にとどめる。

コードレビュータスク → ファイル読み取りのみ、書き込み権限は不要
テスト実行タスク → 本番環境へのデプロイ権限は不要
依存インストールタスク → ネットワーク送信権限は制限

「便利だから何でもできるようにする」は、攻撃されたときの被害範囲を広げます。

5. セキュリティ研究者の視点から

専門家たちが2025年以降に繰り返し指摘してきたのは：

「OSSへの信頼モデルが限界を迎えている」 という現実です。

従来のオープンソースは「多くの目があれば安全」という前提でした。しかし：

npmには200万超のパッケージがあり、全件レビューは不可能
多くのパッケージは無償ボランティアのメンテナー1〜2人が管理
そのメンテナーのアカウントが乗っ取られれば一瞬で汚染される

この問題に対し、GitHubのSignerや各社のSBOM（Software Bill of Materials）対応が進んでいますが、業界全体への普及にはまだ時間がかかります。

筆者の評価（警戒度）: ★★★★★

「理論上の脅威」ではなく「実際に起きている攻撃」です。Trivy・axiosへの事例が示すように、有名ツールさえ例外ではない。完全な防御はありませんが、基本的な対策を積み重ねることで、リスクを「ゼロにする」ではなく「許容できる水準に下げる」ことが重要です。

あなたへの影響

コードを書く・書かせる人（開発者・AIコーディングツールユーザー）

最も影響を受けます。使っているAIコーディングツールがどんなパッケージを自動インストールしているか、一度確認してみてください。package.jsonやpackage-lock.jsonの中身を見ると、意外と知らないパッケージが山ほど入っています。

まずnpm auditを実行するだけで、既知の脆弱性を含むパッケージが一覧できます。

ノーコード・ローコードツールを使う人

直接npmを使わなくても、ローコードツールの裏側はnpmパッケージの塊です。ツールのアップデートに伴って攻撃が入り込む可能性はゼロではありません。ツールを選ぶ際に「セキュリティ更新の頻度」「インシデント対応の透明性」という観点を持つと良いでしょう。

コードを書かない一般ユーザーの方

直接の被害可能性は低いですが、あなたが毎日使うWebサービス・アプリも、開発時にnpmを使っていることがほとんどです。サービスを選ぶ際に「セキュリティ更新が定期的か」「脆弱性の報告・対応が公開されているか」という観点は、サービス選択の一つの指標になります。

まとめ

「npm installは任意コード実行と同義」という表現はショッキングですが、事実に近い比喩です。

AIエージェントが自律的にパッケージを管理し、CI/CDが自動デプロイする世界では、人間の目が届かない「自動化の隙間」にサプライチェーン攻撃が入り込む余地が広がっています。

大切なのは「怖い」で思考停止することではなく、「自分のプロジェクトのリスクを知り、対策を一つずつ実施する」こと。まずロックファイルのコミットとnpm auditの実行から始めるだけで、リスクは大幅に下がります。

ーー Synth