比較
CRACI vs Cybeats SBOM Studio
SBOM Studio 是產品資安團隊保存、擴充與分享 SBOM 的地方。CRACI 則在建置期間記錄 SBOM 並標示完整度狀態,再從那裡持續監控漏洞。
更新日期
簡短回答
Cybeats SBOM Studio 自稱「the SBOM system of record」(SBOM 記錄系統)。它保存來自您產品與供應商的 SBOM,以漏洞與授權情資加以擴充,持續監控,並與客戶及主管機關分享。CRACI 則是一個 GitHub Actions 執行器,記錄每個作業實際取得的相依套件,並依據這份紀錄產生 SBOM,同時標示完整度狀態。
記錄系統的準確度,取決於放進去的內容。SBOM Studio 管理的是其他工具產生的 SBOM。CRACI 則從建置產生 SBOM 並加以監控,因此 CI、SBOM 與漏洞追蹤都來自同一個產品。
一覽
| 功能 | CRACI | Cybeats SBOM Studio |
|---|---|---|
| 產生 SBOM | 在每個 GitHub Actions 作業期間記錄 | 第三方產生工具廠商的 Marketplace |
| SBOM 品質或完整度的訊號 | 標示每個作業與快取的完整度狀態 | Quality Score 在匯入前驗證檔案 |
| 執行器上的對外連線政策 | 預設拒絕或允許,失效即封鎖 | 不執行您的建置 |
| 持續漏洞監控 | 重新評估受監控的 SBOM | 持續比對每個元件 |
| CRA 佐證資料與報告 | CycloneDX 或 SPDX 格式的 SBOM,可透過 API 取得記錄,並備妥 CRA 通報內容;不提供報告匯出 | 可直接提交的 SBOM 與漏洞佐證資料 |
| 漏洞分級研判與 VEX | 分級研判、指派給團隊,以及 VEX | VEX 文件與依政策發出的警示 |
| 匯入供應商 SBOM | 可加入廠商 SBOM | SPDX 2.2 至 3.0.1、CycloneDX 1.2 至 1.7 |
| 與客戶分享 SBOM | 匯出 CycloneDX 與 SPDX 檔案 | 受控分享,包含 Transparency Exchange API |
| 授權分析 | 匯出宣告的授權;授權政策可封鎖建置 | OSS 與 COTS 授權分析 |
- 支援
- 部分支援
- 不支援
Cybeats 的優勢
- 集中治理所有 SBOM 的單一位置。SBOM Studio 是為 ICS 與 OT、醫療器材、電信、汽車及金融服務領域的產品資安團隊打造。它為這些團隊提供「one governed source of truth for every SBOM across your products and suppliers」(涵蓋所有產品與供應商、受治理的單一可信來源)。
- 廣泛的格式支援。匯入與匯出皆支援 SPDX 2.2 至 3.0.1,以及 CycloneDX 1.2 至 1.7。平台也能處理 VEX、AIBOM、CBOM 與 HBOM。
- 在入口把關品質。SBOM Quality Score 會在匯入前驗證檔案,檢查其格式是否符合標準,並記錄 SBOM 不合格的原因。
- 擴充與監控。每個元件都會持續與漏洞情資比對,並提供依政策發出的警示、用來說明哪些漏洞影響您產品的 VEX,以及 OSS 與 COTS 授權分析。
- 分享。與客戶進行受控的 SBOM 與 VEX 交換,包括透過 Transparency Exchange API。另一項產品 SBOM Consumer 則會驗證並監控您收到的廠商 SBOM。
在供應商 SBOM 收件、授權分析與託管分享等方面,SBOM Studio 目前都比 CRACI 做得更多。如果您團隊的工作是跨多項產品與供應商推動 SBOM 計畫,它正是為此而打造。
CRACI 的不同之處
它從建置產生 SBOM
SBOM Studio 匯入 SBOM。至於產生,Cybeats 則指向其 Marketplace,那裡匯集了二進位組成分析與 SBOM 產生工具的廠商。因此,記錄系統中的元件清單仍然來自某種掃描工具。
CRACI 執行作業。您將 runs-on 改為 craci,具套件感知能力的 Proxy 就會在建置期間記錄連往套件來源的流量:npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk 與 Git 來源,以及下載預設組合。相依套件佐證資料會隨 CI 快取一併保存,因此從快取還原的套件仍在紀錄之中。SBOM 包含建置實際使用的所有遞移相依套件。
格式正確不等於完整
品質分數可以確認 SBOM 遵循標準並具備預期欄位,卻無法告訴您產生工具從未看到的東西。各產生工具的結果在結構上就有差異,因為每個工具讀取的檔案組合不同,解析方式也不同,而一份格式正確的文件,完全無法說明它遺漏的相依套件是否曾經出現在工具面前。NTIA 的供應商欄位就是一個好例子:它只驗證有或無,而大多數產生工具根本沒有這項資訊的來源。CRACI 無法用這種方式評分,因為它記錄的是建置,無法掃描目錄。
CRACI 依據記錄本身,針對每個作業與每個快取標示完整度:Complete、Complete with connections、Incomplete、Unavailable 或 Not recorded。紀錄中的缺口是已知的,而非猜測。
控管與來源證明
由於作業由 CRACI 執行,它會執行網路對外連線政策:預設拒絕或預設允許,內建 24 種軟體來源預設組合與具類型的自訂來源,在作業開始前驗證,並且失效即封鎖(fail closed)。API 會回傳 SBOM、網路追蹤與來源證明(provenance)。
監控
CRACI 持續重新評估受監控的 SBOM,並彙整跨建置與跨儲存庫的漏洞。
掌握哪些版本部署在哪裡的資產清冊
CRACI 的資產清冊檢視會在全球範圍內精確顯示哪些軟體版本部署到哪些產品。當新的漏洞出現時,您可以直接看到哪些產品執行受影響的版本,而不必從版本說明與試算表中拼湊答案。
以 CRACI 取代 SBOM Studio
對於使用 GitHub Actions 的軟體團隊,CRACI 涵蓋了 SBOM 記錄系統為其自有產品所要做的事:在每次建置中產生 SBOM,在新漏洞公布時持續重新評估受監控的 SBOM,彙整跨建置與跨儲存庫的檢測結果,並讓資安團隊進行分級研判,再將每一項指派給負責修正的團隊。您也可以加入廠商 SBOM,讓外購元件與您自己的建置一起受到監控。不需要另外執行產生工具,也不需要維護匯入步驟。
請清楚了解您會放棄什麼。SBOM Studio 處理 OSS 與 COTS 授權分析、AIBOM、CBOM 與 HBOM,在匯入時為 SBOM 品質評分,並透過 Transparency Exchange API 與客戶分享 SBOM。CRACI 會依據其記錄的宣告授權執行授權政策,但目前不具備其餘功能。如果您的工作是跨多項產品、供應商與客戶推動 SBOM 計畫,SBOM Studio 正是為此而打造。
關於 Cyber Resilience Act
Cybeats 直接處理 Cyber Resilience Act(CRA)。它稱這項法規為「the main driver of SBOM adoption today」(當前推動 SBOM 採用的主要動力),並表示 SBOM Studio「produces compliant, up to date SBOMs」(產出合規且最新的 SBOM),協助製造商在產品生命週期中維持軟體透明度。其法規指南列出了 24 小時、72 小時與 14 天的通報時程。
CRA 的通報義務自 2026 年 9 月 11 日起透過 CRA Single Reporting Platform 適用,主要條款則自 2027 年 12 月 11 日起適用。24 小時早期預警取決於能否迅速知道哪些版本發布包含受影響的元件,以及能否信任提供這項資訊的資產清冊。CRACI 的 API 會回傳 SBOM、網路追蹤與來源證明,SBOM 也可匯出為 CycloneDX 或 SPDX 並包含漏洞。
CRACI 自動化了企業在更廣泛的 CRA 法規遵循流程中所需的相當大一部分軟體供應鏈可視性與佐證資料。兩項產品都無法單獨讓製造商達成合規。請參閱 CRA 的要求、使用 CRACI 達成 CRA 法規遵循與工業物聯網。
正在評估兩個以上的工具嗎?Cybeats 替代方案並列比較了九種選擇。
CRACI 目前支援 GitHub Actions。GitLab CI、Jenkins 與其他 CI 系統已列入產品藍圖。進一步了解 建置時 SBOM 產生與 為資安團隊打造的 CRACI。