如何用 Google OSS-Rebuild 打造一份符合 SaMD要求的 SBOM
如果是智慧醫療領域相關的人，這幾年應該很常聽到「軟體即醫療器材」（SaMD）的產品，你也一定對 SBOM (Software Bill of Materials，軟體物料清單) 這個詞不陌生。過去這可能只是個「建議事項」，但在美國 FDA…
UpdatedMarch 24, 2026•2 min read
JJhihHao Wu**近期研究重點包含 AI Agent 的供應鏈攻擊、PII 偵測模型評估，以及醫療 AI 在臨床流程中的安全落地。
在這裡，我分享深度技術實測報告（如 NVIDIA NeMo, WildGuard）與職場技術成長心得，致力於在 AI 浪潮中打造具備資安韌性的解決方案。
On this page
如何用 Google OSS-Rebuild 打造一份符合 SaMD要求的 SBOM傳統 SBOM 的盲點OSS-Rebuild：為你的 SBOM 注入「可驗證的血統證明」前提準備Bash 驗證腳本： verify_deps.sh整合到 GitLab CI/CD (.gitlab-ci.yml)除了驗證之外
如何用 Google OSS-Rebuild 打造一份符合 SaMD要求的 SBOM
如果是智慧醫療領域相關的人，這幾年應該很常聽到「軟體即醫療器材」（SaMD）的產品，你也一定對 SBOM (Software Bill of Materials，軟體物料清單) 這個詞不陌生。過去這可能只是個「建議事項」，但在美國 FDA 等監管機構的大力推廣下，它已經是送審文件中的「必備項目」。
不過，有太多的產品審查上，太多團隊把 SBOM 當成一個形式上的勾選項目。使用第三方或商業工具，產出一份長長的、列滿了上百個開源套件的清單，然後就結束了。
如果你只做到這樣，你還沒搞懂監管機構要的到底是什麼。
FDA 所要求的SBOM清單，真正想了解的問題是：「如何證明在貴公司的產品中所使用的這些工具套件都是安全、可信、且未被竄改的？」
一般的 SBOM 多半只能回答第一個問題，頂多加上有些第三方軟體漏洞工具可以一併目前所使用的第三方套件無重大安全性漏洞，但是更進階的安全性驗證，目前是無能為力的。
這就是 Google OSS-Rebuild 能發揮關鍵作用的地方 — — 它能幫你的 SBOM 從一份單純的「成分清單」，升級為一份帶有「品質檢驗證明的出廠報告」。
傳統 SBOM 的盲點
想像一下，你開發了一個 AI 判讀心電圖的 AI 模型，並在專案的 CI/CD 流程中，有個工具自動掃描你的專案，定期的產生 SBOM，並紀錄專案使用了 tensorflow-2.15.0。
幾個月後，資安新聞爆出，某個駭客組織在一個非常短的時間窗口內，成功地將一個被植入後門的 tensorflow-2.15.0 版本上傳到了 PyPI 官方套件庫，然後又迅速將其替換為正常版本。
如果稽核員問：「你要怎麼證明當時 CI/CD 流程下載到的那個 tensorflow-2.15.0，是官方發布的沒有被污染的版本？」
此時，一份只列出套件名稱和版本的傳統 SBOM，就顯得無力，無法證明你所使用的那個二進位檔案的「血統」（Provenance）。
OSS-Rebuild：為你的 SBOM 注入「可驗證的血統證明」
OSS-Rebuild 的價值，就是為每一個開源套件提供一個獨立、可驗證的「血統證明」。它提供的資訊，可以直接強化你的 SBOM，讓它從一份靜態清單變成一份動態的信任憑證。
具體來說，OSS-Rebuild 可以提供以下關鍵數據，而這些數據正是傳統 SBOM 所欠缺的：
驗證狀態 (Verification Status)
原始碼來源 (Source Provenance)
成品雜湊值 (Artifact Hashes)
過去我們可能需要自己寫程式去撈資料庫對應或是透過資安工具的API，不過谷哥爸爸已經釋出了官方的 oss-rebuild CLI 命令列工具，這讓整個驗證流程變得極為簡單直接，也更容易整合到CI/CD自動化流程中。
我們來看看如何使用這個官方工具，打造一個自動化的3PP依賴驗證流程。
前提準備
你的 CI/CD 環境（Runner）必須安裝 Go 語言環境（因為 CLI 工具是用 Go 開發的）。
你的專案根目錄下有
requirements.txt檔案，裡面明確定義了套件與版本（例如absl-py==2.0.0）。
Bash 驗證腳本： verify_deps.sh
與其用 Python 再包一層，我們直接用更適合在 CI/CD 環境中執行的 Bash 腳本來呼叫這個 CLI 工具。
#!/bin/bash
# 當任何指令失敗時立即停止腳本，這是 CI/CD 中的好習慣
set -eo pipefail
echo "--- 開始使用 oss-rebuild CLI 驗證專案依賴套件 ---"
ALL_VERIFIED=true
# 檢查 requirements.txt 是否存在
if [ ! -f "requirements.txt" ]; then
echo "錯誤: 找不到 requirements.txt 檔案！"
exit 1
fi
# 讀取 requirements.txt，過濾掉註解和空行
grep -vE '^\s*#|^\s*$' requirements.txt | while IFS= read -r line || [[ -n "$line" ]]; do
# 解析 'package==version' 格式
# 移除所有空白字元
line_no_space=$(echo "$line" | tr -d '[:space:]')
PACKAGE=$(echo "$line_no_space" | cut -d'=' -f1)
VERSION=$(echo "$line_no_space" | cut -d'=' -f3)
echo "[*] 正在驗證 ${PACKAGE}==${VERSION}..."
# 呼叫 oss-rebuild CLI 工具。
# 如果套件版本被成功驗證過，指令會成功結束 (exit code 0)。
# 如果找不到或未驗證，指令會失敗 (non-zero exit code)。
# 我們將輸出導向 /dev/null 來保持日誌乾淨，只focus在成功或失敗。
if oss-rebuild get pypi "$PACKAGE" "$VERSION" > /dev/null 2>&1; then
echo " [✓] VERIFIED: ${PACKAGE}==${VERSION}"
else
echo " [✗] UNVERIFIED: ${PACKAGE}==${VERSION} - 未在 OSS-Rebuild 數據庫中找到成功的驗證紀錄。"
ALL_VERIFIED=false
fi
done
echo "--- 驗證結束 ---"
if [ "$ALL_VERIFIED" = "true" ]; then
echo "所有依賴套件都已通過 OSS-Rebuild 驗證。"
exit 0
else
echo "發現未經驗證的3PP套件！"
exit 1
fi
整合到 GitLab CI/CD (.gitlab-ci.yml)
有了這個腳本，我們在 GitLab CI/CD 的設定檔就變得非常乾淨。
stages:
- test
- verify-dependencies
- build
# ... 省略 test stage
verify_deps:
stage: verify-dependencies
# 1. 使用一個預裝了 Go 的官方鏡像
image: golang:1.22
before_script:
- echo "安裝 oss-rebuild CLI 工具..."
# 2. 使用官方指令安裝 CLI 工具
- go install github.com/google/oss-rebuild/cmd/oss-rebuild@latest
# 3. 確保安裝好的工具在系統路徑 (PATH) 中
- export PATH="$(go env GOPATH)/bin:${PATH}"
script:
- echo "執行依賴驗證腳本..."
# 4. 賦予腳本執行權限並執行
- chmod +x ./verify_deps.sh
- ./verify_deps.sh
rules:
- if: $CI_COMMIT_BRANCH == "main" || $CI_PIPELINE_SOURCE == "merge_request_event"
除了驗證之外
上面的腳本可以扮演專案的「守門員」角色，確保任何未經驗證的3PP無法進入主分支，但是還可以更進階的運用 oss-rebuild CLI 工具，可以在驗證通過後，針對每一個套件，執行：
oss-rebuild get pypi <package-name> <version> --output=bundle > attestation.json
這個指令會匯出一個包含完整加密簽章和證明（Attestation）的 JSON 檔案，可以將這個 attestation.json 的內容，注入到你的 CycloneDX 或 SPDX 格式的 SBOM 文件中對應的套件條目下，或者直接將這些證明文件與 SBOM 一起打包存檔。
當需要稽核時，你交出的就不只是一份清單，而是一份附帶了數百份「檢驗結果」的智慧醫療產品檢驗報告。
Top comments (0)