CRACI vs DIY SBOM 스택 | 직접 구축에 필요한 것

간단한 답

Syft 또는 Trivy, Grype, Dependency-Track, Cosign, Renovate로 구성한 DIY 스택은 라이선스가 무료이고, 어디서나 실행되며, 역량 있는 플랫폼 팀에게 완전한 통제권을 줍니다. CRACI는 각 빌드가 가져온 항목을 기록하고, 빌드가 연결할 수 있는 곳을 통제하며, 출시된 결과물을 모니터링하고, 증거를 내보내는 관리형 GitHub Actions 러너입니다. 차이는 기능보다는 SBOM이 어디서 나오는지, 그리고 도구 사이의 이음새를 누가 관리하는지에 있습니다. GitLab, Jenkins, Windows에서 빌드하거나 모든 것이 자사 인프라에서 실행되어야 한다면, 현재로서는 DIY를 권하는 것이 솔직한 답입니다.

스택의 구성

완전한 자체 구축 환경은 대개 7개 계층으로 이루어집니다. 각 계층은 저마다 유지 관리가 필요한 실제 프로젝트입니다.

생성. Syft("컨테이너 이미지와 파일 시스템에서 소프트웨어 자재 명세서(SBOM)를 생성"), Trivy, cdxgen("소스와 컨테이너 이미지에서" CycloneDX BOM을 만드는 OWASP 프로젝트), 또는 SPDX를 작성하며 명령줄에서 빌드 드롭 폴더, 패키지 이름, 버전, 공급자를 요구하는 Microsoft SBOM Tool.
매칭. Grype는 EPSS, KEV, 위험 점수와 함께 이미지, 파일 시스템, SBOM을 스캔합니다. OSV-Scanner는 잠금 파일, SBOM, 컨테이너 이미지를 OSV.dev와 매칭합니다.
관리. OWASP Dependency-Track은 CycloneDX SBOM을 수집해 장기간 모니터링합니다. API 서버에는 최소 2 GB RAM과 2 CPU 코어(권장 8 GB, 4코어)가 필요하며, 문서는 프로덕션 배포에 별도 데이터베이스를 갖춘 Docker Compose를 권장합니다.
서명. Cosign은 Fulcio를 통한 키리스 서명과 Rekor 투명성 로그로 이미지, 블롭, SBOM 증명에 서명합니다. GitHub 아티팩트 증명은 Sigstore를 기반으로 SLSA v1.0 Build Level 2 출처 증명을 제공합니다.
업데이트. Renovate나 Dependabot이 종속성을 최신 상태로 유지하는 풀 리퀘스트를 엽니다.
이그레스 제어. StepSecurity Harden-Runner는 GitHub Actions 작업의 아웃바운드 연결을 감사하거나 차단할 수 있습니다. Community 등급은 GitHub 호스팅 러너의 공개 리포지토리에 무료이며, 비공개 리포지토리와 셀프 호스팅 러너에는 Enterprise 등급이 필요합니다. 다른 방법은 셀프 호스팅 러너 주변에 자체 프록시와 방화벽 규칙을 두는 것입니다.
보고. 누군가 위의 모든 결과를 감사인, 고객 또는 CRA 기술 문서에 필요한 문서로 만들어야 합니다.

기능	CRACI	DIY 스택
빌드 실행	작업이 CRACI 러너에서 실행	도구가 CI의 단계로 실행
빌드에서 기록한 SBOM	캐시된 패키지를 포함해 관찰된 다운로드	사후에 파일로부터 재구성
SBOM의 완전성	작업과 캐시마다 명시	생성 도구, 설정, 먼저 설치했는지 여부에 따라 달라짐
러너의 이그레스 정책	기본 거부 또는 허용, 실패 시 차단(fail closed)	Harden-Runner 또는 자체 프록시
서명된 출처 증명	서명된 출처 증명 없음	Cosign 또는 GitHub 아티팩트 증명
출시된 SBOM 모니터링	모니터링 중인 SBOM을 지속적으로 재평가	Dependency-Track을 직접 호스팅하는 경우
포트폴리오 정책, VEX, 트리아지	트리아지, VEX, 라이선스 정책	Dependency-Track 정책과 VEX
CRA 증거와 보고서	CycloneDX 또는 SPDX 형식 SBOM, API를 통한 기록, CRA 통지 내용 준비, 보고서 내보내기는 없음	각 도구의 결과로 보고서를 직접 구성
다른 CI 시스템, Windows, macOS	현재 GitHub Actions의 Linux 지원. 다른 CI, Windows, macOS는 로드맵에 포함	생성 도구와 스캐너가 어떤 CI에서든 실행
고객 인프라에서 실행	현재 관리형. 고객 호스팅 러너는 로드맵에 포함(Enterprise)	직접 호스팅하는 오픈 소스 도구
비용	vCPU 분당 $0.002(2 vCPU는 $0.004), 초 단위 측정. 월 요금과 SBOM당 요금 없음	라이선스는 무료. 엔지니어링 시간, 호스팅, 유지 관리로 비용을 치름.

포함
일부 지원
미포함
로드맵에 포함

비용은 이음새에서 발생합니다

생성 도구를 고르는 것은 그 사각지대를 고르는 것입니다

여러 SBOM 생성 도구를 같은 리포지토리에 실행하면 그 안에 무엇이 들어 있는지에 대해 서로 다른 결과를 내놓습니다. 각 도구는 서로 다른 파일을 읽고 서로 다르게 해석하므로, 얻게 되는 구성 요소 목록은 프로젝트의 속성인 만큼이나 선택한 도구의 속성이기도 합니다. NTIA 공급자 필드는 같은 문제를 반대편에서 보여 줍니다. 대부분의 생성 도구에는 이 필드의 출처가 없으므로, 리포지토리에 무엇이 있든 빈 값으로 나옵니다.

이 도구들 중 고장 난 것은 없습니다. 각 도구는 무엇을 구성 요소로 볼지, 어떤 파일을 신뢰할지에 대해 서로 다른, 문서화된 결정을 내립니다. 하지만 DIY 스택은 선택한 도구의 결정을 그대로 물려받으며, 이후의 파이프라인(매칭, 모니터링, 보고)은 첫 단계만큼만 완전할 수 있습니다.

연결 작업은 직접 해야 합니다

각 도구에는 고유한 릴리스 주기, 취약점 데이터베이스, 출력 형식, 구성이 있습니다. 누군가는 버전을 고정하고, 데이터베이스를 업데이트하고, Dependency-Track과 그 데이터베이스를 패치하고, 서명 ID를 교체하고, 어떤 SBOM을 어디로 보낼지 결정하고, 어떤 단계가 조용히 더 적은 결과를 내기 시작할 때 이를 알아차려야 합니다. 이는 일회성 설정이 아니라 지속적인 플랫폼 작업입니다.

도구도 종속성입니다

보안 도구는 시크릿에 접근할 수 있는 상태로 빌드 안에서 실행되므로 위협 모델에 포함되어야 합니다. 2026년 3월 Aqua Security는 탈취된 자격 증명이 악성 Trivy 릴리스를 게시하고, 대부분의 trivy-action 태그를 약 12시간 동안 자격 증명을 훔치는 코드로 강제 푸시하는 데 사용된 경위를 설명하는 보안 권고를 발표했습니다. Aqua는 이를 공개적으로 문서화했으며, 이는 널리 쓰이는 어떤 프로젝트에도 일어날 수 있는 일이었습니다. 이 사례는 러너의 이그레스 제어가 왜 중요한지 보여 줍니다. 기본 거부 정책은 침해된 단계가 데이터를 보낼 수 있는 곳을 제한하지만, 모든 경로를 막지는 못합니다(이 권고에는 피해자의 GitHub 계정에 리포지토리를 만드는 대체 경로도 설명되어 있습니다).

DIY가 맞는 경우

CI가 GitHub Actions가 아닌 경우. CRACI는 현재 GitHub Actions만 지원하며, GitLab CI와 Jenkins는 로드맵에 있습니다. GitLab, Jenkins, CircleCI 팀은 위의 모든 오픈 소스 도구를 실행할 수 있습니다.
Windows나 macOS에서 빌드하는 경우. CRACI 러너는 현재 Linux(x86-64 및 ARM64)이며, Windows와 macOS는 로드맵에 있습니다.
모든 것이 자사 인프라에서 실행되어야 하는 경우. CRACI는 현재 유럽 인프라에서 관리형 러너를 운영하며, 고객 호스팅 러너는 Enterprise용으로 로드맵에 있습니다.
스택을 직접 소유하려는 플랫폼 팀이 있는 경우. 스택 유지 관리가 의도적인 투자이고 이미 Dependency-Track을 잘 운영하고 있다면 그대로 유지하세요.
설문지 하나에 SBOM 하나만 필요한 경우. 중요도가 낮고 가끔 있는 요청이라면 생성 도구를 수동으로 실행하는 것으로 충분할 수 있습니다.

CRACI가 대체하는 것과 대체하지 않는 것

CRACI는 빌드에서 출발해 여러 계층을 한곳에서 다룹니다. runs-on을 craci로 바꾸면 실행 내역은 계속 GitHub UI에 표시됩니다. 패키지를 인식하는 프록시가 각 작업이 npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk, Git 소스와 다운로드 프리셋에서 가져오는 항목을 기록하며, 종속성 증거는 CI 캐시와 함께 전달됩니다. 모든 작업과 캐시에는 Complete, Complete with connections, Incomplete, Unavailable, Not recorded 중 하나의 완전성 상태가 부여됩니다.

생성: 기록된 빌드로부터 전이적 종속성을 포함한 CycloneDX 및 SPDX 생성.
모니터링: 빌드와 리포지토리 전반에서 발견 사항을 집계하고, 모니터링 중인 SBOM을 지속적으로 재평가.
출처 증명: API가 SBOM, 네트워크 추적, 출처 증명을 반환. CRACI는 출처 증명에 서명하지 않습니다.
이그레스: 24개의 내장 소프트웨어 소스 프리셋을 갖춘 작업별 정책으로, 작업 시작 전에 검증되고, 실패 시 차단(fail closed)되며, 위반 시 알림.
내보내기: 취약점을 포함해 CycloneDX 또는 SPDX 형식의 SBOM. 보고서 내보내기는 없음.

모든 것을 대체하지는 않습니다. 패키지 차단 목록은 로드맵에 있습니다. 서명된 출처 증명이 필요하다면 Cosign이나 GitHub 아티팩트 증명을 유지하세요. 취약한 종속성뿐 아니라 모든 종속성을 최신 상태로 유지하려면 Renovate나 Dependabot이 여전히 유용합니다. 보안 팀이 Dependency-Track에서 작업한다면, CRACI의 REST API로 CycloneDX SBOM을 내려받아 Dependency-Track에 넣을 수 있습니다.

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

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

Cyber Resilience Act 대응

CRA는 제조사에게 "소프트웨어 자재 명세서를 작성하는 것을 포함해, 디지털 요소가 있는 제품에 포함된 취약점과 구성 요소를 식별하고 문서화할 것"을 요구합니다(부속서 I, 제II부). 실제로 악용되고 있는 취약점의 보고 의무는 2026년 9월부터 적용되며, 최초 통지는 24시간 이내에 해야 합니다. DIY 스택도 누군가 각 릴리스에서 SBOM까지 이어지는 증거 흐름을 책임진다면 이를 지원할 수 있습니다. CRACI는 기업이 더 넓은 CRA 컴플라이언스 프로세스에 필요한 소프트웨어 공급망 가시성과 증거의 상당 부분을 자동화하며, CRA 통지의 내용을 준비합니다. 제출은 고객이 직접 합니다. 어떤 방식을 택하든, 무엇이 실제로 악용되고 있는지 판단하는 일은 팀의 몫으로 남습니다. CRA 컴플라이언스와 빌드 시점 SBOM 생성을 확인하세요.