CRACI 與 Dependency-Track 比較

Dependency-Track 的強項

OWASP Dependency-Track 是元件分析的有力選擇。它以 Apache 2.0 授權開源，能追蹤產品組合中每個應用程式每個版本的元件使用情形，並從多個來源取得漏洞情資，包括 National Vulnerability Database 與 GitHub Advisories。它的政策引擎涵蓋資安、授權與營運規則，並能讀取與產生 CycloneDX VEX 文件。其 API 優先的設計很適合 CI/CD：管線會將 SBOM 上傳至 /api/v1/bom。

受監管產業的團隊喜歡它，因為它透明、可自架，並以標準格式為核心打造。它的弱點不在分析本身，而在於輸入它的內容。

分析取決於輸入

Dependency-Track 讀取 SBOM，但不會產生 SBOM。每一項發現、政策違規與產品組合檢視，都取決於您的管線送出的 SBOM。如果 SBOM 遺漏了某個相依套件，Dependency-Track 就無法標示它；如果兩種產生工具結果不一致，Dependency-Track 只會顯示您上傳的那一份。

實務上，各種 SBOM 產生工具的結果經常不一致，原因就寫在它們自己的文件裡：

• 缺乏共同基準。每種產生工具都自行決定什麼算是元件、該信任哪些檔案，因此用兩種工具掃描同一個儲存庫，會得到部分重疊但不相同的清單。
• 漏掉明顯的項目。從鎖定檔解析相依套件的工具，遇到沒有提交任何鎖定檔的儲存庫（例如 express 5.2.1）就無從解析。它仍可能回傳一份清單，內容則是它認得的其他東西，例如 GitHub Actions 與工作流程檔案。
• 設定造成結果起伏。Syft 會依掃描類型選擇 cataloger，因此只要一個旗標，就會改變同一版本的同一工具從同一份 checkout 回報的內容。
• 沒有 manifest 就沒有 SBOM。完全沒有相依套件 manifest 的儲存庫，讓以檔案為基礎的掃描器無從著手，此時各工具回傳的結果，反映的是工具本身而不是專案。
• 中繼資料單薄。大多數產生工具沒有可填入 NTIA supplier 欄位的來源，因此無論儲存庫內容為何，這個欄位都是空的。

CRACI 無法以這種方式比較。它記錄的是建置，而不是掃描目錄，因此無法用相同方式執行。重點不在於這些工具有哪一個不好，而在於對儲存庫做靜態掃描，只是對建置將使用哪些內容的估計，而這個估計會隨工具、設定與現有檔案而變。

CRACI 從源頭改變了什麼

SBOM 來自建置本身

CRACI 是與 GitHub Actions 相容的執行器。您只需將 runs-on 改為 craci，作業就會在 CRACI 的隔離虛擬機器中執行。在每個作業期間，具備套件感知能力的代理伺服器會記錄前往套件來源的流量：npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk 與 Git 來源，以及下載預設集。相依套件的佐證資料會隨 CI 快取一起保存，因此從快取還原的套件仍會留在紀錄中。SBOM 以 CycloneDX 或 SPDX 格式提供，包含建置實際使用的所有遞移相依套件。

不完整時會明確告知

每份 CRACI SBOM 都附有以作業與快取為單位的完整性狀態：Complete、Complete with connections、Incomplete、Unavailable 或 Not recorded。您能清楚知道每份 SBOM 是完整紀錄，還是有缺口。當稽核人員問您如何確認資產清冊完整時，這一點至關重要。

在建置內部記錄 SBOM

CRACI 在自己的執行器內部，根據作業擷取的內容產生 SBOM。API 會回傳 SBOM、網路追蹤與來源證明（provenance）。

控管建置能連到哪裡

由於作業由 CRACI 執行，它能強制執行網路對外連線政策：預設拒絕或預設允許，並提供 24 個內建軟體來源預設集與具型別的自訂來源。政策會在作業開始前驗證，並採失效即封鎖（fail closed）。Dependency-Track 能在事後告訴您某個元件有風險；對外連線政策則從一開始就限制建置能從哪些來源拉取內容。

掌握哪些版本部署在哪裡的資產清冊

CRACI 的資產清冊檢視能在全域範圍內精確呈現哪些軟體版本部署到哪些產品。當新漏洞出現時，您可以直接看到哪些產品執行受影響的版本，不必再從版本說明與試算表中拼湊。

以 CRACI 取代 Dependency-Track

過去需要一套產生工具加上 Dependency-Track 才能完成的工作，CRACI 兩部分都能涵蓋。它在建置中產生 SBOM，在新漏洞公布時持續重新評估受監控的 SBOM，跨建置與儲存庫彙整發現，並讓資安團隊進行分級研判，將每一項發現分派給負責修正的團隊。不需要維護上傳步驟，也不需要執行伺服器。

也請清楚了解您會放棄什麼。Dependency-Track 的政策引擎相當成熟。CRACI 提供可封鎖建置的政策關卡與授權政策，留言與門檻警示則已列入產品藍圖。Dependency-Track 也是開源 且可自架的，而 CRACI 目前為代管服務，客戶自管執行器已列入 Enterprise 的產品藍圖。如果這些比資產清冊的品質更重要，請繼續使用 Dependency-Track。

為什麼這對受監管產業很重要

依據歐盟 Cyber Resilience Act（CRA），製造商必須知道每個產品版本中包含什麼，並處理其中的漏洞；遭積極利用漏洞的通報義務自 2026 年 9 月起生效。因 SBOM 遺漏元件而看不見的漏洞，依然是您的漏洞。

CRACI 將企業在更廣泛的 CRA 法規遵循流程中所需的軟體供應鏈可視性與佐證資料，自動化了相當大的一部分，並能以 CycloneDX 或 SPDX 格式匯出包含漏洞的 SBOM。資產清冊與監控都來自同一份紀錄：每個版本是用什麼建置出來的。請參閱 CRA 法規遵循、工業 IoT與電信。