CRACI vs Cybeats SBOM Studio

간단한 답변

Cybeats SBOM Studio는 스스로를 "SBOM 기록 시스템(system of record)"이라고 부릅니다. 고객사 제품과 공급업체의 SBOM을 저장하고, 취약점 및 라이선스 인텔리전스로 보강하며, 지속적으로 모니터링하고, 고객 및 규제 기관과 공유합니다. CRACI는 각 작업이 실제로 가져온 종속성을 기록하고 그 기록으로 완전성 상태가 표시된 SBOM을 생성하는 GitHub Actions 러너입니다.

기록 시스템의 정확도는 입력되는 데이터의 정확도를 넘을 수 없습니다. SBOM Studio는 다른 도구가 생성한 SBOM을 관리합니다. CRACI는 빌드에서 SBOM을 생성하고 모니터링하므로, CI, SBOM, 취약점 추적이 하나의 제품에서 이루어집니다.

한눈에 보기

Cybeats의 강점

• 모든 SBOM을 위한 하나의 관리 공간. SBOM Studio는 ICS 및 OT, 의료 기기, 통신, 자동차, 금융 서비스 분야의 제품 보안 팀을 위해 만들어졌습니다. "제품과 공급업체 전반의 모든 SBOM에 대한 하나의 관리된 단일 진실 공급원"을 제공합니다.
• 폭넓은 형식 지원. 가져오기와 내보내기 모두 SPDX 2.2부터 3.0.1까지, CycloneDX 1.2부터 1.7까지 지원합니다. VEX, AIBOM, CBOM, HBOM도 처리합니다.
• 입구에서의 품질 관리. SBOM Quality Score는 가져오기 전에 파일을 검증하고, 표준에 맞게 올바른 형식인지 확인하며, SBOM이 기준에 미달하는 이유를 기록합니다.
• 보강과 모니터링. 모든 구성 요소를 취약점 인텔리전스와 지속적으로 매칭하며, 정책 기반 알림, 어떤 취약점이 제품에 영향을 주는지 전달하는 VEX, OSS 및 COTS 라이선스 분석을 제공합니다.
• 공유. Transparency Exchange API를 포함해 고객과 SBOM 및 VEX를 통제된 방식으로 교환합니다. 별도 제품인 SBOM Consumer는 받은 공급업체 SBOM을 검증하고 모니터링합니다.

공급업체 SBOM 수집, 라이선스 분석, 호스팅 방식의 공유는 모두 현재 SBOM Studio가 CRACI보다 더 많은 기능을 제공하는 영역입니다. 여러 제품과 공급업체에 걸친 SBOM 프로그램 운영이 팀의 업무라면, SBOM Studio는 바로 그 목적으로 만들어졌습니다.

CRACI의 차별점

빌드에서 SBOM을 직접 생성

SBOM Studio는 SBOM을 수집합니다. 생성에 대해서는 Cybeats가 자사 Marketplace를 안내하며, 이곳에는 바이너리 구성 분석과 SBOM 생성 도구 공급업체가 모여 있습니다. 결국 기록 시스템에 들어가는 구성 요소 목록은 여전히 어떤 형태의 스캐너에서 나옵니다.

CRACI는 작업을 실행합니다. runs-on을 craci로 바꾸면 패키지를 인식하는 프록시가 빌드 중 패키지 소스로 가는 트래픽을 기록합니다. 대상은 npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk, Git 소스와 다운로드 프리셋입니다. 종속성 증거는 CI 캐시와 함께 전달되므로, 캐시에서 복원된 패키지도 기록에 남습니다. SBOM에는 빌드가 실제로 사용한 모든 전이적 종속성이 포함됩니다.

형식이 올바르다고 완전한 것은 아닙니다

품질 점수는 SBOM이 표준을 따르고 필요한 필드를 갖추었는지 확인할 수 있습니다. 하지만 생성 도구가 아예 보지 못한 것은 알려 줄 수 없습니다. 생성 도구마다 읽는 파일이 다르고 해석 방식도 다르기 때문에 결과가 구조적으로 서로 다르며, 형식이 올바른 문서라도 거기서 빠진 종속성이 애초에 도구 앞에 있었는지는 알려 주지 않습니다. NTIA 공급자 필드가 좋은 예입니다. 이 필드는 있음 또는 없음으로 검증되지만, 대부분의 생성 도구는 이 값을 채울 출처가 없습니다. CRACI는 빌드를 기록할 뿐 디렉터리를 스캔할 수 없으므로 이런 방식으로 점수를 매길 수 없습니다.

CRACI는 기록 자체를 근거로 작업과 캐시마다 완전성을 Complete, Complete with connections, Incomplete, Unavailable, Not recorded 중 하나로 표시합니다. 기록의 빈틈은 추측이 아니라 알려진 사실입니다.

제어와 출처 증명

CRACI는 작업을 실행하므로 네트워크 이그레스 정책을 적용합니다. 기본 거부 또는 기본 허용이며, 24개의 기본 제공 소프트웨어 소스 프리셋과 유형별 사용자 지정 소스를 제공하고, 작업 시작 전에 검증되며 실패 시 차단됩니다. API는 SBOM, 네트워크 추적, 출처 증명을 반환합니다.

모니터링

CRACI는 모니터링 중인 SBOM을 지속적으로 재평가하고, 빌드와 리포지토리 전반의 취약점을 집계합니다.

어디에 무엇이 배포되었는지 보여 주는 인벤토리

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

SBOM Studio를 CRACI로 대체하기

GitHub Actions를 사용하는 소프트웨어 팀이라면, CRACI는 팀의 자체 제품에 대해 SBOM 기록 시스템이 해야 할 일을 처리합니다. 각 빌드에서 SBOM을 생성하고, 새로운 취약점이 공개될 때마다 모니터링 중인 SBOM을 계속 재평가하며, 빌드와 리포지토리 전반의 발견 사항을 집계하고, 보안 팀이 이를 분류해 수정 담당 팀에 할당할 수 있게 합니다. 공급업체 SBOM도 추가할 수 있으므로 외부에서 구매한 구성 요소도 자체 빌드와 함께 모니터링됩니다. 별도로 실행할 생성 도구도, 유지할 가져오기 단계도 없습니다.

포기하게 되는 것도 분명히 알아 두셔야 합니다. SBOM Studio는 OSS 및 COTS 라이선스 분석, AIBOM, CBOM, HBOM을 처리하고, 가져올 때 SBOM 품질을 점수화하며, Transparency Exchange API로 고객과 SBOM을 공유합니다. CRACI는 기록한 선언된 라이선스에 라이선스 정책을 적용하지만, 나머지 기능은 현재 제공하지 않습니다. 여러 제품, 공급업체, 고객에 걸친 SBOM 프로그램 운영이 업무라면 SBOM Studio는 바로 그 목적으로 만들어졌습니다.

Cyber Resilience Act 대응

Cybeats는 CRA를 직접 다룹니다. 이 규정을 "현재 SBOM 도입의 주요 동인"이라고 부르며, SBOM Studio가 "규정을 준수하는 최신 SBOM을 생성"해 제조사가 제품 수명 주기 전반에서 소프트웨어 투명성을 유지하도록 돕는다고 설명합니다. 규정 가이드에는 24시간, 72시간, 14일 보고 일정이 정리되어 있습니다.

CRA의 보고 의무는 2026년 9월 11일부터 CRA Single Reporting Platform을 통해 적용되며, 주요 조항은 2027년 12월 11일부터 적용됩니다. 24시간 이내 조기 경보는 영향받는 구성 요소가 어떤 릴리스에 포함되었는지 빠르게 파악하는 것, 그리고 그 정보를 알려 주는 인벤토리를 신뢰할 수 있는지에 달려 있습니다. CRACI의 API는 SBOM, 네트워크 추적, 출처 증명을 반환하며, SBOM은 취약점을 포함해 CycloneDX 또는 SPDX로 내보낼 수 있습니다.

CRACI는 기업이 더 넓은 CRA 컴플라이언스 프로세스에 필요로 하는 소프트웨어 공급망 가시성과 증거의 상당 부분을 자동화합니다. 어느 제품도 그것만으로 제조사의 컴플라이언스를 충족시켜 주지는 않습니다. CRA의 요구 사항, CRACI를 활용한 CRA 컴플라이언스, 산업용 IoT를 참고하세요.

두 가지보다 많은 도구를 비교하고 계신가요? Cybeats 대안에서 9가지 옵션을 나란히 비교합니다.