SBOM 完全指南：格式、法規與企業落地路徑

SBOM（Software Bill of Materials，軟件物料清單）是軟件的「配料表」：列出一個軟件產品由哪些組件構成、各是什麼版本、來自哪裏、以什麼許可證分發。Log4Shell（CVE-2021-44228）爆發那一夜，有 SBOM 的企業用查詢回答「我們哪裏用了 log4j」，沒有的企業用兩週的人肉排查回答——這就是它的價值。

三種標準格式怎麼選

• SPDX：Linux 基金會主導，已成為國際標準 ISO/IEC 5962，許可證與合規表達能力最強，是開源合規場景的事實標準。
• CycloneDX：OWASP 出品，2024 年成為 Ecma 國際標準，面向安全場景設計，原生支持漏洞可利用性交換（VEX），在 DevSecOps 工具鏈中集成最廣。
• SWID：ISO/IEC 19770-2 軟件標識標籤，主要用於資產管理，新建體系一般不作首選。

實務建議：工具必須同時支持 SPDX 與 CycloneDX 導出——不同甲方、不同法規會點名不同格式，格式之爭不值得站隊。內容上應至少覆蓋 NTIA 提出的七個最小元素：供應商、組件名、版本、唯一標識、依賴關係、SBOM 作者與時間戳。

全球法規都在要 SBOM

美國：2021 年第 14028 號行政令啓動聯邦軟件採購的 SBOM 要求；FDA 自 2023 年起對含網絡功能的醫療器械實施「無 SBOM 不受理」的上市前審查。歐盟：CRA 把機器可讀 SBOM 寫入法定義務，2027 年底全面適用（詳見 CRA 合規時間線）。中國：人民銀行等五部門 2021 年《關於規範金融業開源技術應用與發展的意見》要求金融機構掌握開源使用狀況，信通院牽頭的 SBOM 標準體系與試點持續推進，汽車、醫療等行業的甲方已普遍把 SBOM 寫進交付驗收條款。

四步落地路徑

第一步：生成。用 SCA 工具對代碼庫與製品自動生成 SBOM。關鍵決策是檢測深度——清單級還是片段級，直接決定 SBOM 是「聲明的成分」還是「真實的成分」，差異分析見這篇選型指南；無源碼的外購件與固件用二進制成分分析補齊。

第二步：豐富。裸清單價值有限，把組件關聯到漏洞情報（CVE/CNVD/CNNVD/EUVD）與許可證義務，並用 VEX 標註「存在但不可利用」的項，才能從文檔變成決策依據。

第三步：交付。按客户與法規要求的格式導出、簽名、隨版本歸檔，讓每個發佈版本都有對應的 SBOM 快照。

第四步：運營。SBOM 是活文檔：新漏洞披露時反查受影響產品與版本，應答「我們受不受 XX 漏洞影響」應該是分鐘級查詢而非專項行動。這一步最考驗工具的持續監測能力，也是 CleanSource SCA 這類平台與一次性生成腳本的分界線。

怎麼判斷一份 SBOM 的質量

不同工具生成的 SBOM，紙面格式一樣，含金量可以差一個數量級。三個可量化的指標：

• 覆蓋深度：只有直接依賴，還是解析到傳遞依賴？對靜態鏈接、vendored 代碼、複製片段是否可見？清單級工具生成的 SBOM 只反映「聲明的成分」，與真實成分的偏差可能高達數成。
• 準確率：組件名與版本的識別錯誤會向下遊放大——版本錯一位，關聯的漏洞列表就整個失真。
• 新鮮度：SBOM 是否隨每次構建自動再生成？滯後於版本的清單，在應急響應時反而製造錯誤的安全感。

另一個常被忽略的配套是 VEX（漏洞可利用性交換）。SBOM 回答「有哪些組件」，VEX 回答「其中的漏洞在我的產品裏是否真的可被利用」，狀態包括 not_affected、affected、fixed、under_investigation。給客户交付 SBOM 而不附 VEX，等於把數千條 CVE 的研判工作原樣轉嫁給對方——成熟的交付是兩者同行。

常見誤區最後提醒三條：SBOM 不是越細越好，先把頂層與直接依賴做準；不要手工維護，人肉清單的保鮮期以周計；不要等法規落到頭上才啓動——體系建設需要的時間，比合規截止日給你的時間長。