2026 年每日通報的 CVE 數量比前一年多 131%。

SBOM

客戶要求 SBOM 時該如何回覆

客戶、潛在客戶或採購團隊向您索取 SBOM。這項要求可能出現在資安問卷、合約或一封只有一句話的電子郵件中,而且通常附有期限。以下說明他們想知道什麼、您該提供什麼,以及如何讓下一次的要求變成例行公事。

更新日期

您是向製造商供應元件或嵌入式軟體的供應商嗎?請參閱 供應商 SBOM 指南,其中涵蓋合約、VEX,以及為每個交付的軟體版本提供 SBOM。

客戶為何現在開始要求

  • Cyber Resilience Act(CRA)。在歐盟銷售產品的製造商需要為自己的產品準備 SBOM,並且必須審慎處理所引入的元件,因此這個問題會沿著供應鏈往下傳遞。
  • NIS2。基要實體與重要實體必須處理供應鏈安全。該指令並未明確提到 SBOM,但 SBOM 是買方了解供應商出貨內容的方式之一。請參閱 以 SBOM 作為 NIS2、ISO 27001 與 SOC 2 的佐證資料。
  • 產業規範。FDA 第 524B 條要求網路醫療器材提供 SBOM,其他產業也有各自的規範。
  • 客戶自己的漏洞處理工作。知道您產品內容的客戶,不必開立支援工單,就能判斷新的 CVE 是否影響他們。

提供任何資料前應先談妥的事項

問題 為何重要
哪項產品、哪個版本? 一份 SBOM 描述的是一個版本。請提供客戶實際使用的版本,而不是最新的建置。
哪種格式? 多數要求都接受 CycloneDX 或 SPDX。請詢問他們是否需要特定版本。
要涵蓋多深? 只有最上層的相依套件可能不夠。請預期對方會要求遞移相依套件。
只提供一次,還是每個版本都要提供? 合約可能要求每個版本都提供新的 SBOM,這就排除了任何以人工完成的做法。
依據哪些條件? SBOM 會顯示您的產品是如何組成的。請談妥保密條款與檔案的交付方式。

好的回覆應包含什麼

  • 依約定格式、針對客戶實際使用版本的 SBOM。
  • 每個元件的名稱、版本、供應商、授權與套件識別碼。
  • 相依關係,讓遞移相依套件可以追溯到引入它的元件。
  • 日期、產生它的工具,以及它來自哪一次建置。
  • 坦白說明 SBOM 未涵蓋的任何內容(請參閱 SBOM 完整性)。

檔案的實際樣貌請參閱 SBOM 範例。關於兩種格式,請參閱 CycloneDX 與 SPDX 的比較。客戶收到後可能會檢查哪些項目,請參閱 SBOM 品質檢查清單。

日後會讓您吃虧的錯誤

  • 提供最新的建置,而不是已出貨的版本。建置預設並不是可重現的,因此重新建置同一個 commit,並不保證會得到相同的 SBOM。只有產生該版本的那次建置所留下的 SBOM,才能顯示客戶實際收到的內容。
  • 為了應付這次要求而以人工拼湊。這只能滿足一次要求,下一位客戶、下一個版本時又得重做一遍。請參閱 SBOM 自動化。
  • 承諾超出您能持續做到的範圍。「我們每個版本都會提供一份」寫進合約很容易,但若沒有自動化,就很難做到。
  • 以為提供 SBOM 就結束了。接下來的問題會是「您是否受到這個 CVE 影響?」,而且會在下一個重大漏洞出現時隨之而來。

如何為下一次要求做好準備

當 SBOM 早已存在時,回應要求就會變得容易。在建置版本的管線中為每個版本產生 SBOM,與該版本一起保存,並持續監控其中是否出現新漏洞。如此一來,回應要求只需要下載檔案並附上一段簡短說明,後續問題也能以同一份記錄回答。

CRACI 如何處理

CRACI 會為每個在其執行器上執行的 GitHub Actions 建置記錄 SBOM,因此有人索取時,每個版本都已經有一份。

  • 以 CycloneDX 或 SPDX 匯出,包含遞移相依套件,以及在元件中找到的漏洞。
  • 來自建置本身的佐證資料。SBOM 中的每個元件都確實存在於建置中,以 lockfile 為基礎的工具所遺漏的隱藏相依套件也會被記錄。
  • 每個作業都有完整性狀態,讓您在提供之前就知道自己提供的是什麼。
  • 建置歷程。在您的保留期限內,您可以查看過去的建置與其 SBOM,以及哪些建置含有有漏洞的相依套件。
  • 回答後續問題。CRACI 會持續重新評估受監控的 SBOM、支援 VEX,並在資產清冊檢視中顯示哪些產品執行哪些版本。

客戶要求 SBOM:常見問題

我們有義務向客戶提供 SBOM 嗎?

取決於您的市場與合約。Cyber Resilience Act 將 SBOM 列為技術文件的一部分,應市場監督機關要求時須提交,但並不要求公開發布。客戶取得 SBOM 的權利通常來自合約,因此請確認您已同意的內容。

我們應該提供哪種 SBOM 格式?

CycloneDX 或 SPDX,依客戶要求而定。如果客戶沒有偏好,兩者皆可。請詢問他們的工具是否需要特定版本。

需要包含遞移相依套件嗎?

Cyber Resilience Act 至少要求涵蓋最上層的相依套件,但許多買方期望取得完整的相依樹,而漏洞也經常出現在遞移相依套件中。提供完整的 SBOM 是較穩妥的做法。

SBOM 應該在簽訂 NDA 後才提供給客戶嗎?

這由您與客戶決定。SBOM 會顯示您的產品是由什麼組成的,因此許多廠商會依現有合約或 NDA 分享,而不是公開發布。

應該多久提供一次更新後的 SBOM?

依雙方約定的頻率。相依套件會隨每個版本改變,因此每個版本提供一份新的 SBOM 是誠實的預設做法,而只有在 SBOM 由建置產生時,這才切實可行。

如果客戶詢問的是較舊的版本呢?

您需要產生該版本的那次建置所留下的 SBOM。CRACI 會在您的保留期限內保存建置歷程,預設為 180 天,Enterprise 方案可自訂保留期限,因此需要保存更久的資料請先匯出。

我們從未製作過 SBOM,該從哪裡開始?

從客戶實際使用的版本開始,並選擇能依據您真實建置運作的工具。如果您使用 GitHub Actions,將建置移到 CRACI 執行器上,從第一次執行起就能取得記錄下來的 SBOM。

在下一次要求之前備妥 SBOM

預約示範,看看 CRACI 從真實建置記錄的 SBOM,可直接匯出為 CycloneDX 或 SPDX。

預約示範