比較
CRACI vs OX Security
OX Security 從您的程式碼、管線、registry 與掃描器拼湊出風險全貌,並記錄在 Pipeline Bill of Materials 中。CRACI 則是您的建置實際執行所在的執行器,因此能記錄每次建置擷取的內容,並控管它能連到哪裡。
更新日期
簡短回答
OX Security 是一套應用程式安全態勢管理(ASPM)平台,具備自有掃描器(SAST、SCA、機密、IaC 與容器)、第三方發現彙整、CI/CD 態勢政策,以及執行階段與雲端脈絡。在供應鏈安全方面,它提供 Pipeline Bill of Materials(PBOM):一份已簽署的紀錄,說明每個建置產物如何從 commit 經過 CI/CD 一路到正式環境。
CRACI 爭取的是同一筆供應鏈預算,差別在於觀察的位置。OX 連接您已在使用的原始碼管理、CI 系統與 registry,並從中建立全貌。CRACI 則是 GitHub Actions 的建置執行器:它記錄每個作業實際拉入的內容,在執行期間強制執行對外連線政策,監控已出貨的內容,並產出 CRA 佐證資料。OX 的範圍廣得多;CRACI 則就是建置本身。
重點一覽
| 功能 | CRACI | OX Security |
|---|---|---|
| 執行您的建置 | 作業在 CRACI 執行器上執行 | 連接您所使用的 CI 系統 |
| SBOM 的來源 | 由執行器根據每個作業擷取的內容記錄,包括從 CI 快取還原的內容,並為每個作業提供完整性狀態。 | 從已連接的來源收集:原始碼管理、CI/CD 管線、容器映像檔與匯入的檔案。 |
| 建置網路的對外連線政策 | 預設拒絕或允許,失效即封鎖 | 改以態勢政策檢查工作流程設定 |
| 已簽署的建置紀錄 | 無已簽署的來源證明 | 每次建置簽署 PBOM |
| 持續相依套件監控 | 持續重新評估受監控的 SBOM | 持續更新的資產清冊,依可利用性排定優先順序 |
| 依資安政策封鎖建置 | 政策關卡會封鎖建置 | 發現封鎖性問題時,掃描步驟會讓工作流程失敗 |
| CI/CD 態勢政策 | 未釘選的 action、權限、webhook、機密處理 | |
| SAST、機密、IaC 與容器 | OX Code,並彙整第三方掃描器結果 | |
| 支援的 CI 系統 | 目前支援 GitHub Actions;GitLab CI 與 Jenkins 已列入產品藍圖 | GitHub Actions、GitLab、Jenkins、Azure Pipelines、CircleCI |
| 價格 | 每 vCPU 分鐘 $0.002(2 vCPU 為 $0.004),按秒計費;無月費,也不按 SBOM 計費 | OX Code 依貢獻程式碼的開發人員數計價;未公開牌價(截至 2026 年 9 月)。 |
- 支援
- 不支援
- 已列入產品藍圖
OX Security 的強項
- 超越 SBOM 的建置紀錄。OX 的 PBOM 會擷取管線定義、執行器身分、建置參數、建置產物簽章與版本沿革,OX 表示它包含每次建置所解析的每一個開源元件。PBOM 於每次建置時簽署。OX 也能產生 SPDX 與 CycloneDX 格式的 SBOM。
- CI/CD 態勢。OX 政策會標示不安全的工作流程檔案、未釘選的第三方 action、已淘汰的 GitHub Actions 指令、過度的工作流程權限、明文機密與有風險的 webhook,也能標示未獲准用於建置的 CI 系統。
- 在管線中強制執行。OX Security Scan GitHub Action 會執行機密、SAST、SCA 與 IaC 掃描,並在依您的 OX 政策發現封鎖性問題時讓工作流程失敗。
- 彙整。除了自家結果,OX 也會匯入 Checkmarx、Veracode、SonarQube、Snyk、Black Duck 與 JFrog Xray 等掃描器的發現。
- 廣泛的整合範圍。在 CI 方面,它列出 GitHub Actions、GitLab CI/CD、Jenkins、Azure Pipelines、CircleCI 與 Drone CI,另外還支援八種原始碼管理系統與十種容器 registry。
- AI 時代的功能。OX VibeSec 以 AI Bill of Materials 涵蓋 AI 產生的程式碼與相依套件,AI 修補則會在 pull request 與 IDE 中建議程式碼修正。
CRACI 的不同之處
由執行器記錄,而非從已連接的工具收集
OX 的文件指出,其 SBOM 會從已連接的來源收集資料,包括原始碼管理、CI/CD 管線、容器映像檔與匯入的檔案。這能讓您廣泛掌握整體環境。CRACI 對每次建置的觀點則更窄也更深:具備套件感知能力的代理伺服器會在作業執行期間觀察前往套件來源的流量,涵蓋 npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk 與 Git 來源,以及下載預設集。相依套件的佐證資料會隨 CI 快取一起保存,因此從快取還原的套件仍會被納入。
每份 CRACI SBOM 都附有以作業與快取為單位的完整性狀態:Complete、Complete with connections、Incomplete、Unavailable 或 Not recorded。紀錄有缺口時,它會明確告知。
在建置執行期間進行控管
OX 的態勢政策檢查的是管線如何設定;CRACI 則限制建置能連到哪裡。對外連線政策可設為預設拒絕或預設允許,提供 24 個內建軟體來源預設集,以及適用於 npm、PyPI、apt、apk、Go proxy、Nix、Cargo、OCI registry 與 Git 的具型別自訂來源,並可設定明確的 TLS、TCP、UDP 與 ICMP 規則。政策會在作業開始前驗證,並採失效即封鎖(fail closed),CRACI 也能在發生違規時向您發出警示。
來源證明與監控出自同一份紀錄
API 會回傳 SBOM、網路追蹤與來源證明(provenance)。CRACI 不會簽署來源證明,也不宣稱任何 SLSA 等級。它會在新漏洞公布時,持續重新評估您已出貨版本的 SBOM。
掌握哪些版本部署在哪裡的資產清冊
CRACI 的資產清冊檢視能在全域範圍內精確呈現哪些軟體版本部署到哪些產品。當新漏洞出現時,您可以直接看到哪些產品執行受影響的版本,不必再從版本說明與試算表中拼湊。
OX 領先之處
坦白說:CRACI 沒有 SAST、機密、IaC 或容器掃描,沒有 CI/CD 態勢檢查,沒有第三方掃描器彙整,也沒有執行階段或雲端脈絡。CRACI 的政策關卡能依發現封鎖建置,但 CRACI 目前僅支援 GitHub Actions,GitLab CI 與 Jenkins 已列入產品藍圖。如果您需要一個涵蓋您所有管線與掃描器的平台,OX 涵蓋的範圍廣得多。
哪一個適合您
以下情況較適合 OX Security
- 您想要一個能彙整多種掃描器並跨掃描器排定優先順序的 ASPM 平台。
- 您需要涵蓋 GitLab、Jenkins、Azure Pipelines 或 CircleCI 的 CI/CD 態勢政策。
- 您現在就需要針對程式碼、機密與 IaC 發現進行 pull request 把關。
以下情況較適合 CRACI
- 您在 GitHub Actions 上建置,並希望執行器、對外連線政策與相依套件紀錄集中在同一處。
- 您需要記錄每次建置擷取內容的 SBOM,並附上可出示給稽核人員的完整性狀態。
- 您希望從同一份紀錄取得已出貨內容的監控與 CRA 佐證資料。
兩者並用
CRACI 取代的是執行器,而不是 GitHub Actions,因此 OX Security Scan action 能像其他步驟一樣在 CRACI 執行器上執行。OX 可匯入 CycloneDX 格式的 SBOM,因此 CRACI 可以提供從建置記錄的 SBOM 給 OX 使用。
關於 Cyber Resilience Act
Cyber Resilience Act(CRA)要求製造商掌握每個產品中的元件、處理其中的漏洞並保存佐證資料。OX 的 SBOM、PBOM 與態勢政策有助於安全開發,並能建立涵蓋整體環境的資產清冊。CRACI 將企業在更廣泛的 CRA 法規遵循流程中所需的軟體供應鏈可視性與佐證資料,自動化了相當大的一部分:以 CycloneDX 或 SPDX 匯出的建置時 SBOM、漏洞追蹤,以及透過 API 提供的來源證明。兩種工具都無法單獨讓您符合法規。請參閱CRA 佐證資料與CRA 法規遵循。
導入 CRACI
在您的組織安裝 CRACI GitHub App,然後將作業的執行器標籤改為 runs-on: craci。執行紀錄仍會顯示在 GitHub UI 中。先從一個會產生發布建置產物的工作流程開始,並將 CRACI 的 SBOM 與 OX 針對同一儲存庫顯示的 SBOM 相比較。進一步了解 CI/CD 整合、建置時 SBOM 產生與價格方案。
正在評估兩種以上的工具嗎?OX Security 替代方案並列比較了九個選項。