SBOM pro Yocto a buildy na CRACI

Jak vygenerovat SBOM pomocí Yocto

Build systém OpenEmbedded zapisuje SBOM SPDX pomocí třídy create-spdx. Zda je zapnutá a jakou verzi SPDX zapisuje, závisí na vydání Yocto:

• Kirkstone (4.0): ve výchozím nastavení vypnuto. Přidejte INHERIT += "create-spdx". SPDX 2.2.
• Nanbield (4.3): od tohoto vydání je generování SBOM ve výchozím nastavení zapnuté.
• Scarthgap (5.0): ve výchozím nastavení zapnuto, SPDX 2.2. SPDX 3.0 je k dispozici přes třídu create-spdx-3.0.
• Styhead (5.1) a novější: ve výchozím nastavení zapnuto, SPDX 3.0.

Nastavuje se v konfiguračním souboru, například conf/local.conf. Na aktuálním vydání obvykle není třeba nic přidávat; k vypnutí použijte INHERIT_DISTRO:remove = "create-spdx".

# conf/local.conf

# Kirkstone (4.0): SBOM generation is off by default, so turn it on
INHERIT += "create-spdx"

# Scarthgap (5.0): switch the output from SPDX 2.2 to SPDX 3.0
INHERIT_DISTRO:remove = "create-spdx"
INHERIT_DISTRO:append = " create-spdx-3.0"

# Any release: indented JSON you can read in an editor
SPDX_PRETTY = "1"

Další proměnné SPDX_ přidávají podrobnosti. SPDX_INCLUDE_SOURCES popisuje zdrojové soubory za každým nástrojem hostitele a cílovým balíčkem, což výstup výrazně zvětší. Novější vydání přidávají volby pro konfiguraci jádra, funkce PACKAGECONFIG, informace o dodavateli a package URL pro zdroje Cargo, Go, PyPI, npm a CPAN.

Kam se soubory SBOM ukládají

Sestavte image a SBOM nejvyšší úrovně se objeví vedle něj jako IMAGE-MACHINE.spdx.json v tmp/deploy/images/MACHINE/ uvnitř adresáře buildu. Související soubory jsou ve stejném adresáři a v tmp/deploy/spdx. Na Kirkstone přicházejí dokumenty pro jednotlivé recepty jako archiv IMAGE-MACHINE.spdx.tar.zst.

bitbake core-image-minimal

# The image SBOM
ls tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.spdx.json

# Per-recipe and package documents
ls tmp/deploy/spdx/

# Current releases: an SBOM for one recipe, from its metadata only
bitbake busybox -c create_recipe_sbom

CycloneDX s meta-cyclonedx

Samotné Yocto zapisuje jen SPDX. Pro CycloneDX generuje vrstva meta-cyclonedx SBOM z kořenového souborového systému image a k tomu samostatný soubor VEX s opravenými a ignorovanými CVE, o kterých build systém ví. Přepněte se na větev vrstvy pro své vydání, přidejte ji ke svým vrstvám a zděďte její třídu:

# In your sources directory, on the branch for your release
git clone https://github.com/iris-GmbH/meta-cyclonedx.git
cd meta-cyclonedx
git checkout scarthgap

# conf/bblayers.conf
BBLAYERS += "${BSPDIR}/sources/meta-cyclonedx"

# conf/local.conf
INHERIT += "cyclonedx-export"
# Optional: include build-time packages, not only what is in the image
CYCLONEDX_RUNTIME_PACKAGES_ONLY = "0"

Soubory se ukládají vedle image v DEPLOY_DIR_IMAGE, s příponami .cyclonedx.bom.json a .cyclonedx.vex.json. Výchozí je CycloneDX 1.6, nastavitelné pomocí CYCLONEDX_SPEC_VERSION. Ve výchozím nastavení jsou zahrnuty jen runtime balíčky, což SBOM udržuje malou, ale může vynechat komponenty, které se do image dostanou, aniž by byly nainstalovány jako balíčky.

Co SBOM z Yocto vynechává

SBOM z Yocto důkladně popisuje to, co BitBake sestavuje. V SPDX 3 pokrývá image, každý recept včetně nativních receptů z doby buildu, jejich zdroje, aplikované patche a zranitelnosti označené jako opravené. U core-image-sato to dalo 1,632 samostatných souborů. Abychom zjistili, co vynechává, sestavili jsme image na runneru CRACI, nativním ARM64 s 32 vCPU, a porovnali SBOM z Yocto se SBOM zaznamenanou CRACI, komponentu po komponentě, po normalizaci názvů napříč všemi těmito soubory.

Z 953 komponent v SBOM z CRACI bylo 865 i v SBOM z Yocto. Žádná nebyla jen v SBOM z Yocto. Rozdíly spočívají v tom, co Yocto nevidí, a v tom, jak identifikuje to, co uvádí.

Crate jazyka Rust bez package URL

Obě SBOM obsahují stejných 653 verzí 559 crate jazyka Rust, například cairo-rs a zune-jpeg, které do sebe kompiluje librsvg. Yocto každý z nich uvádí jen jako soubor .crate a URL ke stažení z crates.io, uvnitř receptu, který ho používá. Ani jeden nemá package URL pkg:cargo. CRACI zaznamenává každý crate s ním.

Právě to rozhoduje, zda je můžete monitorovat na zranitelnosti. Párování zranitelností funguje na základě package URL: bezpečnostní upozornění pro crate ho uvádí jako pkg:cargo/... a název souboru v seznamu zdrojů jiného receptu nedává nástrojům pro SBOM a zranitelnosti nic, s čím by ho mohly spárovat. Se samotnou SBOM z Yocto zůstane zranitelný crate ve vašem image nenahlášen.

Se SBOM z CRACI se každý crate páruje s bezpečnostními upozorněními, každý balíček v buildu ukazuje svůj stav zranitelností a CRACI SBOM dál znovu vyhodnocuje, jakmile vyjdou nová upozornění, dlouho po dokončení buildu.

Co našlo jen CRACI

Komponenty chybějící v SBOM z Yocto (celkem 88) pocházely z míst mimo metadata BitBake:

• Balíčky hostitele: 23, nainstalované na stroji buildu, například cpio 2.15 z Ubuntu, libc6, locales a python3-jinja2. BitBake s nimi běží a SBOM z Yocto je neuvádí.
• Zdroje z GitHubu: 10, včetně patchelf, btrfs-progs a GitHub Action actions/upload-artifact, připnuté na commit, na kterém workflow běžel
• Další zdroje a nástroje stažené během buildu, například pseudo-prebuilt, tzdata a nástroje pro build v Pythonu jako hatchling a setuptools_scm

Žádná z nich není v image nainstalovaná, ale všechny leží na kritické cestě buildu: kompromitovaný nástroj hostitele nebo Action může kompromitovat váš image, aniž by kdy byl jeho součástí. CRACI je uvádí, protože vidí provoz přicházející do buildu.

Kolik stojí vestavěná SBOM

Generování SBOM v Yocto není zadarmo. Na stejném runneru s 32 vCPU trval build s ním 155 min 40 s a SBOM zapsal jako 1,632 samostatných souborů SPDX. Build bez něj, se záznamem od CRACI, trval 88 min 48 s. Při sazbě CRACI $0.002 za vCPU-minutu to dělá zhruba $9.96 proti $5.68 za build, a to ještě bez času, který váš tým stráví čekáním.

Ve srovnání s runnery hostovanými na GitHubu je rozdíl větší. CRACI spouští buildy zhruba dvakrát rychleji díky rychlejšímu hardwaru, kratšímu čekání ve frontě a cache, takže stejný build se SBOM z Yocto na 32jádrovém runneru ARM64 hostovaném na GitHubu by trval zhruba 5 h 11 min. Při $0.050 za minutu to je $15.60. Build na CRACI stojí $5.68: o 64% méně, tedy zhruba 2,7krát levněji. Ceníkové ceny GitHubu k září 2026, před započtením zahrnutého využití.

Výstup SPDX z Yocto nese i věci, které CRACI nezaznamenává, například patche, které recept aplikuje, a CVE, které označuje jako opravené. Pokud na nich váš proces závisí, nechte create-spdx zapnuté a používejte SBOM z CRACI vedle něj. Pokud ne, SBOM z CRACI sama pokryje každou komponentu, kterou pokrývala SBOM z Yocto, a ještě víc.

Proč na tom záleží pro bezpečnost dodavatelského řetězce

To, co do buildu vstupuje, rozhoduje o tom, co z něj vychází, ať už je to v image nainstalované, nebo ne. Útočníci to vědí a právě build je místem, kudy pronikly nedávné útoky na dodavatelský řetězec:

• Útoky se skrývají v buildu. Zadní vrátka v xz utils (CVE-2024-3094) byla ve verzích 5.6.0 a 5.6.1. Jejich spouštěč se nacházel v release tarballech, ne v repozitáři Git, a škodlivý kód se do knihovny dostal během jejího sestavování. Čtení zdrojového kódu ho neodhalilo; přesná znalost toho, který tarball build stáhl, ano.
• Závislosti CI jsou také cílem. V březnu 2025 CISA oznámila, že všechny verze GitHub Action tj-actions/changed-files byly tři dny kompromitované. Action běží uvnitř vašeho jobu buildu, a proto CRACI uvádí ty, které váš workflow použil, připnuté na commit, který běžel.
• Crate jazyka Rust mizí v binárkách. Cargo kompiluje crate do programů, které je používají, takže zranitelný crate se dodá uvnitř image, aniž by se kdy objevil jako balíček. Pokud ho SBOM uvádí jen jako název souboru, nástroje pro zranitelnosti ho také nespárují. Dodatečné skenování hotové binárky musí hádat, co do ní vstoupilo; záznam buildu ne.
• Nemůžete reagovat na to, co nevidíte. Když vyjde bezpečnostní upozornění pro crate nebo nástroj buildu, potřebujete vědět, které buildy ho použily. CRACI uchovává SBOM každého buildu a ukazuje, které buildy obsahovaly zranitelnou závislost, přímou nebo tranzitivní, takže víte, v jakém období jste byli zasaženi. To funguje jen tehdy, když má každá komponenta package URL, podle kterého ji lze spárovat.
• Build by se měl dostat jen tam, kam potřebuje. Egress policy CRACI blokuje spojení na hosty, které build nepotřebuje, takže kompromitovaná závislost, která se pokusí poslat vaše tajné klíče na server útočníka, je zastavena, i u útoku, který dosud nikdo neviděl.

Zákazníci i předpisy jako Cyber Resilience Act také žádají po výrobcích připojených zařízení, aby věděli, co do jejich produktů vstupuje. SBOM, která pokrývá celý build, je důkazem, který obstojí, když se zeptají.

Proč se buildy Yocto v CI spouštějí těžko

Úplný build image kompiluje ze zdrojového kódu toolchain, jádro a stovky balíčků. Na standardních 2jádrových runnerech, které nabízí většina služeb CI, to může trvat hodiny, a proto mnoho týmů vyvíjejících embedded systémy drží vyhrazený build server pod stolem nebo v racku. Ten server se pak stává dalším strojem, který je třeba patchovat, zálohovat a vysvětlovat auditorovi.

Build Yocto také stahuje velké množství dat: tarbally se zdrojovým kódem, repozitáře Git a patche z upstreamových projektů a zrcadel. Právě tato stahování musí vaše SBOM zachytit a právě o nich předpisy jako Cyber Resilience Act žádají, aby o nich výrobci připojených zařízení věděli a sledovali je.

Co CRACI dává buildu Yocto

Runnery dimenzované pro BitBake

Runnery CRACI se škálují od 1 do 32 výpočetních jednotek, kde každá jednotka představuje 1 vCPU a 3 GB RAM. Build Yocto si může přímo z workflow vyžádat největší velikost, 32 vCPU a 96 GB RAM. Joby běží v izolovaných virtuálních strojích a běhy se v GitHubu dál zobrazují jako kterýkoli jiný job Actions.

Minuty se měří po sekundách a účtují za vCPU-minutu, takže velký runner stojí za minutu víc a skončí dřív. Aktuální sazby najdete v ceníku.

Síťový přístup, o kterém rozhodujete vy

BitBake už umí omezit svůj fetcher na seznam hostů pomocí BB_ALLOWED_NETWORKS. CRACI přidává druhou kontrolu na runneru: egress policy, která se ověřuje před spuštěním jobu a je fail-closed, takže recept, skript nebo kompromitovaný nástroj, který fetcher obejde, se stejně nedostane na host, který jste nepovolili. CRACI vás upozorní na porušení politiky.

Záznam toho, co build stáhl

CRACI sleduje provoz, který job posílá na hosty s balíčky a zdrojovým kódem, a zaznamenává ho jako důkazy z buildu. U buildu Yocto to znamená nezávislý přehled o zdrojích, které skutečně přišly po síti, vedle SBOM, kterou zapisuje samotné Yocto.

Minimální workflow

Příklad pro Yocto v dokumentaci CRACI sestavuje core-image-sato pro qemux86-64. Pro CRACI je důležitá velikost runneru a konfigurace fetcheru, která používá oficiální zrcadlo zdrojového kódu Yocto:

jobs:
  build:
    runs-on: craci
    steps:
      - uses: cracicorp/setup@v1
        with:
          size: "32"
      # install the host packages from the Yocto quick start, then:
      - run: |
          echo 'SOURCE_MIRROR_URL = "https://downloads.yoctoproject.org/mirror/sources/"' >> conf/local.conf
          echo 'BB_ALLOWED_NETWORKS = "downloads.yoctoproject.org"' >> conf/local.conf
          bitbake core-image-sato

Průvodce v dokumentaci obsahuje celý workflow, včetně závislostí hostitele a nastavení locale, a reference konfigurace runneru uvádí všechny volby nastavení.

Co je dobré vědět

• Buildy běží z GitHub Actions na spravovaných runnerech CRACI v evropské infrastruktuře. Runnery hostované zákazníkem a další systémy CI jsou v plánu vývoje.
• Nasměrujte BitBake na zrcadla, která CRACI vidí, například oficiální zrcadlo zdrojového kódu Yocto, místo libovolných hostů. Průvodce v dokumentaci ukazuje funkční nastavení.
• Rychlé opakované buildy zajistí, když mezi běhy uchováte adresář stažených souborů a cache sdíleného stavu.
• Nativní runnery ARM64 jsou k dispozici za stejnou sazbu jako x86-64.

Vyvíjíte připojená zařízení pro trh EU? Přečtěte si, co CRA požaduje a jak CRACI funguje pro průmyslový IoT a spotřební elektroniku. Používáte Black Duck? Přečtěte si, čím se liší detektor BitBake od Black Duck. Srovnáváte nástroje SBOM pro Yocto? Viz CRACI vs Timesys Vigiles.

SBOM pro Yocto a CRACI: časté dotazy

Generuje Yocto SBOM?

Ano. Build systém OpenEmbedded generuje od Yocto 4.3 (Nanbield) ve výchozím nastavení SBOM SPDX pomocí třídy create-spdx. Pro image zapisuje IMAGE-MACHINE.spdx.json do tmp/deploy/images/MACHINE/ a pokrývá komponenty, licence, závislosti, zdroje, aplikované patche a opravené zranitelnosti. Na Kirkstone (4.0) ji zapnete přidáním INHERIT += "create-spdx".

Jakou verzi SPDX Yocto vytváří?

Od Yocto 5.1 (Styhead) ve výchozím nastavení SPDX 3.0, které jako výchozí nahradilo verzi 2.2. Scarthgap (5.0) ve výchozím nastavení vytváří SPDX 2.2 a pomocí třídy create-spdx-3.0 může přejít na 3.0.

Jak z Yocto získám SBOM CycloneDX?

Přidejte vrstvu meta-cyclonedx ve větvi pro vaše vydání a zděďte cyclonedx-export v local.conf. Vedle image zapíše SBOM .cyclonedx.bom.json a soubor .cyclonedx.vex.json, ve výchozím nastavení ve formátu CycloneDX 1.6.

Co SBOM z Yocto nepokrývá?

Při souběžném buildu core-image-sato obsahovala SBOM zaznamenaná CRACI všech 865 komponent ze SBOM Yocto a dalších 88: balíčky hostitele na stroji buildu, například cpio z Ubuntu, zdroje a Actions z GitHubu a další zdroje stažené během buildu. Yocto navíc uvádí svých 653 verzí crate jazyka Rust jen podle názvu souboru a URL ke stažení, bez package URL, na kterém závisí párování zranitelností. Proč obecné skenery přehlédnou ještě víc, vysvětluje stránka proč skenery SBOM přehlížejí obsah buildů Yocto.

Můžu monitorovat zranitelnosti v buildu Yocto?

Ano, s CRACI. Párování zranitelností funguje na základě package URL a vestavěná SBOM Yocto uvádí crate jazyka Rust jen podle názvu souboru a URL ke stažení, takže je nelze spárovat. CRACI zaznamenává crate jazyka Rust i balíčky stroje buildu s package URL, vůči kterým se bezpečnostní upozornění zveřejňují (pkg:cargo, pkg:deb), včetně všech 653 verzí crate v core-image-sato. U každého balíčku zobrazuje stav zranitelností a SBOM dál znovu vyhodnocuje, jakmile vyjdou nová bezpečnostní upozornění.

Může CRACI nahradit SBOM z Yocto?

Co do pokrytí dodavatelského řetězce ano. Ve stejném srovnání obsahovala SBOM z CRACI každou komponentu z vestavěné SBOM Yocto, dalších 88 a package URL pro každý crate jazyka Rust, a build bez generování SBOM v Yocto trval o 43 % kratší dobu. Výstup SPDX z Yocto ale stále nese metadata receptů, která CRACI nezaznamenává, například aplikované patche a CVE, které recept označuje jako opravené. Pokud na nich závisíte, nechte create-spdx zapnuté.

Zvládne runner CRACI celý build image Yocto?

Runnery CRACI mají až 32 vCPU a 96 GB RAM, nastavitelné z workflow. Dokumentace CRACI obsahuje příklad pro Yocto, který sestaví core-image-sato na největší velikosti.

Jaké CI používá build Yocto na CRACI?

GitHub Actions. Váš workflow běží na spravovaných runnerech CRACI a běhy se v GitHubu zobrazují jako kterýkoli jiný job Actions. Další systémy CI a runnery hostované zákazníkem jsou v plánu vývoje.