CRACI vs Sonatype

요약

Sonatype의 강점은 오픈 소스 거버넌스입니다. 어떤 구성 요소를 허용할지 결정하는 정책, 리포지토리에서 불량 패키지를 막는 방화벽, 애플리케이션에 무엇이 들어갔는지 알려 주는 분석이 있습니다. CRACI는 GitHub Actions와 호환되는 CI 러너로, 빌드가 가져오는 모든 외부 종속성을 기록하고 그 기록에서 SBOM, 출처 증명, 컴플라이언스 증거를 생성합니다. Sonatype은 스캐너이자 게이트키퍼입니다. CRACI는 기록기이며, 정책 게이트로 발견 사항에 따라 빌드를 차단할 수도 있습니다. 둘 다 필요한 팀은 대부분 두 제품을 나란히 운영합니다.

Sonatype 제품 구분

Sonatype은 여러 제품을 판매하며, 이 비교에서는 제품 이름이 중요합니다.

• Sonatype Lifecycle은 소프트웨어 구성 분석(SCA) 및 정책 제품으로, 셀프 호스팅 또는 SaaS로 실행됩니다.
• Sonatype Repository Firewall은 정책을 통과하지 못한 구성 요소가 리포지토리에 들어오기 전에 차단하고 격리합니다. Sonatype Nexus Repository용으로 설계되었습니다. Sonatype Firewall Pro는 JFrog Artifactory, Cloudsmith, GitHub Packages 같은 다른 리포지토리 관리자에서 npm, Maven, PyPI, NuGet을 지원합니다.
• Sonatype SBOM Manager는 VEX 워크플로와 함께 SBOM을 가져오고, 모니터링하고, 공유합니다.

제품 구성은 바뀌고 있습니다. Sonatype의 요금 페이지에 따르면 이제 Lifecycle의 모든 기능이 Sonatype Guide에 포함되며, 신규 고객은 SCA와 거버넌스를 위해 Guide를 구매하고, Guide에는 SBOM Manager의 컴플라이언스 기능도 포함됩니다.

한눈에 보기

Sonatype의 강점

대규모 정책 관리. Lifecycle은 18개의 기본 정책과 보안, 법률, 아키텍처 규칙을 다루는 30개 이상의 사용자 지정 가능한 제약 조건을 제공합니다. 라이선스 정책은 2,000개 이상의 오픈 소스 라이선스를 다룹니다. 도달 가능성, 호환성을 깨는 변경, 업그레이드 가능 여부 데이터로 발견 사항의 우선순위를 정하며, 권장 업그레이드가 담긴 Golden Pull Request를 열 수 있습니다.

빌드 결과물 분석. Lifecycle 통합은 기본적으로 Advanced Binary Fingerprinting을 사용합니다. 빌드 후 애플리케이션에 포함된 모든 것을 내장 종속성까지 검사하며, 이름이 바뀌거나 수정된 구성 요소도 식별할 수 있습니다. 그다음에야 잠금 파일과 매니페스트로 넘어갑니다. 모든 스캔 보고서는 CycloneDX 또는 SPDX SBOM으로 내보낼 수 있습니다.

입구에서 불량 패키지 차단. Repository Firewall은 다운로드 시점에 보안, 라이선스, 품질 기준을 적용하고 의심스러운 구성 요소를 격리합니다. CRACI에는 현재 이에 상응하는 기능이 없습니다. 패키지 차단 목록은 로드맵에 있습니다.

어떤 파이프라인에도 적용. Sonatype은 Jenkins, GitHub Actions, GitLab CI, Azure DevOps, Bamboo와 통합되며, Maven, Gradle, 그리고 그 밖의 CI 서버를 위한 CLI도 제공합니다. CRACI는 현재 GitHub Actions만 지원하며, GitLab CI와 Jenkins는 로드맵에 있습니다.

CRACI의 차이점

결과물을 분석하는 대신 빌드를 기록

바이너리 핑거프린팅은 완성된 애플리케이션 안에 무엇이 있는지 알려 줍니다. 빌드가 그 과정에서 무엇을 내려받았는지는 알려 주지 않습니다. 컴파일러와 도구 체인, 설치 스크립트, 베이스 이미지, curl로 가져온 릴리스 바이너리, 캐시에서 복원된 패키지가 그렇습니다. CRACI는 러너이기 때문에 이를 볼 수 있습니다. 패키지를 인식하는 프록시가 작업이 실행되는 동안 패키지 소스로 가는 트래픽을 관찰하며, npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk, Git 소스와 소스 또는 다운로드 프리셋을 다룹니다. 종속성 증거는 CI 캐시와 함께 전달되므로 캐시된 패키지도 계속 파악됩니다.

모든 SBOM은 작업별 및 캐시별로 자체 완전성을 Complete, Complete with connections, Incomplete, Unavailable, Not recorded 중 하나로 명시합니다. 기록에 공백이 있으면 알 수 있습니다.

빌드가 접근할 수 있는 대상을 통제

Repository Firewall은 리포지토리를 통해 들어오는 것을 관리합니다. CRACI 이그레스 정책은 빌드가 접근할 수 있는 대상 전체를 관리합니다. 정책은 기본 거부 또는 기본 허용이며, 24개의 기본 제공 소프트웨어 소스 프리셋과 npm, PyPI, apt, apk, Go 프록시, Nix, Cargo, OCI 레지스트리, Git용 유형별 사용자 지정 소스가 있습니다. 작업 시작 전에 검증되며 실패 시 차단합니다. 두 제품을 함께 쓰면 빌드 작업이 승인한 소스에서만 패키지를 가져오고, 그 소스는 허용한 패키지만 제공하도록 보장할 수 있습니다.

출시된 제품을 계속 지켜봄

API는 SBOM, 네트워크 추적, 출처 증명을 반환합니다. CRACI는 출처 증명에 서명하지 않습니다. CRACI는 빌드와 리포지토리 전반의 취약점을 집계하고 모니터링 중인 SBOM을 계속 재평가합니다.

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

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

둘 다 사용해야 할 때

• 이미 Nexus Repository와 Firewall을 운영하는 경우. 게이트로 계속 유지하세요. CRACI를 추가하면 모든 빌드에 가져온 것의 기록이 남고, 이그레스 정책으로 빌드가 승인된 소스만 사용하게 할 수 있습니다.
• 법무 팀이 Lifecycle 라이선스 정책에 의존하는 경우. 그대로 유지하세요. CRACI는 SBOM 내보내기에 선언된 라이선스 메타데이터를 포함하며, 라이선스 정책도 적용합니다.
• SBOM Manager에 SBOM을 모으는 경우. SBOM Manager는 CRACI가 내보내는 것과 같은 형식인 CycloneDX와 SPDX를 가져오므로, 빌드 시점 SBOM을 이미 관리 중인 SBOM과 나란히 둘 수 있습니다.
• 파이프라인이 Jenkins나 Azure DevOps에 있는 경우. 현재는 Sonatype이 적합합니다. CRACI를 사용하려면 먼저 해당 파이프라인을 GitHub Actions로 옮겨야 하며, Jenkins는 로드맵에 있습니다.

Cyber Resilience Act 대응

Sonatype은 CRA 사용자 가이드와 CRA 체크리스트를 게시하며, SBOM Manager를 CRA 제품으로 내세웁니다. 가이드는 SBOM의 알려진 취약점을 보고하기 위한 VEX 파일 생성과, 보안 업데이트 배포를 위한 업데이트 사이트로서의 Nexus Repository를 강조합니다.

CRACI는 빌드에서부터 증거 측면을 다룹니다. 완전성이 명시된 릴리스별 SBOM, 출처 증명, 지속적인 취약점 모니터링, CycloneDX 또는 SPDX 형식의 SBOM 내보내기입니다. 기업이 더 넓은 CRA 컴플라이언스 프로세스에 필요로 하는 소프트웨어 공급망 가시성과 증거의 상당 부분을 자동화합니다. 어느 도구도 그 자체만으로 제품을 규정에 맞게 만들지는 않습니다. CRA 컴플라이언스와 CRA란 무엇인가를 참조하세요.

Sonatype과 함께 CRACI 추가하기

CRACI는 GitHub Actions가 아니라 러너를 대체합니다. 워크플로에서 runs-on을 craci로 바꾸면 실행 내역은 계속 GitHub UI에 표시됩니다. Sonatype 단계는 워크플로에 그대로 남습니다. 릴리스 파이프라인 하나로 시작해 CRACI의 SBOM을 Lifecycle 보고서와 비교하고, 한쪽에서만 보인 것을 살펴보세요.