CRACI vs Kusari

簡短的答案

Kusari 是一個軟體供應鏈安全平台，由共同打造 GUAC（供應鏈中繼資料的開源關係圖）的團隊開發。它會從您的原始碼、SBOM、VEX 文件與現有掃描工具的結果，建立持續更新的知識圖譜，排列可被利用的項目，審查 pull request 並開啟修正。CRACI 是 GitHub Actions 執行器。它會在建置執行期間記錄建置引入的內容，控制建置可以連線的位置，並持續監控已出貨的內容。任何關係圖反映的都是它收到的 SBOM；CRACI 則從建置本身產生 SBOM。兩者競爭的是同一筆供應鏈預算。對於您自行建置的軟體，CRACI 以單一產品涵蓋 CI、SBOM 與漏洞追蹤。

一覽

精確說明 Kusari 與 GUAC

GUAC（Graph for Understanding Artifact Composition）是 OpenSSF 旗下 Supply Chain Integrity 工作小組的孵化專案，採用 Apache 2.0 授權。它會將軟體資安中繼資料彙整到圖形資料庫中。其文件列出的輸入包括 CycloneDX 與 SPDX SBOM、in-toto 與 SLSA 證明、OpenVEX 與 CSAF 文件、OpenSSF Scorecard 結果、OSV 與 deps.dev 資料。GUAC 彙整的是其他工具產生的中繼資料；它不會執行建置。

Kusari 的共同創辦人與 Google 共同打造了 GUAC，且一位 Kusari 共同創辦人是 GUAC 的首席維護者。Kusari 表示，其商業產品使用並維護 GUAC、SLSA、OpenSSF Scorecard、ClearlyDefined 與其他開源專案。GUAC 也有其他貢獻者，包括 Google、Red Hat、Purdue University 與 Citi。Kusari 是商業平台；GUAC 是社群專案。

Kusari 的強項

以開放標準建立的關係圖。Kusari 的平台會匯入原始碼、建置產物、CycloneDX 與 SPDX SBOM、VEX，以及現有掃描工具的結果，包括 Snyk、Black Duck、Prisma Cloud、Dependabot 與 GitHub Advanced Security 的結果。它會連同來源證明與沿革，對應直接與遞移相依套件，並顯示新漏洞在您整個環境中的影響範圍。

更少、更好的檢測結果。可達性與可利用性分析會尋找有漏洞的程式碼確實被呼叫的證據，讓待處理清單只保留重要的項目。AutoFix 會產生修正用的 pull request，並在送達您的儲存庫之前加以驗證。

在 pull request 進行檢查。Kusari Inspector 會審查 GitHub 或 GitLab 上的每個 pull request，檢查遞移相依漏洞、外洩的機密、惡意與錯字搶註套件、授權風險、已終止支援的相依套件、不安全的 GitHub Actions 工作流程，以及常見的程式碼弱點。Kusari 表示 Inspector 可免費安裝，不需要與業務通話。

標準與框架。Kusari 可產生 SPDX、CycloneDX 與 in-toto 格式的 SBOM 與證明，並列出支援的框架，包括 EU CRA、FDA 524B、SSDF、IEC 62443 與 DORA。其上傳工具可在 GitHub Actions、GitLab CI/CD、Jenkins、CircleCI、Azure DevOps、Bitbucket Pipelines 與 TeamCity 中運作。

CRACI 的不同之處

Kusari 表示，其關係圖是在軟體建立的過程中，從原始碼與建置系統建立的，而不是從完成的二進位檔重建。這個方向是對的，而這也正是兩項產品分歧之處。Kusari 的 SBOM 來自產生工具：其文件說明，SBOM 是在 pull request 合併時，以其開源 SBOM 工具組 waybill 產生，或使用您自己的工具。產生工具讀取的是 lockfile、manifest、快取與映像檔。CRACI 不會讀取建置的檔案來推測它使用了什麼。CRACI 就是建置執行所在的那台機器。

是記錄，而不是重建

只要對 runs-on 做一行修改，您的工作流程就會在 CRACI 上執行。具備套件感知能力的代理伺服器會記錄每個作業從套件來源下載的內容，從 CI 快取還原的套件也會一併延續記錄。每份 SBOM 都會依作業與快取標示其完整程度：Complete、Complete with connections、Incomplete、Unavailable 或 Not recorded。監控從建置實際取用的內容開始，並清楚知道缺口在哪裡。

在建置期間進行控制

關係圖能協助您事後找出受影響的項目。執行器上的對外連線政策，則在作業執行期間決定它可以連到哪些主機。CRACI 的政策可設為預設拒絕或預設允許，內建 24 種軟體來源預設組態，並會在作業開始前驗證，採失效即封鎖（fail closed）。

來源證明與監控來自同一份記錄

API 會回傳 SBOM、網路追蹤記錄與來源證明（provenance）。CRACI 不會為來源證明簽章。它會持續重新評估受監控的 SBOM。

CRACI 不具備讓 Kusari 與眾不同的功能：它不會匯入其他掃描工具的結果、不做可達性分析，也不會審查 pull request 中的惡意套件與程式碼弱點。目前僅支援 GitHub Actions，GitLab CI 與 Jenkins 已列入產品藍圖。

掌握各處部署內容的資產清冊

CRACI 的資產清冊檢視會精確顯示全球各產品部署了哪些軟體版本。當新漏洞出現時，您可以直接看到哪些產品執行受影響的版本，而不必從版本說明與試算表中拼湊答案。

以 CRACI 取代 Kusari

對於您建置與出貨的軟體，CRACI 涵蓋了企業通常購買關係圖平台的目的。它執行建置、記錄附有完整性說明的 SBOM、在新漏洞發布時持續重新評估受監控的 SBOM、彙整各建置與儲存庫的檢測結果，並讓資安團隊分級研判，將每項結果轉交給負責修正的團隊。對外連線政策從一開始就限制建置可以連到哪裡，這是任何關係圖都做不到的。

也請清楚了解您會放棄什麼。Kusari 能在許多掃描工具與 SBOM 來源之間串連成一張關係圖、匯入 VEX、分析可達性，並審查 pull request 中的惡意套件、外洩機密與程式碼弱點。CRACI 目前都不提供這些功能，且目前僅支援 GitHub Actions，GitLab CI 與 Jenkins 已列入產品藍圖。如果您的主要需求是關聯許多現有工具的檢測結果，Kusari 仍是更合適的選擇。

關於 CRA

Cyber Resilience Act（CRA）要求製造商記錄其產品中的元件（包括 SBOM），並在產品支援期間持續處理漏洞。遭積極利用漏洞的通報義務自 2026 年 9 月起適用。Kusari 將 SBOM、VEX 與檢測結果串連在一張關係圖中，並將 CRA 列為其支援的框架之一。CRACI 則產生每次建置的佐證資料並持續監控：每個版本的建置來源、來源證明、持續監控，以及以 CycloneDX 或 SPDX 匯出 SBOM。CRACI 可將企業在更廣泛的 CRA 法規遵循流程中所需的相當大一部分軟體供應鏈可視性與佐證資料自動化；兩項工具都無法單獨讓產品符合法規。請閱讀 CRA 的要求。

移轉到 CRACI

在建置您出貨產品的工作流程中設定 runs-on: craci。CRACI 取代的是執行器，而不是 GitHub Actions，執行記錄仍會顯示在 GitHub 介面中。進一步了解 建置時 SBOM 產生與 漏洞追蹤。

正在評估兩款以上的工具嗎？Kusari 替代方案並列比較了九個選項。