hihi，我是歐娜😺

前幾天講的風險，大部分都發生在 AI 系統「跑起來之後」。

像是：

• Prompt Injection：模型被惡意輸入影響
• Sensitive Information Disclosure：不該被看到的資料洩漏出去
• Excessive Agency：Agent 手上的能力太大

但假設你的 Prompt 寫得很好、權限也控得很好，結果你一開始下載進來的模型、套件或 Adapter，本身就已經有問題了呢？

今天來看 OWASP LLM Top 10 2026 第四名：

LLM04：Supply Chain（供應鏈風險）。

AI 的 Supply Chain，比想像中長很多

講到 Supply Chain，我第一個想到的其實還是傳統軟體開發。

例如一個 Node.js 專案：

My App
↓
npm package A
↓
package B
↓
package C

只要其中一個 Dependency 被植入惡意程式碼，最上面的 Application 就可能一起受到影響。

這個觀念到了 AI 一樣存在。

但麻煩的是：

AI 系統又多了很多不是「傳統程式碼」的東西。

例如一個 LLM Application 可能會依賴：

Application
├── Python / npm Packages
├── LLM Framework
├── Pre-trained Model
├── Dataset
├── LoRA Adapter
├── Tokenizer
└── Deployment Platform

所以 AI Supply Chain 要問的不只是：

我用了哪些第三方套件？

而是：

這整條鏈上的東西，我到底是從哪裡拿來的？中間有沒有被換掉？現在 Production 跑的，真的是原本驗證過的那一份嗎？

這就是今天的重點！

第一種：傳統 Dependency 問題還是在

先從最熟悉的開始。

AI Application 一樣會使用大量第三方 Library，例如：

PyTorch
Transformers
LangChain
FastAPI
Model Serving Framework

如果這些套件：

• 已經停止維護
• 存在已知漏洞
• Dependency 被入侵
• 安裝到了冒牌套件

一樣可能直接影響整個 AI 系統。

這部分其實跟傳統的 Software Supply Chain Attack 沒有差太多。

但現在多了 AI Coding Assistant 之後，又出現了一個很有趣的風險。

假設 AI 幫你產生：

pip install super-fast-ai-parser

看起來超級合理。

但問題是：

這個 Package 根本不存在。

如果攻擊者發現 AI 很常 Hallucinate 出這個名稱，他就可以真的跑去註冊：

super-fast-ai-parser

然後在裡面放進惡意程式碼。

下一個開發者看到 AI 建議：

pip install super-fast-ai-parser

也沒有特別確認，就直接裝下去。

哇～直接中招🤣

這種利用 AI Hallucinate 套件名稱，再搶先註冊惡意套件的攻擊方式，有一個名字叫做：

Slopsquatting。

所以現在用 AI 寫 Code，連：

「這個 Package 真的存在嗎？」

都變成需要確認的一件事。

第二種：Model 本身也是第三方 Artifact

這才是 AI Supply Chain 開始跟傳統軟體比較不一樣的地方。

現在我們很常直接從 Model Hub 下載別人已經訓練好的模型：

Model Hub
↓
Download Model
↓
Deploy

問題是：

你下載的 Model，本身也是一個外部 Artifact。

假設今天看到一個看起來很正常的模型：

awesome-company/customer-service-7b

但它可能：

• 被人修改過
• 本來就藏有 Backdoor
• 發布者帳號被入侵
• 名字刻意取成跟官方模型很像
• Artifact 在供應鏈過程中被替換

如果沒有經過驗證就直接把它 Deploy 到自己的環境，本質上就是把一個自己沒有完整建立、也不完全知道中間發生過什麼的 Artifact 帶進 Production。

而且 Model 又不像一般 Source Code 那麼容易直接 Review。

幾 GB、甚至幾十 GB 的 Weight：

[0.2841, -0.1937, 1.0284 ...]

你光看也沒辦法看得出：

「第 283,719,281 個參數看起來很邪惡。」

🤣🤣🤣

所以這時候就會出現一個很重要的概念：

Model Provenance。

可以先簡單理解成：

這個模型從哪裡來？誰發布的？是哪個版本？我現在拿到的，真的是原本預期的那一份嗎？

Model Card 不等於 Provenance

很多 Model Hub 都會提供 Model Card。

裡面可能會寫：

Base Model: XXX
Training Data: XXX
License: Apache 2.0
Fine-tuning: Instruction Tuning

這些資訊當然很重要。

但它主要是在告訴你：

「這個模型是什麼。」

它不一定能直接證明：

「你現在手上拿到的檔案，就是你原本預期拿到的那一份。」

例如：

昨天：
model.bin → SHA256: abc123...

今天：
model.bin → SHA256: xyz789...

兩個檔案都叫：

model.bin

甚至 Model Page 看起來完全沒變。

但實際內容已經不一樣了。

所以做 Supply Chain Security，不能只知道：

Model Name

還需要進一步知道：

Source
Version
Hash
Signature

latest 很方便，但安全上要小心

這個概念其實跟 Container Image 很像。

例如 Deployment 永遠寫：

model: company/model:latest

今天：

latest → Version A

但明天供應商更新之後：

latest → Version B

你的 Pipeline 下一次重新部署：

Production
↓
Pull latest
↓
拿到 Version B

問題是：

Version B 可能根本沒有走過你原本對 Version A 做的：

Security Test
Evaluation
Red Team
Approval

所以 Supply Chain Security 很重視一件事：

不要只依賴會變動的版本標籤。

與其永遠相信：

latest

更好的做法是固定：

Model Version
Commit SHA
Artifact Digest

核心概念其實很簡單：

我 Deploy 的，應該是「我驗證過的那一份」，而不是「現在剛好最新的那一份」。

Hash 跟 Signature 又差在哪？

這兩個其實很容易搞混🤣

可以先簡單記成：

Hash
→ 這個檔案有沒有變？

Signature
→ 這個 Artifact 是不是由我預期的 Publisher 簽署的？

Hash

假設一個 Model Artifact 原本的 Hash 是：

SHA256: abc123...

如果檔案內容被修改，重新算出來的 Hash 就會不一樣。

所以 Hash 可以幫助我們確認：

現在拿到的檔案，跟原本驗證過的是不是同一份。

Signature

Signature 則多回答了一個問題：

這份 Artifact 是不是由我信任的 Publisher 簽署的？

不過這裡要注意：

Hash 正確、Signature 正確，也不代表這顆 Model 的行為一定安全。

它們比較像是在確認：

「你現在拿到的，確實是你原本預期的那一份，而且中間沒有被偷偷換掉。」

但那一份 Model 本身有沒有 Backdoor、異常行為，還是需要另外測試。

所以可以簡單記成：

來源可信、檔案沒有被竄改，不代表 Model 本身就是安全的。

LoRA Adapter 也算 Supply Chain

除了完整 Model 之外，現在也很常看到 LoRA Adapter。

可以先很簡單理解成：

不需要重新訓練整顆 Model，而是在原本的 Base Model 上加上一組額外參數，讓模型學會新的能力或行為。

概念像：

Base Model
+
LoRA Adapter
↓
客製化 Model

例如：

General LLM
+
Customer-Service LoRA
↓
公司客服模型

這裡 Supply Chain 要注意的是：

Base Model 可信，不代表後面加上的 Adapter 也一定可信。

例如：

可信的 Base Model
+
被修改過的 LoRA Adapter
↓
有問題的最終 Model

所以不能只確認：

我 Base Model 是從官方下載的。

還要知道：

後面又加了哪些 Artifact？它們又是從哪裡來的？

這也是為什麼 AI Supply Chain 會比傳統 Dependency 再多一層。

那到底怎麼知道自己的 AI Supply Chain 裡有什麼？

這時候就會提到傳統 Software Supply Chain Security 很常看到的：

SBOM（Software Bill of Materials）。

可以把它想成：

軟體的「成分表」。

例如：

Application v1.2

├── FastAPI 0.xx
├── PyTorch 2.x
├── Transformers x.x
└── Package ABC 1.0

這樣當某個套件被發現有已知漏洞時，就可以快速確認：

我的系統有沒有使用到受影響的套件或版本？

但到了 AI，只知道 Software Dependencies 還不夠。

因為我們前面已經看到，AI 系統裡還可能有：

Model
Dataset
LoRA Adapter
Tokenizer
Model Version
Artifact Hash
Source

所以實際上還需要建立一份 Inventory。

至少要能回答：

用了哪個 Model？
哪個版本？
從哪裡來？
有沒有加 Adapter？
用了哪些 Dataset？
最後 Deploy 的是哪一份 Artifact？

因為如果連：

Production 現在到底跑的是什麼？

都答不出來，要談 Supply Chain Security 其實就很困難。

所以 LLM04 到底怎麼防？

我自己會整理成幾件事。

1. 不要看到 Model 就直接下載

先確認：

Publisher
Source
Model Card
License
Maintenance Status
Security History

來源不明的 Model，不要直接進 Production。

2. Pin 版本，不要只相信 latest

Production 使用的：

Package
Model
Container
Adapter

都盡量使用明確版本，或是不可變的 Artifact Reference。

確保：

Deploy 的就是「測過的版本」。

而不是下一次部署時，默默換成另一份 Artifact。

3. 驗證 Artifact

可以透過：

Hash
Signature
Version
Source

確認現在準備 Deploy 的 Artifact，是不是原本預期的那一份。

避免：

原本驗證 A
↓
最後部署的卻是 B

4. 不要只記 Software Dependency

除了 package 之外，AI 系統還要知道：

用了哪個 Model？
哪個版本？
哪個 Dataset？
哪個 Adapter？
從哪裡來？

至少要能清楚回答：

Production 現在到底是由哪些東西組成的？

5. 第三方 Model 上線前還是要測

即使今天：

來源可信
版本正確
Hash 正確
Signature 正確

也不代表它的行為一定符合你的安全需求。

還是需要做：

Evaluation
Security Testing
Red Team
Behavior Monitoring

因為：

來源可信、檔案沒有被竄改，不代表 Model 本身就是安全的。

這些驗證比較像是在確認：

你現在拿到的，確實是你原本預期的那一份。

但那一份本身有沒有 Backdoor、異常行為，或是不符合你的安全需求，還是需要另外測試。

我覺得 LLM04 最重要的一句話

前幾天我們一直在看：

AI 跑起來之後可能發生什麼？

今天 Supply Chain 則是在問更前面的一件事：

你憑什麼相信，現在跑起來的那些東西？

你信任的不只是：

你的 Code

而是一整串：

Package
↓
Framework
↓
Model
↓
Dataset
↓
Adapter
↓
Deployment Artifact

任何一層出了問題，最後 Production 跑的東西，都可能跟你原本以為的不一樣。

所以今天我會記：

不要只知道「我用了哪個模型」，還要知道「它從哪裡來、是哪個版本，最後部署的到底是不是我驗證過的那一份」。

這才是 AI Supply Chain 真正想保護的東西。

先預告下一篇會看的是：

Data and Model Poisoning

因為 Supply Chain 跟 Data and Model Poisoning 其實很容易混在一起～

我自己會先這樣記：

• Supply Chain → 外部引入的 Model / Adapter / Package 等 Artifact，來源是否可信、內容是否被竄改？
• Data and Model Poisoning → 資料或模型遭到污染後，會如何影響 AI 的學習結果與後續行為？

兩者確實會有一些重疊。

例如第三方 Model 被植入 Backdoor，可以從：

「我是不是引進了一個不可信的 Artifact？」

這個 Supply Chain 角度來看。

但如果我們要繼續追：

「這顆 Model 到底是怎麼被動手腳的？攻擊者又怎麼讓這些行為持續留在模型裡？」

就會開始進到 Data and Model Poisoning。

所以兩篇關注的核心不太一樣：

LLM04（Supply Chain）關心的是信任鏈：Artifact 從哪裡來、是哪個版本、最後拿到的是不是你以為的那一份。

LLM05（Data and Model Poisoning）關心的是污染：攻擊者如何透過污染資料或模型，影響 AI 的學習結果與後續行為。

簡單來說，一個在問：

「我拿進來的東西能不能信？」

另一個在問：

「AI 學到的東西，有沒有被人動過手腳？」

明天就是要來看 AI 到底是怎麼被「教壞」的～🤣