SBOM 스캐너가 Yocto 빌드의 내용을 놓치는 이유

Yocto 빌드는 스캐너의 예상과 어떻게 다른가

Yocto 빌드는 패키지 관리자 설치가 아닙니다. 디바이스에 들어가는 것의 대부분은 빌드 시점에 BitBake 안에서 다섯 레이어에 걸쳐 결정됩니다. 스캐너는 사후에 한 레이어만 보고 나머지는 추측해야 합니다.

1. 빌드 호스트

BitBake는 빌드 머신의 도구로 실행됩니다. HOSTTOOLS 변수는 빌드 태스크가 호출할 수 있는 빌드 호스트의 도구를 나열하며, 빌드 시스템은 이를 ${TMPDIR}/hosttools에 심볼릭 링크로 연결합니다. BitBake는 또한 -native 및 -cross 레시피로 자체 도구를 빌드합니다. 호스트 도구는 이미지에 영향을 주지만, 설계상 이미지의 일부가 아닙니다.

2. 가져오기

레시피는 SRC_URI에 소스를 지정하고, 페처는 이를 DL_DIR로 다운로드합니다. 페처는 먼저 DL_DIR를, 그다음 PREMIRRORS를, 그다음 업스트림을, 마지막으로 MIRRORS를 찾습니다. Rust 크레이트는 crate:// 페처를 통해 들어오며, -crates.inc 파일에 나열됩니다. 이 파일은 cargo-update-recipe-crates가 Cargo.lock에서 생성합니다. Go 모듈은 go-mod 클래스를 통해 들어오거나 go-vendor로 벤더링됩니다. BB_NO_NETWORK와 BB_ALLOWED_NETWORKS는 페처가 접속할 수 있는 대상을 제어합니다.

3. 레시피와 패치

각 레시피는 PV에 업스트림 버전을 고정하고 그 위에 패치를 적용합니다. 헤더에 CVE: 줄이 있는 패치는 해당 CVE를 패치됨으로 표시합니다. 버전 번호는 업스트림 버전 그대로이므로, 레시피는 수정되었는데 버전은 그렇지 않다고 말할 수 있습니다.

4. 컴파일된 코드

정적 라이브러리(-staticdev 패키지), Rust 크레이트, Go 모듈은 이를 사용하는 바이너리 안에 들어갑니다. 커널과 모듈은 제품별 구성으로 빌드되므로, 같은 커널 버전을 쓰는 두 플랫폼도 서로 다른 코드를 포함합니다.

5. 이미지

루트 파일 시스템입니다. package-management 이미지 기능은 패키지 관리 도구를 설치하고 패키지 관리자 데이터베이스를 보존합니다. 이 기능이 없으면 패키지 관리자의 데이터 파일이 루트 파일 시스템에서 삭제되며, 프로덕션 이미지에서는 흔한 일입니다.

shared state(sstate) 캐시

BitBake는 태스크를 실행하는 대신 shared state(공유 상태) 캐시에서 태스크의 결과물을 복원할 수 있습니다. Yocto 개요 매뉴얼은 이를 분명히 말합니다. 미리 빌드된 객체가 있으면 컴파일러가 필요 없으며, "따라서 컴파일러는 다운로드조차 되지 않습니다". sstate에서 복원된 태스크는 가져오기, 컴파일, 설치를 건너뛰며, 이는 이 단계들을 관찰하는 데 의존하는 모든 도구에 중요합니다. 자세한 내용은 아래 캐시 섹션에서 다룹니다.

이미지 및 파일 시스템 스캐너가 대부분을 놓치는 이유

• 패키지 데이터베이스가 없습니다. package-management 없이 빌드된 프로덕션 이미지는 스캐너에 읽을 목록을 주지 않으므로, 스캐너는 파일 휴리스틱에 의존하거나 거의 아무것도 보고하지 않습니다. 결과는 완전해 보이지만 거의 비어 있습니다.
• 정적 코드와 벤더링된 코드. /usr/bin/foo에 컴파일된 정적 라이브러리나 크레이트는 패키지 기록을 남기지 않습니다. librsvg가 그 예입니다. 현재 oe-core 레시피에는 350개가 넘는 Rust 크레이트가 나열되어 있지만, 디바이스에서는 하나의 공유 라이브러리입니다.
• 빌드 호스트와 가져온 도구. 이들은 이미지에 결코 들어가지 않으므로 이미지 스캔에도 결코 나타나지 않습니다. 하지만 침해된 호스트 도구나 GitHub Action은 이미지를 침해할 수 있습니다. xz utils 백도어(CVE-2024-3094)는 Git 저장소가 아닌 릴리스 tarball을 통해, 라이브러리가 빌드되는 동안 들어갔습니다. 2025년 3월 CISA는 GitHub Action tj-actions/changed-files의 모든 버전이 3일 동안 침해되었다고 보고했습니다.
• 적용된 패치. 이미지에는 업스트림 버전의 openssl로 표시됩니다. 레시피는 그 버전에 영향을 주는 CVE의 수정 사항을 적용하고 패치에 CVE: 태그를 달았습니다. 그래도 버전 범위 매칭은 이를 탐지합니다. 이는 배포판 백포트 문제의 Yocto 버전이며, 취약점 노이즈를 줄이는 방법에서 다루는 노이즈의 주요 원인 중 하나입니다.

결과적으로 누락된 구성 요소와 잘못된 탐지 결과가 뒤섞이며, 결과 어디에도 무엇이 어느 쪽인지 알려 주지 않습니다. 같은 논리가 Docker 이미지 SBOM의 컨테이너에도, 오픈 소스 SBOM 생성기의 언어 프로젝트에도 적용됩니다.

펌웨어 바이너리 스캔이 추측할 수밖에 없는 이유

바이너리 분석은 추출한 펌웨어의 문자열, 심볼, 코드 시그니처를 알려진 구성 요소와 매칭한 다음 버전을 추론합니다. 바이너리에 명확한 단서가 있으면 이 방식은 통합니다. Yocto 이미지에서는 추측해야 하는 경우가 많습니다.

• 버전 문자열이 없는, 스트립된 바이너리
• 라이브러리 경계가 사라진, 정적으로 링크된 코드
• 크레이트 경계가 하나의 실행 파일 속으로 사라지는, 컴파일된 Rust
• 버전 번호에는 보이지 않는, 백포트된 패치
• 구성에 따라 컴파일에 포함되거나 제외된 커널 코드

바이너리 분석은 직접 빌드하지 않은 펌웨어에 맞는 도구입니다. 공급업체의 바이너리 블롭, 구매한 모듈, 평가 중인 디바이스 등입니다. 빌드가 없다면 바이너리 분석이 유일한 선택지입니다. 판단 기준은 간단합니다. 직접 빌드한다면 기록하고, 받기만 한다면 분석하면서 공급업체에 그들의 빌드에서 나온 SBOM을 요청하세요.

Yocto 자체의 SBOM 및 CVE 도구가 잘하는 것

Yocto Project의 SBOM 작업은 훌륭한 엔지니어링이며, 외부 도구는 알 수 없는 것을 알고 있습니다. 문서는 SBOM을 "사용한 모든 구성 요소, 그 라이선스, 종속성, 소스, 그에 적용된 변경 사항, 수정된 알려진 취약점에 대한 설명"이라고 말합니다.

릴리스별 create-spdx

• 4.3(Nanbield): SPDX 생성이 기본적으로 켜져 있습니다.
• 5.1(Styhead): 2.2 대신 SPDX 3.0이 기본값이 되었고, 외부 CVE 도구에 필요한 정보를 제공하는 vex 클래스가 추가되었습니다.
• 5.3(Whinlatter): 컴파일에 사용된 소스만 포함하는 SPDX_INCLUDE_COMPILED_SOURCES가 추가되었습니다.
• 6.0(Wrynose, 장기 지원): SPDX 2.2가 제거되었고, SPDX_INCLUDE_KERNEL_CONFIG와 SPDX_INCLUDE_PACKAGECONFIG가 추가되었으며, Cargo, Go, PyPI, npm, CPAN 클래스로 빌드된 레시피는 에코시스템 패키지 URL을 받습니다.

SBOM은 BitBake가 호스트용으로 빌드하는 네이티브 도구를 포함해 BitBake가 빌드하는 것을 다룹니다. 레시피가 있는 모든 것에 대해 빠짐없이 기록합니다.

SBOM 안의 VEX로서의 CVE 상태

SPDX 3에서 빌드 시스템은 각 레시피의 CVE 상태를 VEX 관계로 기록합니다. 패치된 CVE는 패치 파일에 연결된 "fixed"가 되고, 패치되지 않은 CVE는 "affected", 무시된 CVE는 "not affected"가 되며 그 이유가 영향 설명이 됩니다. SPDX_INCLUDE_VEX는 포함할 범위를 정합니다. none, current(기본값, 업스트림 소스에서 아직 수정되지 않은 취약점), all 중 하나입니다.

CVE_STATUS와 패치 태그

CVE_STATUS는 CVE별 결정을 이유와 선택적 설명으로 기록합니다. 이유는 패치됨(backported-patch, cpe-stable-backport, fixed-version 등), 패치되지 않음(vulnerable-investigating), 무시됨(cpe-incorrect, disputed, not-applicable-config, not-applicable-platform, upstream-wontfix)에 대응합니다. CVE_STATUS_GROUPS는 하나의 결정을 CVE 그룹에 적용하고, CVE_PRODUCT는 매칭에 사용할 제품 이름을 설정합니다.

# In a recipe or .bbappend
CVE_STATUS[CVE-2020-15523] = "not-applicable-platform: Issue only applies on Windows"

# In the header of a patch file
CVE: CVE-2022-3341
Upstream-Status: Backport [link to the upstream commit]

cve-check에서 sbom-cve-check로

cve-check는 레시피 이름(CVE_PRODUCT)과 버전을 취약점 데이터와 매칭했습니다. 5.2 릴리스 노트는 2024년 초부터 NVD 관리자들이 많은 CVE에 영향받는 CPE를 주석으로 달지 않게 되었으므로, "현재의 CVE 보고서는 좋아 보일 수 있지만 실제로는 일부 취약점이 아예 보고되지 않는다"고 경고합니다. 5.2는 또한 NVD 대신 FKIE 피드를 기본값으로 만들었습니다. Yocto 6.0은 cve-check를 제거하고 sbom-cve-check 클래스로 대체했습니다. 이 클래스는 Bootlin의 sbom-cve-check를 SPDX 출력에 대해 실행합니다. 5.0부터 5.3까지는 여전히 cve-check가 있지만, 레거시로 취급하세요.

Yocto SBOM이 멈추는 지점

Yocto가 볼 수 없는 것은 BitBake 메타데이터 바깥의 모든 것입니다. 저희는 core-image-sato를 32 vCPU를 갖춘 네이티브 ARM64 러너에서 두 번 빌드했습니다. 한 번은 Yocto의 SBOM 생성을 켜고, 한 번은 끄고 빌드한 뒤, 1,632개 파일로 기록된 Yocto의 SPDX 3.0.1 SBOM과 CRACI가 기록한 CycloneDX SBOM을 비교했습니다.

• 구성 요소. CRACI가 기록한 SBOM에는 Yocto SBOM에 있는 모든 구성 요소와 함께, Yocto SBOM이 놓친 88개가 더 있었습니다. 빌드 머신의 호스트 패키지 23개(Ubuntu의 cpio 등), GitHub Action actions/upload-artifact를 포함한 GitHub 소스 10개, 빌드 중에 가져온 기타 소스와 도구 55개입니다.
• Rust 크레이트. 양쪽 모두 같은 653개의 Rust 크레이트 버전을 나열했습니다. 저희가 빌드한 릴리스에서 Yocto SBOM은 이를 다운로드 위치가 있는 .crate 파일로만 나열했고 pkg:cargo 패키지 URL이 없어, 권고와 매칭할 수 없었습니다. Yocto 6.0부터 Cargo 클래스로 빌드된 레시피에는 pkg:cargo/librsvg처럼 레시피 자체의 패키지 URL이 있습니다. 현재 코드에서도 개별 크레이트 다운로드에는 여전히 없습니다. 사용 중인 릴리스가 무엇을 기록하는지 확인하세요.
• 비용. Yocto SBOM 생성을 켠 빌드는 155분 40초가 걸렸고 1,632개의 SPDX 파일을 기록했습니다. 끈 빌드는 88분 48초로 43% 덜 걸렸습니다. SPDX_INCLUDE_SOURCES, SPDX_INCLUDE_COMPILED_SOURCES, SPDX_INCLUDE_KERNEL_CONFIG, SPDX_INCLUDE_PACKAGECONFIG가 켜져 있었으므로 기본 구성이라면 비용이 더 적습니다. Yocto 자체 문서도 컴파일된 소스를 포함하면 core-image-minimal의 압축하지 않은 SBOM이 "수백 메가바이트에서 수 기가바이트로 커질 수 있다"고 경고합니다.

cmake, llvm, ninja, qemu 같은 네이티브 레시피는 Yocto SBOM에 포함되어 있습니다. 방법, 두 SBOM, 전체 보고서는 CRACI의 Yocto 빌드에 있습니다.

Linux 커널 CVE: 구성별 문제

Linux 커널 프로젝트는 2024년 2월 13일 CVE Numbering Authority가 되었다고 발표했으며, 수정 사항에 CVE를 폭넓게 할당합니다. 커널의 CVE 문서는 특정 CVE의 적용 여부는 "Linux 사용자가 판단할 일"이라고 말합니다. "우리는 여러분의 사용 사례를 알지 못하며, 여러분이 커널의 어떤 부분을 사용하는지도 알지 못하기" 때문입니다.

따라서 커널 버전 매칭은 수백 건의 탐지 결과를 만들어 내며, 그 대부분은 여러분의 구성이 결코 컴파일하지 않는 코드에 대한 것입니다. 네 가지 커널 구성을 가진 네 개의 하드웨어 플랫폼은 같은 커널 버전에서 네 가지 다른 답을 냅니다. 대처 방법은 네 가지입니다.

1. 버전 매칭만 사용. 해당 버전의 모든 CVE가 보고됩니다. 노이즈가 최대입니다.
2. 선별한 제외 목록. 커널의 CVE 데이터에서 생성한 CVE_STATUS 항목입니다. 2026년 5월 oe-core는 linux-yocto용으로 생성하던 목록을 제거했습니다. sbom-cve-check가 커널이 제공하는 CVE 목록으로 이를 직접 처리하며, CVE 보고서는 그대로이고 SPDX는 20 MB 가까이 작아지기 때문입니다.
3. 컴파일된 것 기준으로 필터링. 커널 레시피에 SPDX_INCLUDE_COMPILED_SOURCES를 켜면 improve_kernel_cve_report.py가 CVE가 영향을 주는 파일이 커널 빌드에 사용되었는지 확인합니다. Yocto 보안 매뉴얼은 이것이 "CVE 오탐을 70%-80% 줄인다"고 말합니다.
4. 구성 기록. SPDX_INCLUDE_KERNEL_CONFIG(6.0)는 커널 구성을 SBOM에 기록하므로 나중에 답을 확인할 수 있습니다.

예시. 네트워크 드라이버의 커널 CVE 하나. 플랫폼 A는 드라이버를 빌드하고, 플랫폼 B는 빌드하지 않습니다.

플랫폼	드라이버 컴파일 여부	버전 매칭	컴파일된 소스 필터
A	예	보고됨	보고됨: 영향받는 파일이 빌드됨
B	아니요	보고됨	보고되지 않음: 영향받는 파일이 빌드되지 않음

지금 플랫폼별 커널 CVE 보고서가 필요하다면 Yocto의 컴파일된 소스 도구를 머신 구성마다 한 번씩 실행하세요. 답을 결정하는 것은 구성이므로, 보고서는 각 구성의 빌드에서 나와야 합니다.

캐시, 미러, 벤더링: 어떤 기록 방식이든 주의해야 할 지점

• sstate나 채워진 DL_DIR에서 모든 것을 복원하는 빌드는 거의 아무것도 가져오지 않습니다. 가져오기를 관찰하는 기록 방식은 그 캐시와 함께 증거를 이어 가야 하며, 그렇지 않으면 기록이 줄어듭니다.
• 미리 벤더링된 tarball을 가리키는 레시피는 다운로드 하나만 보여 주며, 그 안의 크레이트나 모듈은 보여 주지 않습니다.
• 무엇을 사용하든 릴리스 이미지는 알려진 캐시 상태에서 빌드하고, 직접 관리하는 미러를 유지하며, 빌드 간 구성 요소 수를 비교하세요.

CRACI에서는 CI 캐시에서 복원된 패키지도 SBOM에 남으며, 각 작업의 완전성 상태가 기록이 보지 못한 것을 표시합니다.

무엇을 실행할까: 결정표

상황	사용할 것	얻는 것	여전히 부족한 것
GitHub Actions에서 이미지를 빌드하는 경우	빌드를 기록(CRACI)하고, 패치 및 CVE 상태에 의존한다면 create-spdx를 유지	호스트 패키지, 가져온 소스와 Actions, 크레이트별 pkg:cargo URL, 지속적인 모니터링	구성별 커널 필터링: Yocto의 도구 사용
다른 CI 시스템이나 빌드 서버에서 Yocto로 빌드하는 경우	create-spdx와 sbom-cve-check(이전 릴리스에서는 cve-check), 컴파일된 소스를 이용한 커널 필터링	레시피, 패치, VEX로서의 CVE 상태	호스트 패키지와 가져온 도구의 인벤토리(별도 관리)
직접 빌드하지 않은 펌웨어를 받는 경우	바이너리 분석, 그리고 공급업체의 빌드 SBOM	바이너리에서 추론한 구성 요소	버전, 패치, 빌드 입력에 대한 확실성
플랫폼별 커널 CVE가 필요한 경우	머신 구성별로 Yocto의 컴파일된 소스 도구	각 구성이 빌드하는 코드의 CVE	커널 외 구성 요소(SBOM에서)
이미지 스캐너만 있는 경우	패키지 데이터베이스가 유지된다면 설치된 패키지에 사용	런타임 패키지 목록의 일부	컴파일되어 들어간 것, 패치된 것, 빌드 호스트에 남은 모든 것. 깨끗한 결과는 증거가 아님

각 방법이 보는 것

구성 요소 유형	이미지 스캐너	바이너리 분석	Yocto create-spdx	빌드 기록(CRACI)
설치된 패키지	패키지 데이터베이스가 유지될 때만	파일에서 추론	예	예, 빌드가 가져온 소스에서
정적 라이브러리	아니요	시그니처에서 추론	예, 레시피로	예, 빌드가 가져온 소스에서
Rust 크레이트	아니요	추론. 크레이트 경계는 사라짐	.crate 다운로드로, 크레이트별 패키지 URL 없음	예, 각각 pkg:cargo 패키지 URL 포함
Go 모듈	아니요	바이너리에서 추론	레시피의 모듈 다운로드로	예, 빌드 중에 가져온 경우
적용된 패치와 CVE 상태	아니요	아니요	예, VEX로	아니요
커널 구성	아니요	아니요	예, SPDX_INCLUDE_KERNEL_CONFIG(6.0) 사용 시	아니요
빌드 머신의 호스트 도구	아니요	아니요	아니요(네이티브 레시피는 예)	예
레시피 밖에서 가져온 빌드 도구와 GitHub Actions	아니요	아니요	아니요	예

CRACI의 역할

GitHub Actions에서 실행되는 Yocto 빌드에서 CRACI는 러너이며, 최대 32 vCPU와 96 GB RAM을 제공합니다. CRACI는 호스트 패키지, GitHub 소스와 Actions, 기타 가져온 소스를 포함해 빌드가 끌어온 것을 모든 Rust 크레이트의 패키지 URL과 함께 기록합니다. 공개된 비교에서는 Yocto SBOM에 있는 모든 구성 요소와 함께, Yocto SBOM이 놓친 88개를 더 기록했습니다. 구성 요소를 권고와 매칭하고, 새 권고가 게시될 때마다 SBOM을 계속 재평가하며, 어떤 빌드에 취약한 종속성이 포함되었는지 보여 줍니다.

BitBake는 이미 BB_ALLOWED_NETWORKS로 페처를 제한할 수 있습니다. CRACI의 이그레스 정책은 러너에 두 번째 통제를 추가합니다. 작업 시작 전에 검사되며 실패 시 차단(fail closed) 방식으로 동작하므로, 페처를 우회하는 스크립트나 도구도 허용하지 않은 호스트에는 접속할 수 없습니다.

공급망 커버리지 측면에서 CRACI의 SBOM은 create-spdx를 대체할 수 있습니다. 다만 Yocto의 SPDX에는 적용된 패치와 수정됨으로 표시된 CVE가 여전히 담기며, CRACI는 이를 기록하지 않으므로, 이에 의존한다면 create-spdx를 켜 두세요. CRACI 문서에는 core-image-sato를 빌드하는 예시가 있습니다. 일반적으로 기록이 스캔보다 나은 이유는 빌드 시점 SBOM에서, Yocto 도구 비교는 임베디드 보안 도구 비교와 CRACI와 Timesys Vigiles 비교에서 확인하세요.

CRACI가 답이 아닌 경우

• CVE_STATUS 결정이나 패치되었거나 무시된 CVE의 VEX처럼 패치 수준의 CVE 상태에 의존하는 경우. 이는 Yocto의 SPDX에 있으니 유지하세요.
• 구성별 커널 CVE 보고서가 지금 필요한 경우. Yocto의 컴파일된 소스 도구를 사용하세요.
• 펌웨어를 직접 빌드하지 않는 경우. 바이너리 분석을 사용하세요.
• Yocto 빌드를 GitHub Actions 밖에서 실행하거나 자체 인프라에서 실행해야 하는 경우. CRACI는 현재 유럽 인프라에서 관리형 러너를 제공하며, 다른 CI 시스템과 고객 호스팅 러너는 로드맵에 있습니다.
• Yocto 작업의 SBOM이 특별히 SPDX로 필요한 경우. 공개된 비교에서 CRACI의 SBOM은 CycloneDX였고, Yocto 자체의 SBOM은 SPDX입니다.

EU 시장을 위한 커넥티드 디바이스를 만들고 계신가요? CRA의 요구 사항, VEX의 작동 방식, 그리고 CRACI가 통신 및 네트워크 장비, 산업용 IoT, 소비자 가전에 어떻게 맞는지 읽어 보세요.

Yocto CVE check와 SBOM: 자주 묻는 질문

SCA 도구로 Yocto 기반 제품을 스캔할 수 없는 이유는 무엇입니까?

대부분의 SCA 도구는 매니페스트, lockfile, 이미지의 패키지 데이터베이스를 읽지만, Yocto 빌드는 BitBake 안에서 내용을 결정하기 때문입니다. 프로덕션 이미지는 패키지 데이터베이스를 빼는 경우가 많고, 정적 라이브러리와 Rust 크레이트는 바이너리에 컴파일되어 들어가며, 레시피 패치는 업스트림 버전 번호를 그대로 두고, 빌드 호스트의 도구는 이미지에 결코 들어가지 않습니다.

Trivy, Grype 또는 바이너리 스캐너로 Yocto 이미지나 펌웨어를 스캔할 수 있습니까?

할 수 있지만 얻는 것은 부분적인 답입니다. 이미지 스캐너는 패키지 데이터베이스가 유지된 경우 설치된 패키지를 읽지만, 컴파일되어 들어간 것은 놓칩니다. 바이너리 스캐너는 문자열과 시그니처로 구성 요소를 추론하며, 스트립된 바이너리, 정적 코드, 컴파일된 Rust에서는 추측해야 합니다. 둘 다 빌드 호스트나 레시피가 적용한 패치는 보지 못합니다.

Yocto의 SBOM에 Rust 크레이트와 Go 모듈이 포함됩니까?

이를 사용하는 레시피의 소스로 나열됩니다. 저희가 빌드한 릴리스에서 각 Rust 크레이트는 다운로드 위치가 있는 .crate 다운로드로 나타났고 pkg:cargo 패키지 URL은 없었습니다. Yocto 6.0부터 Cargo 및 Go 클래스로 빌드된 레시피는 에코시스템 패키지 URL을 받지만, 이는 레시피 자체에 대한 것이며 각 크레이트나 모듈 다운로드에 대한 것은 아닙니다.

Yocto 레시피에서 이미 패치한 CVE를 스캐너가 보고하는 이유는 무엇입니까?

스캐너가 버전 번호를 매칭하기 때문입니다. Yocto 레시피는 업스트림 버전을 유지하고 보안 수정 사항을 패치로 적용하며, 이 패치에는 CVE: 줄로 태그가 달리거나 CVE_STATUS에 기록됩니다. 버전 범위 매칭은 패치를 볼 수 없습니다. Yocto 자체의 SPDX는 이러한 CVE를 패치 파일에 연결해 수정됨으로 기록합니다.

Yocto에서 cve-check를 대체한 것은 무엇입니까?

Yocto 6.0의 sbom-cve-check 클래스입니다. 빌드의 SPDX 출력에 대해 Bootlin의 sbom-cve-check를 실행합니다. 릴리스 5.0부터 5.3까지는 레시피 이름과 버전을 매칭하는 cve-check가 여전히 있으며, 5.2 릴리스 노트는 많은 CVE에 더 이상 CPE 데이터가 없어 그 보고서가 취약점을 놓칠 수 있다고 경고합니다.

자체 커널 구성에 대한 Linux 커널 CVE는 어떻게 얻습니까?

커널 레시피에 SPDX_INCLUDE_COMPILED_SOURCES를 켜고 improve_kernel_cve_report.py를 실행하세요. 이 스크립트는 각 CVE가 영향을 주는 파일이 컴파일되었는지 확인합니다. Yocto 보안 매뉴얼에 따르면 CVE 오탐이 70%에서 80%까지 줄어듭니다. 구성마다 빌드되는 코드가 다르므로 머신 구성별로 실행하세요.

shared state 캐시가 SBOM에 영향을 줍니까?

그럴 수 있습니다. sstate에서 복원된 태스크는 가져오기와 컴파일을 건너뛰므로, 이 단계들을 관찰하는 데 의존하는 도구는 더 적게 봅니다. Yocto의 create-spdx는 레시피 메타데이터를 기반으로 동작합니다. 어떤 방법이든 릴리스 이미지는 알려진 캐시 상태에서 빌드하고 빌드 간 구성 요소 수를 비교하세요.

Yocto에 내장된 SBOM으로 CRA에 충분합니까?

CRA는 최소한 최상위 종속성을 포함하는 SBOM을 요구하며, Yocto의 SBOM은 BitBake가 빌드하는 것에 대해서는 빠짐없이 기록합니다. 하지만 빌드 머신의 호스트 패키지, GitHub Actions, 레시피 밖에서 가져온 도구는 나열하지 않습니다. 그것으로 충분한지는 여러분이 판단할 일입니다. SBOM은 프로세스의 증거일 뿐, 그 자체로 규정 준수는 아닙니다.