Waarom SBOM-scanners missen wat er in Yocto-builds zit

Hoe een Yocto-build verschilt van wat scanners verwachten

Een Yocto-build is geen installatie via een pakketbeheerder. Het meeste van wat op het apparaat terechtkomt, wordt tijdens de build bepaald, binnen BitBake, in vijf lagen. Scanners bekijken achteraf één laag en moeten de rest raden.

1. De buildhost

BitBake draait met tools van de buildmachine. De variabele HOSTTOOLS somt de tools op de buildhost op die buildtaken mogen aanroepen, en het buildsysteem maakt er symlinks naar in ${TMPDIR}/hosttools. BitBake bouwt ook zijn eigen tools via -native- en -cross-recipes. Hosttools beïnvloeden de image en maken er bewust geen deel van uit.

2. Ophalen

Recipes noemen hun bronnen in SRC_URI, en de fetcher downloadt ze naar DL_DIR. Hij kijkt eerst in DL_DIR, dan in PREMIRRORS, dan upstream, dan in MIRRORS. Rust-crates komen via de fetcher crate://, vermeld in een -crates.inc-bestand dat cargo-update-recipe-crates genereert uit Cargo.lock. Go-modules komen via de class go-mod of worden gevendord met go-vendor. BB_NO_NETWORK en BB_ALLOWED_NETWORKS bepalen wat de fetcher mag bereiken.

3. Recipes en patches

Elke recipe legt een upstreamversie vast in PV en past daarbovenop patches toe. Een patch met een regel CVE: in de header markeert die CVE als gepatcht. Het versienummer blijft dat van upstream, dus de recipe kan opgelost zijn terwijl de versie iets anders zegt.

4. Gecompileerde code

Statische bibliotheken (de -staticdev-pakketten), Rust-crates en Go-modules belanden in de binaries die ze gebruiken. De kernel en zijn modules worden gebouwd vanuit een productspecifieke configuratie, dus twee platforms met dezelfde kernelversie bevatten verschillende code.

5. De image

Het root-bestandssysteem. De image-feature package-management installeert tools voor pakketbeheer en bewaart de database van de pakketbeheerder. Zonder die feature worden de databestanden van de pakketbeheerder uit het root-bestandssysteem verwijderd, wat gebruikelijk is bij productie-images.

De shared state (sstate) cache, de gedeelde statuscache

BitBake kan de uitvoer van een taak uit de sstate-cache herstellen in plaats van de taak uit te voeren. De overview-handleiding van Yocto zegt het duidelijk: als de vooraf gebouwde objecten beschikbaar zijn, is de compiler niet nodig, “dus wordt de compiler niet eens gedownload”. Taken die uit sstate worden hersteld, slaan fetch, compile en install over, en dat doet ertoe voor elke tool die erop vertrouwt die stappen te observeren. Meer daarover in de sectie over caches hieronder.

Waarom image- en bestandssysteemscanners het meeste missen

• Geen pakketdatabase. Een productie-image die zonder package-management is gebouwd, geeft een scanner geen lijst om te lezen, dus valt die terug op bestandsheuristieken of meldt hij bijna niets. Het resultaat ziet er volledig uit en is bijna leeg.
• Statische en gevendorde code. Een statische bibliotheek of een crate die in /usr/bin/foo is gecompileerd, laat geen pakketrecord achter. librsvg is een voorbeeld: de huidige oe-core-recipe vermeldt meer dan 350 Rust-crates, en op het apparaat is het één shared library.
• Buildhost en opgehaalde tools. Ze zitten nooit in de image, dus nooit in een imagescan, terwijl een gecompromitteerde hosttool of GitHub Action de image kan compromitteren. De backdoor in xz utils (CVE-2024-3094) kwam in de bibliotheek terecht terwijl die werd gebouwd, vanuit release-tarballs in plaats van de Git-repository. In maart 2025 meldde CISA dat elke versie van de GitHub Action tj-actions/changed-files drie dagen lang gecompromitteerd was.
• Toegepaste patches. De image vermeldt openssl in een upstreamversie. De recipe heeft de fix voor een CVE die deze versie treft toegepast en de patch gemarkeerd met CVE:. Een match op versiebereik meldt hem toch. Dit is de Yocto-vorm van het backportprobleem van distributies, en een van de belangrijkste bronnen van de ruis die wordt behandeld in hoe u kwetsbaarheidsruis vermindert.

Opgeteld is het een mengeling van ontbrekende componenten en onjuiste bevindingen, en niets in het resultaat vertelt u welke welke is. Hetzelfde argument geldt voor containers in SBOM's van Docker-images en voor taalprojecten in opensource-SBOM-generators.

Waarom binaire analyse van firmware moet gokken

Binaire analyse vergelijkt strings, symbolen en codesignaturen in uitgepakte firmware met bekende componenten en leidt daaruit versies af. Waar de binary duidelijk bewijs bevat, werkt dat. In een Yocto-image moet ze vaak gokken:

• gestripte binaries zonder versiestrings;
• statisch gelinkte code, waarin de grenzen tussen bibliotheken zijn verdwenen;
• gecompileerde Rust, waarin de grenzen tussen crates opgaan in één uitvoerbaar bestand;
• gebackporte patches, die onzichtbaar zijn in een versienummer;
• kernelcode die de configuratie wel of niet heeft meegecompileerd.

Binaire analyse is de juiste tool voor firmware die u niet zelf hebt gebouwd: blobs van leveranciers, ingekochte modules, een apparaat dat u evalueert. Als u de build niet hebt, is het analyseren van de binary de enige optie. De beslisregel is eenvoudig: bouwt u het, leg het dan vast; ontvangt u het alleen, analyseer het dan en vraag de leverancier om een SBOM uit diens build.

Waar de eigen SBOM- en CVE-tooling van Yocto goed in is

Het SBOM-werk van het Yocto Project is degelijk engineeringwerk, en het weet dingen die geen externe tool kan weten. De documentatie noemt de SBOM “een beschrijving van alle componenten die u hebt gebruikt, hun licenties, hun afhankelijkheden, hun bronnen, de wijzigingen die erop zijn toegepast en de bekende kwetsbaarheden die zijn opgelost”.

create-spdx per release

• 4.3 (Nanbield): SPDX-generatie staat standaard aan.
• 5.1 (Styhead): standaard SPDX 3.0 in plaats van 2.2, en een class vex die externe CVE-tools de informatie geeft die ze nodig hebben.
• 5.3 (Whinlatter): SPDX_INCLUDE_COMPILED_SOURCES, dat alleen de bronnen opneemt die voor het compileren zijn gebruikt.
• 6.0 (Wrynose, long-term support): SPDX 2.2 verwijderd; SPDX_INCLUDE_KERNEL_CONFIG en SPDX_INCLUDE_PACKAGECONFIG toegevoegd; recipes die met de classes voor Cargo, Go, PyPI, npm en CPAN worden gebouwd, krijgen een package URL van hun ecosysteem.

De SBOM dekt wat BitBake bouwt, inclusief de native tools die het voor de host bouwt. Ze is grondig voor alles wat een recipe heeft.

CVE-status als VEX in de SBOM

In SPDX 3 schrijft het buildsysteem de CVE-status van elke recipe als VEX-relaties: een gepatchte CVE wordt “fixed”, gekoppeld aan de patchbestanden; een ongepatchte “affected”; een genegeerde “not affected”, met de reden als impact statement. SPDX_INCLUDE_VEX bepaalt hoeveel erin komt: none, current (de standaard, kwetsbaarheden die nog niet in de upstreambron zijn opgelost) of all.

CVE_STATUS en de patchtag

CVE_STATUS legt per CVE een beslissing vast, als reden en een optionele beschrijving. De redenen vallen onder gepatcht (backported-patch, cpe-stable-backport, fixed-version en andere), ongepatcht (vulnerable-investigating) en genegeerd (cpe-incorrect, disputed, not-applicable-config, not-applicable-platform, upstream-wontfix). CVE_STATUS_GROUPS past één beslissing toe op een groep CVE's, en CVE_PRODUCT stelt de productnaam in die voor het matchen wordt gebruikt.

# 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]

Van cve-check naar sbom-cve-check

cve-check matchte recipenamen (CVE_PRODUCT) en versies met kwetsbaarheidsdata. De release notes van 5.2 waarschuwen dat de beheerders van de NVD sinds begin 2024 veel CVE's niet meer annoteren met de getroffen CPE's, zodat “de huidige CVE-rapporten er goed uit kunnen zien, maar in werkelijkheid sommige kwetsbaarheden gewoon niet worden gemeld”. Met 5.2 werd ook de FKIE-feed de standaard in plaats van de NVD. Yocto 6.0 heeft cve-check verwijderd en vervangen door de class sbom-cve-check, die sbom-cve-check van Bootlin uitvoert op de SPDX-uitvoer. Op 5.0 tot en met 5.3 hebt u nog cve-check; beschouw het als legacy.

Waar de SBOM van Yocto ophoudt

Wat Yocto niet kan zien, is alles buiten de metadata van BitBake. We hebben core-image-sato twee keer gebouwd op een native ARM64-runner met 32 vCPU's, één keer met de SBOM-generatie van Yocto en één keer zonder, en de SPDX 3.0.1-SBOM van Yocto, geschreven als 1.632 bestanden, vergeleken met de CycloneDX-SBOM die CRACI vastlegde:

• Componenten. De door CRACI vastgelegde SBOM bevatte elke component uit de SBOM van Yocto, plus 88 die daarin ontbraken: 23 hostpakketten op de buildmachine (zoals cpio van Ubuntu), 10 GitHub-bronnen, waaronder de GitHub Action actions/upload-artifact, en 55 andere bronnen en tools die tijdens de build werden opgehaald.
• Rust-crates. Beide vermeldden dezelfde 653 versies van Rust-crates. In de release die wij bouwden, vermeldde de SBOM van Yocto ze alleen als .crate-bestanden met een downloadlocatie, zonder pkg:cargo-package URL, zodat ze niet tegen advisories konden worden gematcht. Sinds Yocto 6.0 dragen recipes die met de Cargo-class worden gebouwd een package URL voor de recipe zelf, zoals pkg:cargo/librsvg; in de huidige code hebben de afzonderlijke crate-downloads er nog steeds geen. Controleer wat uw release schrijft.
• Kosten. De build met de SBOM-generatie van Yocto duurde 155 min 40 s en schreef 1.632 SPDX-bestanden. Zonder duurde de build 88 min 48 s, 43% minder. SPDX_INCLUDE_SOURCES, SPDX_INCLUDE_COMPILED_SOURCES, SPDX_INCLUDE_KERNEL_CONFIG en SPDX_INCLUDE_PACKAGECONFIG stonden aan, dus een standaardconfiguratie kost minder. De eigen documentatie van Yocto waarschuwt dat met opgenomen gecompileerde bronnen de ongecomprimeerde SBOM van core-image-minimal “kan groeien van honderden megabytes tot meerdere gigabytes”.

Native recipes zoals cmake, llvm, ninja en qemu staan in de SBOM van Yocto. De methode, beide SBOM's en het volledige rapport staan op Yocto-builds op CRACI.

CVE's in de Linux-kernel: het probleem per configuratie

Het Linux-kernelproject maakte op 13 februari 2024 bekend dat het CVE Numbering Authority was geworden, en het kent royaal CVE's toe aan fixes. De CVE-documentatie zegt dat de toepasselijkheid van een specifieke CVE “door de gebruiker van Linux moet worden bepaald”, omdat “we uw use case niet kennen en niet weten welke delen van de kernel u gebruikt”.

Een match op kernelversie levert dus honderden bevindingen op, de meeste voor code die uw configuratie nooit compileert. Vier hardwareplatforms met vier kernelconfiguraties geven vier verschillende antwoorden voor dezelfde kernelversie. Er zijn vier manieren om ermee om te gaan:

1. Alleen versiematching. Elke CVE voor de versie wordt gemeld. Maximale ruis.
2. Samengestelde uitsluitingslijsten. CVE_STATUS-items gegenereerd uit de CVE-data van de kernel. In mei 2026 verwijderde oe-core zijn gegenereerde lijst voor linux-yocto, omdat sbom-cve-check dit zelf doet op basis van de CVE-lijst die de kernel levert, met een ongewijzigd CVE-rapport en een SPDX die bijna 20 MB kleiner is.
3. Filteren op wat is gecompileerd. Met SPDX_INCLUDE_COMPILED_SOURCES aan voor de kernelrecipe controleert improve_kernel_cve_report.py of de bestanden die een CVE treft zijn gebruikt om de kernel te bouwen. Volgens de securityhandleiding van Yocto “vermindert het CVE-false-positives met 70%-80%”.
4. De configuratie vastleggen. SPDX_INCLUDE_KERNEL_CONFIG (6.0) schrijft de kernelconfiguratie in de SBOM, zodat het antwoord later kan worden gecontroleerd.

Uitgewerkt voorbeeld. Eén kernel-CVE in een netwerkdriver. Platform A bouwt de driver; platform B niet.

Platform	Driver gecompileerd?	Versiematch	Filter op gecompileerde bronnen
A	Ja	Gemeld	Gemeld: de getroffen bestanden zijn gebouwd
B	Nee	Gemeld	Niet gemeld: de getroffen bestanden zijn niet gebouwd

Voor kernel-CVE-rapporten per platform voert u vandaag de tooling van Yocto voor gecompileerde bronnen één keer per machineconfiguratie uit. De configuratie bepaalt het antwoord, dus het rapport moet uit de build van elke configuratie komen.

Caches, mirrors en vendoring: waar elke recorder voorzichtig moet zijn

• Een build die alles herstelt uit sstate of uit een gevulde DL_DIR haalt weinig of niets op. Een recorder die downloads ziet, moet zijn bewijs met die caches meenemen, anders krimpt de vastlegging.
• Een recipe die naar een vooraf gevendorde tarball verwijst, toont één download, niet de crates of modules erin.
• Wat u ook gebruikt: bouw release-images vanuit een bekende cachestatus, houd mirrors aan die u zelf beheert en vergelijk het aantal componenten tussen builds.

Op CRACI blijven pakketten die uit CI-caches worden hersteld in de SBOM, en de volledigheidsstatus van elke job geeft aan wat de vastlegging niet kon zien.

Wat u inzet: een beslistabel

Situatie	Wat u gebruikt	Wat u krijgt	Wat u nog mist
U bouwt de image in GitHub Actions	Leg de build vast (CRACI); behoud create-spdx als u op de patch- en CVE-status ervan vertrouwt	Hostpakketten, opgehaalde bronnen en Actions, een pkg:cargo-URL per crate, doorlopende monitoring	Kernelfiltering per configuratie: gebruik de tooling van Yocto
U bouwt met Yocto in een ander CI-systeem of op een buildserver	create-spdx met sbom-cve-check (of cve-check op oudere releases), kernelfiltering met gecompileerde bronnen	Recipes, patches, CVE-status als VEX	Een inventaris van hostpakketten en opgehaalde tools, apart bijgehouden
U ontvangt firmware die u niet bouwt	Binaire analyse, en een build-SBOM van de leverancier	Componenten afgeleid uit de binary	Zekerheid over versies, patches en build-inputs
U hebt kernel-CVE's per platform nodig	De tooling van Yocto voor gecompileerde bronnen, per machineconfiguratie	CVE's voor de code die elke configuratie bouwt	Componenten buiten de kernel, uit uw SBOM
U hebt alleen een imagescanner	Gebruik hem voor geïnstalleerde pakketten, als de pakketdatabase behouden blijft	Een deel van de runtime-pakketlijst	Alles wat is meegecompileerd, gepatcht of op de buildhost is gebleven; een schoon resultaat is geen bewijs

Wat elke methode ziet

Componentklasse	Imagescanner	Binaire analyse	Yocto create-spdx	Build vastleggen (CRACI)
Geïnstalleerde pakketten	Alleen als de pakketdatabase behouden blijft	Afgeleid uit bestanden	Ja	Ja, uit de bronnen die de build ophaalde
Statische bibliotheken	Nee	Afgeleid uit signaturen	Ja, als recipes	Ja, uit de bronnen die de build ophaalde
Rust-crates	Nee	Afgeleid; grenzen tussen crates verdwijnen	Als .crate-downloads, zonder package URL per crate	Ja, elk met een pkg:cargo-package URL
Go-modules	Nee	Afgeleid uit de binary	Als moduledownloads van de recipe	Ja, als ze tijdens de build worden opgehaald
Toegepaste patches en CVE-status	Nee	Nee	Ja, als VEX	Nee
Kernelconfiguratie	Nee	Nee	Ja, met SPDX_INCLUDE_KERNEL_CONFIG (6.0)	Nee
Hosttools op de buildmachine	Nee	Nee	Nee (native recipes wel)	Ja
Buildtools die buiten recipes worden opgehaald, en GitHub Actions	Nee	Nee	Nee	Ja

Waar CRACI past

Voor Yocto-builds die in GitHub Actions draaien, is CRACI de runner, met tot 32 vCPU's en 96 GB RAM. CRACI legt vast wat de build binnenhaalde, inclusief hostpakketten, GitHub-bronnen en Actions en andere opgehaalde bronnen, met een package URL voor elke Rust-crate: in de gepubliceerde vergelijking elke component uit de SBOM van Yocto, plus 88 die daarin ontbraken. CRACI matcht de componenten tegen advisories, blijft de SBOM opnieuw beoordelen wanneer er nieuwe worden gepubliceerd, en laat zien welke builds een kwetsbare afhankelijkheid bevatten.

BitBake kan zijn fetcher al beperken met BB_ALLOWED_NETWORKS. De egress policy van CRACI voegt een tweede controle toe op de runner, gecontroleerd voordat de job start en fail-closed, zodat een script of tool die de fetcher omzeilt nog steeds geen host kan bereiken die u niet hebt toegestaan.

Voor dekking van de supply chain kan de SBOM van CRACI create-spdx vervangen. De SPDX van Yocto bevat nog steeds de toegepaste patches en de als opgelost gemarkeerde CVE's, die CRACI niet vastlegt, dus laat create-spdx aan staan als u daarop vertrouwt. De documentatie van CRACI bevat een voorbeeld dat core-image-sato bouwt. Waarom vastleggen in het algemeen beter is dan scannen, leest u op SBOM's tijdens de build; Yocto-tools worden vergeleken op embedded-securitytools vergeleken en CRACI vs Timesys Vigiles.

Wanneer CRACI niet het antwoord is

• U vertrouwt op CVE-status op patchniveau, zoals beslissingen in CVE_STATUS en gepatchte of genegeerde CVE's als VEX. Dat zit in de SPDX van Yocto: behoud die.
• U hebt vandaag kernel-CVE-rapporten per configuratie nodig. Gebruik de tooling van Yocto voor gecompileerde bronnen.
• U bouwt de firmware niet zelf. Gebruik binaire analyse.
• Uw Yocto-builds draaien buiten GitHub Actions, of moeten op uw eigen infrastructuur draaien. CRACI biedt vandaag managed runners op Europese infrastructuur; andere CI-systemen en door de klant gehoste runners staan op de roadmap.
• U hebt de SBOM van de Yocto-job specifiek in SPDX nodig. De SBOM van CRACI in de gepubliceerde vergelijking was CycloneDX; de eigen SBOM van Yocto is SPDX.

Bouwt u verbonden apparaten voor de EU-markt? Lees wat de CRA vereist, hoe VEX werkt, en hoe CRACI past bij telecom- en netwerkapparatuur, industriële IoT en consumentenelektronica.

Yocto-CVE-checks en SBOM's: veelgestelde vragen

Waarom kan mijn SCA-tool onze op Yocto gebaseerde producten niet scannen?

Omdat de meeste SCA-tools manifests, lockfiles of de pakketdatabase van een image lezen, terwijl een Yocto-build zijn inhoud binnen BitBake bepaalt. Productie-images laten de pakketdatabase vaak weg, statische bibliotheken en Rust-crates worden in binaries gecompileerd, patches in recipes laten de upstreamversienummers staan, en de tools van de buildhost komen nooit in de image terecht.

Kan ik een Yocto-image of firmware scannen met Trivy, Grype of een binaire scanner?

Dat kan, en u krijgt een gedeeltelijk antwoord. Een imagescanner leest de geïnstalleerde pakketten als de pakketdatabase behouden blijft, en mist wat is meegecompileerd. Een binaire scanner leidt componenten af uit strings en signaturen en moet gokken bij gestripte binaries, statische code en gecompileerde Rust. Geen van beide ziet de buildhost of de patches die een recipe heeft toegepast.

Bevat de SBOM van Yocto Rust-crates en Go-modules?

Ze vermeldt ze als bronnen van de recipe die ze gebruikt. In de release die wij bouwden, verscheen elke Rust-crate als .crate-download met een downloadlocatie en zonder pkg:cargo-package URL. Sinds Yocto 6.0 krijgen recipes die met de classes voor Cargo en Go worden gebouwd een package URL van hun ecosysteem voor de recipe zelf, niet voor elke afzonderlijke crate- of moduledownload.

Waarom meldt mijn scanner CVE's die onze Yocto-recipes al patchen?

Omdat hij versienummers matcht. Een Yocto-recipe behoudt de upstreamversie en past beveiligingsfixes toe als patches, gemarkeerd met een regel CVE: of vastgelegd in CVE_STATUS. Een match op versiebereik kan de patch niet zien. De eigen SPDX van Yocto legt die CVE's vast als opgelost, gekoppeld aan de patchbestanden.

Wat heeft cve-check in Yocto vervangen?

De class sbom-cve-check, in Yocto 6.0. Die voert sbom-cve-check van Bootlin uit op de SPDX-uitvoer van de build. Releases 5.0 tot en met 5.3 hebben nog cve-check, dat recipenamen en versies matchte; de release notes van 5.2 waarschuwen dat de rapporten ervan kwetsbaarheden kunnen missen, omdat veel CVE's geen CPE-data meer bevatten.

Hoe krijg ik CVE's van de Linux-kernel voor mijn eigen kernelconfiguratie?

Zet SPDX_INCLUDE_COMPILED_SOURCES aan voor de kernelrecipe en voer improve_kernel_cve_report.py uit, dat controleert of de bestanden die elke CVE treft zijn gecompileerd. Volgens de securityhandleiding van Yocto vermindert het CVE-false-positives met 70% tot 80%. Voer het uit per machineconfiguratie, want elke configuratie bouwt andere code.

Heeft de shared state-cache invloed op de SBOM?

Dat kan. Taken die uit sstate worden hersteld, slaan fetch en compile over, dus een tool die erop vertrouwt die stappen te observeren, ziet minder. create-spdx van Yocto werkt op basis van de metadata van recipes. Bouw bij elke methode release-images vanuit een bekende cachestatus en vergelijk het aantal componenten tussen builds.

Is de ingebouwde SBOM van Yocto genoeg voor de CRA?

De CRA vraagt om een SBOM die ten minste de afhankelijkheden op het hoogste niveau dekt, en de SBOM van Yocto is grondig voor wat BitBake bouwt. Ze vermeldt geen hostpakketten op de buildmachine, geen GitHub Actions en geen tools die buiten recipes worden opgehaald. Of dat genoeg is, beslist u zelf; de SBOM is bewijs voor uw proces, geen compliance op zich.