跨產品發佈版本維護 SBOM

Sytance · 更新於 2026年9月15日

每份 SBOM 都需要明確對應的軟件版本。軟件更新可能改變組件組成，清單修訂則可能只是更正信息，軟件本身並未變化。分別記錄軟件版本和清單修訂號，才能確認客户收到的軟件及其準確的組件清單。

清單對應的軟件

在構建或發佈流程中選擇可重複執行的階段生成 SBOM，並保留源碼版本、已解析的依賴、構建配置和最終制品標識，以便重新生成或調查該清單。

CycloneDX 指南區分從源碼、構建過程和運行環境生成的清單。不同階段包含的軟件可能不同。標明生成階段後，接收方才能知道清單描述的是聲明的依賴、構建結果，還是實際部署的軟件。

對於網關，需要結合應用構建、基礎鏡像和外購固件組件的信息，保留與供應商 SBOM 的關聯。網關使用的雲端服務可能需要獨立清單，並按照自己的發佈節奏維護。

版本比較需要説明哪些組件新增、刪除、升級或重新構建，以及依賴路徑發生了什麼變化。例如，刪除一個庫再加入另一個庫，組件總數沒有變化，但軟件組成已經不同。

比較時可以統一標識格式，但需要保留原始版本號和標識符。如果工具新識別出此前未知的軟件包，還需要確認這是識別結果改善，還是軟件確實發生了變化。

按照聲明的格式版本校驗文件，再檢查信息含義。確認每個引用均可解析，根產品對應本次發佈，接收方能夠訪問引用的組件 SBOM。

對候選版本執行漏洞和許可證檢查，並將結果關聯到該版本。新增的高優先級問題需要有處理決定；此前允許暫不處置的問題，如果組件版本或運行條件發生變化，也需要重新評估。

將批准發佈的軟件、SBOM、構建記錄和評審結果一起歸檔。採用簽名時，需要驗證簽名，並確認簽名者是預期發佈者。

2026 年聯合 SBOM 指導建議為每次軟件版本或更新提供對應 SBOM，發現錯誤或獲得新的組件細節時發佈清單修訂，並區分未知信息與有意不提供的信息。

例如，供應商更正組件生產方，但固件文件內容沒有變化。此時應保留原有固件標識，發佈新的 SBOM 修訂，説明更正內容，並保留此前文檔。接收方才能區分資料更正與軟件更新。

通過約定渠道提供更新。固定入口可以指向當前修訂，歷史文件保留原始內容。同時確認接收方能夠判斷新修訂替代了哪一份舊清單。

收到新公告後，在各受支持版本中查找相關組件，再結合實際構建和使用方式判斷影響。組件組成保持不變時，新的漏洞信息仍可能使影響判斷髮生變化，因此清單和漏洞評估需要分別保留修訂記錄。

如果網關 1.0 包含受影響庫，而 1.1 已刪除該庫，新版本發佈不會改變已經安裝的 1.0 設備。團隊仍需確定這些舊版本設備的處置方案，並準確記錄公告或 VEX 聲明涵蓋的版本。

明確誰負責跟進供應商更新、分析影響、批准處置方案，以及通知相關人員。根據產品支持義務及新信息的嚴重程度安排複核時點，不能只等待下一次計劃發佈。

支持結束時，保留產品版本與 SBOM 的對應關係，以及與歷史交付有關的處置決定及其依據。按需限制敏感記錄訪問，同時保證獲授權接收方能夠取得已約定的信息。

維護交接時，接手人員需要能夠按產品版本找到清單、定位組件並查看最新影響分析。用一個仍在支持期內的版本核對這些資料，有助於發現缺失記錄或訪問權限問題。