2026 年 7 月：供應鏈稽核挑戰

稽核某 ML 專案的完整供應鏈安全問題，涵蓋依賴、模型來源、資料管線、訓練基礎設施與部署工件。

2026 年 7 月：供應鏈稽核挑戰

稽核某 ML 專案的完整供應鏈 —— 從訓練資料與依賴，到模型工件與部署配置。此挑戰需要跨多個安全領域的廣度，並培養完整安全評估所需的系統化思考。

挑戰概覽

情境

您會取得「SentiBot」（一個情感分析服務）的完整原始碼儲存庫存取權。該儲存庫包含訓練、評估、打包與部署模型所需的一切。您的任務是在每個層級稽核此專案的供應鏈安全問題。

該專案結構為典型 ML 應用：

sentibot/
├── data/
│   ├── raw/                  # Training data sources
│   ├── processed/            # Preprocessed datasets
│   └── scripts/              # Data collection and processing scripts
├── models/
│   ├── base/                 # Base model checkpoints
│   ├── fine-tuned/           # Fine-tuned model artifacts
│   └── configs/              # Training configurations
├── src/
│   ├── training/             # Training code
│   ├── inference/            # Inference server code
│   ├── preprocessing/        # Data preprocessing pipeline
│   └── evaluation/           # Evaluation scripts
├── deploy/
│   ├── docker/               # Dockerfiles
│   ├── k8s/                  # Kubernetes manifests
│   ├── terraform/            # Infrastructure as code
│   └── ci/                   # CI/CD pipeline configs
├── tests/                    # Test suite
├── requirements.txt          # Python dependencies
├── setup.py                  # Package configuration
├── pyproject.toml             # Build configuration
└── README.md

稽核類別

類別 1：依賴安全（25 分）

稽核專案所有依賴項，找出已知漏洞與供應鏈風險。

1.1 Python 依賴（10 分）

• 檢視 requirements.txt 與 pyproject.toml，分辨已釘版與未釘版的依賴
• 檢查已宣告依賴是否有已知漏洞（CVE）
• 辨識來自不尋常或可能被入侵來源的依賴
• 找出套件名稱的 typosquatting 風險
• 檢查是否有已被放棄或維護者有疑慮變動的依賴

1.2 容器依賴（8 分）

• 稽核 Dockerfile 的基底映像安全（未釘版 tag、過時映像、不必要的套件）
• 檢查是否有秘密被烘焙進容器層
• 評估容器建置流程的注入點
• 檢視多階段建置的衛生（是否將建置工件外洩至執行時映像）

1.3 基礎設施依賴（7 分）

• 檢視 Terraform 模組的版本鎖定與來源完整性
• 稽核 Kubernetes manifests 的安全誤配置（privileged 容器、host network 存取、缺少資源限制）
• 檢查 CI/CD 管線配置的注入漏洞與秘密處理

類別 2：資料來源（20 分）

稽核訓練資料管線的完整性與來源問題。

2.1 資料來源驗證（10 分）

• 追溯每一項訓練資料來源至其起源
• 驗證資料收集腳本是否從預期來源擷取並具備完整性檢查
• 檢查是否有可能被對手操弄的資料來源（不帶校驗和的公開 URL、使用者貢獻內容、抓取的網站）
• 找出未正確授權就納入的資料

2.2 資料管線安全（10 分）

• 檢視預處理腳本的注入漏洞（例如對資料內容呼叫 eval()、對不受信任資料進行 pickle 反序列化）
• 檢查允許投毒樣本進入訓練集的資料驗證缺口
• 驗證處理過資料的校驗和在訓練前是否被驗證
• 找出資料管線中的 race condition 或 TOCTOU 問題

類別 3：模型安全（25 分）

稽核模型工件與訓練流程的安全問題。

3.1 基礎模型來源（10 分）

• 驗證基礎模型檢查點的來源與完整性
• 檢查基礎模型如何下載（釘選 hash vs. 可變 URL）
• 找出模型序列化格式的風險（允許任意程式碼執行的基於 pickle 的格式）
• 驗證模型檔案自下載以來未被竄改

3.2 訓練流程安全（8 分）

• 檢視可能引入漏洞的訓練配置（例如允許快速覆寫安全訓練的學習率）
• 檢查可能暗示資料投毒的訓練指標日誌
• 驗證訓練執行可由已宣告輸入重現
• 找出繞過驗證或評估步驟的訓練捷徑

3.3 模型匯出與服務（7 分）

• 稽核模型匯出流程的注入點
• 檢查匯出的模型是否採用安全序列化格式（safetensors vs. pickle）
• 驗證部署管線中是否有模型簽章或完整性檢查
• 檢視推論伺服器的反序列化漏洞

類別 4：部署安全（20 分）

稽核部署管線與執行時配置。

4.1 CI/CD 管線（10 分）

• 檢視 CI/CD 配置的命令注入漏洞
• 檢查管線日誌或環境變數中的秘密
• 驗證管線執行是否使用釘選的工具版本
• 找出缺少的安全關卡（無漏洞掃描、部署前無模型驗證）
• 檢查可能執行攻擊者控制程式碼的 pull request 管線觸發器

4.2 執行時配置（10 分）

• 檢視 Kubernetes manifests 的 security context 誤配置
• 檢查暴露的管理介面或除錯端點
• 驗證秘密是否透過合宜的秘密管理器管理（而非硬編碼或存於環境變數）
• 檢視網路政策是否有適當分段
• 檢查過於寬鬆的 IAM 角色或 service account 權限

類別 5：加分發現（10 分）

額外加分項目：

• 發現不屬於上述類別的問題
• 展示結合多個供應鏈弱點的攻擊鏈
• 提供風險優先排序的修復路徑圖
• 辨識專案安全實務上的系統性問題

稽核方法論

階段 1：清單（2 至 3 小時）

在尋找漏洞前，先建立完整清單：

• 物料清單（BOM）。 列出專案所用的每個依賴、工具與外部資源。
• 資料流圖。 描繪資料如何從來源經過處理、訓練進入部署模型。
• 信任邊界。 辨識專案信任外部輸入之處（下載的模型、擷取的資料、使用者貢獻的程式碼）。

階段 2：自動掃描（2 至 3 小時）

使用自動化工具找出已知問題：

階段 3：人工檢閱（6 至 8 小時）

自動工具會遺漏最有趣的供應鏈問題。人工檢閱應聚焦於：

• 信任決策。 每個程式碼信任外部輸入之處都是潛在漏洞。逐一檢閱。
• 序列化邊界。 跨越序列化邊界（pickle、JSON、protobuf）的資料是常見攻擊向量。
• 建置可重現性。 您能否從相同輸入再現相同的模型工件？若不能，則管線某處不是確定性的，可能可被操弄。
• 存取控制漏洞。 誰能修改每個元件？任何人都能發布新版本的依賴，與由受信任組織維護者不同。

階段 4：報告（2 至 3 小時）

依風險等級組織發現，並提供可行的修復：

## Finding: [Title]
**Risk Level:** Critical/High/Medium/Low
**Category:** Dependency/Data/Model/Deployment
**CVSS:** [Score if applicable]
 
### Description
[What the issue is and where it exists]
 
### Evidence
[Specific files, lines, or configurations that demonstrate the issue]
 
### Attack Scenario
[How an adversary could exploit this issue]
 
### Remediation
[Specific steps to fix the issue, with code examples where helpful]
 
### Priority
[Why this should be fixed now/soon/eventually]

已植入的漏洞

該儲存庫包含多種真實風格的漏洞：

• 明顯問題，任何安全掃描器都能抓到的（5 至 6 個發現）
• 細微問題，需要人工檢閱辨識的（8 至 10 個發現）
• ML 特有問題，傳統安全工具完全遺漏的（4 至 5 個發現）
• 干擾項，看似可疑但實際上無法利用的（2 至 3 個）

挑戰的一部分在於區分真實漏洞與偽陽性，並依實際風險排序發現。

計分

為何 ML 的供應鏈稽核不同

傳統軟體供應鏈稽核聚焦於程式碼依賴與建置管線。ML 專案有傳統工具未涵蓋的額外面向：

資料作為依賴

在傳統軟體中，依賴是函式庫與框架 —— 有版本、已發布，且（理想上）受檢閱。在 ML 中，訓練資料是一種依賴，但不具備這些屬性：

• 訓練資料通常沒有版本。同一資料來源可能隨時間變化而無任何紀錄。
• 資料來源鮮少被追蹤。從原始來源到訓練輸入的保管鏈通常沒有記錄。
• 資料完整性難以驗證。一個被投毒的訓練樣本在不知正確標籤情況下，看起來與合法樣本一模一樣。

此挑戰迫使您以處理程式碼依賴相同的嚴謹度來思考資料：它從何而來、如何驗證、若被入侵會怎樣？

模型作為建置工件

訓練完成的模型是 ML 版本的編譯二進位檔。像二進位檔一樣，它是不透明的 —— 您無法輕易透過讀取權重來檢視其行為。不同於二進位檔的是，在多數情況下它無法從原始碼可重現地建置：

• 非確定性訓練意味著相同程式碼與資料可能產生不同模型。
• 從公開儲存庫下載的基礎模型，信任建立於聲譽而非可驗證的來源。
• 模型序列化格式（尤其是基於 pickle 的格式）可能包含任意可執行程式碼。

GPU 信任邊界

ML 訓練與推論在引入其自身信任考量的 GPU 硬體上執行：

• GPU 驅動程式與 CUDA 函式庫是受信任運算基礎的一部分，但鮮少被稽核。
• 共享 GPU 環境（雲端實例、共享叢集）可能透過共享記憶體在租戶間洩露資訊。
• GPU 特定最佳化（混合精度、量化）會以可能具安全意涵的方式改變模型行為。

與專業實務的連結

供應鏈稽核是 AI 安全領域最搶手的技能之一。部署 ML 系統的組織需要回答以下問題：

• 「我們能信任這個來自 Hugging Face 的模型嗎？」
• 「若訓練資料供應商被入侵會怎樣？」
• 「我們的 CI/CD 管線是否能抵禦內部威脅？」
• 「我們如何驗證生產環境的模型就是我們訓練的模型？」

此挑戰培養為真實組織回答這些問題所需的系統化思考與技術技能。

延伸閱讀

• 基礎設施與供應鏈 —— 供應鏈安全基礎
• LLMOps 安全 —— ML 管線的營運安全
• 微調安全 —— 微調流程的安全
• 2026 年 8 月挑戰 —— 下一個挑戰