CRACI 與 Syft、Grype 比較

簡短的答案

Syft 是廣受歡迎的開源 SBOM 產生工具，Grype 則是與之搭配的漏洞掃描工具。兩者合起來，就能在任何管線中免費完成產生與比對。CRACI 是一款 GitHub Actions 執行器，會記錄每次建置取用的內容、說明該紀錄是否完整、控管建置能連線到哪裡，並持續監控已出貨的內容。一句話說明差異：Syft 從檔案重建 SBOM，能找到多少取決於它的設定，以及執行時磁碟上有什麼。CRACI 則是直接觀察，並追蹤其記錄內容中的漏洞，因此一個產品就能完成兩者的工作。

Syft 與 Grype 的強項

Syft 是「a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems」（從容器映像檔與檔案系統產生軟體物料清單的 CLI 工具與 Go 函式庫）。它能辨識數十種套件系統，從 Alpine、Debian、RPM 到 Go、Python、Java、JavaScript、Ruby、Rust、PHP 與 .NET。它能輸出 CycloneDX、SPDX 與其自有的 Syft JSON，在格式之間轉換，並能依 in-toto 規範建立經簽署的 SBOM 證明。

Grype 會掃描容器映像檔、檔案系統與 SBOM 中的已知漏洞。它以 EPSS、KEV 與風險評分為發現排定優先順序，支援以 OpenVEX 篩選結果，而其 --fail-on 旗標會在發現達到或超過您所選嚴重度的漏洞時讓管線失敗。Anchore 指出，除了下載資料庫之外，Grype「runs entirely locally and doesn't send any data to external services」（完全在本機執行，不會將任何資料傳送到外部服務）。

兩者皆採 Apache-2.0 授權，並由 Anchore 贊助；Anchore 的商用平台 Anchore Enterprise「builds on open source Syft and Grype」（建構於開源的 Syft 與 Grype 之上）。本頁討論的是這兩個開源工具。

當 Syft 面前有正確的檔案時，它的表現很出色。若將它指向一個已提交相依套件的原始碼樹，例如 ollama/ollama，它的預設掃描就能解析出這些套件，連同版本、package URL 以及彼此之間的相依關係。

一個旗標就能改變答案

Syft 依掃描類型選擇 cataloger，其文件也說明了原因：「files that hint at the intent to install software do not have enough information in them to determine the exact version」（僅暗示要安裝軟體的檔案，所含資訊不足以判定確切版本）。cataloger 帶有 declared、installed、image 與 directory 等標籤，而 --select-catalogers 與 --override-default-catalogers 等旗標會改變所用的集合。

在 v1.51.1 的 syft cataloger list 中，讀取 node_modules 的 JavaScript cataloger 被標記為用於映像檔與已安裝內容的掃描，並不在目錄掃描的預設集合中。因此，在已安裝相依套件的 checkout 上，一個旗標就決定了 node_modules 中的 npm 套件究竟會不會被讀取。同樣的工具、同樣的版本、同樣的目錄樹。

反過來看也同樣重要。沒有任何單一設定能適用於所有情況：

• 在一個乾淨、沒有 lockfile 的 express 5.2.1 checkout 上，預設掃描沒有可解析的 npm 相依套件，只會回傳它能辨識的其他內容，例如 GitHub Actions 與工作流程檔案。
• 若開啟已安裝內容的 cataloger，並將它們指向剛提交、尚未安裝任何東西的原始碼樹，它們幾乎沒有東西可讀。
• 一個完全沒有相依套件 manifest 的儲存庫，無論怎麼設定，都沒有相依套件檔案可供掃描讀取。

這些都不是錯誤。Syft 依照設計，回報它面前的檔案所能支持的內容。實際的後果是，SBOM 取決於兩個必須在每條管線中都做對的決定：執行哪些 cataloger，以及掃描前是否已安裝相依套件。而 Grype 只能比對 Syft 列出的內容。SBOM 中缺少的元件永遠不會進入漏洞查詢，因此對它的掃描結果會顯示為沒有問題。

CRACI 的不同之處

CRACI 沒有需要選擇的 cataloger，因為它不會事後讀取目錄樹。您將 runs-on 改為 craci，能辨識套件的代理伺服器就會記錄作業從 npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk 與 Git 來源，以及下載預設集取用的內容。從 CI 快取還原的套件會延續其佐證資料。產生的結果（CycloneDX 或 SPDX）包含建置實際使用的遞移相依套件。

• 完整性一目了然。每個作業與快取都會標示為 Complete、Complete with connections、Incomplete、Unavailable 或 Not recorded。
• 建置受到控管。對外連線政策（預設拒絕或允許，內建 24 個軟體來源預設集）會在作業開始前驗證，並採失效即封鎖（fail closed）。
• 來源證明資料。API 會回傳 SBOM、網路追蹤紀錄與來源證明。CRACI 不簽署來源證明；Syft 的證明則會對 SBOM 簽署。
• 監控。受監控的 SBOM 會持續重新評估，發現也會跨建置與跨儲存庫彙整。

Grype 仍能做到 CRACI 做不到的事。VEX 篩選與掃描非您建置的映像檔是 Grype 的領域。CRACI 的政策關卡可以讓建置失敗；其門檻警示已列入產品藍圖。

部署在哪裡的資產清冊

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

從 Syft 與 Grype 轉移

在 CRACI 上，不需要產生 SBOM，也不需要維護掃描步驟。執行器會在建置執行期間記錄 SBOM，而 CRACI 會在建置完成後持續檢查其中是否出現新漏洞。對於非您建置的映像檔與第三方軟體，以及 GitHub Actions 以外的管線，Syft 與 Grype 仍是合適的工具。

關於 Cyber Resilience Act

Cyber Resilience Act（CRA）要求製造商記錄每項產品中的元件（包括 SBOM），並處理其中的漏洞。Syft 與 Grype 能產生並檢查這份 SBOM，但從每個版本回溯到其 SBOM 的佐證資料軌跡，則需要您自行建立。CRACI 會為每次建置記錄 SBOM，並匯出為 CycloneDX 或 SPDX。它將企業在更廣泛的 CRA 法規遵循流程中所需的軟體供應鏈可視性與佐證資料中相當大的一部分自動化。請參閱 CRA 是什麼與 建置時 SBOM 產生。