비교
이미 종속성을 스캔하고 계십니다. 스캐너가 볼 수 없는 것은 이것입니다.
SCA 도구와 SBOM 생성기는 사용할 가치가 있습니다. 다만 이들은 한 가지 설계 방식을 공유합니다. 사후에 파일로부터 구성 요소 목록을 재구성한다는 것입니다. CRACI는 빌드가 실행되는 동안 이를 기록합니다.
업데이트
현재 스택이 잘하는 것
SCA와 SBOM 생성을 이미 구성했다면 조직 차원의 어려운 작업은 이미 마친 셈입니다. 종속성이 추적되고, 보안 권고가 개발자에게 전달되며, 누군가 요청하면 건넬 파일이 있습니다. 그대로 유지하세요.
- GitHub의 dependency graph와 Dependabot은 많은 팀에서 기본으로 켜져 있습니다. GitHub는 dependency graph를 "리포지토리에 저장된 매니페스트 및 잠금 파일과, dependency submission API를 통해 리포지토리에 제출된 모든 종속성의 요약"이라고 설명합니다. Dependabot 알림은 이를 기반으로 하며, 새 보안 권고가 게시되거나 dependency graph가 변경되면 알려 줍니다.
-
Snyk 같은 상용 SCA도 SBOM을 생성합니다.
snyk sbom명령은 매니페스트 파일과 잠금 파일을 읽어 CycloneDX 또는 SPDX를 출력합니다. 2026년 9월 기준으로 Snyk는 이 기능을 "Snyk Enterprise 플랜 고객에게만 제공된다"고 문서화하고 있습니다. - Syft, Trivy, cdxgen 같은 오픈 소스 생성기는 무료이고 빠르며 CI에 추가하기 쉽습니다. Syft는 스스로를 "컨테이너 이미지와 파일 시스템으로부터 SBOM(Software Bill of Materials)을 생성하는" 도구라고 소개합니다.
이러한 도구는 풀 리퀘스트에 대한 빠른 피드백, 폭넓은 생태계 지원, 개발자에게 익숙한 수정 워크플로에서 가장 강력합니다. CRACI는 현재 이를 대체하지 않습니다. CRACI의 취약점 추적은 빌드와 리포지토리 전반의 발견 사항을 집계하고, 새 취약점이 나타나면 모니터링 중인 SBOM을 재평가합니다. 보안 팀은 발견 사항을 분류하고 담당 팀에 전달할 수 있습니다. 정책 게이트로 빌드를 차단할 수 있으며, 취약점 웹훅은 로드맵에 있습니다.
스캐너와 기록기
위의 모든 도구는 스캐너입니다. 소스 트리, 잠금 파일 또는 컨테이너 이미지를 지정하면 무엇이 들어갔는지 추론합니다. 파일이 전체 내용을 말해 줄 때는 잘 작동합니다. 그렇지 않을 때는 어려워집니다.
- 리포지토리에 잠금 파일이 없어 설치 시점에 버전이 결정됩니다.
- 빌드가 어떤 매니페스트에도 언급되지 않은 CI 캐시에서 패키지를 복원합니다.
- 빌드 단계가 도구, OS 패키지 또는 바이너리를 직접 다운로드합니다.
- npm 설치 훅이나 Rust 빌드 스크립트가 설치 중에 추가 코드를 가져옵니다. Shai-Hulud 웜이 사용한 경로입니다.
- 컨테이너 빌드가 베이스 이미지와 운영 체제 레이어를 가져오는데, 어떤 언어 잠금 파일에도 나열되지 않습니다.
- 출시하는 결과물이 컴파일된 바이너리이고, 그 옆의 매니페스트에는 거의 아무것도 나열되어 있지 않습니다.
CRACI는 기록기입니다. 트래픽을 직접 보며, 스캐너는 그렇지 못합니다. CRACI는 자사의 GitHub Actions
호환 러너에서 빌드를 실행하고, 패키지를 인식하는 프록시가 작업 실행 중 패키지 소스로 향하는 트래픽을 관찰하므로
이렇게 숨겨진 종속성이 SBOM에 포함됩니다. 캐시에서 복원된 패키지는 증거를 그대로
이어받습니다. craci scan ./dir 명령은 없습니다. 사후에 디렉터리를 스캔하는 단계야말로
CRACI가 없애기 위해 존재하는 단계이기 때문입니다.
스캔 결과를 좌우하는 것
스캐너 출력은 도구와 그 도구가 무엇을 대상으로 하는지에 따라 달라집니다. Syft, Trivy, cdxgen, Microsoft SBOM Tool, GitHub의 dependency graph 내보내기, Socket CLI는 각자 읽을 수 있는 것을 바탕으로 목록을 만들어 냅니다. 아래 패턴은 이 도구들의 문서에 설명된 작동 방식에서 나온 것입니다.
모든 도구가 찾아내는 구성 요소는 없습니다
각 생성기는 무엇을 구성 요소로 볼지, 어떤 파일을 신뢰할지를 스스로 결정하므로, 같은 체크아웃에서도 도구마다 다른 목록이 나옵니다. GitHub의 dependency graph 내보내기는 또 다르게 작동합니다. 스캐너가 읽는 파일이 아니라 GitHub가 리포지토리에 대해 알고 있는 정보로 만들어지며, 고정된 커밋이 아니라 기본 브랜치를 읽습니다.
잠금 파일이 없으면 종속성도 없습니다
Express 5.2.1은 잠금 파일을 커밋하지 않습니다. 깨끗한 체크아웃을 대상으로 하면, 잠금 파일이나 설치된 트리에서
종속성을 해석하는 생성기는 그 어느 것도 가지고 있지 않으므로 package.json에 선언된 npm 종속성이
하나도 문서에 들어가지 않습니다. 여기서 고장 난 도구는 없습니다. SBOM에 종속성이 하나라도 포함될지를 결정하는
변수는 도구가 아닙니다. 누군가 먼저 설치를 실행했는지 여부입니다.
플래그 하나가 답을 바꿉니다
Syft의 기본 디렉터리 스캔은 디스크에 설치된 것이 아니라 프로젝트가 선언한 것을 보고합니다. 같은 express 릴리스를 설치한 체크아웃에서는 cataloger 플래그 하나가 설치된 npm 패키지가 목록에 나타날지 말지를 결정합니다. 같은 도구, 같은 버전, 같은 트리인데도 그렇습니다.
제품이 바이너리인 경우
v2.1.259 시점의 anthropics/claude-code 리포지토리에는 어떤 종류의 종속성 매니페스트나 잠금 파일도 없습니다.
게시된 npm 패키지는 런타임 종속성을 0개로 선언하며, 8개의 플랫폼 패키지를 통해 사전 빌드된 네이티브 바이너리를
감쌉니다. @openai/codex 0.149.1도 같은 구조입니다. 매니페스트 리더가 설명할 수 있는 것은 거의 없는
반면 실제로 실행되는 프로그램은 컴파일된 바이너리이므로, 각 도구가 반환하는 결과는 프로젝트보다 도구에 대해 더
많은 것을 말해 줍니다.
같은 패키지, 다른 버전
두 도구가 같은 것을 찾더라도 그것이 무엇인지에 대해 항상 일치하지는 않습니다. 한 도구는 GitHub Action을 커밋 SHA로 고정하고, 다른 도구는 릴리스 태그로 보고할 수 있습니다. 잘못된 버전을 키로 한 취약점 조회는 확신에 찬 잘못된 답을 돌려줍니다.
| 기능 | CRACI | 스캐너가 생성한 SBOM |
|---|---|---|
| 빌드 실행 중 기록 | 패키지 소스로 향하는 작업 트래픽과 CI 캐시 증거 | 트리, 잠금 파일 또는 이미지로부터 사후 재구성 |
| 잠금 파일이 없는 리포지토리 | 설치 시 실제로 결정된 버전을 기록 | 도구와 사전 설치 여부에 따라 다름 |
| 완전성 | 작업별·캐시별 5가지 상태 | 도구가 빈틈을 기록하지 않으면 누락된 구성 요소와 원래 없는 구성 요소를 구분할 수 없음 |
| 새 보안 권고 모니터링 | 모니터링 중인 SBOM을 지속적으로 재평가 | 예: Dependabot 알림 |
| 병합 전 풀 리퀘스트 피드백 | 현재 중점 영역 아님 | 핵심 강점 |
| GitHub Actions 외부에서 실행 | 현재 GitHub Actions 지원, GitLab CI와 Jenkins는 로드맵에 포함 | CLI를 실행하거나 앱을 연결할 수 있는 곳 어디서나 |
| 무료 오픈 소스 옵션 | 무료 티어 없음 | Syft, Trivy, cdxgen |
- 포함
- 일부 지원
- 미포함
- 로드맵에 포함
SCA와 함께 CRACI가 맡는 역할
SCA는 풀 리퀘스트에서 계속 사용하세요. 취약한 버전이 병합되기 전에 잡아내기에 적합한 곳입니다. 질문이 diff가 아니라 빌드에 관한 것일 때 CRACI를 추가하세요.
- 이 릴리스에는 실제로 무엇이 들어 있었나? 기록된 SBOM은 npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk, Git 소스와 다운로드 프리셋을 전이적 종속성까지 포함해 다룹니다. npm과 PyPI용 JFrog Artifactory 미러도 지원합니다.
- 이 목록을 신뢰할 수 있나? 각 작업과 캐시에 완전성 상태가 있으므로, 불완전한 기록이 조용히 빈약해지는 대신 눈에 보이게 됩니다.
- 새 보안 권고의 영향을 받나? 새 취약점이 공개되면 모니터링 중인 SBOM이 재평가되며, 발견 사항은 빌드와 리포지토리 전반에서 집계됩니다.
SBOM은 공개 REST API를 통해 작업의 네트워크 트레이스 및 출처 증명과 함께 CycloneDX 형식으로
다운로드되므로, 이미 사용 중인 SCA를 포함해 CycloneDX를 읽는 모든 도구에 입력할 수 있습니다. 설정은 워크플로의
한 줄입니다. runs-on을 craci로 변경하세요. 현재 지원되는 CI는 GitHub Actions이며,
GitLab CI, Jenkins 및 기타 CI 시스템은 로드맵에 있습니다.
어디에 무엇이 배포되었는지에 대한 인벤토리
CRACI의 인벤토리 뷰는 어떤 소프트웨어 버전이 어떤 제품에 배포되었는지 전 세계 범위에서 정확히 보여 줍니다. 새로운 취약점이 발견되면 릴리스 노트와 스프레드시트를 맞춰 보는 대신, 영향을 받는 버전을 실행하는 제품을 바로 확인할 수 있습니다.
빌드 시점 SBOM 생성과 취약점 추적에 대해 자세히 알아보세요.
CRACI가 대체하는 것과 대체하지 않는 것은 CRACI가 대체하는 것에서 확인하세요.
스캔한 SBOM 옆에 기록된 SBOM을 놓아 보세요
데모를 예약하시면 고객님의 빌드 하나를 CRACI에서 실행하고, 그 결과를 현재 도구가 생성하는 SBOM과 비교해 드립니다.
데모 예약