Proč skenery SBOM nevidí, co je v buildech Yocto

Čím se build Yocto liší od toho, co skenery očekávají

Build Yocto není instalace přes správce balíčků. Většina toho, co skončí v zařízení, se rozhoduje během buildu, uvnitř BitBake, v pěti vrstvách. Skenery se dívají na jednu vrstvu dodatečně a zbytek musí odhadovat.

1. Hostitel buildu

BitBake běží s nástroji ze stroje buildu. Proměnná HOSTTOOLS uvádí nástroje na hostiteli buildu, které smějí úlohy buildu volat, a build systém na ně vytvoří symbolické odkazy v ${TMPDIR}/hosttools. BitBake také sestavuje vlastní nástroje přes recipes -native a -cross. Nástroje hostitele image ovlivňují, a z principu nejsou jeho součástí.

2. Stahování

Recipes uvádějí své zdroje v SRC_URI a fetcher je stáhne do DL_DIR. Nejdřív hledá v DL_DIR, pak v PREMIRRORS, pak upstream a pak v MIRRORS. Rust crates přicházejí přes fetcher crate://, uvedené v souboru -crates.inc, který cargo-update-recipe-crates generuje z Cargo.lock. Moduly Go přicházejí přes třídu go-mod, nebo jsou vendorované pomocí go-vendor. BB_NO_NETWORK a BB_ALLOWED_NETWORKS řídí, kam se fetcher smí připojit.

3. Recipes a patche

Každá recipe připíná upstreamovou verzi v PV a aplikuje na ni patche. Patch s řádkem CVE: v hlavičce označí dané CVE jako opravené. Číslo verze zůstává upstreamové, takže recipe může být opravená, i když její verze říká něco jiného.

4. Zkompilovaný kód

Statické knihovny (balíčky -staticdev), Rust crates a moduly Go skončí uvnitř binárek, které je používají. Jádro a jeho moduly se sestavují z konfigurace specifické pro produkt, takže dvě platformy se stejnou verzí jádra obsahují odlišný kód.

5. Image

Kořenový souborový systém. Funkce image package-management nainstaluje nástroje pro správu balíčků a zachová databázi správce balíčků. Bez ní se datové soubory správce balíčků z kořenového souborového systému smažou, což je u produkčních image běžné.

Cache shared state (sstate, sdílený stav)

BitBake může výstup úlohy obnovit z cache shared state, místo aby ji spustil. Přehledová příručka Yocto to říká přímo: pokud jsou k dispozici předem sestavené objekty, kompilátor není potřeba, „takže se kompilátor ani nestahuje“. Úlohy obnovené ze sstate přeskočí stahování, kompilaci i instalaci, což je důležité pro každý nástroj, který spoléhá na sledování těchto kroků. Více o tom v části o cache níže.

Proč skenery image a souborových systémů většinu z toho přehlédnou

• Žádná databáze balíčků. Produkční image sestavený bez package-management nedá skeneru žádný seznam ke čtení, takže se uchýlí k heuristikám nad soubory, nebo nenahlásí téměř nic. Výsledek vypadá úplně, a přitom je skoro prázdný.
• Statický a vendorovaný kód. Statická knihovna nebo crate zkompilovaný do /usr/bin/foo nezanechá žádný záznam o balíčku. Příkladem je librsvg: aktuální recipe v oe-core uvádí více než 350 Rust crates a v zařízení je to jedna sdílená knihovna.
• Hostitel buildu a stažené nástroje. Nikdy nejsou v image, takže ani ve skenu image, přestože kompromitovaný nástroj hostitele nebo GitHub Action může image kompromitovat. Zadní vrátka v xz utils (CVE-2024-3094) se do knihovny dostala během jejího sestavování, z release tarballů, ne z repozitáře Git. V březnu 2025 CISA oznámila, že všechny verze GitHub Action tj-actions/changed-files byly tři dny kompromitované.
• Aplikované patche. Image uvádí openssl v upstreamové verzi. Recipe aplikovala opravu CVE, které se této verze týká, a označila patch pomocí CVE:. Shoda podle rozsahu verzí ho přesto nahlásí. To je yoctovská podoba problému backportů v distribucích a jeden z hlavních zdrojů šumu, kterému se věnuje článek jak snížit šum výstrah o zranitelnostech.

Výsledkem je směs chybějících komponent a chybných nálezů a nic ve výsledku vám neřekne, co je co. Stejný argument platí pro kontejnery v článku SBOM pro Docker image a pro jazykové projekty v článku open source generátory SBOM.

Proč binární skenování firmwaru musí odhadovat

Binární analýza porovnává řetězce, symboly a signatury kódu v extrahovaném firmwaru se známými komponentami a pak odvozuje verze. Tam, kde binárka nese jasné důkazy, to funguje. V image Yocto ale často musí odhadovat:

• u strippovaných binárek bez řetězců s verzí;
• u staticky linkovaného kódu, kde hranice knihoven zmizely;
• u zkompilovaného Rustu, kde hranice crates zmizí v jednom spustitelném souboru;
• u backportovaných patchů, které v čísle verze nejsou vidět;
• u kódu jádra, který konfigurace zkompilovala dovnitř, nebo vynechala.

Binární analýza je správný nástroj pro firmware, který jste nesestavili sami: bloby od dodavatelů, nakoupené moduly, zařízení, které hodnotíte. Pokud build nemáte, je analýza binárky jedinou možností. Pravidlo pro rozhodnutí je jednoduché: pokud to sestavujete, zaznamenejte to; pokud to jen přijímáte, analyzujte to a požádejte dodavatele o SBOM z jeho buildu.

Co dobře umějí vlastní nástroje Yocto pro SBOM a CVE

Práce projektu Yocto na SBOM je kvalitní inženýrství a ví věci, které žádný vnější nástroj vědět nemůže. Jeho dokumentace říká, že SBOM je „popis všech komponent, které jste použili, jejich licencí, jejich závislostí, jejich zdrojů, změn, které na ně byly aplikovány, a známých zranitelností, které byly opraveny“.

create-spdx podle vydání

• 4.3 (Nanbield): generování SPDX je ve výchozím stavu zapnuté.
• 5.1 (Styhead): ve výchozím stavu SPDX 3.0 místo 2.2 a třída vex, která externím nástrojům pro CVE dává potřebné informace.
• 5.3 (Whinlatter): SPDX_INCLUDE_COMPILED_SOURCES, které zahrne jen zdroje použité při kompilaci.
• 6.0 (Wrynose, dlouhodobá podpora): SPDX 2.2 odstraněno; přidány SPDX_INCLUDE_KERNEL_CONFIG a SPDX_INCLUDE_PACKAGECONFIG; recipes sestavené pomocí tříd Cargo, Go, PyPI, npm a CPAN dostávají package URL ekosystému.

SBOM pokrývá to, co BitBake sestavuje, včetně nativních nástrojů, které sestavuje pro hostitele. U všeho, co má recipe, je důkladná.

Stav CVE jako VEX uvnitř SBOM

V SPDX 3 zapisuje build systém stav CVE každé recipe jako vztahy VEX: opravené CVE se stane „fixed“, propojené se soubory patchů; neopravené „affected“; ignorované „not affected“, s důvodem jako prohlášením o dopadu. SPDX_INCLUDE_VEX určuje, kolik se zahrne: none, current (výchozí, zranitelnosti, které ještě nejsou opravené v upstreamovém zdroji) nebo all.

CVE_STATUS a značka v patchi

CVE_STATUS zaznamenává rozhodnutí pro každé CVE jako důvod a volitelný popis. Důvody odpovídají stavům opraveno (backported-patch, cpe-stable-backport, fixed-version a další), neopraveno (vulnerable-investigating) a ignorováno (cpe-incorrect, disputed, not-applicable-config, not-applicable-platform, upstream-wontfix). CVE_STATUS_GROUPS aplikuje jedno rozhodnutí na skupinu CVE a CVE_PRODUCT nastavuje název produktu, podle kterého se páruje.

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

Od cve-check k sbom-cve-check

cve-check porovnával názvy recipes (CVE_PRODUCT) a verze s daty o zranitelnostech. Poznámky k vydání 5.2 upozorňují, že od začátku roku 2024 přestali správci NVD u mnoha CVE uvádět dotčené CPE, takže „současné reporty CVE mohou vypadat dobře, ale ve skutečnosti některé zranitelnosti prostě nejsou nahlášeny“. Vydání 5.2 také nastavilo jako výchozí zdroj feed FKIE místo NVD. Yocto 6.0 odstranilo cve-check a nahradilo ho třídou sbom-cve-check, která spouští sbom-cve-check od Bootlinu nad výstupem SPDX. Ve vydáních 5.0 až 5.3 máte stále cve-check; berte ho jako legacy.

Kde SBOM z Yocto končí

Yocto nevidí nic, co leží mimo metadata BitBake. core-image-sato jsme sestavili dvakrát na nativním runneru ARM64 s 32 vCPU, jednou s generováním SBOM v Yocto a jednou bez něj, a porovnali jsme SBOM z Yocto ve formátu SPDX 3.0.1, zapsanou jako 1 632 souborů, se SBOM ve formátu CycloneDX, kterou zaznamenalo CRACI:

• Komponenty. SBOM zaznamenaná CRACI obsahovala každou komponentu, kterou měla SBOM z Yocto, a navíc 88, které chyběly: 23 balíčků hostitele na stroji buildu (například cpio z Ubuntu), 10 zdrojů z GitHubu včetně GitHub Action actions/upload-artifact a 55 dalších zdrojů a nástrojů stažených během buildu.
• Rust crates. Obě uváděly stejných 653 verzí Rust crates. Ve vydání, které jsme sestavili, je SBOM z Yocto uváděla jen jako soubory .crate s umístěním ke stažení, bez package URL pkg:cargo, takže je nebylo možné porovnat s bezpečnostními upozorněními. Od Yocto 6.0 nesou recipes sestavené třídou Cargo package URL pro samotnou recipe, například pkg:cargo/librsvg; v aktuálním kódu jednotlivá stažení crates stále žádnou nemají. Ověřte, co zapisuje vaše vydání.
• Náklady. Build s generováním SBOM v Yocto trval 155 min 40 s a zapsal 1 632 souborů SPDX. Bez něj trval build 88 min 48 s, o 43 % méně. SPDX_INCLUDE_SOURCES, SPDX_INCLUDE_COMPILED_SOURCES, SPDX_INCLUDE_KERNEL_CONFIG a SPDX_INCLUDE_PACKAGECONFIG byly zapnuté, takže výchozí konfigurace stojí méně. Vlastní dokumentace Yocto upozorňuje, že se zahrnutými zkompilovanými zdroji může nekomprimovaná SBOM core-image-minimal „narůst ze stovek megabajtů na několik gigabajtů“.

Nativní recipes jako cmake, llvm, ninja a qemu v SBOM z Yocto jsou. Metodika, obě SBOM a celý report jsou na stránce buildy Yocto na CRACI.

CVE v jádře Linuxu: problém jednotlivých konfigurací

Projekt jádra Linuxu oznámil 13. února 2024, že se stal CVE Numbering Authority, a CVE k opravám přiděluje velkoryse. Jeho dokumentace k CVE uvádí, že o použitelnosti konkrétního CVE „rozhoduje uživatel Linuxu“, protože „neznáme váš případ použití a nevíme, které části jádra používáte“.

Shoda podle verze jádra tak vyprodukuje stovky nálezů, většinou pro kód, který vaše konfigurace nikdy nezkompiluje. Čtyři hardwarové platformy se čtyřmi konfiguracemi jádra dají ze stejné verze jádra čtyři různé odpovědi. Existují čtyři způsoby, jak to řešit:

1. Pouze porovnání verzí. Nahlásí se každé CVE pro danou verzi. Maximální šum.
2. Kurátorované seznamy výjimek. Záznamy CVE_STATUS generované z dat jádra o CVE. V květnu 2026 oe-core odstranilo svůj generovaný seznam pro linux-yocto, protože sbom-cve-check to dělá sám ze seznamu CVE, který jádro poskytuje, s nezměněným reportem CVE a SPDX menším téměř o 20 MB.
3. Filtrování podle toho, co bylo zkompilováno. Se zapnutým SPDX_INCLUDE_COMPILED_SOURCES pro recipe jádra kontroluje improve_kernel_cve_report.py, zda byly soubory, kterých se CVE týká, použity při sestavení jádra. Bezpečnostní příručka Yocto uvádí, že to „snižuje počet falešně pozitivních CVE o 70–80 %“.
4. Zaznamenání konfigurace. SPDX_INCLUDE_KERNEL_CONFIG (6.0) zapíše konfiguraci jádra do SBOM, takže odpověď lze později ověřit.

Názorný příklad. Jedno CVE jádra v síťovém ovladači. Platforma A ovladač sestavuje, platforma B ne.

Platforma	Ovladač zkompilován?	Shoda podle verze	Filtr zkompilovaných zdrojů
A	Ano	Nahlášeno	Nahlášeno: dotčené soubory byly sestaveny
B	Ne	Nahlášeno	Nenahlášeno: dotčené soubory nebyly sestaveny

Pro reporty CVE jádra podle platforem dnes spusťte nástroje Yocto pro zkompilované zdroje jednou pro každou konfiguraci stroje. Odpověď rozhoduje konfigurace, takže report musí vzniknout z buildu každé konfigurace.

Cache, mirrory a vendoring: kde musí být každý záznamník opatrný

• Build, který vše obnoví ze sstate nebo z naplněného DL_DIR, stáhne málo nebo nic. Záznamník, který vidí stahování, musí své důkazy přenášet spolu s těmito cache, jinak se záznam zmenší.
• Recipe, která odkazuje na předem vendorovaný tarball, ukazuje jedno stažení, ne crates nebo moduly uvnitř.
• Ať používáte cokoli, sestavujte image pro vydání ze známého stavu cache, udržujte mirrory, které máte pod kontrolou, a porovnávejte počty komponent mezi buildy.

Na CRACI zůstávají balíčky obnovené z cache CI v SBOM a stav úplnosti každého jobu označí, co záznam nemohl vidět.

Co spustit: rozhodovací tabulka

Situace	Co použít	Co získáte	Co vám stále chybí
Image sestavujete v GitHub Actions	Zaznamenejte build (CRACI); ponechte create-spdx, pokud spoléháte na jeho stav patchů a CVE	Balíčky hostitele, stažené zdroje a Actions, URL pkg:cargo pro každý crate, průběžné monitorování	Filtrování jádra podle konfigurace: použijte nástroje Yocto
S Yocto sestavujete v jiném systému CI nebo na build serveru	create-spdx se sbom-cve-check (nebo cve-check ve starších vydáních), filtrování jádra se zkompilovanými zdroji	Recipes, patche, stav CVE jako VEX	Inventář balíčků hostitele a stažených nástrojů, vedený zvlášť
Přijímáte firmware, který nesestavujete	Binární analýzu a SBOM z buildu od dodavatele	Komponenty odvozené z binárky	Jistotu ohledně verzí, patchů a vstupů buildu
Potřebujete CVE jádra pro každou platformu	Nástroje Yocto pro zkompilované zdroje, pro každou konfiguraci stroje	CVE pro kód, který každá konfigurace sestavuje	Komponenty mimo jádro, z vaší SBOM
Máte jen skener image	Použijte ho pro nainstalované balíčky, pokud je databáze balíčků zachována	Část seznamu balíčků za běhu	Vše zkompilované dovnitř, opatchované nebo ponechané na hostiteli buildu; čistý výsledek není důkaz

Co vidí která metoda

Třída komponent	Skener image	Binární analýza	Yocto create-spdx	Záznam buildu (CRACI)
Nainstalované balíčky	Jen pokud je databáze balíčků zachována	Odvozeno ze souborů	Ano	Ano, ze zdrojů, které build stáhl
Statické knihovny	Ne	Odvozeno ze signatur	Ano, jako recipes	Ano, ze zdrojů, které build stáhl
Rust crates	Ne	Odvozeno; hranice crates mizí	Jako stažení .crate, bez package URL pro jednotlivé crates	Ano, každý s package URL pkg:cargo
Moduly Go	Ne	Odvozeno z binárky	Jako stažení modulů dané recipe	Ano, pokud byly staženy během buildu
Aplikované patche a stav CVE	Ne	Ne	Ano, jako VEX	Ne
Konfigurace jádra	Ne	Ne	Ano, se SPDX_INCLUDE_KERNEL_CONFIG (6.0)	Ne
Nástroje hostitele na stroji buildu	Ne	Ne	Ne (nativní recipes ano)	Ano
Nástroje buildu stažené mimo recipes a GitHub Actions	Ne	Ne	Ne	Ano

Kam zapadá CRACI

U buildů Yocto, které běží v GitHub Actions, je CRACI runnerem, s až 32 vCPU a 96 GB RAM. Zaznamenává, co build stáhl, včetně balíčků hostitele, zdrojů a Actions z GitHubu a dalších stažených zdrojů, s package URL pro každý Rust crate: ve zveřejněném srovnání každou komponentu, kterou měla SBOM z Yocto, a navíc 88, které chyběly. Porovnává komponenty s bezpečnostními upozorněními, průběžně znovu vyhodnocuje SBOM, jak vycházejí nová, a ukazuje, které buildy obsahovaly zranitelnou závislost.

BitBake už dnes umí omezit svůj fetcher pomocí BB_ALLOWED_NETWORKS. Egress policy v CRACI přidává druhou kontrolu na runneru, ověřenou před startem jobu a s chováním fail-closed, takže skript nebo nástroj, který fetcher obejde, se stejně nemůže připojit k hostiteli, kterého jste nepovolili.

Pro pokrytí dodavatelského řetězce může SBOM z CRACI nahradit create-spdx. SPDX z Yocto ale stále nese aplikované patche a CVE označená jako opravená, která CRACI nezaznamenává, takže pokud na ně spoléháte, ponechte create-spdx zapnuté. Dokumentace CRACI obsahuje příklad, který sestavuje core-image-sato. Proč je zaznamenávání obecně lepší než skenování, se dočtete na stránce SBOM z doby buildu; nástroje pro Yocto srovnáváme na stránkách srovnání nástrojů pro bezpečnost embedded a CRACI vs Timesys Vigiles.

Kdy CRACI není řešením

• Spoléháte na stav CVE na úrovni patchů, například na rozhodnutí v CVE_STATUS a opravená nebo ignorovaná CVE jako VEX. To je v SPDX z Yocto: ponechte si ho.
• Reporty CVE jádra podle konfigurace potřebujete už dnes. Použijte nástroje Yocto pro zkompilované zdroje.
• Firmware nesestavujete. Použijte binární analýzu.
• Vaše buildy Yocto běží mimo GitHub Actions, nebo musí běžet na vaší vlastní infrastruktuře. CRACI dnes nabízí spravované runnery na evropské infrastruktuře; další systémy CI a runnery hostované zákazníkem jsou v plánu vývoje.
• SBOM jobu Yocto potřebujete konkrétně ve formátu SPDX. SBOM z CRACI byla ve zveřejněném srovnání ve formátu CycloneDX; vlastní SBOM z Yocto je SPDX.

Vyvíjíte připojená zařízení pro trh EU? Přečtěte si, co CRA požaduje, jak funguje VEX a jak CRACI zapadá do oblastí telekomunikace a síťová zařízení, průmyslový IoT a spotřební elektronika.

Yocto CVE check a SBOM: časté dotazy

Proč můj nástroj SCA nedokáže skenovat naše produkty postavené na Yocto?

Protože většina nástrojů SCA čte manifesty, lockfily nebo databázi balíčků v image, zatímco build Yocto rozhoduje o svém obsahu uvnitř BitBake. Produkční image často vynechávají databázi balíčků, statické knihovny a Rust crates se kompilují do binárek, patche v recipes ponechávají upstreamová čísla verzí a nástroje hostitele buildu se do image nikdy nedostanou.

Mohu image Yocto nebo firmware skenovat pomocí Trivy, Grype nebo binárního skeneru?

Můžete, ale dostanete jen částečnou odpověď. Skener image přečte nainstalované balíčky, pokud je databáze balíčků zachována, a přehlédne, co je zkompilováno dovnitř. Binární skener odvozuje komponenty z řetězců a signatur a u strippovaných binárek, statického kódu a zkompilovaného Rustu musí odhadovat. Ani jeden nevidí hostitele buildu ani patche, které recipe aplikovala.

Obsahuje SBOM z Yocto Rust crates a moduly Go?

Uvádí je jako zdroje recipe, která je používá. Ve vydání, které jsme sestavili, se každý Rust crate objevil jako stažení .crate s umístěním ke stažení a bez package URL pkg:cargo. Od Yocto 6.0 dostávají recipes sestavené třídami Cargo a Go package URL ekosystému pro samotnou recipe, ne pro každé jednotlivé stažení crate nebo modulu.

Proč můj skener hlásí CVE, která naše recipes Yocto už opravují?

Protože porovnává čísla verzí. Recipe Yocto ponechává upstreamovou verzi a bezpečnostní opravy aplikuje jako patche, označené řádkem CVE: nebo zaznamenané v CVE_STATUS. Shoda podle rozsahu verzí patch nevidí. Vlastní SPDX z Yocto zaznamenává tato CVE jako opravená, propojená se soubory patchů.

Co v Yocto nahradilo cve-check?

Třída sbom-cve-check v Yocto 6.0. Spouští sbom-cve-check od Bootlinu nad výstupem SPDX z buildu. Vydání 5.0 až 5.3 mají stále cve-check, který porovnával názvy a verze recipes; poznámky k vydání 5.2 upozorňují, že jeho reporty mohou zranitelnosti přehlédnout, protože mnoho CVE už nenese data CPE.

Jak získám CVE jádra Linuxu pro vlastní konfiguraci jádra?

Zapněte SPDX_INCLUDE_COMPILED_SOURCES pro recipe jádra a spusťte improve_kernel_cve_report.py, který zkontroluje, zda byly soubory, kterých se každé CVE týká, zkompilovány. Bezpečnostní příručka Yocto uvádí, že to snižuje počet falešně pozitivních CVE o 70 až 80 %. Spouštějte ho pro každou konfiguraci stroje, protože každá konfigurace sestavuje jiný kód.

Ovlivňuje cache shared state SBOM?

Může. Úlohy obnovené ze sstate přeskočí stahování a kompilaci, takže nástroj, který spoléhá na sledování těchto kroků, vidí méně. create-spdx z Yocto pracuje s metadaty recipes. U jakékoli metody sestavujte image pro vydání ze známého stavu cache a porovnávejte počty komponent mezi buildy.

Stačí pro CRA vestavěná SBOM z Yocto?

CRA požaduje SBOM pokrývající přinejmenším nejdůležitější závislosti produktu a SBOM z Yocto je důkladná u všeho, co BitBake sestavuje. Neuvádí balíčky hostitele na stroji buildu, GitHub Actions ani nástroje stažené mimo recipes. Zda to stačí, je na vašem posouzení; SBOM je důkazem pro váš proces, nikoli soulad sama o sobě.