Hvorfor SBOM-skannere går glipp av innholdet i Yocto-bygg

Hvordan et Yocto-bygg skiller seg fra det skannere forventer

Et Yocto-bygg er ikke en installasjon fra en pakkebehandler. Det meste av det som havner på enheten, avgjøres ved byggetid, inne i BitBake, i fem lag. Skannere ser på ett lag i etterkant og må gjette resten.

1. Byggeverten

BitBake kjører med verktøy fra byggemaskinen. Variabelen HOSTTOOLS lister verktøyene på byggeverten som byggeoppgaver kan kalle, og byggesystemet lager symbolske lenker til dem i ${TMPDIR}/hosttools. BitBake bygger også sine egne verktøy gjennom -native- og -cross-oppskrifter. Vertsverktøy påvirker imaget, og de er bevisst ikke en del av det.

2. Henting

Oppskrifter oppgir kildene sine i SRC_URI, og fetcheren laster dem ned til DL_DIR. Den ser først i DL_DIR, deretter i PREMIRRORS, deretter upstream og til slutt i MIRRORS. Rust-crates kommer gjennom fetcheren crate://, listet i en -crates.inc-fil som cargo-update-recipe-crates genererer fra Cargo.lock. Go-moduler kommer gjennom klassen go-mod eller vendores med go-vendor. BB_NO_NETWORK og BB_ALLOWED_NETWORKS styrer hva fetcheren får nå.

3. Oppskrifter og patcher

Hver oppskrift låser en upstream-versjon i PV og legger patcher oppå. En patch med en CVE:-linje i headeren markerer den CVE-en som patchet. Versjonsnummeret forblir upstream-versjonen, så oppskriften kan være rettet mens versjonen sier noe annet.

4. Kompilert kode

Statiske biblioteker (-staticdev-pakkene), Rust-crates og Go-moduler havner inne i binærfilene som bruker dem. Kjernen og modulene bygges fra en produktspesifikk konfigurasjon, så to plattformer med samme kjerneversjon inneholder forskjellig kode.

5. Imaget

Rotfilsystemet. Image-funksjonen package-management installerer verktøy for pakkehåndtering og bevarer pakkebehandlerens database. Uten den slettes pakkebehandlerens datafiler fra rotfilsystemet, noe som er vanlig på produksjonsimager.

Shared state (sstate)-cachen

BitBake kan gjenopprette resultatet av en oppgave fra shared state-cachen (delt tilstand) i stedet for å kjøre den. Yoctos oversiktsmanual sier det rett ut: hvis de forhåndsbygde objektene er tilgjengelige, trengs ikke kompilatoren, "dermed blir kompilatoren ikke engang lastet ned". Oppgaver som gjenopprettes fra sstate, hopper over henting, kompilering og installasjon, og det har betydning for ethvert verktøy som er avhengig av å observere disse stegene. Mer om det i avsnittet om cacher nedenfor.

Hvorfor image- og filsystemskannere går glipp av det meste

• Ingen pakkedatabase. Et produksjonsimage bygget uten package-management gir skanneren ingen liste å lese, så den faller tilbake på filheuristikk eller rapporterer nesten ingenting. Resultatet ser fullstendig ut og er nesten tomt.
• Statisk og vendoret kode. Et statisk bibliotek eller en crate kompilert inn i /usr/bin/foo etterlater ingen pakkeoppføring. librsvg er et eksempel: den gjeldende oe-core-oppskriften lister mer enn 350 Rust-crates, og på enheten er det ett delt bibliotek.
• Byggevert og hentede verktøy. De er aldri i imaget, og derfor aldri i en image-skanning, selv om et kompromittert vertsverktøy eller en kompromittert GitHub Action kan kompromittere imaget. Bakdøren i xz utils (CVE-2024-3094) kom inn i biblioteket mens det ble bygget, fra release-tarballer og ikke fra Git-repositoriet. I mars 2025 rapporterte CISA at alle versjoner av GitHub Action-en tj-actions/changed-files var kompromittert i tre dager.
• Påførte patcher. Imaget sier openssl i en upstream-versjon. Oppskriften påførte rettelsen for en CVE som berører den versjonen, og merket patchen med CVE:. En matching på versjonsintervall flagger den likevel. Dette er Yocto-varianten av backport-problemet fra distribusjonene, og en av hovedkildene til støyen som omtales i slik reduserer du sårbarhetsstøy.

Summen er en blanding av manglende komponenter og feil funn, og ingenting i resultatet forteller deg hva som er hva. Det samme argumentet gjelder containere i SBOM-er for Docker-imager og språkprosjekter i SBOM-generatorer med åpen kildekode.

Hvorfor binærskanning av firmware må gjette

Binæranalyse matcher strenger, symboler og kodesignaturer i utpakket firmware mot kjente komponenter, og utleder deretter versjoner. Der binærfilen inneholder tydelige spor, fungerer det. I et Yocto-image må den ofte gjette:

• strippede binærfiler uten versjonsstrenger;
• statisk lenket kode, der grensene mellom bibliotekene er borte;
• kompilert Rust, der grensene mellom crates forsvinner inn i én kjørbar fil;
• backportede patcher, som er usynlige i et versjonsnummer;
• kjernekode som konfigurasjonen kompilerte inn eller utelot.

Binæranalyse er det riktige verktøyet for firmware du ikke har bygget selv: blober fra leverandører, innkjøpte moduler, en enhet du evaluerer. Hvis du ikke har bygget, er analyse av binærfilen det eneste alternativet. Beslutningsregelen er enkel: bygger du det, registrerer du det; mottar du det bare, analyserer du det og ber leverandøren om en SBOM fra bygget deres.

Hva Yoctos egne SBOM- og CVE-verktøy gjør bra

SBOM-arbeidet i Yocto Project er god ingeniørkunst, og det vet ting ingen eksterne verktøy kan vite. Dokumentasjonen sier at SBOM-en er "en beskrivelse av alle komponentene du brukte, lisensene deres, avhengighetene deres, kildene deres, endringene som ble påført dem og de kjente sårbarhetene som ble rettet".

create-spdx per utgivelse

• 4.3 (Nanbield): SPDX-generering er på som standard.
• 5.1 (Styhead): SPDX 3.0 som standard i stedet for 2.2, og en vex-klasse som gir eksterne CVE-verktøy informasjonen de trenger.
• 5.3 (Whinlatter): SPDX_INCLUDE_COMPILED_SOURCES, som bare tar med kildene som ble brukt til å kompilere.
• 6.0 (Wrynose, langtidsstøtte): SPDX 2.2 fjernet; SPDX_INCLUDE_KERNEL_CONFIG og SPDX_INCLUDE_PACKAGECONFIG lagt til; oppskrifter bygget med klassene Cargo, Go, PyPI, npm og CPAN får en package URL for økosystemet.

SBOM-en dekker det BitBake bygger, inkludert de native verktøyene den bygger for verten. Den er grundig når det gjelder alt som har en oppskrift.

CVE-status som VEX inne i SBOM-en

I SPDX 3 skriver byggesystemet CVE-statusen til hver oppskrift som VEX-relasjoner: en patchet CVE blir "fixed", koblet til patchfilene; en upatchet blir "affected"; en ignorert blir "not affected", med begrunnelsen som konsekvensbeskrivelse. SPDX_INCLUDE_VEX bestemmer hvor mye som tas med: none, current (standard, sårbarheter som ikke allerede er rettet i upstream-kilden) eller all.

CVE_STATUS og patch-taggen

CVE_STATUS registrerer en beslutning per CVE, som en begrunnelse og en valgfri beskrivelse. Begrunnelsene tilsvarer patchet (backported-patch, cpe-stable-backport, fixed-version og andre), upatchet (vulnerable-investigating) og ignorert (cpe-incorrect, disputed, not-applicable-config, not-applicable-platform, upstream-wontfix). CVE_STATUS_GROUPS bruker én beslutning på en gruppe CVE-er, og CVE_PRODUCT angir produktnavnet som brukes ved matching.

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

Fra cve-check til sbom-cve-check

cve-check matchet oppskriftsnavn (CVE_PRODUCT) og versjoner mot sårbarhetsdata. Utgivelsesnotatene for 5.2 advarer om at NVD-vedlikeholderne siden begynnelsen av 2024 har sluttet å annotere mange CVE-er med de berørte CPE-ene, så "de nåværende CVE-rapportene kan se bra ut, men virkeligheten er at noen sårbarheter rett og slett ikke blir rapportert". 5.2 gjorde også FKIE-feeden til standard i stedet for NVD. Yocto 6.0 fjernet cve-check og erstattet den med klassen sbom-cve-check, som kjører Bootlins sbom-cve-check over SPDX-utdataene. På 5.0 til 5.3 har du fortsatt cve-check; behandle den som utgått.

Der Yoctos SBOM stopper

Det Yocto ikke kan se, er alt utenfor BitBakes metadata. Vi bygget core-image-sato to ganger på en native ARM64-runner med 32 vCPU-er, én gang med Yoctos SBOM-generering og én gang uten, og sammenlignet Yoctos SPDX 3.0.1-SBOM, skrevet som 1 632 filer, med CycloneDX-SBOM-en CRACI registrerte:

• Komponenter. SBOM-en CRACI registrerte, hadde hver komponent Yoctos SBOM hadde, pluss 88 den manglet: 23 vertspakker på byggemaskinen (som Ubuntus cpio), 10 GitHub-kilder, blant dem GitHub Action-en actions/upload-artifact, og 55 andre kilder og verktøy som ble hentet under bygget.
• Rust-crates. Begge listet de samme 653 versjonene av Rust-crates. I utgivelsen vi bygget, listet Yoctos SBOM dem bare som .crate-filer med en nedlastingsplassering, uten en pkg:cargo-package URL, så de kunne ikke matches mot advisories. Siden Yocto 6.0 har oppskrifter bygget med Cargo-klassen en package URL for selve oppskriften, for eksempel pkg:cargo/librsvg; i den nåværende koden har de enkelte crate-nedlastingene fortsatt ingen. Sjekk hva din utgivelse skriver.
• Kostnad. Bygget med Yoctos SBOM-generering tok 155 min 40 s og skrev 1 632 SPDX-filer. Uten den tok bygget 88 min 48 s, 43 % mindre. SPDX_INCLUDE_SOURCES, SPDX_INCLUDE_COMPILED_SOURCES, SPDX_INCLUDE_KERNEL_CONFIG og SPDX_INCLUDE_PACKAGECONFIG var slått på, så en standardkonfigurasjon koster mindre. Yoctos egen dokumentasjon advarer om at med kompilerte kilder inkludert kan den ukomprimerte SBOM-en for core-image-minimal "vokse fra hundrevis av megabyte til flere gigabyte".

Native oppskrifter som cmake, llvm, ninja og qemu er med i Yoctos SBOM. Metoden, begge SBOM-ene og hele rapporten finner du på Yocto-bygg på CRACI.

CVE-er i Linux-kjernen: problemet per konfigurasjon

Linux-kjerneprosjektet kunngjorde 13. februar 2024 at det var blitt en CVE Numbering Authority, og det tildeler CVE-er til rettelser i stor grad. CVE-dokumentasjonen sier at om en bestemt CVE er relevant, "er opp til brukeren av Linux å avgjøre", fordi "vi kjenner ikke ditt bruksområde, og vi vet ikke hvilke deler av kjernen du bruker".

En matching på kjerneversjon gir derfor hundrevis av funn, de fleste for kode konfigurasjonen din aldri kompilerer. Fire maskinvareplattformer med fire kjernekonfigurasjoner gir fire forskjellige svar fra samme kjerneversjon. Det finnes fire måter å håndtere dette på:

1. Bare versjonsmatching. Hver CVE for versjonen rapporteres. Maksimal støy.
2. Kuraterte eksklusjonslister. CVE_STATUS-oppføringer generert fra kjernens CVE-data. I mai 2026 fjernet oe-core sin genererte liste for linux-yocto, fordi sbom-cve-check gjør dette selv ut fra CVE-listen kjernen leverer, med en uendret CVE-rapport og en SPDX som er nesten 20 MB mindre.
3. Filtrering etter det som ble kompilert. Med SPDX_INCLUDE_COMPILED_SOURCES slått på for kjerneoppskriften sjekker improve_kernel_cve_report.py om filene en CVE berører, ble brukt til å bygge kjernen. Yoctos sikkerhetsmanual sier at det "reduserer falske positive CVE-er med 70-80 %".
4. Registrering av konfigurasjonen. SPDX_INCLUDE_KERNEL_CONFIG (6.0) skriver kjernekonfigurasjonen inn i SBOM-en, slik at svaret kan kontrolleres senere.

Gjennomgått eksempel. Én kjerne-CVE i en nettverksdriver. Plattform A bygger driveren; plattform B gjør det ikke.

Plattform	Driver kompilert?	Versjonsmatching	Filter for kompilerte kilder
A	Ja	Rapportert	Rapportert: de berørte filene ble bygget
B	Nei	Rapportert	Ikke rapportert: de berørte filene ble ikke bygget

For kjerne-CVE-rapporter per plattform i dag kjører du Yoctos verktøy for kompilerte kilder én gang per maskinkonfigurasjon. Det er konfigurasjonen som avgjør svaret, så rapporten må komme fra bygget for hver konfigurasjon.

Cacher, speil og vendoring: der enhver registrering må være forsiktig

• Et bygg som gjenoppretter alt fra sstate eller fra en fylt DL_DIR, henter lite eller ingenting. En registrering som ser hentinger, må ta med dokumentasjonen sin sammen med disse cachene, ellers krymper registreringen.
• En oppskrift som peker på en forhåndsvendoret tarball, viser én nedlasting, ikke cratene eller modulene i den.
• Uansett hva du bruker: bygg release-imager fra en kjent cachetilstand, ha speil du selv kontrollerer, og sammenlign antall komponenter mellom bygg.

På CRACI blir pakker som gjenopprettes fra CI-cacher, værende i SBOM-en, og fullstendighetsstatusen for hver jobb flagger det registreringen ikke kunne se.

Hva du bør kjøre: en beslutningstabell

Situasjon	Hva du bruker	Hva du får	Hva du fortsatt mangler
Du bygger imaget i GitHub Actions	Registrer bygget (CRACI); behold create-spdx hvis du er avhengig av patch- og CVE-statusen derfra	Vertspakker, hentede kilder og Actions, en pkg:cargo-URL per crate, løpende overvåking	Kjernefiltrering per konfigurasjon: bruk Yoctos verktøy
Du bygger med Yocto i et annet CI-system eller på en byggeserver	create-spdx med sbom-cve-check (eller cve-check på eldre utgivelser), kjernefiltrering med kompilerte kilder	Oppskrifter, patcher, CVE-status som VEX	En oversikt over vertspakker og hentede verktøy, ført separat
Du mottar firmware du ikke bygger selv	Binæranalyse, og en bygge-SBOM fra leverandøren	Komponenter utledet fra binærfilen	Sikkerhet om versjoner, patcher og byggeinput
Du trenger kjerne-CVE-er per plattform	Yoctos verktøy for kompilerte kilder, per maskinkonfigurasjon	CVE-er for koden hver konfigurasjon bygger	Komponenter utenfor kjernen, fra SBOM-en din
Du har bare en image-skanner	Bruk den for installerte pakker, hvis pakkedatabasen beholdes	En del av pakkelisten ved kjøretid	Alt som er kompilert inn, patchet eller ligger igjen på byggeverten; et rent resultat er ikke dokumentasjon

Hva hver metode ser

Komponentklasse	Image-skanner	Binæranalyse	Yocto create-spdx	Byggeregistrering (CRACI)
Installerte pakker	Bare hvis pakkedatabasen beholdes	Utledet fra filer	Ja	Ja, fra kildene bygget hentet
Statiske biblioteker	Nei	Utledet fra signaturer	Ja, som oppskrifter	Ja, fra kildene bygget hentet
Rust-crates	Nei	Utledet; grensene mellom crates forsvinner	Som .crate-nedlastinger, uten package URL per crate	Ja, hver med en pkg:cargo-package URL
Go-moduler	Nei	Utledet fra binærfilen	Som modulnedlastinger i oppskriften	Ja, når de hentes under bygget
Påførte patcher og CVE-status	Nei	Nei	Ja, som VEX	Nei
Kjernekonfigurasjon	Nei	Nei	Ja, med SPDX_INCLUDE_KERNEL_CONFIG (6.0)	Nei
Vertsverktøy på byggemaskinen	Nei	Nei	Nei (native oppskrifter, ja)	Ja
Byggeverktøy hentet utenfor oppskrifter, og GitHub Actions	Nei	Nei	Nei	Ja

Hvor CRACI passer inn

For Yocto-bygg som kjører i GitHub Actions, er CRACI runneren, med opptil 32 vCPU-er og 96 GB RAM. Den registrerer det bygget trakk inn, inkludert vertspakker, GitHub-kilder og Actions og andre hentede kilder, med en package URL for hver Rust-crate: i den publiserte sammenligningen hver komponent Yoctos SBOM hadde, pluss 88 den manglet. Den matcher komponentene mot advisories, vurderer SBOM-en på nytt etter hvert som nye publiseres, og viser hvilke bygg som inneholdt en sårbar avhengighet.

BitBake kan allerede begrense fetcheren sin med BB_ALLOWED_NETWORKS. CRACIs egress-policy legger til en kontroll til på runneren, som sjekkes før jobben starter og blokkerer ved feil, så et skript eller verktøy som går utenom fetcheren, fortsatt ikke kan nå en vert du ikke har tillatt.

Når det gjelder dekning av leverandørkjeden, kan CRACIs SBOM erstatte create-spdx. Yoctos SPDX inneholder likevel de påførte patchene og CVE-ene som er markert som rettet, og som CRACI ikke registrerer, så la create-spdx være på hvis du er avhengig av dem. CRACI-dokumentasjonen har et eksempel som bygger core-image-sato. Hvorfor registrering generelt slår skanning, står på SBOM-er fra byggetid; Yocto-verktøy sammenlignes på sikkerhetsverktøy for embedded sammenlignet og CRACI vs Timesys Vigiles.

Når CRACI ikke er svaret

• Du er avhengig av CVE-status på patchnivå, som CVE_STATUS-beslutninger og patchede eller ignorerte CVE-er som VEX. Det ligger i Yoctos SPDX: behold det.
• Du trenger kjerne-CVE-rapporter per konfigurasjon i dag. Bruk Yoctos verktøy for kompilerte kilder.
• Du bygger ikke firmwaren selv. Bruk binæranalyse.
• Yocto-byggene dine kjører utenfor GitHub Actions, eller må kjøre på din egen infrastruktur. CRACI tilbyr i dag administrerte runnere på europeisk infrastruktur; andre CI-systemer og kundehostede runnere er på veikartet.
• Du trenger SBOM-en for Yocto-jobben spesifikt i SPDX. CRACIs SBOM i den publiserte sammenligningen var CycloneDX; Yoctos egen SBOM er SPDX.

Bygger du tilkoblede enheter for EU-markedet? Les hva CRA krever, hvordan VEX fungerer, og hvordan CRACI passer for telekom- og nettverksutstyr, industriell IoT og forbrukerelektronikk.

Yocto CVE check og SBOM-er: ofte stilte spørsmål

Hvorfor kan ikke SCA-verktøyet vårt skanne de Yocto-baserte produktene våre?

Fordi de fleste SCA-verktøy leser manifester, lockfiler eller pakkedatabasen i et image, mens et Yocto-bygg avgjør innholdet sitt inne i BitBake. Produksjonsimager utelater ofte pakkedatabasen, statiske biblioteker og Rust-crates kompileres inn i binærfilene, patcher i oppskriftene lar upstream-versjonsnumrene stå, og verktøyene på byggeverten når aldri imaget.

Kan jeg skanne et Yocto-image eller firmware med Trivy, Grype eller en binærskanner?

Det kan du, og du får et delvis svar. En image-skanner leser de installerte pakkene hvis pakkedatabasen beholdes, og går glipp av det som er kompilert inn. En binærskanner utleder komponenter fra strenger og signaturer og må gjette ved strippede binærfiler, statisk kode og kompilert Rust. Ingen av dem ser byggeverten eller patchene en oppskrift påførte.

Inneholder Yoctos SBOM Rust-crates og Go-moduler?

Den lister dem som kilder til oppskriften som bruker dem. I utgivelsen vi bygget, dukket hver Rust-crate opp som en .crate-nedlasting med en nedlastingsplassering og uten pkg:cargo-package URL. Siden Yocto 6.0 får oppskrifter bygget med klassene Cargo og Go en package URL for økosystemet for selve oppskriften, ikke for hver crate- eller modulnedlasting.

Hvorfor rapporterer skanneren vår CVE-er som Yocto-oppskriftene våre allerede har patchet?

Fordi den matcher versjonsnumre. En Yocto-oppskrift beholder upstream-versjonen og påfører sikkerhetsrettelser som patcher, merket med en CVE:-linje eller registrert i CVE_STATUS. En matching på versjonsintervall kan ikke se patchen. Yoctos egen SPDX registrerer disse CVE-ene som rettet, koblet til patchfilene.

Hva erstattet cve-check i Yocto?

Klassen sbom-cve-check, i Yocto 6.0. Den kjører Bootlins sbom-cve-check over SPDX-utdataene fra bygget. Utgivelsene 5.0 til 5.3 har fortsatt cve-check, som matchet oppskriftsnavn og versjoner; utgivelsesnotatene for 5.2 advarer om at rapportene kan gå glipp av sårbarheter fordi mange CVE-er ikke lenger har CPE-data.

Hvordan får jeg CVE-er i Linux-kjernen for min egen kjernekonfigurasjon?

Slå på SPDX_INCLUDE_COMPILED_SOURCES for kjerneoppskriften og kjør improve_kernel_cve_report.py, som sjekker om filene hver CVE berører, ble kompilert. Yoctos sikkerhetsmanual sier at det reduserer falske positive CVE-er med 70 til 80 %. Kjør det per maskinkonfigurasjon, siden hver konfigurasjon bygger forskjellig kode.

Påvirker shared state-cachen SBOM-en?

Det kan den. Oppgaver som gjenopprettes fra sstate, hopper over henting og kompilering, så et verktøy som er avhengig av å observere disse stegene, ser mindre. Yoctos create-spdx jobber ut fra oppskriftsmetadata. Uansett metode: bygg release-imager fra en kjent cachetilstand og sammenlign antall komponenter mellom bygg.

Er Yoctos innebygde SBOM nok for CRA?

CRA krever en SBOM som dekker minst avhengighetene på øverste nivå, og Yoctos SBOM er grundig når det gjelder det BitBake bygger. Den lister ikke vertspakker på byggemaskinen, GitHub Actions eller verktøy hentet utenfor oppskrifter. Om det er nok, må du vurdere selv; SBOM-en er dokumentasjon for prosessen din, ikke samsvar i seg selv.