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

比較

SBOM 管理

SBOM 管理是一項持續性的工作:依產品與版本儲存 SBOM、監控是否出現新漏洞,並將 SBOM 提供給提出要求的人。產生 SBOM 只是管線中的一個步驟,讓數百份 SBOM 持續保有用處,才是真正的工作。

更新日期

Two routes to a monitored SBOM After the build: files such as source, a lockfile or an image are scanned by a generator such as Syft, Trivy or cdxgen, and the SBOM file goes to a manager such as Anchore, FOSSA, Cybeats, Manifest, Lineaje or Dependency-Track, which stores and monitors it. During the build: CRACI records what the build job fetched and produces an SBOM with a completeness state, which it monitors for new vulnerabilities. After the build generate, then manage Files source, lockfile or image Generator Syft, Trivy, cdxgen SBOM file what the scan could see Manager Anchore, FOSSA, Cybeats, Manifest, Lineaje, D-Track During the build record, then monitor build job on CRACI Recorded every package the job fetched SBOM with a completeness state Monitored for new vulnerabilities

每篇比較都會說明另一款產品的強項、CRACI 的不同之處,以及何時適合兩者並用。所有類別請見所有比較。

SBOM 管理包含哪些工作

  1. 收集。從您自己的建置與供應商處收集 SBOM,不論其格式為何。
  2. 正規化。將 CycloneDX 與 SPDX 檔案,以及不同工具對元件的不同命名方式, 整合成一致的檢視。
  3. 檢查品質。找出缺漏的內容,例如授權、識別碼或相依關係。 請參閱品質不佳的 SBOM 長什麼樣子。
  4. 監控。持續將已儲存的 SBOM 與新的漏洞資料比對,讓一則資安公告能轉化為 受影響版本的清單。
  5. 分級研判。判斷哪些項目重要、交由負責的團隊處理,並記錄結果,例如寫入 VEX 聲明。
  6. 分享。將客戶、稽核人員與主管機關所詢問版本的 SBOM 提供給他們。

這些工作背後的做法,請參閱 SBOM 最佳實務。如果您剛接觸這個主題, 請從什麼是 SBOM 開始。

為什麼試算表與資料夾不再管用

一個產品搭配一份 SBOM,放在一個儲存庫裡就夠了。但多個產品、各自有受支援的版本與供應商,就行不通了。 真正重要的問題橫跨所有產品:哪些版本包含這個套件、哪些客戶在執行這些版本,以及從什麼時候開始? 要從一整個資料夾的 JSON 檔案中找出答案需要好幾天,而那時您往往只有幾個小時。

管理工具、產生工具與建置時記錄

  • SBOM 管理工具,例如 Anchore、FOSSA、Cybeats、Manifest、Lineaje 與 Dependency-Track,負責儲存、 分析與監控 SBOM。它們管理的是交給它們的 SBOM,因此紀錄的完整程度取決於背後的產生工具。
  • SBOM 產生工具,例如 Syft、Trivy 與 cdxgen,會在事後掃描目錄、映像檔或 lockfile。 它們回報的內容取決於眼前的檔案。兩類工具的並列比較,請參閱 最佳 SBOM 工具。
  • 建置時記錄會在建置執行期間擷取相依套件。這是 CRACI 採用的做法。

若要為每個團隊與管線設定一致的產生政策,請參閱跨工程團隊的 SBOM 產生。

選擇 SBOM 管理工具的評估重點

  • 可匯入 CycloneDX 與 SPDX,並在需要時匯入供應商提供的 SBOM
  • 依版本追蹤 SBOM,而不只是依儲存庫
  • 在新漏洞公開時重新檢查已儲存的 SBOM
  • 顯示相依關係,讓檢測結果能指向需要升級的套件
  • 支援分級研判與 VEX,讓決策得以保留
  • 在客戶提出要求時,提供分享 SBOM 的方式

CRACI 的定位

CRACI 會在您的 GitHub Actions 建置執行時記錄 SBOM。執行器上具備套件感知能力的代理伺服器會記錄作業擷取的每個 套件,包括從 CI 快取還原的套件,因此 SBOM 描述的是產生該建置產物的建置本身,而不是在附近某處執行的掃描。 每個作業的 SBOM 都帶有完整性狀態,以 CycloneDX 與 SPDX 匯出的檔案包含遞移相依套件,以及每個元件宣告的授權。 每當有新漏洞出現,CRACI 都會持續重新評估受監控的 SBOM,其資產清冊檢視則能精確顯示全球各地哪些軟體版本部署在 哪些產品上。

Cyber Resilience Act(CRA)對 SBOM 的要求,請參閱 CRA 法規遵循:SBOM 要求與工具。進一步了解 建置時 SBOM 產生。若要在管理供應商寄來的 SBOM 之前先加以檢查, 請參閱 SBOM 品質檢查清單。

CRACI 與各工具比較

並列比較

在同一頁比較多款工具,適合您在選擇類別而非單一產品時參考。

SBOM 管理:常見問題

什麼是 SBOM 管理?

這是一項持續性的工作:跨產品與供應商收集 SBOM、保持其一致性、監控是否出現新漏洞,並分享給需要的人。

SBOM 產生工具與 SBOM 管理工具有什麼不同?

產生工具負責產生 SBOM 檔案。管理工具則儲存來自多個來源的 SBOM,並持續檢查。管理工具的完整程度,取決於它所收到的 SBOM。

您需要 SBOM 管理工具嗎?

如果只有一個產品、版本不多,產生工具加上妥善的儲存可能就足夠。若有多個產品、受支援的版本或供應商 SBOM,問題會橫跨太多檔案,無法以人工回答。

Dependency-Track 是 SBOM 管理工具嗎?

是的。它是 OWASP 推出的開源平台,可匯入 SBOM 並監控其中的已知漏洞。您需要自行執行它並提供 SBOM。

其他類別

在您自己的管線上體驗 CRACI

預約示範,我們將與您一起檢視您的建置、SBOM 與法規遵循佐證資料。

預約示範