SBOM 不止是合規清單：從「我用了什麼」到「我能承受什麼」
監管和客户開始要求交付 SBOM（軟件物料清單），於是很多團隊把它當成一份「交差文檔」——生成、歸檔、應付審計。這浪費了 SBOM 真正的價值。一份好的 SBOM 不是終點，而是治理的起點。
一份清單，三個層次
同樣是 SBOM，深度差別很大。
- 有什麼：列出組件與版本。這是最低要求，也是大多數工具止步的地方。
- 風險如何：把每個組件關聯到 CVE / CNVD / CNNVD / EUVD 等多源漏洞庫，標註許可證。
- 怎麼辦：結合可達性與可利用性，告訴你先修哪個——而不是甩給你一份 500 條的待辦。
片段級，而不是包級
聲明式的依賴解析會漏掉兩類東西：被複制粘貼進項目的開源片段，以及被改名、裁剪、篡改的組件。片段級指紋比對直接對代碼本身生成指紋，比對海量組件庫，因此能識別「換了馬甲」的開源代碼，也能發現許可證被悄悄改動的情況。
SBOM 的價值不在於「完整列出」，而在於「準確關聯」。列得再全，如果關聯不到風險，也只是一張紙。
讓清單驅動行動
把 SBOM 接進 CI/CD，它就從靜態文檔變成動態防線：新引入的高危組件即時攔截、許可證衝突自動告警、漏洞情報變化實時迴流。合規只是副產品，真正的收益是可治理。
這是 CleanSource SCA 的設計哲學：不止生成清單，更讓清單變成可執行的治理動作。