三月你產了一份 SBOM，裡面有某個加密函式庫的 3.0.x 版。

四月，那個函式庫公布了一個弱點。

那份 SBOM 一個字都沒有變，但它的意義變了。

這就是整件事的關鍵：SBOM 的內容是靜態的，它代表的風險是動態的。所以真正要建的能力不是「產出 SBOM」，是每當外面的世界變了，能重新問一次。

食品業有一樣的處境。某個添加物被主管機關重新評估、限量調整，架上產品的成分一個字都沒改，但它的合規狀態變了。所以業者要有人盯公告，不能只在上架那天檢查一次。

兩種「活起來」，不要搞混

這是今天最重要的區分。

多數團隊只做了左邊那一欄，因為它裝起來比較快，而且看得到成效。

但 Annex I Part II 的義務是跟著支援期間走的，不是跟著 CI 走的。左邊那欄再完整，也回答不了「你三年前賣出去那批機器，現在有沒有問題」。

建置時比對的最小可行版本

先講快的那一半，因為它是持續比對的前置條件：沒有穩定產出的 SBOM，就沒有東西可以持續比對。

最小的示範就兩行。這是工具的官方用法，不是任何人的正式管線：

三件事要注意。

**SBOM 與掃描結果都要存成建置產物，而且跟版本綁在一起。**Day 20 那句話在這裡兌現：SBOM 的版本號其實是產品的版本號。存在某個人的電腦上，等於沒存。

**SARIF 的用途是給工具讀，不是給人看。**選它的理由是各種平台都吃這個格式，之後要換工具或接儀表板不用重做。

**退出碼要能控制。**預設情況下這兩個指令跑完就結束，不會擋任何東西。什麼情況該讓建置失敗，是明天整天要談的題目，今天先把資料產出來。

持續比對：CRA 真正要的那一半

已經出貨的版本要能被重新問。這需要三樣東西：

一個存放所有已發布 SBOM 的地方，用「產品 × 版本」索引
一個會更新的弱點資料來源
一個排程，定期重跑比對

Dependency-Track 這類平台做的就是這件事。你把 SBOM 上傳，它保存下來，之後每當弱點資料更新，它自動重新比對並發出通知。

導入這種平台的時候，有四個設計問題要先想清楚。這幾題沒有標準答案，但答錯了之後很難改：

第三題最容易被省略，因為停止監控可以立刻讓儀表板變乾淨。但 Day 19 講過，Part II 在整個支援期間持續適用。你公開標示到 2032 年，那 2032 年之前它都在監控範圍裡。

儀表板會變成沒有人看的東西

這一段是誠實的提醒。

這類平台導入之後最常見的結局是：儀表板上永遠有幾千條紅的，於是三個月後沒有人打開它。

原因不難理解。儀表板預設顯示的是「目前所有問題」，而那個數字在任何有規模的產品線上都會是四位數，而且不會歸零。人對一個永遠不會變綠的畫面會失去反應。

你真正需要的是差異報告：

今天新增了哪幾條
今天哪幾條出現了修補版本
今天哪幾條進入了已知遭利用的目錄

**儀表板回答「現在有多糟」，日報回答「今天要做什麼」。**你需要的是後者，而且它可以短到五行。

這件事不需要等平台功能，多數平台都有 API，寫一個排程去拉差異就好。

誰維護這件事

回到 Day 09 那四件事：這屬於「盤點」，所以規格歸中樞。

但實際操作可以，也應該交出去：

中樞定義上傳規格與差異報告的判準。產品團隊在發版流程裡上傳 SBOM。平台自動比對。中樞每天看差異報告，決定哪幾條要進軌二。

中樞在這條鏈上唯一不能交出去的，是那個判準。誰來按 upload 不重要，「什麼情況要動」這件事必須是同一把尺。

明天 Day 23：擋與不擋，依賴掃描的門檻設計

有了資料之後，下一個問題是什麼情況該讓建置失敗。第一次導入一定全紅，所以關鍵設計是把「這次新引入的」跟「既有的技術債」分開。以及為什麼豁免流程要跟門檻一起設計。

順便問一句。你們最近一次發布的韌體：

如果今天公布一個新的函式庫弱點，多久會有人知道它受不受影響？

（a）自動通知，當天　（b）下次掃描時，可能幾週　（c）要有人手動去查　（d）沒有已發布版本的 SBOM，查不了

留個字母就好，不用打長篇。（b）跟（c）之間的差距，比多數人想的小，因為兩者都依賴有人記得。

這系列每天更新，覺得有用的話訂閱一下，我盡量不寫廢話。

參考：Regulation (EU) 2024/2847 Annex I Part II(1)(3)、第 13(8) 條支援期間；Syft、Grype、CycloneDX、SARIF、Dependency-Track 為其官方用法。四個設計問題與差異報告做法為個人整理，尚未經導入驗證，非法規明文。