2026년 최고의 SBOM 도구

요약

• 컨테이너 이미지와 파일 시스템용 무료 SBOM: Syft, 또는 취약점, 시크릿, IaC 스캐너도 필요하다면 Trivy.
• 소스 코드에서 생성하는 CycloneDX: CycloneDX 커뮤니티의 cdxgen.
• 이미 패키징하는 빌드 출력물의 SPDX: Microsoft SBOM Tool.
• AWS 워크로드: Amazon Inspector와 연동되는 Amazon Inspector SBOM Generator.
• GitHub 리포지토리의 빠른 SBOM: GitHub의 종속성 그래프 내보내기.
• SBOM을 모니터링할 무료 셀프 호스팅 환경: OWASP Dependency-Track.
• 라이선스 컴플라이언스 우선: FOSSA. 공급업체 및 포트폴리오 SBOM: Manifest 또는 Cybeats. 대규모 컨테이너와 정부 정책 팩: Anchore Enterprise.
• 자체 빌드가 실제로 가져온 항목의 SBOM, 취약점 모니터링 및 출처 증명 데이터 포함: GitHub Actions용 CRACI.

SBOM 도구가 하는 일

소프트웨어 자재 명세서(SBOM)는 소프트웨어에 포함된 구성 요소, 라이브러리, 종속성을 CycloneDX나 SPDX 같은 기계가 읽을 수 있는 형식으로 나열합니다. SBOM 도구는 두 종류로 나뉩니다. 생성기는 SBOM을 작성합니다. 관리 도구는 여러 제품과 공급업체의 SBOM을 저장하고, 취약점 데이터와 매칭하고, 정책을 적용하고, 공유합니다. 관리 도구는 생성기가 넘겨주는 데이터에 의존합니다.

어떤 도구로 SBOM을 만드느냐만큼 언제 만드느냐도 중요합니다. CISA의 SBOM 유형 가이드는 개발 환경과 소스 파일에서 만드는 소스 SBOM, 릴리스할 아티팩트를 빌드하는 과정에서 생성하는 빌드 SBOM, 빌드 후 실행 파일이나 컨테이너 이미지 같은 아티팩트를 분석해 생성하는 분석 SBOM을 구분합니다. 아래 생성기 대부분은 소스 또는 분석 SBOM을 만듭니다. CRACI는 빌드 SBOM을 만듭니다. 차이점은 빌드 시점 SBOM에서 자세히 설명합니다.

이 페이지의 대상

이 페이지는 Cyber Resilience Act, 고객 설문, 또는 자체 취약점 관리 때문에 SBOM이 필요하고 여러 선택지를 검토 중인 팀을 위한 것입니다. CRACI를 만드는 저희가 작성했다는 점을 감안해 주세요. 다른 도구에 대한 모든 내용은 해당 도구의 공식 문서를 근거로 하며, 각 도구마다 더 자세한 CRACI vs X 페이지가 있습니다.

SBOM 도구 선택 방법

• SBOM을 생성해야 합니까, 관리해야 합니까, 아니면 둘 다입니까? 생성기는 파일을 만들어 줍니다. 관리 도구는 여러 제품과 공급업체의 파일을 보관하고, 보강하고, 이에 대응할 수 있는 공간을 제공합니다.
• 자체 소프트웨어입니까, 구매한 소프트웨어입니까? 자체 빌드는 입력을 직접 통제하므로 기록할 수 있습니다. 공급업체 소프트웨어에는 수령, 검증, 때로는 바이너리 분석이 필요합니다.
• 목록이 완전하다는 것을 얼마나 확신해야 합니까? 생성기는 사후에 파일을 읽으며, 생각보다 도구 간 결과가 많이 다릅니다(아래 참고). 빌드 SBOM은 빌드가 사용한 것을 설명합니다.
• 고객이 어떤 형식을 요구합니까? CycloneDX와 SPDX 모두 널리 인정되며, 대부분의 도구는 둘 중 하나 이상을 작성합니다.
• 어떤 CI를 사용하며, 셀프 호스팅이 필수입니까? 오픈 소스 생성기는 어디서나 실행됩니다. CRACI는 현재 관리형 서비스로 Linux의 GitHub Actions를 지원하며, GitLab CI, Jenkins, 고객 호스팅 러너는 로드맵에 있습니다.

여러 팀이 같은 방식으로 SBOM을 만들어야 한다면 엔지니어링 팀 전반의 SBOM 생성을 참고하세요.

SBOM 생성기

이 비교는 각 생성기가 무엇을 하는지를 다루며, 반환하는 구성 요소의 개수를 비교하지는 않습니다.

CRACI

CRACI는 스캐너가 아니라 기록기입니다. GitHub Actions 작업이 CRACI 러너에서 실행되고, 패키지를 인식하는 프록시가 CI 캐시에서 복원된 패키지를 포함해 각 작업이 가져온 항목을 기록합니다. CycloneDX 또는 SPDX 형식의 SBOM에는 빌드가 사용한 전이적 종속성이 포함되며, 작업 및 캐시별 완전성이 명시됩니다. 이후 CRACI는 모니터링 중인 SBOM을 계속 재평가하므로, 생성기와 관리 도구의 역할을 함께 수행합니다. GitHub Actions에서 빌드하는 소프트웨어에 가장 적합합니다. 주의할 점: 이미지나 디렉터리를 스캔할 수 없으며, 현재는 GitHub Actions에서 Linux 작업만 실행합니다(다른 CI 시스템, Windows, macOS는 로드맵에 있습니다). CRACI의 SBOM 생성

Syft

Syft는 컨테이너 이미지와 파일 시스템을 위한 Anchore의 무료 Apache-2.0 생성기입니다. 수십 가지 패키지 유형을 인식하고, CycloneDX, SPDX, Syft JSON을 작성하며, 서명된 in-toto SBOM 증명을 생성할 수 있습니다. 함께 쓰는 Grype가 SBOM을 취약점과 매칭합니다. 이미지와, 무료 생성기가 필요한 모든 파이프라인에 가장 적합합니다. 주의할 점: 카탈로거는 스캔 유형에 따라 선택되므로, 종속성이 설치된 express 체크아웃에서는 플래그 하나에 따라 npm 패키지가 결과에 나타나는지 여부가 갈립니다. CRACI vs Syft 및 Grype

Trivy

Aqua Security의 Trivy는 이미지, 파일 시스템, 리포지토리, VM 이미지, Kubernetes를 위한 다용도 Apache-2.0 스캐너입니다. 취약점, IaC 구성 오류, 시크릿, 라이선스를 찾아내며, 부수적으로 CycloneDX나 SPDX를 작성합니다. 여러 보안 검사를 하나의 무료 바이너리로 처리하려는 팀에 가장 적합합니다. 주의할 점: 리포지토리에서는 잠금 파일을 읽으므로, express 5.2.1(잠금 파일 없음)과 claude-code(매니페스트 없음)에서는 문서에 적힌 그대로 읽을 것이 없습니다. CRACI vs Trivy

cdxgen

cdxgen은 소스와 컨테이너 이미지에서 CycloneDX BOM을 만드는 OWASP CycloneDX 프로젝트이며, Apache-2.0 라이선스입니다. CycloneDX를 표준으로 쓰며 해당 형식의 커뮤니티가 만든 생성기를 원하는 팀에 가장 적합합니다. 주의할 점: 다른 스캐너와 마찬가지로 눈앞의 파일이 선언한 것만 보고할 수 있습니다. CRACI vs DIY SBOM 스택

Microsoft SBOM Tool

Microsoft SBOM Tool은 SPDX 2.2(요청 시 SPDX 3.0)를 작성하는 MIT 라이선스 생성기로, SBOM을 SPDX 사양에 맞게 검증할 수도 있습니다. 명령줄에서 빌드 드롭 폴더, 패키지 이름, 버전, 공급자를 입력받으므로 빌드 후 단계로 동작하며, GitHub Actions와 Azure Pipelines에서 실행됩니다. 이미 패키징하는 빌드 출력물에 대한 SPDX가 필요한 팀에 가장 적합합니다. 주의할 점: 빌드 드롭이 아니라 커밋된 상태의 리포지토리를 대상으로 하면 설명할 것이 거의 없습니다. 명령줄에서 공급자를 입력받으므로 공급자 필드를 채울 수 있습니다. CRACI vs DIY SBOM 스택

GitHub 종속성 그래프 내보내기

GitHub의 종속성 그래프는 리포지토리의 매니페스트와 잠금 파일, 그리고 종속성 제출 API로 전송된 항목을 요약하며, UI나 REST API에서 SPDX로 내보낼 수 있습니다. Dependabot 알림의 기반이 되며 모든 GitHub 플랜에 포함됩니다. 이미 GitHub를 사용하며 빠르게 SBOM이 필요한 팀에 가장 적합합니다. 주의할 점: 고정된 커밋이 아니라 기본 브랜치를 반영하며, 스캐너가 읽는 파일이 아니라 GitHub가 리포지토리에 대해 알고 있는 정보로 만들어집니다. CRACI vs GitHub Advanced Security

Amazon Inspector SBOM Generator

Sbomgen은 Amazon Inspector 자체의 이미지, Lambda, EC2 스캔에 쓰이는 생성기로, 독립형 Linux 바이너리로 제공됩니다. 컨테이너 이미지, 디렉터리, 아카이브, 마운트된 볼륨, 컴파일된 Go 및 Rust 바이너리에서 패키지 메타데이터를 읽고, OS 패키지(APK, DPKG, RPM)와 C#, Go, Java, Node.js, PHP, Python, Ruby, Rust 등의 언어를 다루며, CycloneDX를 작성합니다. 취약점 발견 사항을 얻기 위해 SBOM을 Amazon Inspector Scan API로 보낼 수 있으며, 이를 위해서는 AWS 계정이 필요합니다. 워크로드가 이미 AWS에서 실행되는 팀에 가장 적합합니다. 주의할 점: Linux에서만 실행되며, 다른 스캐너와 마찬가지로 읽은 파일이 선언한 것만 찾아냅니다.

Safeguard

Safeguard의 CLI는 Syft와 Grype를 실행해 리포지토리, 컨테이너 이미지, 업로드된 매니페스트에서 CycloneDX 및 SPDX SBOM을 만들며, 플랫폼은 AI가 작성한 수정 풀 리퀘스트와 정책 게이트를 더합니다. 스캔과 자동 수정을 하나의 구독으로 원하는 팀에 가장 적합합니다. 주의할 점: 다른 스캐너와 마찬가지로 읽은 파일이 선언한 것을 나열합니다. CRACI vs Safeguard

스캔으로 만든 SBOM이 좌우되는 요소

위의 생성기들을 같은 리포지토리에 적용하면 서로 다른 목록이 나옵니다. 각 도구의 공식 문서로 예측할 수 있는 패턴은 다음과 같습니다.

• 무엇이 구성 요소인지에 대한 판단이 도구마다 다릅니다. 생성기마다 어떤 파일을 신뢰할지, 찾은 것을 어떻게 명명할지 스스로 정하므로, 같은 리포지토리라도 도구마다 다른 목록이 나옵니다.
• 잠금 파일이 없으면 종속성도 없습니다. Express 5.2.1은 잠금 파일을 커밋하지 않으므로, 잠금 파일에서 종속성을 해석하는 생성기는 npm 종속성을 하나도 보고하지 않고 그 밖에 인식한 것만 반환합니다.
• 매니페스트가 아예 없는 경우. claude-code 리포지토리에는 매니페스트도 잠금 파일도 없으므로, 각 도구가 반환하는 결과는 다른 유형의 파일로 조합한 것이며 프로젝트보다는 도구에 대해 더 많은 것을 말해 줍니다.
• 빈약한 메타데이터. 대부분의 생성기에는 공급자 정보를 얻을 출처가 없으므로 공급자 필드가 비어 있는 경우가 많습니다.

이 도구들 중 고장 난 것은 없습니다. 각 도구는 설계된 대로 눈앞의 파일을 읽습니다. 중요한 점은 스캔으로 만든 SBOM이 도구, 설정, 그리고 누군가 먼저 종속성을 설치했는지에 좌우된다는 것입니다. Syft, Trivy, cdxgen이 각각 무엇을 읽는지는 오픈 소스 SBOM 생성기가 놓치는 것을 참고하세요.

SBOM 관리 도구

Anchore Enterprise

Anchore Enterprise는 Syft와 Grype를 기반으로 대규모 조직에 필요한 기능을 더합니다. 컨테이너, 소스, 파일 시스템 SBOM, 스키마 정확성을 검증한 가져온 SBOM, 원본 아티팩트 없이 이루어지는 지속적 재스캔, 그리고 FedRAMP, NIST, CIS, PCI DSS, CMMC용 정책 팩을 제공합니다. Kubernetes, Docker Compose 또는 에어갭 환경에 배포됩니다. 여러 CI 시스템에 걸친 대규모 컨테이너 환경과 정부 업무에 가장 적합합니다. 주의할 점: SBOM은 여전히 스캐너가 찾은 것을 설명하며, 요금은 견적 방식입니다. CRACI vs Anchore

FOSSA

FOSSA는 라이선스 컴플라이언스에서 출발했습니다. 전문(全文) 라이선스 탐지, 정책, 저작자 표시 고지를 제공합니다. SPDX 및 CycloneDX SBOM을 생성하고 가져오며, VDR 또는 VEX 문서를 추가할 수 있고, 가져온 SBOM을 NTIA 및 FDA 최소 요소와 대조하며, Enterprise에서는 포털을 통해 SBOM을 공유합니다. Free 플랜은 프로젝트 5개까지 지원합니다. 라이선스 위험이 최우선 관심사인 팀에 가장 적합합니다. 주의할 점: CLI는 작동하는 빌드가 있으면 빌드 도구에 질의하고 없으면 소스에서 추론하며, 바이너리 및 스니펫 스캔은 추가 기능입니다. CRACI vs FOSSA

Cybeats SBOM Studio

SBOM Studio는 스스로를 "SBOM 기록 시스템(the SBOM system of record)"이라고 부릅니다. SPDX 2.2~3.0.1과 CycloneDX 1.2~1.7을 가져오고 내보내며, 가져오기 전에 SBOM 품질을 평가하고, 모든 구성 요소를 지속적으로 매칭하며, Transparency Exchange API를 포함한 방식으로 고객과 SBOM 및 VEX 데이터를 공유합니다. ICS, 의료 기기, 통신, 자동차 분야에서 SBOM 프로그램을 운영하는 제품 보안 팀에 가장 적합합니다. 주의할 점: SBOM을 생성하기보다는 관리하며, 품질 점수는 형식을 확인할 뿐 생성기가 놓친 것을 확인하지는 않습니다. CRACI vs Cybeats 및 Cybeats 대안

Manifest

Manifest는 자사 제품, 공급업체, AI 모델 전반의 SBOM을 수집하고, 보강하고, 공유합니다. 공급업체는 보안 포털을 통해 업로드하며, 공급업체가 SBOM을 제공하지 않으면 Manifest가 바이너리를 분석해 생성할 수 있습니다. SPDX, CycloneDX, VEX를 지원하며 FDA 가이드, NIST 800-218, UNECE R155에 매핑됩니다. 주된 위험 노출이 구매한 소프트웨어인 조직에 가장 적합합니다. 주의할 점: GitHub Action은 기본적으로 Syft로 자사 SBOM을 생성합니다. CRACI vs Manifest

OWASP Dependency-Track

Dependency-Track은 모든 애플리케이션의 모든 버전에 걸쳐 구성 요소를 추적하는 Apache 2.0 플랫폼으로, NVD와 GitHub Advisories 등의 소스에서 취약점 데이터를 가져오고, 보안, 라이선스, 운영 정책을 적용하며, CycloneDX VEX를 읽고 생성합니다. 파이프라인은 API를 통해 SBOM을 업로드합니다. 투명한 셀프 호스팅 분석 플랫폼을 원하는 팀에 가장 적합합니다. 주의할 점: SBOM을 생성하지 않으며, 직접 운영해야 합니다(API 서버에 최소 2 GB RAM과 CPU 코어 2개가 필요합니다). Dependency-Track 사용자를 위한 CRACI

CycloneDX와 SPDX

두 형식 모두 개방형 표준이며, 이 페이지의 도구 대부분은 둘 중 하나 이상을 작성합니다. CycloneDX는 OWASP 프로젝트로 Ecma International이 ECMA-424로 표준화했으며, 구성 요소 목록과 함께 취약점 및 VEX 데이터를 담습니다. SPDX는 Linux Foundation 프로젝트이자 국제 표준인 ISO/IEC 5962:2021입니다. Cyber Resilience Act는 특정 형식을 지정하지 않고 "일반적으로 사용되고 기계가 읽을 수 있는 형식"을 요구하므로, 고객과 다운스트림 도구가 읽는 형식을 선택하세요. 두 형식을 나란히 보려면 SBOM 예시를, 운영 방법은 SBOM 모범 사례를 참고하세요. 대규모 SBOM 저장 및 모니터링은 SBOM 관리를 참고하세요.

CRACI의 위치

CRACI는 스캐너도 관리 도구도 아닌 기록기입니다. GitHub Actions 작업이 CRACI 러너에서 실행되고(runs-on을 craci로 변경), 패키지를 인식하는 프록시가 각 작업이 npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk, Git 소스와 다운로드 프리셋에서 가져오는 항목을 기록합니다. CI 캐시에서 복원된 패키지는 증거를 그대로 이어받습니다. CycloneDX 또는 SPDX 형식의 SBOM에는 빌드가 사용한 전이적 종속성이 포함되며, 작업 및 캐시별 완전성이 Complete, Complete with connections, Incomplete, Unavailable, Not recorded 중 하나로 명시됩니다. CRACI의 인벤토리 보기는 어떤 소프트웨어 버전이 어떤 제품에 배포되어 있는지 전 세계 범위에서 정확히 보여 줍니다.

빌드 후에도 CRACI는 모니터링 중인 SBOM을 계속 재평가하고, 빌드와 리포지토리 전반의 취약점을 집계하며, VEX를 지원하고, API를 통해 SBOM, 네트워크 추적, 출처 증명을 반환하며, SBOM을 CycloneDX 또는 SPDX 파일로 내보냅니다. 공급업체 SBOM을 추가할 수 있어 구매한 구성 요소도 자체 빌드와 함께 모니터링됩니다. 기업이 더 넓은 CRA 컴플라이언스 프로세스에 필요로 하는 소프트웨어 공급망 가시성과 증거의 상당 부분을 자동화합니다. 전체 기능은 CRACI의 SBOM 생성을 참고하세요.

즉, CRACI는 직접 빌드하는 소프트웨어에 대해 생성기와 관리 도구의 역할을 함께 수행합니다. 다음과 같은 경우에는 적합하지 않습니다.

• 직접 빌드하지 않은 이미지나 소프트웨어의 SBOM이 필요한 경우(Syft나 Trivy 같은 생성기를 사용하세요),
• 제품과 공급업체 포트폴리오 전반에 걸쳐 다양한 규칙 유형을 갖춘 성숙한 정책 엔진이 필요한 경우(관리 도구를 사용하세요),
• 파이프라인이 GitHub Actions 외부나 Windows 또는 macOS에서 실행되거나, 셀프 호스팅이 필수인 경우(모두 CRACI의 로드맵에 있습니다).

가장 빠른 판단 방법은 나란히 비교하는 것입니다. 데모를 예약하고, 워크플로 하나를 CRACI에서 실행해, 그 SBOM을 현재 도구가 만든 SBOM과 나란히 놓아 보세요.

SCA 도구 비교, AI 생성 SBOM과 빌드 시점 SBOM 비교, 빌드 시점 SBOM이 스캔한 SBOM과 다른 이유도 참고하세요.

SBOM 도구: 자주 묻는 질문

SBOM 도구란 무엇입니까?

SBOM 도구는 소프트웨어 자재 명세서(SBOM)를 생성하거나 관리합니다. SBOM은 소프트웨어에 포함된 구성 요소, 라이브러리, 종속성을 기계가 읽을 수 있는 형태로 나열한 목록입니다. Syft, Trivy, cdxgen 같은 생성기는 파일을 읽어 SBOM을 작성합니다. Dependency-Track, FOSSA, Anchore Enterprise 같은 관리 도구는 SBOM을 저장하고, 취약점 데이터와 매칭하고, 공유합니다. CRACI는 빌드 중에 SBOM을 기록하고 이후에도 모니터링합니다.

가장 좋은 무료 SBOM 도구는 무엇입니까?

무엇을 대상으로 하느냐에 따라 다릅니다. Syft와 Trivy는 컨테이너 이미지와 파일 시스템용 무료 Apache-2.0 생성기입니다. cdxgen은 소스와 이미지에서 CycloneDX를 작성합니다. Microsoft SBOM Tool은 빌드 출력 폴더에 대한 SPDX를 작성합니다. OWASP Dependency-Track은 이 도구들이 만든 SBOM을 관리하는 무료 셀프 호스팅 관리 도구입니다.

Syft와 Trivy 중 무엇을 써야 합니까?

Syft는 SBOM 생성에 집중하며 취약점 매칭을 위해 Grype와 함께 사용합니다. Trivy는 IaC 구성 오류, 시크릿, 라이선스까지 찾아내는 더 넓은 범위의 스캐너이며, 그 과정에서 CycloneDX나 SPDX도 작성합니다. 둘 다 눈앞에 있는 파일을 읽으므로, 둘 다 잠금 파일이나 설치된 패키지가 있어야 제대로 작동합니다.

CycloneDX와 SPDX 중 어떤 SBOM 형식을 써야 합니까?

둘 다 개방형이며 널리 지원되는 표준입니다. CycloneDX는 OWASP 프로젝트로 Ecma International이 ECMA-424로 표준화했으며, 취약점과 VEX 데이터도 담습니다. SPDX는 Linux Foundation 프로젝트이자 국제 표준인 ISO/IEC 5962:2021입니다. 고객과 다운스트림 도구가 요구하는 형식을 사용하세요. 대부분의 생성기는 두 형식을 모두 작성합니다.

같은 프로젝트인데 SBOM 도구마다 결과가 다른 이유는 무엇입니까?

생성기마다 어떤 파일을 신뢰할지, 무엇을 구성 요소로 볼지를 스스로 판단합니다. 잠금 파일을 읽는 도구도, 설치된 패키지를 읽는 도구도, 바이너리를 읽는 도구도 있으며, 잠금 파일이 없는 리포지토리에서는 잠금 파일을 읽는 도구가 할 수 있는 일이 없습니다. 스캔으로 만든 SBOM은 도구, 설정, 그리고 스캔 전에 종속성이 설치되었는지에 따라 달라집니다. 빌드 시점 SBOM은 빌드가 실제로 가져온 항목을 기록하므로 이런 문제가 없습니다.

Cyber Resilience Act는 특정 SBOM 도구나 형식을 요구합니까?

아닙니다. CRA 부속서 I 제II부는 제조사에게 일반적으로 사용되고 기계가 읽을 수 있는 형식으로, 최소한 제품의 최상위 종속성을 포함하는 소프트웨어 자재 명세서를 작성하도록 요구합니다. CycloneDX와 SPDX 모두 이에 해당합니다. 규정은 특정 도구를 지정하지 않습니다.

CRACI로 직접 빌드하지 않은 소프트웨어의 SBOM을 생성할 수 있습니까?

아닙니다. CRACI는 CRACI 러너에서 실행되는 빌드를 기록하므로, CRACI의 SBOM은 직접 빌드하는 소프트웨어를 설명합니다. 구매한 소프트웨어의 경우 공급업체의 SBOM을 CRACI에 추가해 자체 빌드와 함께 모니터링할 수 있습니다. 직접 빌드하지 않은 서드파티 컨테이너 이미지에는 Syft나 Trivy 같은 스캐너가 현실적인 선택입니다.

CRACI는 어떤 CI 시스템을 지원합니까?

현재는 Linux x86-64 및 ARM64 러너의 GitHub Actions를 지원합니다. runs-on을 craci로 바꾸면 되며, 실행 내역은 그대로 GitHub에 표시됩니다. GitLab CI와 Jenkins를 시작으로 다른 CI 시스템 지원이 로드맵에 있습니다.