供應鏈深入分析

專家4 分鐘閱讀更新於 2026-03-13

AI 供應鏈相依樹之完整分析，涵蓋模型權重、分詞器、資料集、函式庫與基礎設施元件，含稽核方法論。

supply-chain deep-analysis dependencies security

供應鏈深入分析

AI 供應鏈比傳統軟體供應鏈更深、也更不可見。生產 AI 系統依賴模型權重（不透明的二進位檔）、分詞器組態（可包含可執行程式碼）、訓練資料集（規模之下難以稽核）、編排函式庫（快速釋出、審查有限）以及基礎設施元件（GPU 驅動、容器執行期、服務框架）。任何單一層被入侵都可顛覆整個系統。

AI 相依樹

典型生產 AI 系統有六層相依，各有不同信任假設與攻擊向量。

層級	元件	信任假設	主要攻擊向量
模型權重	預訓練模型、微調檢查點、adapter 權重	權重可安全載入	Pickle RCE、被植入木馬的權重、後門插入
分詞器	詞彙檔、tokenizer 組態、自訂 tokenizer 程式碼	分詞器只處理文字	自訂 tokenizer 程式碼執行、詞彙操控
資料集	訓練資料、評估基準、RAG 語料	資料乾淨且具代表性	資料投毒、基準操控、語料注入
函式庫	ML 框架、編排函式庫、工具套件	函式庫良性且正確	相依混淆、typosquatting、惡意更新
基礎設施	GPU 驅動、容器執行期、服務框架	基礎設施已正確設定	驅動漏洞、容器逃逸、錯誤設定
組態	超參數、部署組態、feature flag	組態已審查且正確	組態注入、機密暴露、漂移

模型權重分析

出處驗證

驗證來源倉儲
確認模型下載自官方倉儲。檢查 HuggingFace 組織驗證徽章、commit 歷史與 model card。注意 typosquatted 倉儲名稱。
檢查檔案格式
確認權重使用 safetensors 而非基於 pickle 的格式（.pt、.bin、.pkl）。若存在 pickle 檔，必須在載入前稽核。
驗證 checksum
把下載檔案的 SHA-256 雜湊與發布的 checksum 比對。HuggingFace 模型可對照 model card 的 commit hash。
掃描自訂程式碼
檢查自訂 modeling 程式碼（modeling_*.py、configuration_*.py）。若需要 trust_remote_code=True，載入前逐檔稽核。
測試後門
以已知觸發樣式執行行為測試。後門模型在觸發輸入時產生異常輸出，其他情境則表現正常。

權重完整性評估

檢查	所能偵測	方法
檔案格式驗證	基於 pickle 的 RCE 載荷	檢查檔案 magic bytes；safetensors 開頭為 `{`（JSON header）
統計分析	指向竄改的異常權重分布	比對參考模型的權重統計
層級雜湊	針對性權重修改（後門插入）	對各層雜湊，跨檢查點比對
行為測試	後門觸發器	以已知觸發樣式測試、量測輸出偏移

分詞器安全

分詞器常在安全稽核中被忽略，因為被視為簡單的文字處理器。但分詞器組態可含可執行程式碼，詞彙操控也可悄悄改變模型行為。

風險	描述	影響
自訂 tokenizer 程式碼	`tokenizer.py` 或 `tokenizer_config.json` 參照自訂 Python 類別	分詞器初始化時執行任意程式碼
詞彙操控	修改後的詞彙把特定 token 對應到非預期 ID	特定片語的安全繞過、微妙行為變化
前後處理注入	tokenizer 組態中的自訂前後處理函式	文字處理期間執行程式碼
BPE merge table 投毒	修改 merge 規則改變文字切分	特定輸入造成行為改變

資料集供應鏈

風險評估矩陣

資料來源	完整性風險	驗證方式
HuggingFace Datasets	中——社群上傳且審查有限	檢查 dataset card、貢獻者歷史、樣本抽查
Common Crawl / C4	高——網路抓取含對抗性內容	統計分析、毒性掃描、去重稽核
內部資料	低到中——視內部控制而定	存取控制稽核、資料血緣追蹤
合成資料（LLM 產生）	中——模型偏見會傳遞	多樣性分析、幻覺率、來源模型稽核
抓取資料（自製）	高——無出處保證	URL 驗證、內容檢驗、法務審查

資料管線稽核

import hashlib
from datasets import load_dataset
 
def audit_dataset(dataset_name, expected_hash=None):
    """Basic dataset integrity audit."""
    ds = load_dataset(dataset_name, split="train")
 
    audit_results = {
        "name": dataset_name,
        "num_samples": len(ds),
        "columns": ds.column_names,
        "sample_hash": hashlib.sha256(
            str(ds[:100]).encode()
        ).hexdigest(),
    }
 
    # Check for suspicious patterns in text fields
    text_cols = [c for c in ds.column_names if ds.features[c].dtype == "string"]
    for col in text_cols:
        samples = ds[col][:1000]
        injection_patterns = [
            "ignore previous", "system prompt", "IMPORTANT:",
            "<script", "javascript:", "eval(",
        ]
        for pattern in injection_patterns:
            matches = sum(1 for s in samples if pattern.lower() in s.lower())
            if matches > 0:
                audit_results[f"suspicious_{col}_{pattern}"] = matches
 
    if expected_hash and audit_results["sample_hash"] != expected_hash:
        audit_results["integrity_warning"] = "Hash mismatch!"
 
    return audit_results

函式庫相依分析

ML 專屬的相依風險

套件類別	範例	主要風險	稽核重點
ML 框架	PyTorch、TensorFlow、JAX	原生程式碼漏洞、pickle 預設	版本釘選、build 驗證
編排	LangChain、LlamaIndex、Semantic Kernel	快速釋出、不安全預設	changelog 檢視、安全公告追蹤
資料處理	pandas、numpy、Pillow	C 擴充漏洞、反序列化	CVE 追蹤、輸入驗證
模型服務	vLLM、TGI、Triton	網路暴露、GPU 記憶體存取	組態強化、存取控制
實驗追蹤	MLflow、W&B、Neptune	憑證儲存、artifact 完整性	存取控制、artifact 簽章

AI 系統的 SBOM

標準SBOM 涵蓋軟體函式庫但遺漏 AI 特定元件。延伸 AI 的 SBOM 應包含：

Model Bill of Materials (MBOM)——模型名稱、版本、來源、格式、checksum、訓練資料出處
Data Bill of Materials (DBOM)——資料集名稱、版本、來源、前處理指令稿、授權
標準 SBOM——所有 Python/系統套件含版本與雜湊
基礎設施 BOM——GPU 驅動、CUDA 版本、容器基礎映像、服務框架版本

供應鏈稽核方法論

盤點所有元件
列出六層中的每個相依。使用 pip freeze、容器映像檢視、model card 檢視、基礎設施文件。目標是完整 BOM。
評估各元件出處
對每個元件回答：來自何處？誰發布？如何遞送？是否驗證完整性？出處不明或未驗證者標記為風險。
辨識關鍵路徑
對應出從輸入到輸出路徑上的元件。被入侵的分詞器影響每個請求；被入侵的評估資料集僅影響模型挑選。
針對已知攻擊樣式測試
檢查模型 artifact 中的 pickle 檔、載入程式碼中的 trust_remote_code=True、requirements 檔中未釘選的相依、組態中暴露的機密。
產出強化建議
依風險（關鍵路徑位置 × 可利用度）與可行性排序。先取得快速勝利：釘選版本、改用 safetensors、移除不必要的工具。

參考資料

SLSA (Supply-chain Levels for Software Artifacts) -- 供應鏈安全框架
OWASP Machine Learning Security Top 10 -- ML 供應鏈風險
Model Cards for Model Reporting (Mitchell et al., 2019) -- 模型文件化標準

供應鏈深入分析

專家4 分鐘閱讀更新於 2026-03-13

AI 供應鏈相依樹之完整分析，涵蓋模型權重、分詞器、資料集、函式庫與基礎設施元件，含稽核方法論。

supply-chain deep-analysis dependencies security

供應鏈深入分析

AI 相依樹

典型生產 AI 系統有六層相依，各有不同信任假設與攻擊向量。

層級	元件	信任假設	主要攻擊向量
模型權重	預訓練模型、微調檢查點、adapter 權重	權重可安全載入	Pickle RCE、被植入木馬的權重、後門插入
分詞器	詞彙檔、tokenizer 組態、自訂 tokenizer 程式碼	分詞器只處理文字	自訂 tokenizer 程式碼執行、詞彙操控
資料集	訓練資料、評估基準、RAG 語料	資料乾淨且具代表性	資料投毒、基準操控、語料注入
函式庫	ML 框架、編排函式庫、工具套件	函式庫良性且正確	相依混淆、typosquatting、惡意更新
基礎設施	GPU 驅動、容器執行期、服務框架	基礎設施已正確設定	驅動漏洞、容器逃逸、錯誤設定
組態	超參數、部署組態、feature flag	組態已審查且正確	組態注入、機密暴露、漂移

模型權重分析

出處驗證

驗證來源倉儲
確認模型下載自官方倉儲。檢查 HuggingFace 組織驗證徽章、commit 歷史與 model card。注意 typosquatted 倉儲名稱。
檢查檔案格式
確認權重使用 safetensors 而非基於 pickle 的格式（.pt、.bin、.pkl）。若存在 pickle 檔，必須在載入前稽核。
驗證 checksum
把下載檔案的 SHA-256 雜湊與發布的 checksum 比對。HuggingFace 模型可對照 model card 的 commit hash。
掃描自訂程式碼
檢查自訂 modeling 程式碼（modeling_*.py、configuration_*.py）。若需要 trust_remote_code=True，載入前逐檔稽核。
測試後門
以已知觸發樣式執行行為測試。後門模型在觸發輸入時產生異常輸出，其他情境則表現正常。

權重完整性評估

檢查	所能偵測	方法
檔案格式驗證	基於 pickle 的 RCE 載荷	檢查檔案 magic bytes；safetensors 開頭為 `{`（JSON header）
統計分析	指向竄改的異常權重分布	比對參考模型的權重統計
層級雜湊	針對性權重修改（後門插入）	對各層雜湊，跨檢查點比對
行為測試	後門觸發器	以已知觸發樣式測試、量測輸出偏移

分詞器安全

分詞器常在安全稽核中被忽略，因為被視為簡單的文字處理器。但分詞器組態可含可執行程式碼，詞彙操控也可悄悄改變模型行為。

風險	描述	影響
自訂 tokenizer 程式碼	`tokenizer.py` 或 `tokenizer_config.json` 參照自訂 Python 類別	分詞器初始化時執行任意程式碼
詞彙操控	修改後的詞彙把特定 token 對應到非預期 ID	特定片語的安全繞過、微妙行為變化
前後處理注入	tokenizer 組態中的自訂前後處理函式	文字處理期間執行程式碼
BPE merge table 投毒	修改 merge 規則改變文字切分	特定輸入造成行為改變

資料集供應鏈

風險評估矩陣

資料來源	完整性風險	驗證方式
HuggingFace Datasets	中——社群上傳且審查有限	檢查 dataset card、貢獻者歷史、樣本抽查
Common Crawl / C4	高——網路抓取含對抗性內容	統計分析、毒性掃描、去重稽核
內部資料	低到中——視內部控制而定	存取控制稽核、資料血緣追蹤
合成資料（LLM 產生）	中——模型偏見會傳遞	多樣性分析、幻覺率、來源模型稽核
抓取資料（自製）	高——無出處保證	URL 驗證、內容檢驗、法務審查

資料管線稽核

import hashlib
from datasets import load_dataset
 
def audit_dataset(dataset_name, expected_hash=None):
    """Basic dataset integrity audit."""
    ds = load_dataset(dataset_name, split="train")
 
    audit_results = {
        "name": dataset_name,
        "num_samples": len(ds),
        "columns": ds.column_names,
        "sample_hash": hashlib.sha256(
            str(ds[:100]).encode()
        ).hexdigest(),
    }
 
    # Check for suspicious patterns in text fields
    text_cols = [c for c in ds.column_names if ds.features[c].dtype == "string"]
    for col in text_cols:
        samples = ds[col][:1000]
        injection_patterns = [
            "ignore previous", "system prompt", "IMPORTANT:",
            "<script", "javascript:", "eval(",
        ]
        for pattern in injection_patterns:
            matches = sum(1 for s in samples if pattern.lower() in s.lower())
            if matches > 0:
                audit_results[f"suspicious_{col}_{pattern}"] = matches
 
    if expected_hash and audit_results["sample_hash"] != expected_hash:
        audit_results["integrity_warning"] = "Hash mismatch!"
 
    return audit_results

函式庫相依分析

ML 專屬的相依風險

套件類別	範例	主要風險	稽核重點
ML 框架	PyTorch、TensorFlow、JAX	原生程式碼漏洞、pickle 預設	版本釘選、build 驗證
編排	LangChain、LlamaIndex、Semantic Kernel	快速釋出、不安全預設	changelog 檢視、安全公告追蹤
資料處理	pandas、numpy、Pillow	C 擴充漏洞、反序列化	CVE 追蹤、輸入驗證
模型服務	vLLM、TGI、Triton	網路暴露、GPU 記憶體存取	組態強化、存取控制
實驗追蹤	MLflow、W&B、Neptune	憑證儲存、artifact 完整性	存取控制、artifact 簽章

AI 系統的 SBOM

標準SBOM 涵蓋軟體函式庫但遺漏 AI 特定元件。延伸 AI 的 SBOM 應包含：

Model Bill of Materials (MBOM)——模型名稱、版本、來源、格式、checksum、訓練資料出處
Data Bill of Materials (DBOM)——資料集名稱、版本、來源、前處理指令稿、授權
標準 SBOM——所有 Python/系統套件含版本與雜湊
基礎設施 BOM——GPU 驅動、CUDA 版本、容器基礎映像、服務框架版本

供應鏈稽核方法論

盤點所有元件
列出六層中的每個相依。使用 pip freeze、容器映像檢視、model card 檢視、基礎設施文件。目標是完整 BOM。
評估各元件出處
對每個元件回答：來自何處？誰發布？如何遞送？是否驗證完整性？出處不明或未驗證者標記為風險。
辨識關鍵路徑
對應出從輸入到輸出路徑上的元件。被入侵的分詞器影響每個請求；被入侵的評估資料集僅影響模型挑選。
針對已知攻擊樣式測試
檢查模型 artifact 中的 pickle 檔、載入程式碼中的 trust_remote_code=True、requirements 檔中未釘選的相依、組態中暴露的機密。
產出強化建議
依風險（關鍵路徑位置 × 可利用度）與可行性排序。先取得快速勝利：釘選版本、改用 safetensors、移除不必要的工具。

參考資料

SLSA (Supply-chain Levels for Software Artifacts) -- 供應鏈安全框架
OWASP Machine Learning Security Top 10 -- ML 供應鏈風險
Model Cards for Model Reporting (Mitchell et al., 2019) -- 模型文件化標準

供應鏈深入分析

驗證來源倉儲

檢查檔案格式

驗證 checksum

掃描自訂程式碼

測試後門

盤點所有元件

評估各元件出處

辨識關鍵路徑

針對已知攻擊樣式測試

產出強化建議

相關文章

供應鏈深入分析

驗證來源倉儲

檢查檔案格式

驗證 checksum

掃描自訂程式碼

測試後門

盤點所有元件

評估各元件出處

辨識關鍵路徑

針對已知攻擊樣式測試

產出強化建議

相關文章