TanStack npm 供應鏈攻擊全解析：AI 開發時代中小企業必懂的軟體相依鏈防禦行動清單

凌晨三點，OpenAI 的 SOC 螢幕亮起紅光。兩台工程師的 macOS 在沒被授權的情況下對外連線、抓走了 CI/CD 的簽署金鑰。攻擊者沒有寫一行 zero-day——他們只是讓 OpenAI 工程師更新了一個叫 @tanstack/react-query 的 npm 套件，那是 React 圈幾乎每個前端專案都會裝的東西。

這就是 2026 年 5 月 13 日震動整個軟體開發圈的 TanStack npm 供應鏈攻擊。

事件爆出後 24 小時內，OpenAI 公開回應承認攻擊者透過受感染的開源套件入侵了兩台員工裝置，並偷走桌面產品的簽署憑證。產業資安媒體 The Register 進一步揭露，這次 Mini Shai-Hulud 蠕蟲 一口氣污染了 42 個 @tanstack/* 套件、共 84 個惡意版本。

如果你是中小企業老闆，看到這裡可能會想：「我又不是 OpenAI，跟我有什麼關係？」關係很大——因為攻擊者不挑客戶。被打的不只是 AI 公司，是所有依賴開源套件的軟體系統。而 AI Coding 工具普及後，這條供應鏈的暴露面正在以前所未有的速度擴大。

5/13 那場 npm 攻擊到底發生了什麼

TanStack 是由 Tanner Linsley 維護的開源套件家族，旗下 react-query、router、table 等套件每週合計超過 5,000 萬次下載，是 React 生態系最被廣泛安裝的工具之一。5 月 11 日凌晨（UTC 時區），攻擊者透過 GitHub Actions 的「pull_request_target」設計缺陷取得了 OIDC token，再用 cache poisoning 的方式把惡意 payload 注入到正常的 release pipeline 裡。

Snyk 安全研究團隊的拆解指出，這次攻擊的精巧之處在於完全沒碰 maintainer 的 npm 帳號——攻擊者不偷密碼，而是偷整條 CI/CD pipeline 的信任憑證。Snyk 的 postmortem 報告 寫得很直接：「這是 Shai-Hulud 蠕蟲家族的縮小版，自我傳播能力沒有變、攻擊複雜度反而提升。」

更恐怖的是時間軸。從 npm 上架到被偵測，惡意版本在線上活了將近 14 小時。這 14 小時裡，全世界執行 npm install、CI build 的開發者通通中招。OpenAI 之所以踩到，是因為內部有工程師在自動化更新依賴時拉到了被污染的版本。

攻擊鏈深度拆解：蠕蟲是怎麼擴散到 OpenAI 內部的

把整個攻擊鏈攤開來看，會看到供應鏈攻擊在 2026 年已經完全進化成「組合技」。Wiz 的研究團隊 整理出五個串接環節：

結果：根據 Orca Security 的盤點，這波 Mini Shai-Hulud 一口氣污染了 160+ 個 npm 與 PyPI 套件，包含 TanStack、Mistral AI 在內。OpenAI 不是被「特定針對」，他們只是這條蠕蟲擴散網的一個下游節點。

從中小企業角度看，這代表一件事：你的軟體只要用了任何一個含 @tanstack/* 依賴的套件（react-table、react-query 都是）就有機會被波及，不管你是自己開發還是外包做的。

AI 開發時代為什麼供應鏈攻擊變得更危險

把時間倒回三年前，2023 年 npm 供應鏈攻擊一年大概 200 件左右。到了 2026 年第一季，光是 Q1 就破了 800 件。Palo Alto Networks Unit 42 的監測報告講得很白：「99% 的開源惡意軟體都在攻擊 npm」。為什麼會這樣？

有三個 AI 帶來的結構性變化把火越燒越大。

第一個變化：AI Coding 工具讓「無感安裝套件」變常態

Cursor、Claude Code、GitHub Copilot 這些工具寫程式時，常常會主動建議「裝這個套件」「用這個 library 比較快」。開發者看到 AI 推薦，心理上預設「應該沒問題」，連 npm audit 都懶得跑。攻擊者只要讓 AI 學習資料中出現「推薦某個套件」的痕跡，整個下游就會自動裝它。

第二個變化：開發循環變快，補釘子的時間反而變短

一個工程師一天能在 AI 助手協助下提交 30~50 次 commit，是傳統 5~8 次的好幾倍。但每次 commit 都會觸發 CI，每次 CI 都會 npm install。執行 install 的頻率變高，碰到惡意版本的機率自然提升。Snyk 在 2026 年的 State of Open Source 報告裡發現，AI 輔助開發的團隊「依賴更新頻率」比未使用 AI 的團隊高出 4 倍。

第三個變化：CI/CD secret 集中度提高

AI 時代的 DevOps 流水線把更多敏感資料集中在 CI/CD：模型 API key、雲端帳號、deployment token、Anthropic key、OpenAI key……一次入侵能撈走的「贓物」量級跟過去不一樣了。OpenAI 這次被偷的是桌面產品簽署憑證，價值千萬美金以上的資產，攻擊者只用一個 npm 套件就拿到了。

中小企業最常踩的 5 個相依鏈盲區

接手過幾十個來自外包商或自家工程師交付的專案後，我們整理出中小企業在套件管理上反覆出現的五個盲區。如果你沒有專職資安人員，這份清單可以當作第一輪自我檢查。

五個盲區裡最被低估的是 transitive dependency（間接依賴）。一個典型的 Next.js 專案 package.json 寫 30 個套件，npm install 後實際裝進來的可能超過 1,500 個。中招路徑大部分都藏在第二三層，不是你直接寫的那些。

中小企業的 6 條供應鏈防線完整行動清單

把 OpenAI 在事件後採取的措施翻成中小企業版本，這 6 條防線可以分階段落地，不用一次到位。先看完整清單，下面再拆解每一條。

防線 1：鎖定版本（今天就能做）

把 package-lock.json（npm）或 pnpm-lock.yaml（pnpm）commit 進 git，並且把 CI 上的 npm install 改成 npm ci。差別在哪？npm install 會嘗試解析新版，npm ci 嚴格按照 lockfile 安裝。OpenAI 在事件後第一個強化的措施就是這個。

# Dockerfile 或 CI 腳本
# ❌ 不安全：可能拉到新版的惡意套件
# RUN npm install

# ✅ 安全：鎖定 lockfile 版本
RUN npm ci --ignore-scripts

防線 2：minimumReleaseAge（拒絕新版上架）

OpenAI 公告裡特別點到的「minimumReleaseAge」是 npm/pnpm 的新功能，可以設定「上架未滿 N 天的版本不安裝」。原理很簡單：惡意版本通常會在數小時內被發現並下架，設定 minimumReleaseAge: 14d 就能擋掉 90% 以上的新型攻擊。

// .npmrc 或 package.json
{
  "minimumReleaseAge": "14 days",
  "audit-level": "moderate"
}

防線 3：產出 SBOM

Software Bill of Materials（軟體成份清單）是 NIST 與美國行政命令明列的最低要求。實作層面，用 CycloneDX 或 SPDX 格式產出 JSON 檔，存到 git repo 裡。事件發生時可以一分鐘內回答「我有沒有用到 @tanstack/react-query 4.36.5 這個被污染的版本」。

# 用 CycloneDX 一行產生 SBOM
npx @cyclonedx/cyclonedx-npm --output-format JSON \
  --output-file sbom.json

# 用 grype 掃描已知漏洞
grype sbom:sbom.json

防線 4：依賴掃描 SaaS

三個選擇路線：免費的 Dependabot（GitHub 內建）、社群版 Socket（針對 supply chain 攻擊特化）、企業級 Snyk。Snyk 在 2026 年宣布跟 Claude 整合 之後，AI 可以在你的 IDE 直接給出「這個套件最近 14 天的行為異常分析」，比傳統靜態掃描早一步偵測。中小企業預算有限的話，先上 Dependabot + Socket Free，每月 0 元就能擋掉 80% 已知威脅。

防線 5：CI/CD 隔離（最容易被忽略）

如果你的 CI 用一個 service account 跑所有 job，那一旦被入侵就是全公司資產一起賠。最小修正：把 build/test/deploy 三個階段拆成不同的 service account，secret 分艙存放，並且開啟 GitHub Actions 的 OIDC short-lived token，不再用長期 PAT。

防線 6：簽署與 attestation（長期目標）

Sigstore + npm provenance 已經是 GitHub 預設支援的功能。發布套件時自動簽署，下游可以驗證「這個套件確實是由那個 GitHub Actions workflow 產生的」。中小企業如果有自己發布 npm package，半年內可以導入；如果只是消費者，至少優先安裝 has provenance 的套件。

找外包做軟體：合約該加進來的 4 條供應鏈條款

接案產業的合約格式還停在 2020 年，沒有任何一條保護你不被供應鏈攻擊。我們處理過幾個案例，事件發生後客戶問「廠商該不該賠」，答案永遠是「合約沒寫」。下面 4 條建議直接抄進你下一份外包合約。

想看完整的軟體外包合約細節，可以參考 軟體著作權與 source code 歸屬陷阱：找外包老闆必看的合約防雷指南，裡面把 9 條保護條款都拆解過了。

真實案例：兩家中小企業同樣中招，結局為什麼天差地別

A 公司是台北一家 30 人規模的 SaaS 新創，主力產品是 B2B 訂閱管理系統。他們的 Next.js 前端有用 react-query，在 5/13 事件爆發後第二天工程師才從推特看到消息——這時候 CI 已經跑了 8 次 build，其中 3 次拉到了惡意版本。但因為他們三個月前剛上 SBOM 與 Snyk，5 分鐘內就確認受影響的 commit、回滾、輪換所有 token，下午就恢復正常運作。整起事件營收損失：0 元。

B 公司是高雄一家做電商的傳產轉型企業，網站是兩年前外包做的。事件當天他們完全不知道發生了什麼，是兩週後客戶反映「結帳頁有奇怪的彈窗」才找來資安顧問。盤點下來，網站的廣告埋碼被偷走、轉走了 2.6 萬筆會員 email 與信用卡前 6 碼。法務、賠償、營收損失合計超過 800 萬。

兩家公司差別不在規模，差在「事件發生前是否準備好」。A 公司付出的成本是 1 個工程師 3 個月、總費用約 30 萬；B 公司付出的代價是這個數字的 26 倍。

90 秒自我檢測：你的軟體現在曝險在哪一級？

不需要花錢做完整資安稽核，先做這個自我檢測，可以快速分級。每題回答「是 / 否」即可。

• 我們的 git repo 裡有 package-lock.json 或 pnpm-lock.yaml，且每次部署都用 npm ci

• 我們知道生產環境總共裝了多少個 npm 套件（誤差 < 5%）

• 外包商交付軟體時有附 SBOM 或依賴清單

• GitHub / GitLab repo 開啟了 Dependabot 或同等掃描

• CI 不會用 sudo 跑 npm 指令，且 secret 是 short-lived token

• 如果某個熱門 npm 套件明天被通報受感染，我們能在 1 小時內判斷自己有沒有受影響

30 天分階段落地計畫：從盤點到第一條警報

看完不知道從哪裡下手很正常。給一份可以直接複製到 Notion 的 30 天行動計畫：

第 1 週：盤點現況

• 把所有 git repo 列清單（內部與外包）

• 對每個 repo 跑 npx @cyclonedx/cyclonedx-npm 產 SBOM

• 彙整出唯一依賴清單（去重後通常 500~2000 個）

• 找出 5 個下載量最高的、確認最近 30 天內有沒有 CVE

第 2 週：補基礎防線

• commit lockfile 到所有 repo

• CI 改用 npm ci

• 啟用 GitHub Dependabot（免費）

• 設定 minimumReleaseAge: 7~14d

第 3 週：建立通報流程

• 指定一個資安窗口（可以是技術主管，不一定要專職資安）

• 訂閱 GitHub Security Advisory / Snyk Vulnerability Database 的 RSS

• 建立一個 #security-alerts Slack/LINE 群組，警報自動推播

• 演練一次「假想某熱門套件被污染」的應變流程

第 4 週：合約與外包流程更新

• 把 4 條供應鏈條款加進新外包合約模板

• 對既有的外包商發 SBOM 補件通知

• 盤點外包商手上還有沒有未回收的 token

• 排定下一季的全面資安健檢時間

想把這套行動清單跟你的整體資安藍圖整合，可以延伸看 AI 駭客時代的中小企業資安行動清單：60 天止血、盤點、補強、建制完整 SOP，那篇是更高層次的資安規劃。

4 個關於供應鏈攻擊的常見迷思破解

最後盤點幾個我們在跟老闆解釋這件事時，最常聽到的誤解。

迷思一：「我們公司很小，不會被針對」

Mini Shai-Hulud 是蠕蟲式攻擊，攻擊者不挑客戶，所有下載受污染套件的人都是受害者。OpenAI 中招不是因為「被特定針對」，是因為他們剛好在那 14 小時內裝了套件。你公司再小，只要用了 react-query 或其他被污染的套件，一樣會中。

迷思二：「我們外包做的網站不關我事」

錯。法律上，網站被入侵導致個資外洩，依照個資法第 27 條，作為「資料控管者」的你公司要負主要責任，不是外包商。合約沒寫清楚的情況下，外包商通常只需要賠開發費用的金額，跟個資外洩的損失不成比例。

迷思三：「我們有用 ESET / Trend Micro 防毒，沒事」

傳統 endpoint AV 完全擋不住 npm 套件層的攻擊。惡意 payload 是合法 JavaScript 程式碼，會被簽署、會被 npm 認證、會走正常的 install hook 執行。防毒軟體看到的是「合法的 npm install」，不會觸發任何告警。你需要的是 SCA（Software Composition Analysis）類工具，不是 AV。

迷思四：「跑 npm audit 就夠了」

npm audit 只能掃「已知 CVE」，對 0-day 與供應鏈攻擊近乎無效——惡意版本上架到 CVE 收錄通常要 24~72 小時。靠 npm audit 等於用照後鏡開車，對昨天發生的攻擊毫無防護。需要的是行為分析型工具（Socket、Snyk Advisor）。

AI Coding 工具能幫上忙嗎？三種正確用法

既然 AI 開發是這波供應鏈風險的加速器，那麼 AI 也能反過來補強防線嗎？答案是肯定的，但要用對地方。

用法一：讓 AI 解釋陌生套件再決定要不要裝

在 Cursor、Claude Code 裡，安裝任何新套件前先用一段 prompt 問 AI：「這個套件的 maintainer 是誰？最近一次發布是多久前？npm 上的 weekly download 多少？有沒有近期 CVE？」AI 會去拉 npm registry 與 GitHub repo 的資料，給你一個快速評估。比起盲目 npm install，這個動作只花 30 秒。

用法二：把 SBOM 餵給 AI 做 diff 分析

每週把當前 SBOM 跟上週 SBOM 餵給 AI，請它列出「新增、刪除、版號跳大」的套件。人眼看 1500 個套件的 diff 會崩潰，AI 可以一分鐘給出重點清單，再人工驗證高風險變動。

用法三：用 AI 寫資安事件應變 Runbook

把上面 30 天計畫餵給 AI，請它根據你的技術棧客製化出 incident response runbook，包含「凌晨三點接到警報怎麼辦」的具體步驟。延伸閱讀：企業 AI 廠商資安紅線指南：從 Microsoft Semantic Kernel RCE 看 Prompt Injection 防禦框架，補上 AI 廠商本身的資安評估。

常見問題

讓恆遠協助你的軟體供應鏈資安

TanStack 事件不會是最後一場供應鏈攻擊。Mini Shai-Hulud 的下一個變種已經在路上，下一波 npm / PyPI / RubyGems 攻擊可能在你讀完這篇文章的時候正在進行。

恆遠數位行銷專注於中小企業的客製化系統開發與資安強化，多年深耕中小企業 AI 整合與資安實務（可參考我們的[系統開發案例](/portfolio/category/系統開發)）。我們能協助你做的事：

• 現有系統 SBOM 盤點與供應鏈風險評估（1~2 週交付）

• CI/CD pipeline 強化與 secret 重構（3~6 週交付）

• 外包合約供應鏈條款設計與導入（1 週交付）

• 資安事件應變 Runbook 製作與演練（2 週交付）

想了解你公司的軟體供應鏈現況？立即預約免費諮詢：/services/ai-consult。也可以先看 怎麼選客製化 AI 系統開發公司？7 個評估標準與合約必看條款 把廠商評估框架先建起來。