Dependency-Track 替代方案

CRACI 是我們開發的產品，請將這點納入考量；我們依據各工具自己的文件描述每個選項，並說明何時其他工具更合適。

團隊為何尋找替代方案

OWASP Dependency-Track 以 Apache 2.0 授權開源。它會追蹤產品組合中每個應用程式每個版本的元件使用情形，從 National Vulnerability Database 與 GitHub Advisories 等來源取得漏洞情資，套用資安、授權與營運政策，並可讀取與產生 CycloneDX VEX。管線透過其 API 將 SBOM 上傳給它。對許多團隊而言，它就是正確的答案，而且不需要任何授權費用。

團隊進一步尋找的原因，通常與範圍和適用性有關：

• 您不想自行維運。Dependency-Track 需自行託管，因此伺服器、升級與備份都由您負責。
• 您需要供應商相關的工作流程。向廠商收集 SBOM、分析廠商的二進位檔，或與客戶分享 SBOM，是部分商業平台的核心功能。
• 您需要能產出法律文件的授權合規功能，例如著作權聲明（attribution notice）。
• 您不信任輸入的資料。Dependency-Track 分析的是它收到的 SBOM，並不會產生 SBOM。如果產生工具漏掉了某個相依套件，後續的每項檢測結果也都會漏掉它。

選擇時要注意什麼

• SBOM 從何而來：由平台產生、匯入，或從建置記錄。
• 是否有任何機制告訴您 SBOM 的完整程度。
• VEX、分級研判與政策工作流程，若您的資安團隊目前就以這些為日常工作。
• 授權分析與著作權聲明。
• 由誰維運，以及是否能自行託管或在離線隔離環境中執行。
• 接收供應商 SBOM，以及與客戶或主管機關分享。

各個選項

CRACI（我們的產品）

CRACI 不是產品組合分析平台，而是相容於 GitHub Actions 的執行器：您只要將 runs-on 改為 craci，具備套件感知能力的代理伺服器就會記錄每個作業從套件來源取用的內容，包含從 CI 快取還原的套件。CycloneDX 或 SPDX 格式的 SBOM 即來自這份記錄，並為每個作業與每個快取標示完整性狀態。CRACI 會持續監控這些 SBOM 是否出現新漏洞，API 則會回傳 SBOM、網路追蹤記錄與來源證明（provenance）。CRACI 的資產清冊檢視會精確顯示全球各產品部署了哪些軟體版本。

最適合：使用 GitHub Actions、問題出在輸入資料的團隊。CRACI 在建置中產生 SBOM 並加以監控，因此不需要執行產生工具，也不必維護上傳步驟。

考量點：您希望在源頭取得建置佐證資料與對外連線控制。CRACI 讓資安團隊能分級研判檢測結果、轉交給對的團隊並記錄 VEX。CRACI 的政策關卡可以阻擋建置，並會強制執行授權政策。CRACI 目前僅支援 GitHub Actions，GitLab CI 與 Jenkins 已列入產品藍圖。

給 Dependency-Track 使用者的 CRACI 介紹

Anchore Enterprise

Anchore Enterprise 建立在 Anchore 的開源工具 Syft 與 Grype 之上。它可從容器映像檔、原始碼與檔案系統產生 SBOM，匯入在其他地方建立的 SBOM，不需原始建置產物即可重新掃描已儲存的 SBOM，並強制執行 FedRAMP、NIST、CIS、PCI DSS 與 CMMC 的政策套件。可部署於 Kubernetes、Docker Compose 或離線隔離環境，並整合 GitHub、GitLab、Jenkins、AWS CodeBuild 與 Azure Pipelines。價格需洽詢報價。

最適合：橫跨多套 CI 系統的容器機群，以及政府或離線隔離環境。

考量點：您想要一套仍由自己維運的商業平台。如果您只需要產生與比對，Syft 與 Grype 是免費的。

CRACI vs Anchore

FOSSA

FOSSA 起家於開源授權合規：全文授權偵測、自動化政策與著作權聲明。它可產生與讀取 SPDX 與 CycloneDX 格式的 SBOM，並可選擇附上 VDR 或 VEX 聲明，對匯入的 SBOM 強制檢查 NTIA 與 FDA 最低要素，Enterprise 方案還可透過 SBOM Portal 分享 SBOM。Free 方案以多租戶 SaaS 形式提供；Business 每個專案每月 $20，按年計費（截至 2026 年 9 月）。

最適合：以授權風險與供應商 SBOM 為主要顧慮的團隊。

考量點：您想要代管平台，以及免費的起步方式。

CRACI vs FOSSA

Cybeats SBOM Studio

SBOM Studio 自稱為「the SBOM system of record」（SBOM 的權威記錄系統）。它會儲存來自您產品與供應商的 SBOM，支援 SPDX 2.2 至 3.0.1 與 CycloneDX 1.2 至 1.7，以 SBOM Quality Score 驗證檔案，持續將每個元件與漏洞情資比對，處理 VEX 與授權分析，並與客戶分享 SBOM，包括透過 Transparency Exchange API。在 SBOM 產生方面，Cybeats 則引導使用者使用其 Marketplace 中的工具廠商。

最適合：ICS 與 OT、醫療器材、電信與汽車產業的中央產品資安團隊。

考量點：您在許多產品與供應商之間推動 SBOM 計畫。

CRACI vs Cybeats

Manifest

Manifest 可為您的產品、廠商的軟體與您的 AI 模型建立、匯入、擴充並分享 SBOM。廠商透過入口網站上傳 SBOM；若廠商未提供，Manifest 可從編譯後的二進位檔產生一份。它會將檢測結果轉為工單與供應商聯繫事項，支援 VEX，其 CLI 可在任何 CI 中運作，另有預設執行 Syft 的 GitHub Action。

最適合：主要風險來自所採購軟體的組織。

考量點：第三方風險與 AI 模型資產清冊，與您自己的建置同樣重要。

CRACI vs Manifest

ONEKEY

ONEKEY 是針對連網裝置的產品資安與法規遵循平台。您上傳韌體映像檔，它便會分析二進位檔（不需要原始碼），找出元件、已知漏洞，以及可能的零時差漏洞，例如寫死的帳密。它可從二進位檔產生 SBOM，匯入來自原始碼掃描工具或供應商的 SBOM，匯出 CycloneDX 與 SPDX，並每天重新分析已上傳的韌體。其 Compliance Wizard 涵蓋 Cyber Resilience Act（CRA）、IEC 62443-4-2、ETSI EN 303 645 與 Radio Equipment Directive。

最適合：需要分析韌體（包含從未自行建置的供應商二進位檔）的裝置製造商。

考量點：您的產品是連網裝置，而不是網路服務。

CRACI vs ONEKEY

SBOM Observer

SBOM Observer 由瑞典公司 Bitfront AB 開發，可匯入、正規化 SBOM 並進行版本管理，執行政策檢查，追蹤各元件的漏洞，並產出法規遵循佐證資料。它支援 SPDX、CycloneDX 與 VEX，可採用 SaaS 或地端部署（可選擇離線隔離），並提供開源 CLI 與 SBOM.link 檢視器等免費工具。截至 2026 年 9 月 29 日，Business 每位使用者每月約 $80（€69），最多 10 個專案；Enterprise 適用 25 位以上使用者，價格需洽詢。

最適合：希望以公開價格的代管服務完成 Dependency-Track 工作的團隊。

考量點：依使用者計價，以及各方案的專案數上限符合您的產品組合。

sbomify

sbomify 透過其開源 GitHub Action 在 CI 中產生 SBOM，跨版本管理 SBOM，並透過品牌化的 Trust Center 分享 SBOM 與法規遵循文件，包括透過 Transparency Exchange API。它支援 CycloneDX 與 SPDX，並整合 Google OSV 與 Dependency-Track 進行分析。它是開源軟體，可自行託管。截至 2026 年 9 月，Community 方案免費，限 1 項產品與 5 個元件，且僅能公開文件；Business 每月 $159，按年計費。

最適合：需要與客戶分享 SBOM，而不只是分析 SBOM 的團隊。

考量點：您想保留 Dependency-Track 進行分析；sbomify 可與它整合。

並列比較

「未說明」表示我們在該廠商的公開頁面中找不到相關資訊。表格涵蓋 Dependency-Track 與前五個選項；ONEKEY、SBOM Observer 與 sbomify 已在上方說明。除了 CRACI 之外，每個平台分析的都是由其他工具產生的 SBOM，或以掃描工具、從二進位檔產生 SBOM，因此無論您選擇哪一個，輸入資料的品質都同樣重要。

Dependency-Track 與 Dependency-Check 的比較

兩者名稱相近，也都是 OWASP 專案，但負責的工作不同。Dependency-Track 自己的文件對兩者做了比較：

• 是什麼。Dependency-Track 是一個平台。Dependency-Check 是一套函式庫，提供命令列介面、Maven 與 Ant 等工具的建置外掛，以及 Jenkins 外掛。
• 如何運作。Dependency-Track 從 SBOM 出發，SBOM 可在建置時產生或向廠商取得。Dependency-Check 會掃描檔案系統上的檔案，並以不同的信心程度擷取證據。
• 比對方式。Dependency-Track 透過 NVD 與其他來源精確比對。Dependency-Check 則透過 NVD 進行模糊比對。
• 結果。Dependency-Track 透過網頁介面與 REST API 提供指標，並具備以專案及整個產品組合為單位的稽核工作流程。Dependency-Check 則為每個專案產生靜態的 HTML、XML、JSON 或 CSV 報告。

簡而言之，Dependency-Check 是掃描工具，Dependency-Track 則是長期分析 SBOM 的地方。兩者都不會記錄您的建置取用了哪些內容。

關於 Cyber Resilience Act

如果 CRA 是您重新檢視 SBOM 工具的原因：通報義務自 2026 年 9 月 11 日起適用，在得知遭積極利用的漏洞後 24 小時內須提出早期預警。要做到這點，必須知道哪些版本含有受影響的元件，而這又取決於每個版本的 SBOM 是否正確。Anchore、FOSSA、Cybeats 與 Manifest 都發布了 CRA 相關資料。CRACI 可將企業在更廣泛的 CRA 法規遵循流程中所需的相當大一部分軟體供應鏈可視性與佐證資料自動化。本頁沒有任何平台能單獨讓產品符合法規。

何時應繼續使用 Dependency-Track

• 您能自在地維運它，且免費、開源、自行託管的平台符合您的政策。
• 您的資安團隊仰賴它的政策引擎、VEX 與產品組合檢視。
• 您真正的缺口在於 SBOM 品質。那就改善輸入資料，並保留現有的分析工具。

若想進一步了解輸入端，請閱讀建置時 SBOM 產生與 CRA 法規遵循的介紹。

Dependency-Track 替代方案常見問題

團隊比較方案時常問問題的簡短解答

什麼是 Dependency-Track？

OWASP Dependency-Track 是採用 Apache 2.0 授權的免費開源平台，用於分析 SBOM。它會追蹤產品組合中每個應用程式每個版本的元件，將其與 NVD、GitHub Advisories 等漏洞來源比對，套用資安、授權與營運政策，並可讀取與產生 CycloneDX VEX。它不會產生 SBOM；管線需透過其 API 上傳 SBOM。

什麼是相依套件追蹤？

相依套件追蹤是指記錄您軟體每個版本所使用的第三方元件，並持續將這份記錄與漏洞資料及政策比對。當新的資安公告發布時，它會告訴您哪些版本含有受影響的元件。這份記錄通常是每個版本一份 SBOM。

如何執行 Dependency-Track？

其文件建議使用 Docker Compose：從 dependencytrack.org 下載 docker-compose.yml，再執行 docker compose up -d。API 伺服器至少需要 2 GB 記憶體。正式環境的設定請參閱 docs.dependencytrack.org。

Dependency-Track 與 Dependency-Check 有什麼不同？

Dependency-Track 是一個平台，會分析整個產品組合的 SBOM，並透過網頁介面與 REST API 提供結果。OWASP Dependency-Check 則是一套命令列工具與建置外掛，會掃描磁碟上的檔案，透過 NVD 以模糊比對找出漏洞，並為每個專案產生靜態報告。

有代管版的 Dependency-Track 替代方案嗎？

有。FOSSA 以 SaaS 形式提供，SBOM Observer 提供 SaaS 或地端部署，sbomify 則有附免費 Community 方案的雲端服務。CRACI 同樣是代管服務，而且直接從建置產生 SBOM，不必等待上傳。