Hvorfor SBOM-scannere overser indholdet af Yocto-builds

Hvordan et Yocto-build adskiller sig fra det, scannere forventer

Et Yocto-build er ikke en installation via en pakkemanager. Det meste af det, der ender på enheden, afgøres på buildtidspunktet, inde i BitBake, i fem lag. Scannere kigger på ét lag bagefter og må gætte resten.

1. Buildværten

BitBake kører med værktøjer fra buildmaskinen. Variablen HOSTTOOLS angiver de værktøjer på buildværten, som buildopgaver må kalde, og buildsystemet laver symlinks til dem i ${TMPDIR}/hosttools. BitBake bygger også sine egne værktøjer via -native- og -cross-recipes. Værtsværktøjer påvirker imaget og er med vilje ikke en del af det.

2. Hentning

Recipes angiver deres kilder i SRC_URI, og fetcheren downloader dem til DL_DIR. Den kigger først i DL_DIR, derefter i PREMIRRORS, så upstream og til sidst i MIRRORS. Rust crates kommer via crate://-fetcheren, angivet i en -crates.inc-fil, som cargo-update-recipe-crates genererer ud fra Cargo.lock. Go-moduler kommer via klassen go-mod eller vendores med go-vendor. BB_NO_NETWORK og BB_ALLOWED_NETWORKS styrer, hvad fetcheren må nå.

3. Recipes og patches

Hver recipe fastlåser en upstream-version i PV og lægger patches oven på. En patch med en CVE:-linje i headeren markerer den CVE som patchet. Versionsnummeret forbliver upstream-versionen, så recipen kan være rettet, mens versionen siger noget andet.

4. Kompileret kode

Statiske biblioteker (-staticdev-pakkerne), Rust crates og Go-moduler ender inde i de binærfiler, der bruger dem. Kernen og dens moduler bygges ud fra en produktspecifik konfiguration, så to platforme på samme kerneversion indeholder forskellig kode.

5. Imaget

Rodfilsystemet. Image-funktionen package-management installerer pakkehåndteringsværktøjer og bevarer pakkemanagerens database. Uden den slettes pakkemanagerens datafiler fra rodfilsystemet, hvilket er almindeligt på produktionsimages.

Cachen shared state (sstate), den delte tilstandscache

BitBake kan gendanne outputtet af en opgave fra shared state-cachen i stedet for at køre den. Yoctos overview manual siger det ligeud: hvis de forudbyggede objekter er tilgængelige, er der ikke brug for compileren, "derfor downloades compileren slet ikke". Opgaver gendannet fra sstate springer hentning, kompilering og installation over, hvilket har betydning for ethvert værktøj, der er afhængigt af at overvåge de trin. Mere om det i afsnittet om caches nedenfor.

Hvorfor image- og filsystemscannere overser det meste

• Ingen pakkedatabase. Et produktionsimage bygget uden package-management giver en scanner ingen liste at læse, så den falder tilbage på filheuristik eller rapporterer næsten ingenting. Resultatet ser komplet ud og er næsten tomt.
• Statisk og vendoret kode. Et statisk bibliotek eller en crate kompileret ind i /usr/bin/foo efterlader ingen pakkepost. librsvg er et eksempel: den nuværende oe-core-recipe angiver mere end 350 Rust crates, og på enheden er det ét delt bibliotek.
• Buildvært og hentede værktøjer. De er aldrig i imaget og derfor aldrig i en image-scanning, selv om et kompromitteret værtsværktøj eller en GitHub Action kan kompromittere imaget. Bagdøren i xz utils (CVE-2024-3094) kom ind i biblioteket, mens det blev bygget, fra release-tarballs og ikke fra Git-repositoriet. I marts 2025 rapporterede CISA, at alle versioner af GitHub Action'en tj-actions/changed-files var kompromitteret i tre dage.
• Anvendte patches. Imaget siger openssl i en upstream-version. Recipen anvendte rettelsen af en CVE, der påvirker den version, og mærkede patchen med CVE:. Et match på versionsinterval markerer den alligevel. Det er Yoctos udgave af distributionernes backport-problem og en af hovedkilderne til den støj, der behandles i sådan reducerer du støj fra sårbarheder.

Summen er en blanding af manglende komponenter og forkerte fund, og intet i resultatet fortæller dig, hvad der er hvad. Det samme argument gælder for containere i SBOM'er til Docker-images og for sprogprojekter i open source SBOM-generatorer.

Hvorfor binærscanning af firmware må gætte

Binæranalyse matcher strenge, symboler og kodesignaturer i udpakket firmware mod kendte komponenter og udleder derefter versioner. Hvor binærfilen bærer tydelige spor, virker det. I et Yocto-image må den ofte gætte:

• strippede binærfiler uden versionsstrenge;
• statisk linket kode, hvor grænserne mellem biblioteker er væk;
• kompileret Rust, hvor grænserne mellem crates forsvinder ind i én eksekverbar fil;
• backportede patches, som er usynlige i et versionsnummer;
• kernekode, som konfigurationen kompilerede ind eller ud.

Binæranalyse er det rigtige værktøj til firmware, du ikke selv har bygget: leverandørblobs, indkøbte moduler, en enhed, du evaluerer. Hvis du ikke har buildet, er analyse af binærfilen den eneste mulighed. Beslutningsreglen er enkel: hvis du bygger det, så registrér det; hvis du kun modtager det, så analysér det og bed leverandøren om en SBOM fra deres build.

Hvad Yoctos egne SBOM- og CVE-værktøjer gør godt

Yocto Projects SBOM-arbejde er god ingeniørkunst, og det ved ting, som intet eksternt værktøj kan vide. Ifølge dokumentationen er SBOM'en "en beskrivelse af alle de komponenter, du har brugt, deres licenser, deres afhængigheder, deres kilder, de ændringer, der blev anvendt på dem, og de kendte sårbarheder, der blev rettet".

create-spdx pr. release

• 4.3 (Nanbield): SPDX-generering er slået til som standard.
• 5.1 (Styhead): SPDX 3.0 som standard i stedet for 2.2 og en vex-klasse, der giver eksterne CVE-værktøjer de oplysninger, de har brug for.
• 5.3 (Whinlatter): SPDX_INCLUDE_COMPILED_SOURCES, som kun medtager de kilder, der blev brugt til kompilering.
• 6.0 (Wrynose, langtidssupport): SPDX 2.2 fjernet; SPDX_INCLUDE_KERNEL_CONFIG og SPDX_INCLUDE_PACKAGECONFIG tilføjet; recipes bygget med klasserne Cargo, Go, PyPI, npm og CPAN får en package URL for deres økosystem.

SBOM'en dækker det, BitBake bygger, inklusive de native værktøjer, det bygger til værten. Den er grundig med alt, der har en recipe.

CVE-status som VEX inde i SBOM'en

I SPDX 3 skriver buildsystemet hver recipes CVE-status som VEX-relationer: en patchet CVE bliver "fixed", knyttet til patchfilerne; en upatchet "affected"; en ignoreret "not affected", med begrundelsen som impact statement. SPDX_INCLUDE_VEX bestemmer, hvor meget der kommer med: none, current (standarden, sårbarheder, der ikke allerede er rettet i upstream-kilden) eller all.

CVE_STATUS og patch-mærket

CVE_STATUS registrerer en beslutning pr. CVE som en begrundelse og en valgfri beskrivelse. Begrundelserne svarer til patchet (backported-patch, cpe-stable-backport, fixed-version og andre), upatchet (vulnerable-investigating) og ignoreret (cpe-incorrect, disputed, not-applicable-config, not-applicable-platform, upstream-wontfix). CVE_STATUS_GROUPS anvender én beslutning på en gruppe CVE'er, og CVE_PRODUCT angiver det produktnavn, der bruges til matchning.

# 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 matchede recipe-navne (CVE_PRODUCT) og versioner mod sårbarhedsdata. Release notes til 5.2 advarer om, at NVD's vedligeholdere siden starten af 2024 er holdt op med at annotere mange CVE'er med de berørte CPE'er, så "de nuværende CVE-rapporter kan se gode ud, men virkeligheden er, at nogle sårbarheder simpelthen ikke rapporteres". 5.2 gjorde også FKIE-feedet til standard i stedet for NVD. Yocto 6.0 fjernede cve-check og erstattede den med klassen sbom-cve-check, som kører Bootlins sbom-cve-check på SPDX-outputtet. På 5.0 til 5.3 har du stadig cve-check; betragt den som legacy.

Hvor Yoctos SBOM stopper

Det, Yocto ikke kan se, er alt uden for BitBakes metadata. Vi byggede core-image-sato to gange på en native ARM64-runner med 32 vCPU'er, én gang med Yoctos SBOM-generering og én gang uden, og sammenlignede Yoctos SPDX 3.0.1-SBOM, skrevet som 1.632 filer, med den CycloneDX-SBOM, CRACI registrerede:

• Komponenter. CRACI's registrerede SBOM havde alle komponenter fra Yoctos SBOM plus 88, den overså: 23 værtspakker på buildmaskinen (fx Ubuntus cpio), 10 GitHub-kilder, herunder GitHub Action'en actions/upload-artifact, og 55 andre kilder og værktøjer hentet under buildet.
• Rust crates. Begge angav de samme 653 Rust crate-versioner. I den release, vi byggede, angav Yoctos SBOM dem kun som .crate-filer med en download-placering, uden en pkg:cargo-package URL, så de kunne ikke matches mod advisories. Siden Yocto 6.0 har recipes bygget med Cargo-klassen en package URL for selve recipen, fx pkg:cargo/librsvg; i den nuværende kode har de enkelte crate-downloads stadig ingen. Tjek, hvad din release skriver.
• Omkostning. Buildet med Yoctos SBOM-generering tog 155 min 40 s og skrev 1.632 SPDX-filer. Uden den tog buildet 88 min 48 s, 43 % mindre. SPDX_INCLUDE_SOURCES, SPDX_INCLUDE_COMPILED_SOURCES, SPDX_INCLUDE_KERNEL_CONFIG og SPDX_INCLUDE_PACKAGECONFIG var slået til, så en standardkonfiguration koster mindre. Yoctos egen dokumentation advarer om, at med kompilerede kilder medtaget kan den ukomprimerede SBOM for core-image-minimal "vokse fra hundredvis af megabyte til flere gigabyte".

Native recipes som cmake, llvm, ninja og qemu er med i Yoctos SBOM. Metoden, begge SBOM'er og den fulde rapport findes på Yocto-builds på CRACI.

CVE'er i Linux-kernen: problemet pr. konfiguration

Linux-kerneprojektet meddelte den 13. februar 2024, at det var blevet CVE Numbering Authority, og det tildeler CVE'er til rettelser i stor stil. Dets CVE-dokumentation siger, at det er "op til brugeren af Linux at afgøre", om en bestemt CVE er relevant, fordi "vi kender ikke dit use case, og vi ved ikke, hvilke dele af kernen du bruger".

Et match på kerneversionen giver derfor hundredvis af fund, de fleste for kode, som din konfiguration aldrig kompilerer. Fire hardwareplatforme med fire kernekonfigurationer giver fire forskellige svar ud fra den samme kerneversion. Der er fire måder at håndtere det på:

1. Kun versionsmatchning. Alle CVE'er for versionen rapporteres. Maksimal støj.
2. Kuraterede udelukkelseslister. CVE_STATUS-poster genereret ud fra kernens CVE-data. I maj 2026 fjernede oe-core sin genererede liste for linux-yocto, fordi sbom-cve-check selv gør det ud fra den CVE-liste, kernen leverer, med en uændret CVE-rapport og en SPDX, der er næsten 20 MB mindre.
3. Filtrering efter, hvad der blev kompileret. Med SPDX_INCLUDE_COMPILED_SOURCES slået til for kerne-recipen tjekker improve_kernel_cve_report.py, om de filer, en CVE berører, blev brugt til at bygge kernen. Ifølge Yoctos security manual "reducerer det falske positiver for CVE'er med 70 %-80 %".
4. Registrering af konfigurationen. SPDX_INCLUDE_KERNEL_CONFIG (6.0) skriver kernekonfigurationen ind i SBOM'en, så svaret kan efterprøves senere.

Gennemregnet eksempel. Én kerne-CVE i en netværksdriver. Platform A bygger driveren; platform B gør ikke.

Platform	Driver kompileret?	Versionsmatch	Filter på kompilerede kilder
A	Ja	Rapporteret	Rapporteret: de berørte filer blev bygget
B	Nej	Rapporteret	Ikke rapporteret: de berørte filer blev ikke bygget

For kerne-CVE-rapporter pr. platform i dag skal du køre Yoctos værktøjer til kompilerede kilder én gang pr. maskinkonfiguration. Konfigurationen er det, der afgør svaret, så rapporten skal komme fra hver konfigurations build.

Caches, mirrors og vendoring: hvor enhver registrering skal være forsigtig

• Et build, der gendanner alt fra sstate eller fra et udfyldt DL_DIR, henter lidt eller intet. Et værktøj, der registrerer hentninger, skal føre sine beviser med i de caches, ellers skrumper registreringen.
• En recipe, der peger på en forhåndsvendoret tarball, viser én download, ikke de crates eller moduler, den indeholder.
• Uanset hvad du bruger: byg release-images fra en kendt cachetilstand, behold mirrors, du selv kontrollerer, og sammenlign antallet af komponenter mellem builds.

På CRACI bliver pakker gendannet fra CI-caches i SBOM'en, og hvert jobs fuldstændighedsstatus markerer, hvad registreringen ikke kunne se.

Hvad du skal køre: en beslutningstabel

Situation	Hvad du skal bruge	Hvad du får	Hvad du stadig mangler
Du bygger imaget i GitHub Actions	Registrér buildet (CRACI); behold create-spdx, hvis du er afhængig af dens patch- og CVE-status	Værtspakker, hentede kilder og Actions, en pkg:cargo-URL pr. crate, løbende overvågning	Kernefiltrering pr. konfiguration: brug Yoctos værktøjer
Du bygger med Yocto i et andet CI-system eller på en buildserver	create-spdx med sbom-cve-check (eller cve-check på ældre releases), kernefiltrering med kompilerede kilder	Recipes, patches, CVE-status som VEX	En opgørelse over værtspakker og hentede værktøjer, ført separat
Du modtager firmware, som du ikke bygger	Binæranalyse og en build-SBOM fra leverandøren	Komponenter udledt af binærfilen	Sikkerhed om versioner, patches og build-input
Du har brug for kerne-CVE'er pr. platform	Yoctos værktøjer til kompilerede kilder, pr. maskinkonfiguration	CVE'er for den kode, hver konfiguration bygger	Komponenter uden for kernen, fra din SBOM
Du har kun en image-scanner	Brug den til installerede pakker, hvis pakkedatabasen bevares	En del af listen over runtime-pakker	Alt, der er kompileret ind, patchet eller efterladt på buildværten; et rent resultat er ikke et bevis

Hvad hver metode ser

Komponentklasse	Image-scanner	Binæranalyse	Yocto create-spdx	Registrering af buildet (CRACI)
Installerede pakker	Kun hvis pakkedatabasen bevares	Udledt af filer	Ja	Ja, fra de kilder, buildet hentede
Statiske biblioteker	Nej	Udledt af signaturer	Ja, som recipes	Ja, fra de kilder, buildet hentede
Rust crates	Nej	Udledt; grænserne mellem crates forsvinder	Som .crate-downloads, uden package URL pr. crate	Ja, hver med en pkg:cargo-package URL
Go-moduler	Nej	Udledt af binærfilen	Som moduldownloads i recipen	Ja, når de hentes under buildet
Anvendte patches og CVE-status	Nej	Nej	Ja, som VEX	Nej
Kernekonfiguration	Nej	Nej	Ja, med SPDX_INCLUDE_KERNEL_CONFIG (6.0)	Nej
Værtsværktøjer på buildmaskinen	Nej	Nej	Nej (native recipes, ja)	Ja
Buildværktøjer hentet uden for recipes og GitHub Actions	Nej	Nej	Nej	Ja

Hvor CRACI passer ind

For Yocto-builds, der kører i GitHub Actions, er CRACI runneren, med op til 32 vCPU'er og 96 GB RAM. Den registrerer, hvad buildet trak ind, inklusive værtspakker, GitHub-kilder og Actions og andre hentede kilder, med en package URL for hver Rust crate: i den offentliggjorte sammenligning alle komponenter fra Yoctos SBOM plus 88, den overså. Den matcher komponenterne mod advisories, bliver ved med at genvurdere SBOM'en, efterhånden som nye udgives, og viser, hvilke builds der indeholdt en sårbar afhængighed.

BitBake kan allerede begrænse sin fetcher med BB_ALLOWED_NETWORKS. CRACI's egress-politik tilføjer en ekstra kontrol på runneren, tjekket før jobbet starter og med blokering ved fejl, så et script eller værktøj, der går uden om fetcheren, stadig ikke kan nå en vært, du ikke har tilladt.

Når det gælder dækning af forsyningskæden, kan CRACI's SBOM erstatte create-spdx. Yoctos SPDX indeholder stadig de anvendte patches og de CVE'er, der er markeret som rettet, hvilket CRACI ikke registrerer, så behold create-spdx slået til, hvis du er afhængig af dem. CRACI-dokumentationen indeholder et eksempel, der bygger core-image-sato. Hvorfor registrering generelt slår scanning, kan du læse på SBOM'er fra buildtidspunktet; Yocto-værktøjer sammenlignes på sammenligning af sikkerhedsværktøjer til embedded og CRACI vs Timesys Vigiles.

Når CRACI ikke er svaret

• Du er afhængig af CVE-status på patchniveau, fx CVE_STATUS-beslutninger og patchede eller ignorerede CVE'er som VEX. Det ligger i Yoctos SPDX: behold den.
• Du har brug for kerne-CVE-rapporter pr. konfiguration i dag. Brug Yoctos værktøjer til kompilerede kilder.
• Du bygger ikke selv firmwaren. Brug binæranalyse.
• Dine Yocto-builds kører uden for GitHub Actions eller skal køre på din egen infrastruktur. CRACI tilbyder i dag administrerede runners på europæisk infrastruktur; andre CI-systemer og kundehostede runners er på roadmappen.
• Du har specifikt brug for Yocto-jobbets SBOM i SPDX. CRACI's SBOM i den offentliggjorte sammenligning var CycloneDX; Yoctos egen SBOM er SPDX.

Bygger du forbundne enheder til EU-markedet? Læs hvad CRA kræver, hvordan VEX fungerer, og hvordan CRACI passer til telekom- og netværksudstyr, industriel IoT og forbrugerelektronik.

Yocto CVE checks og SBOM'er: ofte stillede spørgsmål

Hvorfor kan vores SCA-værktøj ikke scanne vores Yocto-baserede produkter?

Fordi de fleste SCA-værktøjer læser manifester, lockfiles eller et images pakkedatabase, og et Yocto-build afgør sit indhold inde i BitBake. Produktionsimages dropper ofte pakkedatabasen, statiske biblioteker og Rust crates kompileres ind i binærfiler, patches i recipes lader upstream-versionsnumrene stå, og buildværtens værktøjer når aldrig frem til imaget.

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

Det kan du, og du får et delvist svar. En image-scanner læser de installerede pakker, hvis pakkedatabasen bevares, og overser det, der er kompileret ind. En binærscanner udleder komponenter af strenge og signaturer og må gætte ved strippede binærfiler, statisk kode og kompileret Rust. Ingen af dem ser buildværten eller de patches, en recipe har anvendt.

Indeholder Yoctos SBOM Rust crates og Go-moduler?

Den angiver dem som kilder til den recipe, der bruger dem. I den release, vi byggede, optrådte hver Rust crate som en .crate-download med en download-placering og ingen pkg:cargo-package URL. Siden Yocto 6.0 får recipes bygget med klasserne Cargo og Go en package URL for deres økosystem for selve recipen, ikke for hver crate- eller moduldownload.

Hvorfor rapporterer vores scanner CVE'er, som vores Yocto-recipes allerede har patchet?

Fordi den matcher versionsnumre. En Yocto-recipe beholder upstream-versionen og anvender sikkerhedsrettelser som patches, mærket med en CVE:-linje eller registreret i CVE_STATUS. Et match på versionsinterval kan ikke se patchen. Yoctos egen SPDX registrerer de CVE'er som rettet, knyttet til patchfilerne.

Hvad erstattede cve-check i Yocto?

Klassen sbom-cve-check i Yocto 6.0. Den kører Bootlins sbom-cve-check på buildets SPDX-output. Release 5.0 til 5.3 har stadig cve-check, som matchede recipe-navne og versioner; release notes til 5.2 advarer om, at dens rapporter kan overse sårbarheder, fordi mange CVE'er ikke længere har CPE-data.

Hvordan får jeg Linux-kernens CVE'er for min egen kernekonfiguration?

Slå SPDX_INCLUDE_COMPILED_SOURCES til for kerne-recipen, og kør improve_kernel_cve_report.py, som tjekker, om de filer, hver CVE berører, blev kompileret. Ifølge Yoctos security manual reducerer det falske positiver for CVE'er med 70 % til 80 %. Kør det pr. maskinkonfiguration, da hver konfiguration bygger forskellig kode.

Påvirker shared state-cachen SBOM'en?

Det kan den. Opgaver gendannet fra sstate springer hentning og kompilering over, så et værktøj, der er afhængigt af at overvåge de trin, ser mindre. Yoctos create-spdx arbejder ud fra recipe-metadata. Uanset metode: byg release-images fra en kendt cachetilstand, og sammenlign antallet af komponenter mellem builds.

Er Yoctos indbyggede SBOM nok til CRA?

CRA kræver en SBOM, der som minimum dækker afhængighederne på øverste niveau, og Yoctos SBOM er grundig med det, BitBake bygger. Den angiver ikke værtspakker på buildmaskinen, GitHub Actions eller værktøjer hentet uden for recipes. Om det er nok, er din vurdering; SBOM'en er bevis for din proces, ikke compliance i sig selv.