CRACI vs Dependency-Track

Dependency-Track의 강점

OWASP Dependency-Track은 구성 요소 분석에 탁월한 선택입니다. Apache 2.0 라이선스의 오픈 소스이며, 포트폴리오에 있는 모든 애플리케이션의 모든 버전에 걸쳐 구성 요소 사용을 추적하고, National Vulnerability Database와 GitHub Advisories를 포함한 여러 소스에서 취약점 정보를 가져옵니다. 정책 엔진은 보안, 라이선스, 운영 규칙을 다루며, CycloneDX VEX 문서를 수집하고 생성합니다. API 우선 설계로 CI/CD에 잘 맞습니다. 파이프라인은 SBOM을 /api/v1/bom에 업로드합니다.

규제 산업의 팀들은 투명하고, 셀프 호스팅이 가능하며, 표준 형식을 중심으로 구축되었다는 점에서 이 도구를 선호합니다. 약점은 분석이 아닙니다. 분석에 들어가는 입력입니다.

분석은 입력에 달려 있습니다

Dependency-Track은 SBOM을 수집할 뿐 생성하지 않습니다. 모든 발견 사항, 정책 위반, 포트폴리오 뷰는 파이프라인이 보내는 SBOM에 달려 있습니다. SBOM에 종속성이 누락되면 Dependency-Track은 이를 표시할 수 없습니다. 두 생성기의 결과가 다르면 Dependency-Track은 업로드된 쪽을 보여 줄 뿐입니다.

실제로 SBOM 생성기들의 결과는 크게 다르며, 그 이유는 각 도구의 문서에 나와 있습니다.

• 공통 기반이 없습니다. 각 생성기는 무엇을 구성 요소로 볼지, 어떤 파일을 신뢰할지를 스스로 결정하므로, 두 도구를 같은 리포지토리에 적용하면 일부는 겹치지만 서로 다른 목록이 나옵니다.
• 당연한 것을 놓칩니다. 잠금 파일에서 종속성을 해석하는 도구는 express 5.2.1처럼 잠금 파일을 커밋하지 않는 리포지토리에서는 해석할 것이 없습니다. 그래도 GitHub Actions나 워크플로 파일처럼 그 밖에 인식하는 것으로 목록을 반환할 수는 있습니다.
• 설정에 따라 크게 달라집니다. Syft는 스캔 유형에 따라 cataloger를 선택하므로, 플래그 하나로 같은 체크아웃에서 같은 버전의 같은 도구가 보고하는 내용이 바뀝니다.
• 매니페스트가 없으면 SBOM도 없습니다. 종속성 매니페스트가 전혀 없는 리포지토리는 파일 기반 스캐너에 아무런 근거를 주지 못하며, 이때 각 도구가 반환하는 결과는 프로젝트보다 도구에 대해 더 많은 것을 말해 줍니다.
• 빈약한 메타데이터. 대부분의 생성기에는 NTIA supplier 필드의 출처가 없으므로, 리포지토리에 무엇이 있든 이 필드는 비어 있게 됩니다.

CRACI는 이런 방식으로 비교할 수 없습니다. 디렉터리를 스캔하는 대신 빌드를 기록하므로 같은 방식으로 실행할 수 없기 때문입니다. 요점은 이 도구들 중 어느 것이 나쁘다는 것이 아닙니다. 리포지토리의 정적 스캔은 빌드가 사용할 것에 대한 추정치이며, 그 추정치는 도구, 설정, 존재하는 파일에 따라 달라진다는 것입니다.

CRACI가 출발점에서 바꾸는 것

SBOM은 빌드에서 나옵니다

CRACI는 GitHub Actions 호환 러너입니다. runs-on을 craci로 변경하면 작업이 CRACI의 격리된 가상 머신에서 실행됩니다. 각 작업 중 패키지를 인식하는 프록시가 패키지 소스로 향하는 트래픽을 기록합니다. npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk, Git 소스와 다운로드 프리셋이 대상입니다. 종속성 증거는 CI 캐시와 함께 이동하므로 캐시에서 복원된 패키지도 기록에 남습니다. CycloneDX 또는 SPDX 형식의 SBOM에는 빌드가 실제로 사용한 모든 전이적 종속성이 포함됩니다.

불완전할 때 알려 줍니다

모든 CRACI SBOM에는 작업별·캐시별 완전성 상태가 표시됩니다. Complete, Complete with connections, Incomplete, Unavailable, Not recorded 중 하나입니다. 각 SBOM이 완전한 기록인지, 빈틈이 있는지 알 수 있습니다. 감사인이 인벤토리가 완전하다는 것을 어떻게 아느냐고 물을 때 이것이 중요합니다.

빌드 안에서 SBOM을 기록합니다

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

빌드가 접근할 수 있는 대상을 제어합니다

CRACI는 작업을 직접 실행하므로 네트워크 이그레스 정책을 적용할 수 있습니다. 기본 거부 또는 기본 허용이며, 24개의 내장 소프트웨어 소스 프리셋과 유형별 사용자 지정 소스를 제공합니다. 정책은 작업 시작 전에 검증되며 실패 시 차단(fail closed)됩니다. Dependency-Track은 구성 요소가 위험하다는 것을 사후에 알려 줄 수 있고, 이그레스 정책은 애초에 빌드가 가져올 수 있는 소스를 제한합니다.

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

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

Dependency-Track을 CRACI로 대체하기

CRACI는 예전에 생성기와 Dependency-Track이 나눠 맡던 작업의 양쪽을 모두 다룹니다. 빌드에서 SBOM을 생성하고, 새 취약점이 공개될 때마다 모니터링 중인 SBOM을 계속 재평가하며, 빌드와 리포지토리 전반의 발견 사항을 집계하고, 보안 팀이 이를 분류하여 각각을 수정 담당 팀에 전달할 수 있게 합니다. 유지 관리할 업로드 단계도, 운영할 서버도 없습니다.

포기하게 되는 것도 분명히 알아 두세요. Dependency-Track의 정책 엔진은 성숙합니다. CRACI에는 빌드를 차단하는 정책 게이트와 라이선스 정책이 있으며, 코멘트와 임계값 알림은 로드맵에 있습니다. Dependency-Track은 또한 오픈 소스이며 셀프 호스팅이 가능한 반면, CRACI는 현재 관리형 서비스이며 고객 호스팅 러너는 Enterprise용으로 로드맵에 있습니다. 이러한 점이 인벤토리의 품질보다 중요하다면 Dependency-Track을 계속 사용하세요.

규제 산업에서 이것이 중요한 이유

EU Cyber Resilience Act에 따라 제조업체는 각 제품 릴리스에 무엇이 들어 있는지 파악하고 그 안의 취약점을 처리해야 하며, 적극적으로 악용되는 취약점에 대한 보고 의무는 2026년 9월부터 시작됩니다. SBOM이 구성 요소를 놓쳐서 보이지 않는 취약점도 여전히 귀사의 취약점입니다.

CRACI는 기업이 더 넓은 CRA 컴플라이언스 프로세스에 필요로 하는 소프트웨어 공급망 가시성과 증거의 상당 부분을 자동화하며, 취약점을 포함한 SBOM을 CycloneDX 또는 SPDX로 내보냅니다. 인벤토리와 모니터링은 각 릴리스가 무엇으로 빌드되었는지에 대한 같은 기록에서 나옵니다. CRA 컴플라이언스, 산업용 IoT, 통신을 확인하세요.