Yocto-SBOM och byggen på CRACI

Så genererar du en SBOM med Yocto

Byggsystemet OpenEmbedded skriver SBOM:er i SPDX via klassen create-spdx. Om den är påslagen, och vilken SPDX-version den skriver, beror på Yocto-releasen:

• Kirkstone (4.0): avslagen som standard. Lägg till INHERIT += "create-spdx". SPDX 2.2.
• Nanbield (4.3): SBOM-genereringen är påslagen som standard från och med den här releasen.
• Scarthgap (5.0): påslagen som standard, SPDX 2.2. SPDX 3.0 finns via klassen create-spdx-3.0.
• Styhead (5.1) och senare: påslagen som standard, SPDX 3.0.

Du ställer in det i en konfigurationsfil som conf/local.conf. På en aktuell release behöver du oftast inte lägga till något; för att slå av den använder du 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"

Andra SPDX_-variabler ger fler detaljer. SPDX_INCLUDE_SOURCES beskriver källfilerna bakom varje värdverktyg och målpaket, vilket gör utdata betydligt större. Nyare releaser lägger till alternativ för kärnkonfigurationen, PACKAGECONFIG-funktioner, leverantörsinformation och paket-URL:er för källor från Cargo, Go, PyPI, npm och CPAN.

Var SBOM-filerna hamnar

Bygg en avbild så hamnar SBOM:en på toppnivå bredvid den, som IMAGE-MACHINE.spdx.json i tmp/deploy/images/MACHINE/ i byggkatalogen. Relaterade filer finns i samma katalog och i tmp/deploy/spdx. På Kirkstone kommer dokumenten per recept som ett arkiv, 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 med meta-cyclonedx

Yocto skriver själv bara SPDX. För CycloneDX genererar lagret meta-cyclonedx en SBOM från avbildens rotfilsystem, plus en separat VEX-fil med de patchade och ignorerade CVE:er som byggsystemet känner till. Checka ut lagrets gren för din release, lägg till den bland dina lager och ärv dess klass:

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

Filerna hamnar bredvid avbilden i DEPLOY_DIR_IMAGE, med suffixen .cyclonedx.bom.json och .cyclonedx.vex.json. Standard är CycloneDX 1.6, inställt med CYCLONEDX_SPEC_VERSION. Som standard ingår bara körtidspaket, vilket håller SBOM:en liten men kan utelämna komponenter som hamnar i avbilden utan att installeras som paket.

Vad Yoctos SBOM utelämnar

Yoctos SBOM är grundlig när det gäller det som BitBake bygger. I SPDX 3 omfattar den avbilden, varje recept inklusive de native-recept som används vid byggtid, deras källor, de applicerade patcharna och de sårbarheter som markerats som åtgärdade. För core-image-sato blev det 1,632 separata filer. För att se vad den utelämnar byggde vi avbilden på en CRACI-runner, nativ ARM64 med 32 vCPU, och jämförde Yoctos SBOM med den som CRACI registrerade, komponent för komponent, efter att ha normaliserat namnen i alla de filerna.

Av 953 komponenter i CRACI:s SBOM fanns 865 också i Yoctos. Ingen fanns bara i Yoctos. Skillnaderna ligger i det Yocto inte kan se, och i hur den identifierar det den faktiskt listar.

Rust-crates utan paket-URL

Båda SBOM:erna innehåller samma 653 versioner av 559 Rust-crates, som cairo-rs och zune-jpeg, som librsvg kompilerar in. Yocto listar var och en bara som en .crate-fil och en nedladdnings-URL från crates.io, inuti receptet som använder den. Inte en enda har en paket-URL av typen pkg:cargo. CRACI registrerar varje crate med en.

Det avgör om du kan bevaka dem för sårbarheter. Sårbarhetsmatchning bygger på paket-URL:er: en säkerhetsbulletin för en crate anger den som pkg:cargo/..., och ett filnamn i ett annat recepts källista ger SBOM- och sårbarhetsverktyg inget att matcha mot. Med enbart Yoctos SBOM blir en sårbar crate i din avbild aldrig rapporterad.

Med CRACI:s matchas varje crate mot säkerhetsbulletiner, varje paket i bygget visar sin sårbarhetsstatus, och CRACI fortsätter att omvärdera SBOM:en när nya säkerhetsbulletiner publiceras, långt efter att bygget är klart.

Vad bara CRACI hittade

De 88 komponenter som saknades i Yoctos SBOM kom från utanför BitBakes metadata:

• 23 värdpaket installerade på byggmaskinen, som Ubuntus cpio 2.15, libc6, locales och python3-jinja2. BitBake körs med dem, och Yoctos SBOM listar dem inte.
• 10 källor från GitHub, bland dem patchelf, btrfs-progs och GitHub-actionen actions/upload-artifact, fastlåsta till den commit som arbetsflödet körde
• Andra källor och verktyg som hämtades under bygget, som pseudo-prebuilt, tzdata och byggverktyg för Python som hatchling och setuptools_scm

Inget av detta installeras i avbilden, men allt ligger i byggets kritiska väg: ett komprometterat värdverktyg eller en komprometterad action kan kompromettera din avbild utan att någonsin ingå i den. CRACI listar dem eftersom CRACI ser trafiken som kommer in i bygget.

Vad den inbyggda SBOM:en kostar

Yoctos SBOM-generering är inte gratis. På samma runner med 32 vCPU tog bygget med den 155 min 40 s och skrev SBOM:en som 1,632 separata SPDX-filer. Bygget utan den, med CRACI:s registrering, tog 88 min 48 s. Med CRACI:s pris på $0.002 per vCPU-minut blir det cirka $9.96 mot $5.68 per bygge, utan att räkna tiden ditt team lägger på att vänta.

Skillnaden är större mot GitHub-hostade runners. CRACI kör byggen ungefär dubbelt så snabbt, tack vare snabbare hårdvara, kortare kötider och cachning, så samma bygge med Yoctos SBOM på en GitHub-hostad ARM64-runner med 32 kärnor skulle ta cirka 5 h 11 min. Till $0.050 per minut blir det $15.60. CRACI-bygget kostar $5.68: 64% mindre, eller ungefär 2,7 gånger billigare. GitHubs listpriser per september 2026; inkluderade minuter gäller inte större runners.

Yoctos SPDX-utdata innehåller visserligen saker som CRACI inte registrerar, till exempel de patchar ett recept applicerar och de CVE:er det markerar som åtgärdade. Om din process är beroende av dem, behåll create-spdx påslaget och använd CRACI:s SBOM vid sidan av. Annars täcker CRACI:s SBOM på egen hand varje komponent som Yoctos gjorde, och fler.

Därför spelar det roll för säkerheten i leveranskedjan

Det som går in i ett bygge avgör vad som kommer ut, oavsett om det installeras i avbilden eller inte. Det vet angripare, och det är via bygget som de senaste attackerna mot leveranskedjan har tagit sig in:

• Attacker gömmer sig i bygget. Bakdörren i xz utils (CVE-2024-3094) fanns i version 5.6.0 och 5.6.1. Dess utlösare låg i release-tarballarna snarare än i Git-repot, och den skadliga koden kom in i biblioteket medan det byggdes. Att läsa källkoden avslöjade den inte; att veta exakt vilken tarball bygget hämtade gör det.
• CI-beroenden är också mål. I mars 2025 rapporterade CISA att varje version av GitHub-actionen tj-actions/changed-files var komprometterad i tre dagar. En action körs inuti ditt byggjobb, och därför listar CRACI de actions som ditt arbetsflöde använde, fastlåsta till den commit som kördes.
• Rust-crates försvinner in i binärer. Cargo kompilerar in crates i programmen som använder dem, så en sårbar crate levereras inuti avbilden utan att någonsin synas som ett paket. Om SBOM:en bara listar den som ett filnamn kan sårbarhetsverktygen inte heller matcha den. Att skanna den färdiga binären i efterhand innebär att gissa vad som gick in; att registrera bygget gör det inte.
• Du kan inte agera på det du inte ser. När en säkerhetsbulletin kommer för en crate eller ett byggverktyg behöver du veta vilka byggen som använde den. CRACI sparar varje bygges SBOM och visar vilka byggen som innehöll det sårbara beroendet, direkt eller transitivt, så att du vet under vilken period du var påverkad. Det fungerar bara när varje komponent har en paket-URL att matcha mot.
• Ett bygge ska bara nå det som behövs. CRACI:s policy för utgående trafik blockerar anslutningar till värdar som bygget inte behöver, så ett komprometterat beroende som försöker skicka dina hemligheter till en angripares server stoppas, även i en attack som ingen har sett tidigare.

Kunder och regelverk som Cyber Resilience Act kräver också att tillverkare av uppkopplade enheter vet vad som ingår i deras produkter. En SBOM som täcker hela bygget är ett bevis som håller när de frågar.

Därför är Yocto-byggen svåra att köra i CI

Ett fullständigt avbildsbygge kompilerar en verktygskedja, en kärna och hundratals paket från källkod. På de vanliga runnerna med 2 kärnor som de flesta CI-tjänster erbjuder kan det ta timmar, så många team inom inbyggda system har en dedikerad byggserver under ett skrivbord eller i ett rack, och den servern blir ännu en maskin att patcha, säkerhetskopiera och förklara för en revisor.

Ett Yocto-bygge laddar också ner mycket: käll-tarballar, Git-repon och patchar från uppströmsprojekt och speglar. Det är de nedladdningarna som din SBOM måste redovisa, och det är dem som regelverk som Cyber Resilience Act kräver att tillverkare av uppkopplade enheter känner till och håller reda på.

Vad CRACI ger ett Yocto-bygge

Runners dimensionerade för BitBake

CRACI-runners skalar från 1 till 32 beräkningsenheter, där varje enhet är 1 vCPU och 3 GB RAM. Ett Yocto-bygge kan begära den största storleken, 32 vCPU och 96 GB RAM, direkt från arbetsflödet. Jobben körs i isolerade virtuella maskiner och körningarna syns fortfarande i GitHub som vilket annat Actions-jobb som helst.

Minuterna mäts per sekund och debiteras per vCPU-minut, så en stor runner kostar mer per minut och blir klar snabbare. Se priser för aktuella priser.

Nätverksåtkomst som du bestämmer över

BitBake kan redan begränsa sin fetcher till en lista över värdar med BB_ALLOWED_NETWORKS. CRACI lägger till en andra kontroll i runnern: en policy för utgående trafik som kontrolleras innan jobbet startar och blockerar vid fel, så att ett recept, ett skript eller ett komprometterat verktyg som går runt fetchern ändå inte kan nå en värd som du inte har tillåtit. CRACI larmar dig vid policyöverträdelser.

En registrering av vad bygget hämtade

CRACI observerar trafiken som ett jobb skickar till paket- och källvärdar och registrerar den som byggbevis. För ett Yocto-bygge innebär det en oberoende redovisning av de källor som faktiskt kom över nätverket, bredvid den SBOM som Yocto själv skriver.

Ett minimalt arbetsflöde

Yocto-exemplet i CRACI:s dokumentation bygger core-image-sato för qemux86-64. Det som spelar roll för CRACI är runnerstorleken och en fetcher-konfiguration som använder Yoctos officiella källspegel:

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

Guiden i dokumentationen har hela arbetsflödet, inklusive värdberoenden och språkinställningar, och referensen för runnerkonfiguration listar alla inställningsalternativ.

Bra att veta

• Byggen körs på CRACI:s hanterade runners på europeisk infrastruktur, från GitHub Actions. Kundhostade runners och andra CI-system finns på roadmapen.
• Peka BitBake mot speglar som CRACI kan se, som Yoctos officiella källspegel, snarare än godtyckliga värdar. Guiden i dokumentationen visar ett fungerande upplägg.
• Det är genom att behålla nedladdningskatalogen och shared state-cachen mellan körningar som upprepade byggen blir snabba.
• Nativa ARM64-runners finns till samma pris som x86-64.

Bygger du uppkopplade enheter för EU-marknaden? Läs vad CRA kräver, och hur CRACI fungerar för industriell IoT och hemelektronik. Jämför du SBOM-verktyg för Yocto? Se CRACI vs Timesys Vigiles.

Yocto-SBOM:er och CRACI: vanliga frågor

Genererar Yocto en SBOM?

Ja. Byggsystemet OpenEmbedded genererar som standard en SBOM i SPDX sedan Yocto 4.3 (Nanbield), via klassen create-spdx. För en avbild skriver den IMAGE-MACHINE.spdx.json till tmp/deploy/images/MACHINE/, med komponenter, licenser, beroenden, källor, applicerade patchar och åtgärdade sårbarheter. På Kirkstone (4.0) lägger du till INHERIT += "create-spdx" för att slå på den.

Vilken SPDX-version tar Yocto fram?

SPDX 3.0 som standard sedan Yocto 5.1 (Styhead), som ersatte 2.2 som standard. Scarthgap (5.0) tar fram SPDX 2.2 som standard och kan byta till 3.0 med klassen create-spdx-3.0.

Hur får jag en SBOM i CycloneDX från Yocto?

Lägg till lagret meta-cyclonedx från grenen för din release och ärv cyclonedx-export i local.conf. Det skriver en .cyclonedx.bom.json-SBOM och en .cyclonedx.vex.json-fil bredvid avbilden, som standard i CycloneDX 1.6.

Vad missar Yoctos SBOM?

I ett bygge av core-image-sato sida vid sida hade CRACI:s registrerade SBOM alla 865 komponenter i Yoctos SBOM plus 88 till: värdpaket på byggmaskinen som Ubuntus cpio, källor och Actions från GitHub samt andra källor som hämtades under bygget. Yocto listar dessutom sina 653 versioner av Rust-crates bara med filnamn och nedladdnings-URL, utan paket-URL, som sårbarhetsmatchningen bygger på.

Kan jag bevaka sårbarheter i ett Yocto-bygge?

Ja, med CRACI. Sårbarhetsmatchning bygger på paket-URL:er, och Yoctos inbyggda SBOM listar Rust-crates bara med filnamn och nedladdnings-URL, så de går inte att matcha. CRACI registrerar Rust-crates och byggmaskinens paket med de paket-URL:er som säkerhetsbulletiner publiceras mot (pkg:cargo, pkg:deb), inklusive alla 653 crate-versioner i core-image-sato. CRACI visar varje pakets sårbarhetsstatus och fortsätter att omvärdera SBOM:en när nya säkerhetsbulletiner publiceras.

Kan CRACI ersätta Yoctos SBOM?

När det gäller täckningen av leveranskedjan, ja. I samma jämförelse hade CRACI:s SBOM varje komponent i Yoctos inbyggda SBOM, 88 till och en paket-URL för varje Rust-crate, och bygget utan Yoctos SBOM-generering tog 43 % kortare tid. Yoctos SPDX-utdata innehåller fortfarande receptmetadata som CRACI inte registrerar, till exempel de applicerade patcharna och de CVE:er som ett recept markerar som åtgärdade. Om du är beroende av dem, behåll create-spdx påslaget.

Klarar en CRACI-runner ett fullständigt bygge av en Yocto-avbild?

CRACI-runners går upp till 32 vCPU och 96 GB RAM, inställt från arbetsflödet. CRACI:s dokumentation innehåller ett Yocto-exempel som bygger core-image-sato på den största storleken.

Vilken CI använder ett Yocto-bygge på CRACI?

GitHub Actions. Ditt arbetsflöde körs på CRACI:s hanterade runners och körningarna syns i GitHub som vilket annat Actions-jobb som helst. Andra CI-system och kundhostade runners finns på roadmapen.