比較
CRACI vs Aikido
Aikido 把多種資安掃描工具整合在同一個儀表板之後。CRACI 則是您的建置所執行的執行器,並記錄每次建置拉取了哪些內容。兩者解決不同的問題,也能良好地搭配使用。
更新日期
整合與佐證資料
團隊考慮 Aikido,通常是因為想減少資安工具的數量。Aikido 在單一產品中涵蓋開源相依套件、自有程式碼、機密、基礎架構即程式碼、容器、雲端安全態勢、動態測試與執行階段防護,並在同一處分級研判檢測結果。對於需要快速取得廣泛涵蓋範圍的小型團隊而言,這是很有吸引力的選擇。
團隊考慮 CRACI 的理由則較為聚焦。他們需要知道建置實際做了什麼、控管建置能連到哪裡,並為每個版本發布產生在客戶或稽核人員面前站得住腳的佐證資料。CRACI 透過本身就是 CI 執行器來做到這一點。
| 功能 | CRACI | Aikido |
|---|---|---|
| 執行您的建置 | 作業在 CRACI 執行器上執行 | 在您現有的 CI 中加入掃描檢查 |
| 從建置記錄相依套件 | 實際觀察到的取得,包含 CI 快取還原 | 依資訊清單檔與 lockfile 建立 |
| SBOM 匯出 | CycloneDX 與 SPDX,標示每個作業與快取的完整度 | SPDX、CycloneDX 或 CSV,另有匯出 API |
| 封鎖惡意套件 | 目前以對外連線政策限制可連線的來源 | Safe Chain 支援 npm 與 PyPI,可在本機與 CI 使用 |
| 可達性分析 | 函式層級,用以減少雜訊 | |
| 依檢測結果封鎖 pull request | 政策關卡會封鎖建置;未說明是否封鎖 pull request | 針對重大檢測結果 |
| SAST、機密、IaC、雲端、DAST | 另有容器掃描與執行階段防護 | |
| GitHub Actions 以外的 CI | 目前支援 GitHub Actions;GitLab CI 與 Jenkins 已列入產品藍圖 | GitLab、Jenkins、Bitbucket、CircleCI 等 |
| 法規遵循報告 | CycloneDX 或 SPDX 格式的 SBOM,可透過 API 取得記錄;不提供報告匯出 | SOC 2 與 ISO 27001,Advanced 方案以上 |
| 價格 | 每 vCPU 分鐘 $0.002(2 vCPU 為 $0.004),按秒計量;沒有月費,也不按 SBOM 收費 | 提供免費的 Developer 方案;付費方案每月 $350 起(截至 2026 年 9 月)。 |
- 支援
- 部分支援
- 不支援
- 已列入產品藍圖
Aikido 的優勢
涵蓋範圍是它的最大賣點。Aikido 的每個方案都列出 SCA、SAST、機密偵測、IaC、雲端安全態勢、容器掃描、DAST、授權掃描與 SBOM 產生。其 SCA 使用函式層級的可達性分析來減少雜訊,AutoFix 則會以修補後的版本開啟 pull request。在 CI 中,它可以封鎖含有重大風險的 pull request,並支援 GitHub、GitLab、Jenkins、Bitbucket、CircleCI 等平台。CRACI 目前僅支援 GitHub Actions,GitLab CI 與 Jenkins 已列入產品藍圖。
Aikido 也提供 Safe Chain,這是一款免費工具,會在 npm 與 PyPI 套件管理工具前方執行本機 Proxy,於本機與 CI 中在安裝前封鎖含有已知惡意軟體的套件。CRACI 目前不會封鎖個別套件。全組織的套件封鎖清單已列入 CRACI 產品藍圖,尚未納入產品。
在法規遵循方面,Aikido 的較高階方案包含 SOC 2 與 ISO 27001 法規遵循報告,並可同步到 Drata、Vanta 等法規遵循平台。如果您的主要目標是以應用程式安全檢測結果支援 SOC 2 計畫,Aikido 正是為此打造。
CRACI 的不同之處
CRACI 就是 CI 執行環境
Aikido 的執行階段防護保護的是執行中的應用程式。CRACI 運作於另一個執行環境:建置作業。您的 GitHub Actions 作業在 CRACI 上的隔離虛擬機器中執行,執行器規格從 1 到 32 個運算單位,支援 x86-64 或 ARM64。設定方式是把 runs-on 改為 craci。您的工作流程維持不變,執行紀錄仍會顯示在 GitHub 介面中。
由於作業由 CRACI 執行,它可以在作業執行期間執行對外連線政策。政策可設為預設拒絕或預設允許,內建 24 種軟體來源預設組合,並支援 npm、PyPI、apt、apk、Go proxy、Nix、Cargo、OCI 登錄庫與 Git 等具類型的自訂來源。政策會在作業開始前驗證,並且失效即封鎖(fail closed)。掃描工具可以告訴您某個有風險的套件存在;網路政策則能阻止建置連到不該連的地方。
確定性的建置佐證資料
Aikido 依據資訊清單檔與 lockfile 建立相依套件檢視,再在其上加入分析,包括由 AI 驅動的可利用性檢查。這是安排工作優先順序的合理方式。
CRACI 的 SBOM 並非推論而來。具套件感知能力的 Proxy 會記錄作業從套件來源取得了什麼,而相依套件佐證資料會隨 CI 快取一併保存,因此從快取還原的套件仍會被計入。每份 SBOM 都會標示每個作業與每個快取的完整度:Complete、Complete with connections、Incomplete、Unavailable 或 Not recorded。它是實際發生之事的紀錄,而非估算,並會告訴您缺口在哪裡。
這點很重要,因為靜態 SBOM 工具之間的差異比多數人預期的還大,而原因出在結構上。每個工具讀取的檔案組合不同,解析方式也不同,因此一個儲存庫被認為包含哪些內容,取決於您問的是哪個工具、以及它如何設定。像 express 5.2.1 這樣未提交 lockfile 的專案,lockfile 讀取工具就完全沒有東西可解析。CRACI 無法用這種標準比較,因為它記錄的是建置,而不是掃描目錄,而這正是重點:建置紀錄不取決於當下剛好有哪些檔案。
透過 API 取得來源證明資料
CRACI 在自己的執行器內,依據作業取得的內容產生 SBOM。API 會回傳 SBOM、網路追蹤與來源證明(provenance)。
建立在這份紀錄之上的法規遵循成果
對於歐盟 Cyber Resilience Act(CRA)而言,困難之處在於證明每個版本發布包含了什麼,以及您如何長期追蹤其漏洞。CRACI 彙整跨建置與跨儲存庫的漏洞,並持續重新評估受監控的 SBOM。SBOM 可匯出為 CycloneDX 或 SPDX 並包含漏洞,API 則會回傳 SBOM、網路追蹤與來源證明。它自動化了企業在更廣泛的 CRA 法規遵循流程中所需的相當大一部分軟體供應鏈可視性與佐證資料。請參閱 CRA 法規遵循與 CRA 佐證資料。
掌握哪些版本部署在哪裡的資產清冊
CRACI 的資產清冊檢視會在全球範圍內精確顯示哪些軟體版本部署到哪些產品。當新的漏洞出現時,您可以直接看到哪些產品執行受影響的版本,而不必從版本說明與試算表中拼湊答案。
各自適合的情境
- 選擇 Aikido:當您想用一個工具涵蓋程式碼、相依套件、雲端與執行中的應用程式,目前使用 GitHub Actions 以外的 CI 系統,或您的法規遵循重點是依據應用程式安全檢測結果產出 SOC 2 或 ISO 27001 報告。
- 選擇 CRACI:當您在 GitHub Actions 上建置,需要確切知道每次建置取得了什麼、控管建置的網路存取,並為 CRA 與客戶稽核保存版本發布佐證資料。
- 兩者並用:當您想要 Aikido 的掃描與 pull request 把關,再加上 CRACI 的建置執行環境控管與佐證資料。Aikido 的 CI 檢查與 Safe Chain 以步驟形式在您的工作流程中執行,這些步驟也能像其他步驟一樣在 CRACI 執行器上執行。
想了解更多細節?請閱讀建置時 SBOM 產生、漏洞追蹤與價格方案。