CRACI vs Syft 및 Grype

간단한 답변

Syft는 널리 쓰이는 오픈 소스 SBOM 생성 도구이며, Grype는 함께 쓰는 취약점 스캐너입니다. 두 도구를 함께 쓰면 어떤 파이프라인에서든 생성과 매칭을 무료로 처리할 수 있습니다. CRACI는 각 빌드가 가져온 것을 기록하고, 그 기록이 완전한지 표시하며, 빌드가 연결할 수 있는 대상을 제어하고, 출시한 것을 계속 모니터링하는 GitHub Actions 러너입니다. 한 줄로 요약하면 이렇습니다. Syft는 파일로부터 SBOM을 재구성하며, 얼마나 찾아내는지는 설정과 실행 시점에 디스크에 있는 것에 따라 달라집니다. CRACI는 SBOM을 관찰로 얻고 기록한 것의 취약점을 추적하므로, 하나의 제품이 두 도구의 역할을 모두 합니다.

Syft와 Grype의 강점

Syft는 "컨테이너 이미지와 파일 시스템에서 Software Bill of Materials(SBOM)를 생성하는 CLI 도구이자 Go 라이브러리"입니다. Alpine, Debian, RPM부터 Go, Python, Java, JavaScript, Ruby, Rust, PHP, .NET까지 수십 가지 패키징 시스템을 인식합니다. CycloneDX, SPDX, 자체 Syft JSON을 작성하고, 형식 간 변환을 지원하며, in-toto 사양을 사용해 서명된 SBOM 증명을 만들 수 있습니다.

Grype는 컨테이너 이미지, 파일 시스템, SBOM에서 알려진 취약점을 스캔합니다. EPSS, KEV, 위험 점수로 탐지 결과의 우선순위를 정하고, 결과 필터링을 위한 OpenVEX를 지원하며, --fail-on 플래그는 선택한 심각도 이상의 취약점을 발견하면 파이프라인을 실패 처리합니다. Anchore에 따르면 Grype는 데이터베이스 다운로드를 제외하면 "전적으로 로컬에서 실행되며 외부 서비스로 어떤 데이터도 보내지 않습니다."

두 도구 모두 Apache-2.0 라이선스이며 Anchore가 후원합니다. Anchore의 상용 플랫폼인 Anchore Enterprise는 "오픈 소스 Syft와 Grype를 기반으로" 만들어졌습니다. 이 페이지는 오픈 소스 도구를 다룹니다.

Syft는 올바른 파일이 눈앞에 있을 때 강력합니다. ollama/ollama처럼 종속성을 커밋한 소스 트리를 대상으로 하면, 기본 스캔이 버전, 패키지 URL, 종속성 간의 연결 관계까지 해석해 냅니다.

플래그 하나가 답을 바꿉니다

Syft는 스캔 유형에 따라 카탈로거를 선택하며, 문서는 그 이유를 이렇게 설명합니다. "소프트웨어를 설치하려는 의도를 암시하는 파일에는 정확한 버전을 판단할 만큼 충분한 정보가 없습니다." 카탈로거에는 declared, installed, image, directory 같은 태그가 붙어 있으며, --select-catalogers와 --override-default-catalogers 같은 플래그로 그 조합을 바꿀 수 있습니다.

v1.51.1의 syft cataloger list를 보면, node_modules를 읽는 JavaScript 카탈로거는 이미지 스캔과 설치 스캔용 태그가 붙어 있고 디렉터리 스캔의 기본 조합에는 들어 있지 않습니다. 따라서 설치가 완료된 체크아웃에서는 플래그 하나에 따라 node_modules의 npm 패키지를 읽을지 말지가 결정됩니다. 같은 도구, 같은 버전, 같은 트리인데도 그렇습니다.

반대 측면도 똑같이 중요합니다. 어디서나 맞는 단일 설정은 없습니다.

• 잠금 파일이 없는 express 5.2.1의 깨끗한 체크아웃에서는 기본 스캔이 해석할 npm 종속성이 없으므로, GitHub Actions와 워크플로 파일처럼 그 밖에 인식하는 것만 반환합니다.
• 설치 카탈로거를 켜고 아직 아무것도 설치되지 않은, 커밋된 상태의 소스 트리를 대상으로 하면 읽을 것이 거의 없습니다.
• 종속성 매니페스트가 아예 없는 리포지토리는 설정과 관계없이 스캔이 읽을 종속성 파일이 없습니다.

이 중 어느 것도 버그가 아닙니다. Syft는 설계대로 눈앞의 파일이 뒷받침하는 것을 보고합니다. 실질적인 결과는 SBOM이 모든 파이프라인에서 누군가 올바르게 내려야 하는 두 가지 결정에 달려 있다는 것입니다. 어떤 카탈로거를 실행할지, 그리고 스캔 전에 종속성을 설치했는지입니다. 게다가 Grype는 Syft가 나열한 것만 매칭할 수 있습니다. SBOM에서 빠진 구성 요소는 취약점 조회에 도달하지 못하므로, 그 구성 요소에 대해서는 스캔 결과가 깨끗하게 나옵니다.

CRACI의 차별점

CRACI는 사후에 트리를 읽지 않으므로 선택할 카탈로거가 없습니다. runs-on을 craci로 바꾸면, 패키지를 인식하는 프록시가 작업이 npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk, Git 소스와 다운로드 프리셋에서 가져오는 것을 기록합니다. CI 캐시에서 복원된 패키지도 증거를 그대로 이어받습니다. CycloneDX 또는 SPDX로 나오는 결과에는 빌드가 실제로 사용한 전이적 종속성이 포함됩니다.

• 완전성을 명시합니다. 모든 작업과 캐시는 Complete, Complete with connections, Incomplete, Unavailable, Not recorded 중 하나로 표시됩니다.
• 빌드를 제어합니다. 이그레스 정책(기본 거부 또는 허용, 24개의 기본 제공 소프트웨어 소스 프리셋)은 작업 시작 전에 검증되고 실패 시 차단됩니다.
• 출처 증명 데이터. API는 SBOM, 네트워크 추적, 출처 증명을 반환합니다. CRACI는 출처 증명에 서명하지 않습니다. Syft 증명은 SBOM에 서명합니다.
• 모니터링. 모니터링 중인 SBOM을 지속적으로 재평가하고, 빌드와 리포지토리 전반의 탐지 결과를 집계합니다.

Grype는 여전히 CRACI가 하지 않는 일을 합니다. VEX 필터링과 직접 빌드하지 않은 이미지의 스캔은 Grype의 영역입니다. CRACI의 정책 게이트는 빌드를 실패 처리할 수 있으며, 임계값 알림은 로드맵에 있습니다.

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

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

Syft와 Grype에서 옮겨 오기

CRACI에서는 생성할 SBOM도, 유지할 스캔 단계도 없습니다. 러너가 빌드 실행 중에 SBOM을 기록하고, 빌드가 끝난 뒤에도 CRACI가 새로운 취약점이 있는지 계속 확인합니다. 직접 빌드하지 않은 이미지와 서드파티 소프트웨어, 그리고 GitHub Actions 외부의 파이프라인에는 Syft와 Grype가 여전히 적합한 도구입니다.

Cyber Resilience Act 대응

CRA는 제조사가 SBOM을 포함해 각 제품의 구성 요소를 문서화하고 그 취약점을 처리하기를 요구합니다. Syft와 Grype는 그 SBOM을 생성하고 점검할 수 있지만, 각 릴리스에서 해당 SBOM으로 이어지는 증거 추적은 직접 구축해야 합니다. CRACI는 빌드별로 SBOM을 기록하고 CycloneDX 또는 SPDX로 내보냅니다. CRACI는 기업이 더 넓은 CRA 컴플라이언스 프로세스에 필요로 하는 소프트웨어 공급망 가시성과 증거의 상당 부분을 자동화합니다. CRA란 무엇인가와 빌드 시점 SBOM 생성을 참고하세요.