CRACI vs Black Duck

간단한 답변

Black Duck은 소프트웨어 구성 분석(SCA) 제품을 중심으로 정적 분석, 바이너리 분석, 퍼징, 보안 태세 관리를 갖춘 폭넓은 애플리케이션 보안 포트폴리오입니다. CRACI는 빌드가 가져오는 모든 외부 종속성을 기록하고, 그 기록으로부터 SBOM, 출처 증명, 컴플라이언스 증거를 생성하는 GitHub Actions 호환 CI 러너입니다. Black Duck은 스캐너이며, 철저한 스캐너입니다. CRACI는 기록 장치입니다. GitHub Actions에서 실행되는 빌드의 SBOM 생성과 종속성 모니터링에서는 두 도구가 겹칩니다. 스니펫 매칭, 바이너리 분석, 자체 코드의 정적 분석에서는 겹치지 않으며, CRACI는 이를 수행하지 않습니다.

한눈에 보기

Black Duck의 강점

아무도 선언하지 않은 오픈 소스 찾기. Black Duck SCA는 패키지 관리자 스캔에 시그니처 스캔, 부분적이거나 수정된 코드에 대한 스니펫 탐지, 바이너리 분석을 결합합니다. 코드가 리포지토리에 복사되었거나 매니페스트 없이 벤더링된 경우에 중요합니다. 발견 사항은 Black Duck Security Advisories를 기반으로 심각도, 우선순위, 도달 가능성 지표를 제공하며, 플랫폼은 악성 패키지를 표시합니다.

라이선스. Black Duck은 선언된 라이선스와 선언되지 않은 라이선스, 전체 라이선스 텍스트, 저작권 데이터를 식별하며, KnowledgeBase는 2,750개 이상의 오픈 소스 라이선스를 추적합니다. CRACI는 SBOM 내보내기에 선언된 라이선스 메타데이터를 포함하고 라이선스 정책을 적용합니다.

바이너리와 펌웨어. Black Duck Binary Analysis는 소스 코드에 접근하지 않고 실행 파일, 라이브러리, 컨테이너, 펌웨어를 검사합니다. 서드파티 바이너리를 받거나 완성된 펌웨어 이미지를 확인해야 한다면, 이는 CRACI가 다루지 않는 영역입니다.

SCA 그 이상. Coverity는 22개 언어에 걸친 정적 분석을, Defensics는 퍼즈 테스트를 제공하며, Software Risk Manager는 애플리케이션 보안 태세 관리(ASPM) 시스템으로서 발견 사항을 통합합니다. Black Duck은 Jenkins, GitLab, Azure DevOps, Bitbucket Pipelines, CircleCI, TeamCity 등 다양한 CI 시스템과 통합됩니다. Bridge CLI는 취약한 직접 종속성을 업그레이드하는 Fix PR을 열 수 있습니다.

Black Duck이 더 강한 부분:

• 서드파티 펌웨어 등 직접 빌드하지 않은 소프트웨어의 바이너리 분석.
• 스니펫과 라이선스의 깊이: 자체 파일 안에 있는 오픈 소스의 부분 복사본, 선언되지 않은 라이선스, 전체 라이선스 텍스트와 저작권 데이터를 2,750개 이상의 라이선스를 담은 KnowledgeBase로 식별합니다.
• 성숙도와 CI 지원 범위: Jenkins, GitLab, Azure DevOps 등 다수.
• 더 넓은 포트폴리오: Coverity를 통한 SAST, Defensics를 통한 퍼징, Software Risk Manager를 통한 애플리케이션 보안 태세 관리.
• 도달 가능성 지표와 악성 패키지 탐지. 둘 다 Black Duck의 SCA 제품 페이지에 나와 있습니다.

Black Duck이 구성 요소를 찾는 방법과 빌드 기록이 더하는 것

Black Duck은 오픈 소스를 식별하는 네 가지 방법과 Yocto 빌드용 디텍터를 사용합니다. 각 방법은 검사하는 대상에 대해서는 강력하지만, 모두 빌드 이후나 빌드 외부에 존재하는 것, 즉 매니페스트, 파일 트리, 바이너리, BitBake 태스크 그래프를 바탕으로 작동합니다. 빌드 기록 장치는 다른 종류의 증거를 더합니다. 릴리스 빌드가 실제로 가져온 것을 완전성을 명시해 기록합니다.

패키지 관리자 디텍터(Black Duck Detect)

작동 방식. Black Duck Detect는 프로젝트의 패키지 관리자에서 종속성을 찾아 추출하는 디텍터를 실행하며, 각 패키지 관리자를 사용해 종속성 계층을 도출합니다. Detect는 프로젝트에 대해 Black Duck 시그니처 스캐너도 실행합니다. 기본적으로 모든 Detect 도구가 실행 대상이며, 어떤 도구를 실행할지는 구성에서 결정합니다.

강점. 빌드를 변경하지 않고도 여러 생태계와 CI 시스템에 걸쳐 선언된 직접 및 전이 종속성을 파악합니다.

빌드 기록이 더하는 것. 선언된 트리는 패키지 관리자가 설치하겠다고 밝힌 것입니다. 설치 훅이 다운로드하는 코드, 빌드 시점에 다운로드하는 빌드 스크립트, 베이스 이미지 레이어처럼 어떤 매니페스트에도 나오지 않는 가져오기는 설계상 그 범위 밖에 있습니다. CRACI는 이를 기록하며, 각 작업의 완전성 상태가 보지 못한 부분을 표시합니다.

시그니처 스캔

작동 방식. 시그니처 스캐너는 파일, 디렉터리, 아카이브를 탐색하고 그 시그니처를 Black Duck KnowledgeBase에 있는 오픈 소스 구성 요소의 시그니처와 비교합니다. 시그니처는 파일 시스템 메타데이터와 파일 내용의 단방향 MD5 또는 SHA-1 해시입니다. 스캔은 파일 경로, 파일 크기, 시그니처를 전송하며, Black Duck은 소스 코드나 바이너리 코드가 사내 밖으로 전송되지 않는다고 밝힙니다. 수정된 오픈 소스 아카이브와 디렉터리에 대해 퍼지 매치를 생성합니다. 개별 파일 매칭은 선택 사항입니다. 릴리스 2020.2.0 이전에는 기본값이었지만, 오탐이 상당히 많아 Black Duck이 기본적으로 껐습니다.

강점. 매니페스트 없이 복사되거나 벤더링되거나 이름이 바뀐 오픈 소스를 언어와 관계없이 찾습니다.

빌드 기록이 더하는 것. 시그니처 스캔은 실행되는 위치에 있는 파일을 봅니다. 빌드가 가져와서 사용하고 폐기한 것은 더 이상 해시할 수 있는 곳에 없습니다. 두 방식은 서로 다른 질문에 답합니다. "이 트리에 어떤 코드가 있는가"와 "이 빌드가 무엇을 가져왔는가"입니다. 벤더링된 코드에는 시그니처 스캔이 맞는 도구입니다.

스니펫 매칭

작동 방식. 시그니처 스캔 이후의 두 번째 단계입니다. 매치되지 않은 파일과, 매치되지 않은 디렉터리 및 아카이브 안의 파일이 스니펫 스캔 대상이 됩니다. Black Duck은 단방향 해시의 일종인 codeprints를 계산하고, KnowledgeBase 파일의 코드와 일치하는 코드 부분을 찾습니다.

강점. 자체 파일 안에 있는 오픈 소스 코드의 부분 복사본과 그에 따르는 라이선스 의무.

빌드 기록이 더하는 것. 없습니다. CRACI는 파일 내부를 들여다보지 않습니다.

Black Duck Binary Analysis

작동 방식. Black Duck Binary Analysis는 코드에 접근할 수 없는 경우에도 실행 파일, 라이브러리, 컨테이너, 펌웨어에 컴파일된 오픈 소스를 검사합니다. 정적 분석과 문자열 분석을 KnowledgeBase에 대한 퍼지 매칭과 결합해 사용하며, 구성 요소, 취약점, 라이선스를 보고합니다. 이메일 주소와 인증 토큰 같은 민감한 정보, 과도한 권한을 요청하는 모바일 애플리케이션도 표시합니다.

강점. 직접 빌드하지 않은 소프트웨어: 공급업체 펌웨어, 구매한 모듈, 다른 누군가가 만든 완성 이미지. 이는 CRACI가 다루지 않는 영역입니다. 빌드가 없다면 바이너리를 분석하는 것이 그 내부를 보는 방법입니다. 다른 펌웨어 도구는 CRACI vs Finite State와 CRACI vs ONEKEY에서 비교합니다.

빌드 기록이 더하는 것. CRACI에서 직접 빌드하는 소프트웨어의 경우, 나온 것으로부터의 추론이 아니라 들어간 것의 기록입니다. 컴파일된 코드의 결과물 분석은 입력을 추론해야 하지만, 그것을 만든 빌드의 기록은 그럴 필요가 없습니다. 두 가지는 같은 제품에 대한 서로 다른 증거입니다.

Yocto와 BitBake(Detect의 BitBake 디텍터)

작동 방식. Detect의 BitBake 디텍터는 빌드 환경 스크립트(기본값 oe-init-build-env)를 소싱하고, bitbake --environment를 실행해 대상 머신 아키텍처와 라이선스 디렉터리를 찾으며, bitbake-layers show-recipes를 실행해 각 레시피를 해당 레이어에 연결합니다. detect.bitbake.package.names에 지정된 각 대상에 대해 bitbake -g를 실행해 task-depends.dot를 생성하고, 그 파일에서 레시피와 종속성 관계를 읽습니다. 빌드 종속성을 제외하기 위해 Detect는 이미지의 license.manifest를 읽고 이미지에 설치된 것만 남깁니다. 결과는 KnowledgeBase와 매칭된 레시피 수준의 종속성 그래프입니다.

강점. 빌드를 변경하지 않고 이미지를 레시피 수준에서 빠르게 파악할 수 있으며, 빌드 전용 레시피를 제외하는 옵션도 있습니다.

빌드 기록이 더하는 것. 이 그래프는 BitBake 태스크 그래프로 만들어지므로 레시피를 나열합니다. 빌드가 사용하는 것 중 레시피가 아닌 것, 즉 빌드 호스트에 설치된 패키지, 워크플로의 GitHub Actions, 스크립트가 가져오는 도구는 구조상 그 그래프 밖에 있습니다. CRACI는 BitBake 빌드를 실행하고 그런 가져오기도 기록합니다. 실제 이미지에서 어떻게 보이는지는 CRACI의 Yocto 빌드에 게시된 나란히 비교를 참조하세요. 이 비교는 Yocto 자체의 create-spdx SBOM을 대상으로 한 것이며, Black Duck과 비교한 것이 아닙니다.

완전성

스캔은 매치된 것을 보고합니다. CRACI는 각 작업의 완전성을 Complete, Complete with connections, Incomplete, Unavailable, Not recorded의 다섯 가지 상태로 명시합니다. 기록의 공백은 조용히 묻히지 않고 드러납니다.

방법별 비교

방법	읽는 대상	시점	강점	빌드 기록이 더하는 것
패키지 관리자 디텍터	프로젝트의 패키지 관리자	Detect가 실행되는 곳에서, 프로젝트의 파일과 도구로부터	선언된 직접 및 전이 종속성	어떤 매니페스트에도 없는 가져오기, 완전성 상태 포함
시그니처 스캔	파일, 디렉터리, 아카이브	스캔이 실행되는 곳에서, 존재하는 파일에 대해	복사되거나 벤더링되거나 이름이 바뀐 오픈 소스	빌드가 가져온 뒤 폐기한 것
스니펫 매칭	매치되지 않은 파일(codeprints 형태)	시그니처 스캔 이후	자체 파일 안의 오픈 소스 부분 복사본	없음: CRACI는 파일 내부를 보지 않음
Black Duck Binary Analysis	실행 파일, 라이브러리, 컨테이너, 펌웨어	빌드 이후, 결과물에 대해	직접 빌드하지 않은 소프트웨어	자체 빌드의 경우, 입력의 기록
BitBake 디텍터	task-depends.dot, 레시피, 레이어	빌드 환경에서, BitBake 자체 명령으로	이미지의 레시피 수준 파악	호스트 패키지, GitHub Actions, 레시피 외부에서 가져온 도구
CRACI 빌드 기록	작업에서 패키지 소스로 가는 트래픽	빌드 중	캐시와 숨은 종속성을 포함해 릴리스 빌드가 실제로 가져온 것	해당 없음

CRACI가 다른 점

빌드를 직접 지켜봅니다

위의 모든 기법은 매니페스트, 소스 트리, 바이너리 같은 무언가를 검사합니다. 그 어느 것도 실행 중인 빌드를 보지 못하며, 결과물을 형성하지만 결과물에는 드러나지 않을 수 있는 툴체인, 설치 스크립트, 베이스 이미지, 릴리스 다운로드, 캐시된 패키지도 보지 못합니다. CRACI는 러너이므로 그 활동을 직접 봅니다. 패키지를 인식하는 프록시가 npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk, Git 소스와 다운로드 프리셋에 대한 패키지 소스 트래픽을 관찰합니다. 종속성 증거는 CI 캐시와 함께 전달됩니다.

각 SBOM은 작업별 및 캐시별 완전성을 Complete, Complete with connections, Incomplete, Unavailable, Not recorded의 다섯 가지 상태로 명시합니다. CycloneDX 및 SPDX 내보내기가 포함됩니다.

빌드 네트워크를 통제합니다

CRACI가 작업을 실행하므로 작업에 이그레스 정책을 설정할 수 있습니다. 기본 거부 또는 기본 허용, 24개의 기본 제공 소프트웨어 소스 프리셋, 그리고 npm, PyPI, apt, apk, Go 프록시, Nix, Cargo, OCI 레지스트리, Git에 대한 유형별 사용자 지정 소스를 제공합니다. 정책은 작업 시작 전에 검증되고 실패 시 차단되며, 작업이 정책을 위반하면 CRACI가 알림을 보낼 수 있습니다. 스캐너는 들어온 것을 보고합니다. 이그레스 정책은 들어올 수 있는 것을 제한합니다.

출처 증명과 모니터링

API는 SBOM, 네트워크 추적, 출처 증명을 반환합니다. CRACI는 모니터링 중인 SBOM을 새로운 취약점에 대해 계속 재평가합니다.

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

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

Black Duck SBOM과 CRACI SBOM

Black Duck SCA는 자재 명세서에서 SPDX 2.2, 2.3, 3.0 및 CycloneDX 1.3~1.6 형식으로 SBOM을 내보내며, SBOM 파일을 가져올 수도 있습니다. CRACI는 빌드 기록에서 CycloneDX와 SPDX를 내보내며 구성 요소에서 발견된 취약점을 함께 담고, API는 SBOM, 네트워크 추적, 출처 증명 데이터를 반환합니다. 차이는 형식이 아니라 목록의 출처입니다. Black Duck의 목록은 스캔이 매치한 것에서, CRACI의 목록은 빌드가 가져온 것에서 나옵니다.

어느 쪽이 적합한가, 그리고 둘 다 사용할 때

• Yocto로 빌드하는 임베디드 제품. CRACI는 최대 32 vCPU, 96 GB의 러너에서 BitBake 빌드를 실행하고 가져온 것을 기록하며, BitBake 자체의 네트워크 통제를 보완하는 이그레스 정책을 제공합니다. Black Duck의 BitBake 디텍터는 태스크 그래프에서 이미지의 레시피를 매핑하고, Black Duck Binary Analysis는 완성된 이미지를 확인할 수 있습니다. CRACI의 Yocto 빌드와 Yocto 가이드를 참조하세요.
• 복사되거나 벤더링된 오픈 소스의 이력이 긴 코드. 스니펫 및 시그니처 스캔은 Black Duck의 강점입니다. 계속 사용하세요.
• 릴리스 증거가 필요한 GitHub Actions 사용 팀. CRACI는 각 빌드를 기록하고, 그 SBOM과 출처 증명 데이터를 보관하며, SBOM을 CycloneDX 또는 SPDX로 내보냅니다.
• Jenkins, GitLab 또는 Azure DevOps의 파이프라인. 현재는 Black Duck이 적합합니다. CRACI는 현재 GitHub Actions만 지원하며 GitLab CI와 Jenkins는 로드맵에 있으므로, 해당 파이프라인은 먼저 옮겨야 합니다.

Cyber Resilience Act 대응

Black Duck은 기한, 24시간 취약점 보고 요건, 그리고 SCA만으로는 CRA에 충분하지 않다고 보는 이유를 다루는 일련의 CRA 페이지를 게시하고 있습니다. Black Duck은 자사 포트폴리오를 규정에 대응시킵니다. EUVD 및 NVD 데이터로 코드베이스를 분석하고 SBOM을 생성하는 Black Duck SCA, 2026년 7월에 발표된 CRA 대응 검사 옵션을 갖춘 Coverity, 견고성 테스트를 위한 Defensics, 정책 게이트를 위한 Software Risk Manager입니다. Black Duck의 주장은 규정이 계층을 요구한다는 것입니다. 구성 요소에는 SCA, 자체 코드와 서비스에는 정적 및 동적 테스트가 필요하다는 것입니다.

CRACI는 빌드 자체에서 나온 증거를 더합니다. 각 릴리스에 무엇이 들어갔는지, 그 기록이 얼마나 완전한지, 그리고 이후의 지속적인 모니터링이며, SBOM은 CycloneDX 또는 SPDX로 내보낼 수 있습니다. CRACI는 기업이 더 넓은 CRA 컴플라이언스 프로세스에 필요로 하는 소프트웨어 공급망 가시성과 증거의 상당 부분을 자동화합니다. CRA 컴플라이언스와 산업용 IoT에 대해 자세히 알아보세요.

Black Duck과 함께 CRACI 추가하기

CRACI는 GitHub Actions가 아니라 러너를 대체합니다. 워크플로에서 runs-on을 craci로 바꾸면 실행은 여전히 GitHub UI에 표시됩니다. Black Duck 스캔 단계는 워크플로에 그대로 남습니다. 제품 릴리스 하나를 골라 CRACI의 빌드 시점 SBOM을 Black Duck의 자재 명세서와 비교하고, 한쪽에서만 발견된 구성 요소를 검토해 보세요.

Black Duck과 CRACI: 자주 묻는 질문

각 도구가 구성 요소를 찾는 방법과 함께 쓰는 방법

Black Duck은 오픈 소스를 어떻게 찾습니까?

네 가지 방법에 더해 Yocto용 BitBake 디텍터가 있습니다. Black Duck Detect는 프로젝트의 패키지 관리자를 읽어 종속성 트리를 도출합니다. 시그니처 스캐너는 파일, 디렉터리, 아카이브의 해시를 KnowledgeBase와 매칭합니다. 스니펫 매칭은 매치되지 않은 파일에서 오픈 소스 코드의 부분 복사본을 찾습니다. Black Duck Binary Analysis는 컴파일된 실행 파일, 라이브러리, 컨테이너, 펌웨어를 검사합니다.

Black Duck Binary Analysis란 무엇입니까?

소스 코드에 접근하지 않고 실행 파일, 라이브러리, 컨테이너, 펌웨어에 컴파일된 오픈 소스를 검사하는 Black Duck 제품입니다. 정적 분석과 문자열 분석을 KnowledgeBase에 대한 퍼지 매칭과 함께 사용하며, 구성 요소, 취약점, 라이선스와 함께 인증 토큰 같은 민감한 정보도 보고합니다. 공급업체 펌웨어처럼 직접 빌드하지 않은 소프트웨어에 적합합니다.

Black Duck은 Yocto를 지원합니까?

예. Detect의 BitBake 디텍터는 각 대상 이미지에 대한 bitbake -g를 포함해 BitBake 자체 명령을 실행하고, task-depends.dot에서 레시피와 그 종속성을 읽으며, 이미지의 license.manifest를 사용해 빌드 종속성을 제외할 수 있습니다. 결과는 KnowledgeBase와 매칭된 레시피 수준의 종속성 그래프입니다.

CRACI가 Black Duck을 대체합니까?

아니요. CRACI는 스니펫, 바이너리, 정적 분석을 하지 않으므로 이는 Black Duck에 남습니다. CRACI에서 실행되는 빌드의 경우 SBOM 생성과 종속성 모니터링을 맡을 수 있습니다. 각 GitHub Actions 빌드가 가져온 것을 기록하고, SBOM을 CycloneDX 또는 SPDX로 내보내며, 새로운 취약점에 대해 계속 재평가합니다.

둘 다 사용할 수 있습니까?

예. CRACI는 GitHub Actions가 아니라 러너를 대체하므로, Black Duck 스캔 단계는 같은 워크플로에서 CRACI 러너 위에서 계속 실행됩니다. 릴리스 하나를 골라 CRACI의 빌드 시점 SBOM을 Black Duck의 자재 명세서와 비교하고, 한쪽에서만 발견된 구성 요소를 검토해 보세요.

Black Duck과 Snyk의 차이는 무엇인가요?

둘 다 소프트웨어 구성 분석(SCA) 도구이지만 오픈소스를 찾는 방식이 다릅니다. Snyk Open Source는 매니페스트와 락파일로 의존성 트리를 만들고, 관리되지 않는 C/C++ 코드는 의존성의 전체 소스 코드가 스캔 디렉터리에 있을 때 파일 시그니처를 대조합니다. IDE, CLI, 저장소, CI에서 쓰는 개발자 중심 도구이며 Snyk Code, Snyk Container, Snyk IaC와 함께 제공됩니다. Black Duck은 여기에 모든 파일의 시그니처 스캔, 부분 복사본을 찾는 스니펫 매칭, 소스 코드 없이 컴파일된 소프트웨어와 펌웨어를 분석하는 Binary Analysis를 더합니다. Snyk은 Free 플랜과 월 $25부터 시작하는 Team 플랜을 공개하고, Black Duck은 견적 기반입니다. 둘 다 빌드를 실행하지 않습니다. CRACI는 빌드를 실행하고 각 GitHub Actions 빌드가 가져온 것을 기록하므로 어느 쪽과도 함께 쓸 수 있습니다.