Yocto-SBOM en builds op CRACI

Een SBOM genereren met Yocto

Het OpenEmbedded-buildsysteem schrijft SPDX-SBOM's via de class create-spdx. Of die aan staat, en welke SPDX-versie hij schrijft, hangt af van de Yocto-release:

• Kirkstone (4.0): standaard uit. Voeg INHERIT += "create-spdx" toe. SPDX 2.2.
• Nanbield (4.3): vanaf deze release staat SBOM-generatie standaard aan.
• Scarthgap (5.0): standaard aan, SPDX 2.2. SPDX 3.0 is beschikbaar via de class create-spdx-3.0.
• Styhead (5.1) en later: standaard aan, SPDX 3.0.

U stelt het in via een configuratiebestand zoals conf/local.conf. Op een actuele release hoeft u meestal niets toe te voegen; om het uit te schakelen gebruikt u 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"

Andere SPDX_-variabelen voegen detail toe. SPDX_INCLUDE_SOURCES beschrijft de bronbestanden achter elke hosttool en elk doelpakket, waardoor de output veel groter wordt. Recente releases voegen opties toe voor de kernelconfiguratie, PACKAGECONFIG-features, leveranciersinformatie en package URL's voor bronnen uit Cargo, Go, PyPI, npm en CPAN.

Waar de SBOM-bestanden terechtkomen

Bouw een image en de SBOM op het hoogste niveau verschijnt ernaast, als IMAGE-MACHINE.spdx.json in tmp/deploy/images/MACHINE/ binnen de buildmap. Gerelateerde bestanden staan in dezelfde map en in tmp/deploy/spdx. Op Kirkstone komen de documenten per recipe als archief 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 met meta-cyclonedx

Yocto zelf schrijft alleen SPDX. Voor CycloneDX genereert de layer meta-cyclonedx een SBOM uit het root-bestandssysteem van de image, plus een apart VEX-bestand met de gepatchte en genegeerde CVE's die het buildsysteem kent. Check de branch van de layer voor uw release uit, voeg hem toe aan uw layers en laat zijn class overerven:

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

De bestanden komen naast de image terecht in DEPLOY_DIR_IMAGE, met de suffixen .cyclonedx.bom.json en .cyclonedx.vex.json. De standaard is CycloneDX 1.6, in te stellen met CYCLONEDX_SPEC_VERSION. Standaard worden alleen runtimepakketten opgenomen. Dat houdt de SBOM klein, maar kan componenten weglaten die de image bereiken zonder als pakket te zijn geïnstalleerd.

Wat de Yocto-SBOM weglaat

De SBOM van Yocto is grondig als het gaat om wat BitBake bouwt. In SPDX 3 omvat hij de image, elke recipe inclusief de native recipes voor de buildtijd, hun bronnen, de toegepaste patches en de kwetsbaarheden die als opgelost zijn gemarkeerd. Voor core-image-sato kwam dat neer op 1,632 afzonderlijke bestanden. Om te zien wat hij weglaat, hebben we de image gebouwd op een CRACI-runner, native ARM64 met 32 vCPU's, en de SBOM van Yocto component voor component vergeleken met de SBOM die CRACI vastlegde, nadat we de namen in al die bestanden hadden genormaliseerd.

Van de 953 componenten in de SBOM van CRACI stonden er 865 ook in die van Yocto. Geen enkele stond alleen in die van Yocto. De verschillen zitten in wat Yocto niet kan zien, en in hoe het identificeert wat het wel vermeldt.

Rust-crates zonder package URL

Beide SBOM's bevatten dezelfde 653 versies van 559 Rust-crates, zoals cairo-rs en zune-jpeg, die librsvg meecompileert. Yocto vermeldt elke crate alleen als .crate-bestand met een download-URL van crates.io, binnen de recipe die hem gebruikt. Geen enkele heeft een pkg:cargo-package URL. CRACI legt elke crate vast met een package URL.

Dat bepaalt of u ze op kwetsbaarheden kunt monitoren. Het matchen van kwetsbaarheden werkt op package URL's: een advisory voor een crate noemt die als pkg:cargo/..., en een bestandsnaam in de bronnenlijst van een andere recipe geeft SBOM- en kwetsbaarheidstools niets om tegen te matchen. Met alleen de SBOM van Yocto blijft een kwetsbare crate in uw image ongemeld.

Met die van CRACI wordt elke crate gematcht tegen advisories, toont elk pakket in de build zijn kwetsbaarheidsstatus, en blijft CRACI de SBOM opnieuw beoordelen zodra nieuwe advisories worden gepubliceerd, lang nadat de build klaar is.

Wat alleen CRACI vond

De 88 componenten die in de SBOM van Yocto ontbraken, kwamen van buiten de metadata van BitBake:

• 23 hostpakketten die op de buildmachine zijn geïnstalleerd, zoals cpio 2.15 van Ubuntu, libc6, locales en python3-jinja2. BitBake draait ermee, en de SBOM van Yocto vermeldt ze niet.
• 10 GitHub-bronnen, waaronder patchelf, btrfs-progs en de GitHub Action actions/upload-artifact, vastgepind op de commit die de workflow draaide
• Andere bronnen en tools die tijdens de build zijn opgehaald, zoals pseudo-prebuilt, tzdata en Python-buildtools zoals hatchling en setuptools_scm

Geen van deze is in de image geïnstalleerd, maar ze liggen allemaal op het kritieke pad van de build: een gecompromitteerde hosttool of Action kan uw image compromitteren zonder er ooit deel van uit te maken. CRACI vermeldt ze omdat het het verkeer ziet dat de build binnenkomt.

Wat de ingebouwde SBOM kost

De SBOM-generatie van Yocto is niet gratis. Op dezelfde runner met 32 vCPU's duurde de build ermee 155 min 40 s en schreef hij de SBOM als 1,632 afzonderlijke SPDX-bestanden. De build zonder SBOM-generatie, met CRACI als recorder, duurde 88 min 48 s. Tegen het tarief van CRACI van $0.002 per vCPU-minuut is dat ongeveer $9.96 tegenover $5.68 per build, nog los van de tijd die uw team erop wacht.

Het verschil is groter ten opzichte van door GitHub gehoste runners. CRACI draait builds ongeveer twee keer zo snel, dankzij snellere hardware, kortere wachtrijen en caching, dus dezelfde build met de SBOM van Yocto zou op een door GitHub gehoste 32-core ARM64-runner ongeveer 5 h 11 min duren. Tegen $0.050 per minuut is dat $15.60. De build op CRACI kost $5.68: 64% minder, of ongeveer 2,7 keer goedkoper. GitHub-catalogusprijzen per september 2026; inbegrepen minuten gelden niet voor grotere runners.

De SPDX-output van Yocto bevat wel dingen die CRACI niet vastlegt, zoals de patches die een recipe toepast en de CVE's die hij als opgelost markeert. Hangt uw proces daarvan af, laat create-spdx dan aan staan en gebruik de SBOM van CRACI ernaast. Zo niet, dan dekt de SBOM van CRACI op zichzelf elk component dat in die van Yocto stond, en meer.

Waarom dit belangrijk is voor ketenbeveiliging

Wat een build ingaat, bepaalt wat eruit komt, of het nu in de image wordt geïnstalleerd of niet. Aanvallers weten dat, en recente aanvallen op de softwareketen zijn via de build binnengekomen:

• Aanvallen verbergen zich in de build. De backdoor in xz utils (CVE-2024-3094) zat in de versies 5.6.0 en 5.6.1. De trigger zat in de release-tarballs in plaats van in de Git-repository, en de kwaadaardige code kwam tijdens het bouwen in de bibliotheek terecht. De broncode lezen bracht hem niet aan het licht; precies weten welke tarball de build ophaalde wel.
• CI-afhankelijkheden zijn ook doelwitten. In maart 2025 meldde CISA dat elke versie van de GitHub Action tj-actions/changed-files drie dagen lang gecompromitteerd was. Een Action draait binnen uw buildjob, en daarom vermeldt CRACI de Actions die uw workflow gebruikte, vastgepind op de commit die draaide.
• Rust-crates verdwijnen in binaries. Cargo compileert crates in de programma's die ze gebruiken, dus een kwetsbare crate wordt in de image meegeleverd zonder ooit als pakket te verschijnen. Als de SBOM hem alleen als bestandsnaam vermeldt, kunnen kwetsbaarheidstools hem evenmin matchen. Wie achteraf de voltooide binary scant, moet raden wat erin is gegaan; wie de build vastlegt, hoeft dat niet.
• U kunt niet reageren op wat u niet ziet. Wanneer er een advisory verschijnt voor een crate of een buildtool, moet u weten welke builds die gebruikten. CRACI bewaart de SBOM van elke build en toont welke builds de kwetsbare afhankelijkheid bevatten, direct of transitief, zodat u weet in welke periode u getroffen was. Dat werkt alleen als elk component een package URL heeft om op te matchen.
• Een build mag alleen bereiken wat hij nodig heeft. Het egressbeleid van CRACI blokkeert verbindingen met hosts die de build niet nodig heeft, zodat een gecompromitteerde afhankelijkheid die uw secrets naar de server van een aanvaller probeert te sturen wordt tegengehouden, zelfs bij een aanval die niemand eerder heeft gezien.

Klanten en regelgeving zoals de Cyber Resilience Act vragen fabrikanten van verbonden apparaten ook te weten wat er in hun producten zit. Een SBOM die de hele build dekt, is bewijs dat standhoudt wanneer ze ernaar vragen.

Waarom Yocto-builds lastig in CI te draaien zijn

Een volledige imagebuild compileert een toolchain, een kernel en honderden pakketten vanaf de broncode. Op de standaard 2-core runners die de meeste CI-diensten bieden, kan dat uren duren. Daarom houden veel embedded teams een eigen buildserver onder een bureau of in een rack, en die server wordt nog een machine om te patchen, te back-uppen en aan een auditor uit te leggen.

Een Yocto-build downloadt ook veel: bron-tarballs, Git-repositories en patches van upstreamprojecten en mirrors. Die downloads zijn wat uw SBOM moet verantwoorden, en wat regelgeving zoals de Cyber Resilience Act fabrikanten van verbonden apparaten vraagt te kennen en bij te houden.

Wat CRACI een Yocto-build biedt

Runners op maat voor BitBake

CRACI-runners schalen van 1 tot 32 compute units, waarbij elke unit 1 vCPU en 3 GB RAM is. Een Yocto-build kan vanuit de workflow zelf het grootste formaat aanvragen, 32 vCPU's en 96 GB RAM. Jobs draaien in geïsoleerde virtuele machines en de runs verschijnen nog steeds in GitHub zoals elke andere Actions-job.

Minuten worden per seconde gemeten en per vCPU-minuut gefactureerd, dus een grote runner kost meer per minuut en is eerder klaar. Zie prijzen voor de actuele tarieven.

Netwerktoegang die u bepaalt

BitBake kan zijn fetcher al beperken tot een lijst hosts met BB_ALLOWED_NETWORKS. CRACI voegt een tweede controle toe op de runner: een egressbeleid dat wordt gecontroleerd voordat de job start en fail-closed is, zodat een recipe, een script of een gecompromitteerde tool die de fetcher omzeilt nog steeds geen host kan bereiken die u niet hebt toegestaan. CRACI waarschuwt u bij overtredingen van het beleid.

Een vastlegging van wat de build ophaalde

CRACI observeert het verkeer dat een job naar pakket- en bronhosts stuurt en legt het vast als buildbewijs. Voor een Yocto-build betekent dat een onafhankelijk verslag van de bronnen die daadwerkelijk over het netwerk zijn binnengekomen, naast de SBOM die Yocto zelf schrijft.

Een minimale workflow

Het Yocto-voorbeeld in de documentatie van CRACI bouwt core-image-sato voor qemux86-64. Wat voor CRACI telt, zijn het runnerformaat en een fetcherconfiguratie die de officiële bronmirror van Yocto gebruikt:

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

De handleiding in de documentatie bevat de volledige workflow, inclusief hostafhankelijkheden en de instelling van locales, en de referentie voor runnerconfiguratie vermeldt elke setupoptie.

Goed om te weten

• Builds draaien vanuit GitHub Actions op de beheerde runners van CRACI op Europese infrastructuur. Door de klant gehoste runners en andere CI-systemen staan op de roadmap.
• Laat BitBake mirrors gebruiken die CRACI kan zien, zoals de officiële bronmirror van Yocto, in plaats van willekeurige hosts. De handleiding in de documentatie toont een werkende opzet.
• De downloadmap en de shared state-cache tussen runs bewaren, is wat herhaalde builds snel maakt.
• Native ARM64-runners zijn beschikbaar tegen hetzelfde tarief als x86-64.

Bouwt u verbonden apparaten voor de EU-markt? Lees wat de CRA vereist, en hoe CRACI werkt voor industrieel IoT en consumentenelektronica. Vergelijkt u SBOM-tools voor Yocto? Zie CRACI vs Timesys Vigiles.

Yocto-SBOM's en CRACI: veelgestelde vragen

Genereert Yocto een SBOM?

Ja. Het OpenEmbedded-buildsysteem genereert sinds Yocto 4.3 (Nanbield) standaard een SPDX-SBOM, via de class create-spdx. Voor een image schrijft het IMAGE-MACHINE.spdx.json naar tmp/deploy/images/MACHINE/, met componenten, licenties, afhankelijkheden, bronnen, toegepaste patches en opgeloste kwetsbaarheden. Op Kirkstone (4.0) voegt u INHERIT += "create-spdx" toe om het in te schakelen.

Welke SPDX-versie produceert Yocto?

Sinds Yocto 5.1 (Styhead) standaard SPDX 3.0, dat 2.2 als standaard heeft vervangen. Scarthgap (5.0) produceert standaard SPDX 2.2 en kan met de class create-spdx-3.0 overschakelen naar 3.0.

Hoe krijg ik een CycloneDX-SBOM uit Yocto?

Voeg de layer meta-cyclonedx toe op de branch voor uw release en laat de class cyclonedx-export overerven in local.conf. Die schrijft een .cyclonedx.bom.json-SBOM en een .cyclonedx.vex.json-bestand naast de image, standaard in CycloneDX 1.6.

Wat mist de Yocto-SBOM?

In een vergelijkende build van core-image-sato bevatte de door CRACI vastgelegde SBOM alle 865 componenten uit de SBOM van Yocto plus 88 extra: hostpakketten op de buildmachine, zoals cpio van Ubuntu, GitHub-bronnen en Actions, en andere bronnen die tijdens de build werden opgehaald. Yocto vermeldt bovendien zijn 653 versies van Rust-crates alleen met bestandsnaam en download-URL, zonder package URL, terwijl het matchen van kwetsbaarheden daarop steunt.

Kan ik kwetsbaarheden in een Yocto-build monitoren?

Ja, met CRACI. Het matchen van kwetsbaarheden werkt op package URL's, en de ingebouwde SBOM van Yocto vermeldt Rust-crates alleen met bestandsnaam en download-URL, dus die kunnen niet worden gematcht. CRACI legt de Rust-crates en de pakketten van de buildmachine vast met de package URL's waartegen advisories worden gepubliceerd (pkg:cargo, pkg:deb), inclusief alle 653 crateversies in core-image-sato. Het toont de kwetsbaarheidsstatus van elk pakket en blijft de SBOM opnieuw beoordelen zodra nieuwe advisories worden gepubliceerd.

Kan CRACI de Yocto-SBOM vervangen?

Voor de dekking van de keten wel. In dezelfde vergelijking bevatte de SBOM van CRACI elk component uit de ingebouwde SBOM van Yocto, 88 extra en een package URL voor elke Rust-crate, en de build zonder SBOM-generatie van Yocto duurde 43% korter. De SPDX-output van Yocto bevat nog steeds recipe-metadata die CRACI niet vastlegt, zoals de toegepaste patches en de CVE's die een recipe als opgelost markeert. Steunt u daarop, laat create-spdx dan aan staan.

Kan een CRACI-runner een volledige Yocto-imagebuild aan?

CRACI-runners gaan tot 32 vCPU's en 96 GB RAM, in te stellen vanuit de workflow. De documentatie van CRACI bevat een Yocto-voorbeeld dat core-image-sato op het grootste formaat bouwt.

Welke CI gebruikt een Yocto-build op CRACI?

GitHub Actions. Uw workflow draait op de beheerde runners van CRACI en de runs verschijnen in GitHub zoals elke andere Actions-job. Andere CI-systemen en door de klant gehoste runners staan op de roadmap.