CRACI vs 自建 SBOM 工具組

簡短的答案

以 Syft 或 Trivy、Grype、Dependency-Track、Cosign 與 Renovate 組成的自建工具組不需授權費用、可在任何地方執行， 並讓有能力的平台團隊擁有完全的掌控權。CRACI 則是代管的 GitHub Actions 執行器，會記錄每次建置擷取的內容、 控管其可連線的對象、監控已出貨的內容，並匯出佐證資料。 兩者的差異與其說在功能，不如說在 SBOM 的來源，以及由誰維護各工具之間的銜接。若您在 GitLab、Jenkins 或 Windows 上建置， 或所有東西都必須在您自己的基礎架構上執行，那麼老實說，目前自建才是適合您的建議。

這套工具組的樣貌

完整的自建環境通常有七層。每一層都是一個真正的專案，各自需要維運。

1. 產生。Syft（「從容器映像檔與檔案系統產生軟體物料清單（SBOM）」）、Trivy、cdxgen（一個 OWASP 專案， 可「從原始碼與容器映像檔」建立 CycloneDX BOM），或是 Microsoft SBOM Tool；後者會輸出 SPDX， 並要求在命令列提供建置輸出資料夾、套件名稱、版本與供應商。
2. 比對。Grype 可掃描映像檔、檔案系統與 SBOM，並提供 EPSS、KEV 與風險評分。OSV-Scanner 會將 lockfile、SBOM 與容器映像檔與 OSV.dev 比對。
3. 管理。OWASP Dependency-Track 可匯入 CycloneDX SBOM 並長期監控。其 API 伺服器至少需要 2 GB RAM 與 2 個 CPU 核心（建議 8 GB 與 4 核心），而其文件建議正式環境部署 使用 Docker Compose 並搭配獨立的資料庫。
4. 簽署。Cosign 可簽署映像檔、blob 與 SBOM 證明，並透過 Fulcio 進行無金鑰簽署， 搭配 Rekor 透明度日誌。GitHub artifact attestations 建立在 Sigstore 之上，提供 SLSA v1.0 Build Level 2 來源證明。
5. 更新。Renovate 或 Dependabot 會開啟 pull request，讓相依套件保持最新。
6. 對外連線控管。StepSecurity Harden-Runner 可稽核或封鎖 GitHub Actions 作業的對外連線。其 Community 方案對使用 GitHub 託管執行器的公開儲存庫免費；私有儲存庫 與自架執行器則需要 Enterprise 方案。另一種做法是在自架執行器周圍設置您自己的代理伺服器與防火牆規則。
7. 報告。必須有人將上述所有工具的輸出，整理成稽核人員、客戶 或 CRA 技術文件所需的文件。

成本藏在銜接之處

選擇產生工具，就是選擇它的盲點

將多個 SBOM 產生工具指向同一個儲存庫，它們對其內容的判斷並不會一致。每個工具讀取的檔案不同， 解析方式也不同，因此您得到的元件清單，既反映專案本身，也同樣反映您挑選的工具。從另一個角度看， NTIA 的供應商欄位也說明了同一件事：大多數產生工具沒有這個欄位的資料來源，因此無論儲存庫裡有什麼，該欄位都是空的。

這些工具都沒有壞掉。每個工具對於什麼算是元件、該信任哪些檔案，都做了不同且有文件記載的決定。 但自建工具組會承襲您所選工具的決定，而管線的其餘部分（比對、監控、報告）的完整度，最多也只能和第一步一樣。

銜接工作由您負責

每個工具都有自己的發布節奏、漏洞資料庫、輸出格式與設定。必須有人固定版本、 更新資料庫、為 Dependency-Track 及其資料庫套用修補程式、輪替簽署身分、決定哪份 SBOM 送往何處， 並在某個步驟悄悄開始產出較少內容時察覺問題。這是持續性的平台工作，而不是一次性的設定。

工具本身也是相依套件

資安工具在您的建置中執行，並能存取您的機密，因此應納入您的威脅模型。2026 年 3 月， Aqua Security 發布資安公告，說明遭竊的憑證如何被用來發布惡意的 Trivy 版本，並將大部分的 trivy-action 標籤強制推送（force-push）到竊取憑證的程式碼，持續約 12 小時。 Aqua 公開記錄了此事件，而這種事可能發生在任何廣泛使用的專案上。這說明了為什麼 執行器上的對外連線控管很重要：預設拒絕的政策能限制遭入侵的步驟可將資料送往何處， 但無法封鎖所有管道（該公告也描述了一種備援手法，會在受害者的 GitHub 帳號上建立儲存庫）。

何時自建才是正確選擇

• 您的 CI 不是 GitHub Actions。CRACI 目前僅支援 GitHub Actions，GitLab CI 與 Jenkins 已列入 產品藍圖。使用 GitLab、Jenkins 與 CircleCI 的團隊可以執行上述所有開源工具。
• 您在 Windows 或 macOS 上建置。CRACI 執行器目前為 Linux（x86-64 與 ARM64）；Windows 與 macOS 已列入產品藍圖。
• 所有東西都必須在您的基礎架構上執行。CRACI 目前在歐洲的基礎架構上執行代管執行器， 客戶自架執行器已列入 Enterprise 的產品藍圖。
• 您有想要自行掌控的平台團隊。若維護這套工具組是刻意的投資，而且您已經把 Dependency-Track 運作得很好， 那就繼續使用。
• 您只需要為一份問卷提供一份 SBOM。對於風險不高、偶爾才有的需求，手動執行一次產生工具 可能就已足夠。

CRACI 能取代什麼，又不能取代什麼

CRACI 從建置開始，將數個層級整合在同一個地方。您將 runs-on 改為 craci，執行紀錄仍會顯示在 GitHub UI 中。具備套件感知能力的代理伺服器會記錄每個作業從 npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk 與 Git 來源，以及下載預設集中拉取的內容，而相依套件的佐證資料 會隨 CI 快取一併延續。每個作業與快取都會取得完整度狀態：Complete、Complete with connections、Incomplete、 Unavailable 或 Not recorded。

• 產生：從記錄下來的建置產生 CycloneDX 與 SPDX，包括遞移相依套件。
• 監控：彙整各次建置與各儲存庫的檢測結果，並持續重新評估受監控的 SBOM。
• 來源證明：API 會回傳 SBOM、網路追蹤與來源證明。CRACI 不會簽署 來源證明。
• 對外連線：每個作業的政策，內建 24 個軟體來源預設集，在作業開始前驗證， 失效即封鎖，並在違規時發出警示。
• 匯出：以 CycloneDX 或 SPDX 格式匯出包含漏洞的 SBOM；不提供報告匯出。

它並不能取代一切。套件封鎖清單已列入產品藍圖。若您需要經簽署的來源證明，請繼續使用 Cosign 或 GitHub artifact attestations。 若要讓所有相依套件（而不只是有漏洞的套件）保持最新，Renovate 或 Dependabot 仍然有其價值。若 Dependency-Track 是您資安團隊的工作平台，可透過 CRACI 的 REST API 下載 CycloneDX SBOM，並匯入其中。

部署位置的資產清冊

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

關於 Cyber Resilience Act

Cyber Resilience Act（CRA）要求製造商「識別並記錄具數位元素產品中所包含的漏洞與元件，包括編製軟體物料清單」 （附件 I 第 II 部分）。遭積極利用漏洞的通報義務自 2026 年 9 月起適用，首次通報期限為 24 小時。 只要有人負責維護從每個版本回溯到其 SBOM 的佐證軌跡，自建工具組也能支援這些要求。CRACI 將企業在更廣泛的 CRA 法規遵循流程中所需的相當大一部分軟體供應鏈可視性與佐證資料自動化，並為您預先備妥 CRA 通報內容以供提交。無論您選擇哪條路， 判斷哪些漏洞遭積極利用，仍由您的團隊負責。請參閱 CRA 法規遵循與 建置時 SBOM 產生。