CRACI vs Aikido

통합인가, 증거인가

팀들이 Aikido를 검토하는 이유는 대개 보안 도구 수를 줄이고 싶어서입니다. Aikido는 오픈 소스 종속성, 자체 코드, 시크릿, 코드형 인프라(IaC), 컨테이너, 클라우드 보안 태세, 동적 테스트, 런타임 보호를 하나의 제품에서 다루며, 발견 사항을 한곳에서 분류할 수 있습니다. 폭넓은 범위를 빠르게 갖춰야 하는 작은 팀에게는 강력한 제안입니다.

팀들이 CRACI를 검토하는 이유는 더 구체적입니다. 빌드가 실제로 무엇을 했는지 알고, 빌드가 접근할 수 있는 대상을 통제하며, 고객이나 감사인 앞에서도 통하는 각 릴리스의 증거를 만들어야 하기 때문입니다. CRACI는 CI 러너 자체가 됨으로써 이를 해냅니다.

Aikido의 강점

핵심은 범위의 폭입니다. Aikido의 모든 플랜에는 SCA, SAST, 시크릿 탐지, IaC, 클라우드 보안 태세, 컨테이너 스캔, DAST, 라이선스 스캔, SBOM 생성이 포함됩니다. SCA는 함수 수준 도달 가능성으로 노이즈를 줄이며, AutoFix는 패치된 버전으로 풀 리퀘스트를 엽니다. CI에서는 치명적 위험이 있는 풀 리퀘스트를 차단할 수 있으며, GitHub, GitLab, Jenkins, Bitbucket, CircleCI 등과 함께 작동합니다. CRACI는 현재 GitHub Actions만 지원하며, GitLab CI와 Jenkins는 로드맵에 있습니다.

Aikido는 또한 Safe Chain을 제공합니다. npm 및 PyPI 패키지 관리자 앞에서 로컬 프록시를 실행하여, 알려진 멀웨어가 포함된 패키지가 설치되기 전에 로컬과 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 UI에 표시됩니다.

CRACI는 작업을 직접 실행하므로 작업 중에 이그레스 정책을 적용할 수 있습니다. 정책은 기본 거부 또는 기본 허용이며, 24개의 내장 소프트웨어 소스 프리셋과 npm, PyPI, apt, apk, Go 프록시, Nix, Cargo, OCI 레지스트리, Git용 유형별 사용자 지정 소스를 제공합니다. 정책은 작업 시작 전에 검증되며 실패 시 차단(fail closed)됩니다. 스캐너는 위험한 패키지가 존재한다고 알려 줄 수 있습니다. 네트워크 정책은 빌드가 가서는 안 될 곳에 닿지 못하게 막습니다.

결정론적 빌드 증거

Aikido는 매니페스트와 잠금 파일로 종속성 뷰를 구성하고, 그 위에 AI 기반 악용 가능성 검사를 비롯한 분석을 더합니다. 작업의 우선순위를 정하는 합리적인 방법입니다.

CRACI의 SBOM은 추론한 것이 아닙니다. 패키지를 인식하는 프록시가 작업이 패키지 소스에서 가져온 항목을 기록하며, 종속성 증거는 CI 캐시와 함께 이동하므로 캐시에서 복원된 패키지도 집계됩니다. 각 SBOM은 작업별·캐시별로 자체 완전성을 명시합니다. Complete, Complete with connections, Incomplete, Unavailable, Not recorded 중 하나입니다. 추정치가 아니라 실제로 일어난 일의 기록이며, 어디에 빈틈이 있는지도 알려 줍니다.

이것이 중요한 이유는 정적 SBOM 도구들의 결과가 대부분의 생각보다 훨씬 다르며, 그 원인이 구조적이기 때문입니다. 각 도구는 서로 다른 파일 집합을 읽고 서로 다르게 해석하므로, 리포지토리에 무엇이 들어 있다고 판단되는지는 어떤 도구에 물었는지, 그 도구가 어떻게 구성되었는지에 달려 있습니다. express 5.2.1처럼 잠금 파일을 커밋하지 않는 프로젝트는 잠금 파일 리더에게 해석할 것을 전혀 주지 않습니다. CRACI는 디렉터리를 스캔하는 대신 빌드를 기록하므로 이런 기준으로 비교할 수 없습니다. 바로 그것이 요점입니다. 빌드 기록은 어떤 파일이 우연히 존재하는지에 좌우되지 않습니다.

API를 통한 출처 증명 데이터

CRACI는 작업이 가져온 항목을 바탕으로 CRACI의 러너 안에서 SBOM을 생성합니다. API는 SBOM, 네트워크 추적, 출처 증명을 반환합니다.

그 기록 위에 쌓은 컴플라이언스 성과

EU Cyber Resilience Act에서 어려운 부분은 각 릴리스에 무엇이 들어갔는지, 그리고 시간이 지나면서 그 취약점을 어떻게 추적하는지 보여 주는 것입니다. CRACI는 빌드와 리포지토리 전반의 취약점을 집계하고, 모니터링 중인 SBOM을 지속적으로 재평가합니다. SBOM은 취약점을 포함해 CycloneDX 또는 SPDX로 내보내며, API는 SBOM, 네트워크 추적, 출처 증명을 반환합니다. CRACI는 기업이 더 넓은 CRA 컴플라이언스 프로세스에 필요로 하는 소프트웨어 공급망 가시성과 증거의 상당 부분을 자동화합니다. CRA 컴플라이언스와 CRA 증거를 참고하세요.

어디에 무엇이 배포되었는지에 대한 인벤토리

CRACI의 인벤토리 뷰는 어떤 소프트웨어 버전이 어떤 제품에 배포되었는지 전 세계 범위에서 정확히 보여 줍니다. 새로운 취약점이 발견되면 릴리스 노트와 스프레드시트를 맞춰 보는 대신, 영향을 받는 버전을 실행하는 제품을 바로 확인할 수 있습니다.

각 제품이 맞는 경우

• 코드, 종속성, 클라우드, 실행 중인 앱을 하나의 도구로 다루고 싶거나, 현재 GitHub Actions 외의 CI 시스템을 사용하거나, 컴플라이언스의 초점이 애플리케이션 보안 발견 사항 기반의 SOC 2 또는 ISO 27001 보고라면 Aikido를 선택하세요.
• GitHub Actions에서 빌드하며, 각 빌드가 정확히 무엇을 가져왔는지 알고, 빌드 네트워크 접근을 통제하고, CRA 및 고객 감사를 위한 릴리스 증거를 보관해야 한다면 CRACI를 선택하세요.
• Aikido의 스캔과 풀 리퀘스트 게이트에 더해 CRACI의 빌드 런타임 통제와 증거가 필요하다면 둘 다 사용하세요. Aikido의 CI 검사와 Safe Chain은 워크플로의 단계로 실행되며, 이 단계들은 다른 단계와 마찬가지로 CRACI 러너에서 실행할 수 있습니다.