サプライチェーン攻撃の40年 AI時代の依存を守る入門ガイド

Posted at 2026-10-08

はじめに

npm install を打つとき、その先で何百ものパッケージの作者を信頼していることを意識する人は多くありません。ところが 2025〜2026 年の npm や PyPI の主な事件を並べると、そのいずれでも侵入口になったのは目新しい脆弱性よりも、開発者が信頼して取り込んでいる依存・更新・ビルドの経路でした。では、AI がコードを書き、AI エージェントが開発端末で動くようになった今、守るべき場所は 40 年前から何が変わり、何が変わっていないのでしょうか。

対象読者は、npm や PyPI の依存を日常的に使い、AI コーディングツールも開発に取り入れているエンジニアです。

時事の数字から確認します。警察庁の「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等」によると、令和8年上半期のランサムウェア被害報告件数は 123 件で、統計を取り始めた令和2年下半期以降、半期として過去最多でした（警察庁 PDF）。IPA の「情報セキュリティ10大脅威 2026」組織向けでは、1 位「ランサム攻撃による被害」、2 位「サプライチェーンや委託先を狙った攻撃」に続き、3 位に「AIの利用をめぐるサイバーリスク」が新たに選ばれています（IPA）。

ただし、どちらも「AI のせいで攻撃が増えた」ことを示すデータではありません。この記事では、AI との関わりを一次資料で確認できた事件だけを AI の文脈で扱い、因果は断定しません。

TL;DR

この記事を読むと、次のことができるようになります。

1984 年から 2026 年までのサプライチェーン攻撃を 5 期に分け、どの期にも共通する「狙われる場所」を説明できる
AI 時代に増えた入口（AI 関連の依存、開発端末上の AI エージェント、存在しないパッケージ名の提案）を、事件ごとに AI との関係を区別して説明できる
CISA KEV の公開 JSON を自分で集計し、その数字で言えることと言えないことを切り分けられる
lockfile、install スクリプト、公開権限、パッチの優先度、AI エージェントの権限という順で、自分のリポジトリの防御を点検できる

40年を5期で見る

期	代表的な出来事	狙われた場所	AI との関係
0（1984）	Thompson の講演	コンパイラという信頼の起点	なし
1（2016〜2018）	left-pad、event-stream	パッケージの依存とメンテナ権限	なし
2（2020〜2021）	SolarWinds、Codecov	ビルド・配布の基盤	なし
3（2024）	xz utils	上流プロジェクトのリリース物	なし
4（2025〜2026）	Nx、Shai-Hulud、LiteLLM、axios、TanStack、ChainDrop	公開権限・CI・開発端末	事件ごとに異なる（後述）

0期: 1984年、信頼をどこまで遡れるか

Ken Thompson は 1984 年のチューリング賞講演「Reflections on Trusting Trust」（CACM Vol.27 No.8）で、次の問いを置きました。

To what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software.
出典: MIT 6.857 講義配布の転載 PDF（公式版は ACM Digital Library）

ソースコードを読んで安全を確かめても、それをビルドする道具まで信頼できるとは限りません。最後は「書いた人を信頼するしかない」という指摘は、40 年後の依存管理にもそのまま当てはまります。

1期: 2016〜2018年、依存の脆さとメンテナ権限

2016 年 3 月の left-pad は攻撃ではありません。npm の公式ポストによると、混乱の原因は「abrupt unpublishing」、つまり作者によるパッケージの突然の取り下げでした（npm blog）。小さな 1 パッケージが消えただけで多くのビルドが止まり、依存の連鎖がどれだけ細い糸でつながっているかが可視化されました。

2018 年の event-stream は、その糸が悪用された事例です。npm の公式記録によると、新しくメンテナになった人物が 2018-09-09 に event-stream 3.3.6 へ flatmap-stream という依存を追加し、npm はこれを「posing as a maintainer, took over maintainership」と記述しています。2018-11-26 に npm Security へ通報があり、npm は該当パッケージを削除しました。影響は Copay の 5.0.2〜5.1.0 に及んでいます（npm blog）。

2期: 2020〜2021年、ビルドと配布の基盤

CISA の勧告 AA20-352A（初版 2020-12-17）は、初期侵入経路の一つを SolarWinds Orion 製品の DLL に対するサプライチェーン侵害と説明しています（CISA）。利用者が導入した製品そのものに、侵害が含まれていました。

Codecov の公式発表によると、CI で使われる Bash Uploader は 2021-01-31 から断続的に不正改変され、2021-04-01 に顧客がチェックサムの不一致を報告したことで是正されました。Codecov は CI の環境変数に置いた認証情報の再発行を推奨しています（Codecov）。

3期: 2024年、上流のリリース物

2024-03-29、Andres Freund 氏が oss-security メーリングリストに「backdoor in upstream xz/liblzma leading to ssh server compromise」と投稿しました（openwall）。影響を受けたのは xz utils 5.6.0 と 5.6.1 のリリース tarball で、CISA は同日のアラートで 5.4.6 へのダウングレードを推奨しています（CISA）。利用者が手を入れていない上流のリリース物そのものが、侵害の置き場所になった事例です。

4期: 2025〜2026年、公開権限と開発端末

この期の事件は数が多いため、AI との関係で 3 つに分けます。

区分	事件	一次資料の記述
攻撃に AI ツールが使われた	Nx s1ngularity（2025-08）	Nx 公式ポストモーテム
AI 関連の依存・設定が標的や永続化先になった	LiteLLM（2026-03）、ChainDrop（2026-08）	LiteLLM 公式、Microsoft Security Blog
AI とは無関係	Shai-Hulud（2025-09）、axios（2026-03）、TanStack（2026-05）	CISA、axios メンテナ、TanStack 公式

Nx s1ngularity: Nx のポストモーテムによると、悪性版は 2025-08-26 に公開され、約 4 時間で npm から削除されました。根本原因は GitHub Actions のインジェクション脆弱性による publish トークンの窃取です。Nx はこの攻撃が被害端末の「local AI tools (like Claude and Gemini)」を使おうとしたと記述しています（Nx）。一方、Wiz が収集したサンプルの分析では、AI を使ったデータ持ち出しの成功は「under a quarter of cases」にとどまりました（Wiz）。AI ツールは悪用の対象になったものの、攻撃の成否を大きく左右したとまでは言えません。

Shai-Hulud: CISA は 2025-09-23 のアラートで、500 を超える npm パッケージに広がった自己複製型のワームを報告しています（CISA）。同アラートに AI の関与の記述はありません。

LiteLLM: LiteLLM の公式発表によると、PyPI 上の 1.82.7 と 1.82.8 が 2026-03-24 に悪性版として公開され、PyPI が隔離しました（LiteLLM）。LLM の API を束ねるゲートウェイという AI 関連ライブラリが標的になった事件で、攻撃に AI が使われたとは書かれていません。本ブログでも「LiteLLM供給チェーン攻撃入門」で詳しく扱いました。

axios: axios メンテナの事後記録によると、悪性リリースは 2026-03-31 に公開され約 3 時間で削除されました。リード・メンテナの PC がソーシャルエンジニアリングとマルウェアで侵害され、盗まれた npm 認証情報で公開されたもので、個人アカウントから直接公開しており、OIDC による公開フローはこれから採用すると説明されています（axios issue #10636）。本ブログの「Claude Code ソースコード流出と axios 攻撃」でも取り上げています。

TanStack: TanStack のポストモーテムによると、2026-05-11 に 42 パッケージ・84 バージョンが短時間で公開され、その公開は「OIDC trusted-publisher binding」で認証されていました。メンテナは、この仕組みに公開ごとのレビューが無い点を弱点に挙げています（TanStack）。

ChainDrop: Microsoft Security Blog（2026-08-04）は、400 を超える npm パッケージに広がった自己増殖型のワームを報告し、盗んだ GitHub 認証情報で「inject Claude and Visual Studio Code configuration files into repositories」したと記述しています（Microsoft）。攻撃者が AI を使ったという記述はなく、AI ツールの設定ファイルが永続化の置き場所として使われた事例です。

変わらないもの

5 期を並べると、狙われた場所は 3 種類に収まります。

信頼の連鎖: 利用者はソースを読まずに依存や更新を受け入れる（Thompson の問い、SolarWinds、xz）
メンテナと公開権限: 公開できる人やトークンを押さえれば、正規のパッケージとして配布できる（event-stream、Nx、axios）
更新とビルドの経路: CI やビルド工程の中で実行されるものは、成果物に混ざる（Codecov、TanStack）

1984 年の問いが 2026 年になっても古びないのは、利用者が「誰が書き、誰が公開し、どこでビルドされたか」を自分では確かめにくい構造が変わっていないからです。対策の推奨もほとんど同じ顔ぶれで繰り返されています。Codecov が 2021 年に勧めた認証情報の再発行は、2025 年の CISA の Shai-Hulud アラートでも推奨に入っています。axios と Nx の是正策はどちらも、OIDC による公開への切り替えを含んでいました。

AI時代に変わったもの

一次資料で確認できる範囲では、変化は「攻撃が AI で高度化した」ことではなく、守る対象の範囲が広がったことです。

依存先に AI 関連ライブラリが加わった: LiteLLM のような LLM ゲートウェイは複数のモデル API への接続を一手に引き受けるため、侵害されると下流のアプリケーションへ影響が及びます。公式発表も、影響を受けうる下流として AI agent frameworks を挙げています。
開発端末上の AI エージェントや CLI が新しい入口・悪用対象になった: Nx では端末の AI CLI が悪用されようとし、ChainDrop では AI ツールの設定ファイルがリポジトリへの永続化に使われました。開発端末に置かれた AI ツールは、ファイルを読み、コマンドを実行する権限を持つため、侵害された依存から見れば使える道具の一つになります。
存在しないパッケージ名をモデルが提案するリスク: コード生成 LLM のパッケージ幻覚を分析した論文（arXiv:2406.10279、論文に 2025 年の USENIX Security Symposium 掲載予定と記載）は、16 モデル・576,000 サンプルを調べ、幻覚の割合を商用モデルで少なくとも 5.2%、オープンソースモデルで 21.7% と報告しています。存在しない名前を攻撃者が先に登録すれば、AI の提案をそのまま入れた開発者が取り込むことになります。業界では slopsquatting と呼ばれることがありますが、これは論文の用語ではありません。実際に悪用された事例は、筆者の調査範囲では一次資料で確認できていません。

TanStack の事件からは、もう一つの示唆が読み取れます。Trusted Publishing は「誰が公開したか」を長命トークンなしで保証する仕組みで、provenance は「どこでどうビルドされたか」を検証可能にします。しかしビルド工程の中で悪性コードが実行された場合、その成果物は正規の経路で、正規の署名付きで公開されます。npm の provenance のドキュメントも、provenance はパッケージが悪意あるコードを含まないことの保証ではないと明記しています（npm Docs）。

公開データで見る現在

AI 時代の変化を数字で確かめられないかと考え、CISA の Known Exploited Vulnerabilities（KEV）カタログを実際に取得して集計しました。KEV は、実際に悪用が確認された脆弱性を CISA が登録する台帳で、JSON で公開されています。

$ TZ=Asia/Tokyo date; curl -sS -o kev.json -w 'HTTP %{http_code} size %{size_download}\n' https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json; date
2026-10-08 20:41:03 JST
HTTP 200 size 1767828
2026-10-08 20:41:04 JST

集計に使ったスクリプトの主要部分です。追加年ごとに件数、CVE 番号の年が追加年と同じ件数、追加時点で 5 年以上前の CVE の件数を数えています。

import json,sys,collections,statistics
d=json.load(open(sys.argv[1]+'/kev.json'))
v=d['vulnerabilities']
print('catalogVersion',d['catalogVersion'],'dateReleased',d['dateReleased'],'count',d['count'],'len',len(v))
by=collections.Counter();same=collections.Counter();old=collections.Counter()
for x in v:
    a=int(x['dateAdded'][:4]);c=int(x['cveID'].split('-')[1])
    by[a]+=1;same[a]+=(a==c);old[a]+=(a-c>=5)
print('year added same% old5+%')
for y in sorted(by): print(y,by[y],same[y],round(100*same[y]/by[y]),old[y],round(100*old[y]/by[y]))
print('min dateAdded',min(x['dateAdded'] for x in v),'max',max(x['dateAdded'] for x in v))

出力（ベンダー別集計の行は省略）は次のとおりです。

catalogVersion 2026.10.04 dateReleased 2026-10-04T18:52:56.0635Z count 1734 len 1734
year added same% old5+%
2021 311 120 39 17 5
2022 555 91 16 261 47
2023 187 121 65 18 10
2024 186 116 62 18 10
2025 245 151 62 30 12
2026 250 169 68 25 10
min dateAdded 2021-11-03 max 2026-10-04

列は左から、追加年・追加件数・CVE 採番年が追加年と同じ件数・その割合（%）・追加時点で 5 年以上前の CVE の件数・その割合（%）です。2021 年は 11 月の開始後 2 か月分、2022 年は立ち上げ期の登録が集中しているため、比較には 2023 年以降を使います。

追加年	KEV 追加件数	CVE 採番年＝追加年	追加時点で 5 年以上前の CVE
2023	187	65%	10%（18 件）
2024	186	62%	10%（18 件）
2025	245	62%	12%（30 件）
2026（10/4 まで）	250	68%	10%（25 件）

出典: CISA KEV JSON フィード（catalogVersion 2026.10.04 を 2026-10-08 20:41 JST に取得し筆者が集計）

筆者が集計して目を引いたのは右端の列です。追加時点で 5 年以上前の CVE が、2023 年以降も毎年 1 割前後含まれています。新しい脆弱性への対応が注目されがちですが、悪用が確認される脆弱性の一部は、修正が出てから長く放置された古いものです。

参考として、製品名を手で選んだ 4 種類（Langflow、LiteLLM、MLflow、Ray）に限って数えると、KEV に登録されていたのは 2025 年に 1 件、2026 年に 10 件でした。2026 年に AI 関連の OSS 製品の脆弱性が複数登録された、とまでは言えますが、製品の選び方が網羅的ではないため傾向は読めません。また、これは製品の脆弱性が悪用された記録であり、4 期で見た「悪性版が公開される」サプライチェーン侵害とは別の話です。

データで言えないこと

ここまでの数字には、それぞれ読み方の上限があります。

KEV の件数は攻撃や被害の件数ではない: 悪用が確認され、CISA が登録した脆弱性の数です。2026 年の 250 件が 2025 年通年を上回っていても、被害が増えたことの証明にはなりません。
「CVE 採番年＝追加年」の割合は悪用の速さではない: CVE 番号の年は採番の年で、公開日とは一致しません。KEV の JSON には CVE の公開日が含まれないため、公開から悪用までの日数はこの集計では出せていません。
KEV では 40 年の比較ができない: カタログの開始は 2021-11 で、AI 時代以前との比較には使えません。
警察庁の不審アクセス増加は被害件数ではない: 同じ資料にある「1日・1IPアドレス当たり 1 万 3,687 件（前年比 50.7%増）」は観測センサー上のアクセス件数です。被害の増加を示す数字としては、ランサムウェア被害報告 123 件のほうを使うべきです。そしてその 123 件も、サプライチェーン攻撃の件数ではありません。
AI と被害増の因果は言えない: 上のどの数字も、AI の普及と結びつける根拠にはなりません。Wiz の Nx 分析の数値も、Wiz が集めたサンプルに基づくものです。

現場で持ち帰る防御チェックリスト

40 年の事件から逆算すると、防御は「入れる前」「入れるとき」「公開するとき」「入れたあと」「開発端末」の順で効きます。

1. lockfile と npm ci で依存を固定する

npm ci は lockfile を必須とし、package.json と食い違えばエラーで止まります。lockfile を書き換えることもありません（npm Docs: npm ci）。

2. install 時のスクリプト実行を絞る

依存の postinstall などは、既定ではインストール時に実行されます。--ignore-scripts を付けると実行されません（npm Docs: config）。この挙動と前項の lockfile の挙動を、クラウドのサンドボックス（Node v22.22.0 / npm 10.9.4）で実際に確かめました。依存には、postinstall で作業ディレクトリに空の目印ファイルを書くだけの無害なローカルパッケージ（file: 依存）を使い、ネットワークからの取得はしていません。

--- lock generation (ignore scripts)
up to date, audited 3 packages in 414ms        # package-lock.json 生成
--- A: npm ci
added 1 package, and audited 3 packages in 446ms
  → POSTINSTALL_RAN.txt が生成された（postinstall が実行された）
--- B: npm ci --ignore-scripts
added 1 package, and audited 3 packages in 410ms
  → POSTINSTALL_RAN.txt は生成されず（cat: No such file or directory）
--- C: package.json に lock に無い依存(demo-dep2)を追加して npm ci --ignore-scripts
npm error code EUSAGE
npm error `npm ci` can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with `npm install` before continuing.
npm error Missing: demo-dep2@1.0.0 from lock file      (exit=1)

矢印の行は確認結果を書き添えたメモです。A では目印ファイルが作られ、B では作られませんでした。C では lockfile に無い依存を足した時点で npm ci が失敗し、lockfile は更新されていません。注意点として、ネイティブビルドが必要なパッケージはスクリプトを止めると動かなくなることがあり、筆者はその影響までは確かめていません。導入するならテスト環境で依存ごとに確認してください。

npm の config には、公開から指定日数を超えたバージョンだけを入れる min-release-age もあります（既定は無効）。Microsoft は ChainDrop の報告で、npm CLI v12 へ更新したうえでこの設定を使うよう推奨しています。上の実測に使った npm 10 系では使えない可能性があるため、導入前に手元の npm のバージョンを確認してください。Nx の悪性版は約 4 時間、axios は約 3 時間で削除されており、公開直後のバージョンを避けるだけでも取り込む機会を減らせます。

3. 公開権限を守る

パッケージを公開する側なら、長命の npm トークンを CI に置かず、OIDC による Trusted Publishing に切り替えます。GitHub Actions や GitLab CI では provenance も自動生成されます（npm Docs: Trusted publishers）。provenance の考え方は SLSA の Build Track（L1〜L3）として整理されています（SLSA v1.2）。

ただし TanStack が示したように、これらはビルド工程の中で実行された悪性コードを止めません。CI 側では、TanStack が是正策に挙げたサードパーティ Action のコミット SHA でのピン留めと、外部からの貢献でパイプラインが動く条件の見直し（Nx の是正策）を合わせて行います。

4. 依存の中身を見える化する

SBOM: CISA はソフトウェア部品表を「a nested inventory, a list of ingredients that make up software components」と説明しています（CISA SBOM）。事件の報告が出たとき、自分が該当版を使っているかを即答できるかが分かれ目になります。
OpenSSF Scorecard: Pinned-Dependencies や Token-Permissions などのチェックで、依存先プロジェクトの運用状態を点検できます（Scorecard）。
Dependabot security updates: アラートが出た依存について、修正版への PR を自動で作成します（GitHub Docs）。CISA も Shai-Hulud アラートで有効化を推奨しています。

5. パッチの優先度に KEV を使う

すべての脆弱性を同時に直せないなら、KEV に載っているものから先に直します。KEV は「悪用が確認された」ことを基準にした台帳なので、深刻度スコアだけで並べるより、実際に狙われている順に近づきます。集計で見たとおり、KEV には毎年 1 割前後、5 年以上前の CVE が入ってくるため、古い依存の棚卸しも同じ枠で扱います。

6. AI エージェントの権限と秘密情報を分ける

Nx と ChainDrop は、開発端末の AI ツールとその設定が攻撃の通り道になりうることを示しました。次の点を見直します。

AI エージェントや CLI に、本番の認証情報や npm の公開トークンが見える環境で作業させない
エージェントが書き換えた設定ファイルやワークフローは、通常のコードと同じくレビューを通す
AI が提案したパッケージ名は、レジストリ上の存在・公開者・公開時期を確認してから入れる
事件が報告されたら、Codecov と CISA の推奨どおり、関係しうる認証情報を再発行する

Thompson の問いに戻ると、2026 年の開発者が信頼しているのは、コンパイラの作者だけではありません。依存の作者、公開トークン、CI、そして端末で動く AI エージェントまで、信頼の連鎖は長くなりました。連鎖を短くすることはできなくても、上の 6 項目で「どこまで信頼しているか」を自分で決めることはできます。まずは手元のリポジトリで npm ci を使っているか、CI に長命トークンが残っていないかの 2 点から確かめてみてください。

参考リンク

事件の一次資料は各節の本文にリンクしています。ここでは防御と統計の資料だけを挙げます。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up