CRACI 與 JFrog Artifactory

從兩個角度觀察同一條供應鏈

許多工程組織會讓套件流量經過 JFrog Artifactory。遠端儲存庫作為 npm 或 PyPI 等公開套件登錄庫的快取代理，依需求下載套件並保留副本。虛擬儲存庫將多個來源整合在同一個 URL 之後，而您自己的建置產出則存放在本地儲存庫中。這讓您能在同一處查看並管控進入公司的內容。

CRACI 則位於另一個位置。它是您 GitHub Actions 作業執行時所用的 CI 執行器，並在每個作業執行期間記錄該作業引入的外部相依套件。Artifactory 回答的是「有哪些東西流經我們的儲存庫？」CRACI 回答的是「這次特定的建置用了什麼，又產出了哪個建置產物？」

Artifactory 的強項

Artifactory 是成熟的儲存庫管理工具。它讓團隊能可靠地透過快取存取上游套件，為內部建置產物提供存放處，並為多種套件類型提供單一管控點。在此基礎上，JFrog Platform 還提供更多功能：

• Build-info。使用 JFrog CLI 時，您可以在指令中加上建置名稱與編號，並發布一份 JSON 紀錄，內容包括解析出的相依套件、產出的建置產物、環境變數與 Git 資訊。這份紀錄支援追溯、建置晉升與 Xray 掃描。
• Xray。掃描建置產物與建置中的漏洞，並以 SPDX 與 CycloneDX 格式匯出 SBOM。根據 JFrog 的授權對照表，Xray 包含在 Pro X、Enterprise X 與 Enterprise+ 訂閱中（截至 2026 年 9 月）。
• Curation。在惡意或有漏洞的套件送達開發人員之前，於遠端儲存庫加以封鎖，包括已存在於遠端快取中的套件。

在套件登錄庫層級封鎖個別套件是一項真正的優勢。CRACI 目前不封鎖個別套件；全組織層級的套件封鎖清單已列入 CRACI 產品藍圖。

CRACI 能補足之處

不依賴流量路由的可見性

Artifactory 只看得到經過它的內容，而建置並不總是配合。作業可能會從 GitHub release 下載工具鏈、安裝作業系統套件、從公開登錄庫拉取基礎映像檔，或執行會下載二進位檔的腳本。JFrog 自己的文件指出，其他工具下載的相依套件可以用 build-add-dependencies 手動登記，這表示必須有人知道它們的存在。

CRACI 在執行器上進行記錄。一個能辨識套件的代理會在作業期間觀察前往套件來源的流量，涵蓋 npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk 與 Git 來源，以及下載預設集。如果您的 npm 或 PyPI 安裝經由 Artifactory 鏡像，這樣也沒問題：CRACI 同樣會記錄這些套件。

無須額外步驟的每次建置佐證

Build-info 很有價值，但需要您逐一加入每條管線。在 CRACI 上，每個作業都有這份紀錄，因為它由執行器產生。相依套件的佐證資料會隨 CI 快取一起保留，因此從快取還原的套件仍會被計入。每份 SBOM 都依作業與快取標示完整性狀態：Complete、Complete with connections、Incomplete、Unavailable 或 Not recorded。紀錄有缺口時，它會明白標示。

讓建置走在核准的路徑上

由於作業由 CRACI 執行，您可以設定它的網路對外連線政策。政策可設為預設拒絕或預設允許，提供 24 個內建的軟體來源預設集、具型別的自訂來源（npm、PyPI、apt、apk、Go proxy、Nix、Cargo、OCI 登錄庫與 Git），以及明確的 TLS、TCP、UDP 與 ICMP 規則。政策會在作業開始前驗證，並採失效即封鎖。允許您的 Artifactory 主機並拒絕直接存取公開登錄庫的政策，有助於確保建置確實走經管控的路徑。作業違反政策時，CRACI 會向您發出警示。

與 Artifactory 並存的建置佐證資料

API 會回傳 SBOM、網路追蹤與來源證明。CRACI 不會簽署來源證明。請照常將建置產物存放在 Artifactory 中；建置下載內容的紀錄則來自 CRACI。

對於需因應歐盟 Cyber Resilience Act（CRA）的團隊，這份紀錄可作為版本層級的佐證資料。CRACI 跨建置與儲存庫彙整漏洞，持續重新評估受監控的 SBOM，並以 CycloneDX 或 SPDX 格式匯出。請參閱 CRA 佐證資料與 CRA 法規遵循。

掌握哪些軟體部署在何處的資產清冊

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

兩者如何搭配

1. 繼續以 Artifactory 作為套件代理、建置產物儲存庫與版本發行點。
2. 將 runs-on 改為 craci，即可把 GitHub Actions 作業移到 CRACI。工作流程維持不變，執行結果仍會顯示在 GitHub UI 中。
3. 照常將 npm 與 PyPI 安裝指向您的 Artifactory 鏡像。
4. 使用 CRACI 對外連線政策，讓建置只使用核准的來源，包括 Artifactory。
5. 以 CRACI 每次建置的 SBOM、來源證明與網路追蹤作為每個版本的佐證資料。

如果您目前仰賴 JFrog build-info 或 Curation，請繼續使用。CRACI 目前僅支援 GitHub Actions（GitLab CI 與 Jenkins 已列入產品藍圖），因此其他 CI 系統上的管線維持原狀。

如果您要取代的是 Artifactory 本身，請參閱 JFrog Artifactory 替代方案。

常見問題

CRACI 會取代 Artifactory 嗎？

不會。CRACI 不是儲存庫管理工具，它不儲存也不發行您的套件或發布二進位檔。它執行您的建置，並記錄與建置相關的佐證資料。

CRACI 與 Xray 的功能重疊嗎？

部分重疊。兩者都能以 CycloneDX 與 SPDX 匯出 SBOM，也都協助您追蹤漏洞。差別在於輸入：Xray 掃描 JFrog 所知道的建置產物與建置；CRACI 的 SBOM 與漏洞檢視則來自每次建置在執行期間下載的內容，並跨建置與儲存庫彙整。如果 Xray 已嵌入您的發布流程，請保留它，並將 CRACI 的每次建置紀錄視為第二個獨立來源。

哪些 Artifactory 儲存庫類型可以與 CRACI 搭配使用？

已確認 Artifactory 的 npm 與 PyPI 鏡像可與 CRACI 建置搭配使用。若是其他套件類型，請在搬移那些管線之前，先與我們討論您的環境配置。