SBOM 字段實操指南：NTIA 七要素之外還該填什麼

七要素是門檻，不是天花板

每次討論 SBOM 該怎麼填，對話往往止步於 NTIA 的七要素清單——供應商、組件名稱、版本、唯一標識、依賴關係、SBOM 作者、時間戳。檢查完這七項，有人就認為工作完成了。

這個判斷在 2021 年《行政令 EO 14028》剛落地時或許勉強成立。但當 FDA 於 2023 年 3 月起正式要求醫療器械上市申請必須附帶完整 SBOM，EU CRA 將在 2027 年 12 月全面適用並開出最高 1500 萬歐元或全球營收 2.5% 的罰款，汽車領域 UN R155 / ISO 21434 與國內 GB 44495 強制國標相繼生效，七要素的"最低可行"定位就越來越尷尬了。

問題不在於七要素是錯的，而在於它們在實操中極容易填錯，且填完之後還有大量決定 SBOM 實際價值的字段被忽視。本文按照從"必填"到"強烈建議"的順序逐一拆解，重點標出高頻陷阱，供負責 SBOM 生產或消費的工程師、合規負責人蔘考。

---

逐字段拆解：七要素的常見填錯方式

1. 供應商名稱（Supplier Name）——歧義最多的字段

這是實操中最容易產生歧義的字段。同一個組件，上游可能有多個"供應商"身份：原始作者、打包維護者、鏡像分發者、內部二次封裝者。

典型陷阱：把包註冊表名稱（如 npmjs.com）填入供應商字段，或把 Git 用户名與法人主體混用。對於企業內部 fork 或私有鏡像，供應商字段應當明確標註內部標識，而非照抄上游名稱——否則在漏洞響應時根本無法快速判斷"這個組件到底誰在維護"。

SPDX（ISO/IEC 5962）規範中，PackageSupplier 支持 Organization: 和 Person: 前綴，CycloneDX（已成為 Ecma 標準）則在 supplier 與 author 之間做了更細緻的區分。選型時應與下游消費方對齊，避免解析歧義。

2. 組件版本（Version）——"無版本"不等於可以留空

對於從源碼構建、未打 tag 的內部組件，版本字段留空會讓漏洞匹配徹底失效。正確做法是填入 Git commit SHA 的縮寫（至少 12 位），並在附加字段中説明版本來源類型。

3. 唯一標識（Unique Identifier）與哈希——兩者不可互相替代

唯一標識（PURL 或 CPE）解決的是"這是哪個組件"的問題，哈希解決的是"這是組件的哪個構建產物"的問題。兩者缺一不可，卻經常被混淆或只填其一。

PURL（pkg: 格式）已成為跨生態互操作的事實標準，覆蓋 npm、Maven、PyPI、Cargo 等主流包管理器。CPE 在政府採購和 NVD 漏洞匹配場景仍有不可替代的地位。

哈希算法的選型同樣有講究：MD5 和 SHA-1 在完整性校驗場景已不夠用，SHA-256 是當前最低要求，對於高安全等級場景應使用 SHA-512。哈希對象應明確是壓縮包還是解壓後的文件樹，否則兩端校驗必然對不上。片段級 SCA 與清單級 SCA 的差異在這裏尤為關鍵——清單隻能給出聲明版本，哈希才能證明實際使用的代碼與聲明一致。

4. 依賴關係（Dependency Relationships）——深度不夠等於沒填

這是七要素中信息密度最低、最容易被敷衍的字段。只聲明直接依賴，不展開傳遞依賴，SBOM 的漏洞覆蓋率會大幅縮水。Log4Shell（CVE-2021-44228，2021 年 12 月）的大面積擴散，相當程度上正是因為多數組織不知道自己的應用棧裏有多少層傳遞依賴帶入了 log4j-core。

實操建議：

• 傳遞依賴至少展開到三層，對於安全敏感系統建議全量展開
• 區分 DYNAMIC_LINK、STATIC_LINK、CONTAINS 等關係類型，而非統一用 DEPENDS_ON
• 開發依賴（devDependency）與運行時依賴必須分別標註，買方在做風險評估時關注點截然不同

5. SBOM 作者與時間戳——生命週期管理的起點

時間戳不只是"SBOM 是什麼時候生成的"，它決定了這份 SBOM 在什麼條件下應該被視為失效。建議同時填寫 created（初次生成）和 documentNamespace 中的版本標識，配合 CI/CD 流水線在每次構建時自動刷新，而不是作為一次性文檔手動維護。

---

七要素之外：哪些字段真正影響可用性

七要素打完地基之後，以下字段決定 SBOM 能否被機器消費、能否支撐漏洞響應、能否滿足審計要求。

許可證字段（License）

SPDX License Expression 支持複合表達式（如 Apache-2.0 AND MIT），應當同時填寫 DeclaredLicense（包元數據中聲明的）和 ConcludedLicense（經掃描工具實際確認的）。兩者不一致時，需要人工審核而非自動覆蓋。許可證衝突檢測的實操方法值得單獨深入。

生命週期狀態（Lifecycle / EOL）

Python 2 於 2020 年正式 EOL，AngularJS 於 2022 年 EOL，Log4j 1.x 早在 2015 年即已停止維護——但這些組件至今仍大量出現在生產環境的 SBOM 中，且沒有任何字段標註其 EOL 狀態。CycloneDX 的 lifecyclePhase 字段和自定義屬性均可承載這一信息，建議列為必填項。停止維護的開源組件風險值得專門評估。

VEX 關聯字段——漏洞可利用性的上下文

VEX（Vulnerability Exploitability eXchange）不屬於 SBOM 本體，但與 SBOM 高度耦合。一份沒有 VEX 的 SBOM 遇到漏洞公告時，消費方只能知道"組件存在該 CVE"，無法判斷"在當前部署場景下是否真正可利用"。

VEX 的四個核心狀態——not_affected、affected、fixed、under_investigation——配合影響陳述（impact statement）和操作陳述（action statement），才能構成完整的漏洞響應鏈條。EU CRA 的報告義務（2026 年 9 月 11 日起生效）明確要求製造商提供可利用性評估，VEX 是目前最成熟的機器可讀載體。

構建信息與 SLSA 出處（Provenance）

組件是如何構建的、由哪條流水線產出、構建環境是否可復現——這些信息在供應鏈投毒場景（如 2024 年 3 月曝光的 xz 後門 CVE-2024-3094）中具有決定性的溯源價值。CycloneDX 的 externalReferences 和 buildMetaData 字段，配合 SLSA 出處文檔，是目前最可操作的填寫路徑。

---

買方與賣方：關注重點不對稱

SBOM 的生產者（軟件賣方）和消費者（採購方/運營方）對字段的優先級判斷往往存在明顯不對稱，這種不對稱如果不在合同階段對齊，會在漏洞響應時產生嚴重摩擦。

賣方通常更關注：

• 字段是否滿足合規提交要求（FDA、CRA、GB 44495）
• 生成工具鏈的覆蓋率與自動化程度
• 內部敏感信息（自研組件名、內部拓撲）是否需要脱敏

買方通常更關注：

• 哈希是否可驗證（防止 SBOM 與實際交付物不一致）
• 傳遞依賴是否完整展開
• VEX 是否隨漏洞公告持續更新，而非一次性附件
• EOL 組件是否有明確標註和替換計劃

建議在採購合同或技術附件中明確約定：SBOM 格式版本、更新頻率、VEX 響應時限、以及爭議字段（尤其是供應商名稱和版本）的填寫規範。SBOM 從合規要求到能力建設的路徑提供了更完整的治理框架參考。

對於需要處理二進制交付物的買方，僅憑 SBOM 聲明內容無法核驗實際成分，CleanBinary 的二進制成分分析能力可以從產物側反向驗證 SBOM 的準確性。對於希望在研發階段即建立 SBOM 生產規範的團隊，CleanSource SCA 支持覆蓋 600 餘種包管理生態、基於 3.2 億組件指紋的全量依賴解析，可直接輸出 SPDX 和 CycloneDX 格式；輕量化起步可選擇 CleanSource SCA CE 社區版。PureStream 則在合規治理層面提供 AI 驅動的策略編排，適合需要跨團隊統一 SBOM 質量基線的場景。

---

結語：字段質量決定 SBOM 的實際價值

SBOM 的價值不取決於它有多少字段，而取決於每個字段是否準確、是否機器可讀、是否在組件生命週期內持續維護。一份七要素齊全但哈希不可驗證、依賴關係只有一層、供應商名稱前後不一致的 SBOM，在漏洞響應時能提供的幫助極其有限。

從 xz 後門到 Shai-Hulud npm 蠕蟲（2025 年 9 月），供應鏈攻擊的手法在持續演化，而防禦側的信息質量必須至少與攻擊面的複雜度同步提升。把 SBOM 從一次性合規文檔變成持續更新的軟件物料賬本，字段規範是起點，工具鏈自動化是保障，買賣雙方的合同約定是紐帶。

關於 SBOM 完整體系的建立，可參考《SBOM 完全指南》；醫療器械行業的具體合規路徑，可參考醫療器械 SBOM 合規實踐。

---