Yocto-SBOM og Yocto-bygg på CRACI

Slik genererer du en SBOM med Yocto

Byggesystemet OpenEmbedded skriver SPDX-SBOM-er gjennom klassen create-spdx. Om den er på, og hvilken SPDX-versjon den skriver, avhenger av Yocto-utgivelsen:

• Kirkstone (4.0): av som standard. Legg til INHERIT += "create-spdx". SPDX 2.2.
• Nanbield (4.3): SBOM-generering er på som standard fra og med denne utgivelsen.
• Scarthgap (5.0): på som standard, SPDX 2.2. SPDX 3.0 er tilgjengelig gjennom klassen create-spdx-3.0.
• Styhead (5.1) og senere: på som standard, SPDX 3.0.

Du angir det i en konfigurasjonsfil som conf/local.conf. På en gjeldende utgivelse er det vanligvis ingenting å legge til; for å slå det av bruker 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"

Andre SPDX_-variabler gir flere detaljer. SPDX_INCLUDE_SOURCES beskriver kildefilene bak hvert vertsverktøy og hver målpakke, noe som gjør utdataene mye større. Nyere utgivelser har tilvalg for kjernekonfigurasjonen, PACKAGECONFIG-funksjoner, leverandørinformasjon og package URL-er for kilder fra Cargo, Go, PyPI, npm og CPAN.

Hvor SBOM-filene havner

Bygg et image, så dukker SBOM-en på toppnivå opp ved siden av det, som IMAGE-MACHINE.spdx.json i tmp/deploy/images/MACHINE/ inne i byggekatalogen. Tilhørende filer ligger i den samme katalogen og i tmp/deploy/spdx. På Kirkstone kommer dokumentene per oppskrift som et IMAGE-MACHINE.spdx.tar.zst-arkiv.

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 selv skriver bare SPDX. For CycloneDX genererer laget meta-cyclonedx en SBOM fra imagets rotfilsystem, pluss en separat VEX-fil med de patchede og ignorerte CVE-ene byggesystemet kjenner til. Sjekk ut lagets gren for din utgivelse, legg det til i lagene dine, og arv klassen:

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

Filene havner ved siden av imaget i DEPLOY_DIR_IMAGE, med suffiksene .cyclonedx.bom.json og .cyclonedx.vex.json. Standard er CycloneDX 1.6, som angis med CYCLONEDX_SPEC_VERSION. Som standard tas bare kjøretidspakker med, noe som holder SBOM-en liten, men kan utelate komponenter som havner i imaget uten å bli installert som pakker.

Hva Yocto-SBOM-en utelater

Yoctos SBOM er grundig når det gjelder det BitBake bygger. I SPDX 3 dekker den imaget, hver oppskrift inkludert de native oppskriftene for byggetid, kildene deres, patchene som er påført, og sårbarhetene som er markert som rettet. For core-image-sato ble det 1,632 separate filer. For å se hva den utelater, bygde vi imaget på en CRACI-runner, native ARM64 med 32 vCPU-er, og sammenlignet Yoctos SBOM med den CRACI registrerte, komponent for komponent, etter å ha normalisert navnene på tvers av alle disse filene.

Av 953 komponenter i SBOM-en fra CRACI var 865 også i Yoctos. Ingen fantes bare i Yoctos. Forskjellene ligger i det Yocto ikke kan se, og i hvordan den identifiserer det den faktisk oppgir.

Rust-crates uten package URL

Begge SBOM-ene inneholder de samme 653 versjonene av 559 Rust-crates, som cairo-rs og zune-jpeg, som librsvg kompilerer inn. Yocto oppgir hver av dem bare som en .crate-fil og en nedlastings-URL fra crates.io, inne i oppskriften som bruker den. Ikke én har en pkg:cargo-package URL. CRACI registrerer hver crate med en.

Det avgjør om du kan overvåke dem for sårbarheter. Sårbarhetsmatching bygger på package URL-er: En advisory for en crate navngir den som pkg:cargo/..., og et filnavn i en annen oppskrifts kildeliste gir SBOM- og sårbarhetsverktøy ingenting å matche den mot. Med bare Yoctos SBOM blir en sårbar crate i imaget ditt aldri rapportert.

Med SBOM-en fra CRACI matches hver crate mot advisories, hver pakke i bygget viser sårbarhetsstatusen sin, og CRACI vurderer SBOM-en fortløpende på nytt etter hvert som nye advisories publiseres, lenge etter at bygget er ferdig.

Det bare CRACI fant

De 88 komponentene som manglet i Yoctos SBOM, kom fra utenfor BitBakes metadata:

• 23 vertspakker installert på byggemaskinen, som Ubuntus cpio 2.15, libc6, locales og python3-jinja2. BitBake kjører med dem, og Yoctos SBOM oppgir dem ikke.
• 10 kilder fra GitHub, blant dem patchelf, btrfs-progs og GitHub Action-en actions/upload-artifact, låst til committen workflowen kjørte
• Andre kilder og verktøy hentet under bygget, som pseudo-prebuilt, tzdata og byggeverktøy for Python som hatchling og setuptools_scm

Ingen av disse er installert i imaget, men alle ligger i byggets kritiske sti: Et kompromittert vertsverktøy eller en kompromittert Action kan kompromittere imaget ditt uten noen gang å være en del av det. CRACI oppgir dem fordi den ser trafikken som kommer inn i bygget.

Hva den innebygde SBOM-en koster

Yoctos SBOM-generering er ikke gratis. På den samme runneren med 32 vCPU-er tok bygget med den 155 min 40 s og skrev SBOM-en som 1,632 separate SPDX-filer. Bygget uten den, med CRACI som registrerte, tok 88 min 48 s. Med CRACIs pris på $0.002 per vCPU-minutt blir det omtrent $9.96 mot $5.68 per bygg, før tiden teamet ditt bruker på å vente på det.

Forskjellen er større mot GitHub-hostede runnere. CRACI kjører bygg omtrent dobbelt så raskt, takket være raskere maskinvare, kortere køtid og caching, så det samme bygget med Yoctos SBOM på en GitHub-hostet 32-core ARM64-runner ville tatt omtrent 5 h 11 min. Til $0.050 per minutt blir det $15.60. Bygget på CRACI koster $5.68: 64% mindre, eller omtrent 2,7 ganger billigere. GitHubs listepriser per september 2026; inkluderte minutter dekker ikke større runnere.

Yoctos SPDX-utdata inneholder ting CRACI ikke registrerer, som patchene en oppskrift påfører, og CVE-ene den markerer som rettet. Hvis prosessen din er avhengig av dem, lar du create-spdx være på og bruker SBOM-en fra CRACI ved siden av. Hvis ikke, dekker SBOM-en fra CRACI på egen hånd hver komponent Yoctos gjorde, og flere til.

Hvorfor dette betyr noe for sikkerheten i leverandørkjeden

Det som går inn i et bygg, avgjør hva som kommer ut av det, enten det er installert i imaget eller ikke. Det vet angripere, og bygget er der nylige angrep på leverandørkjeden har kommet inn:

• Angrep gjemmer seg i bygget. Bakdøren i xz utils (CVE-2024-3094) fantes i versjon 5.6.0 og 5.6.1. Utløseren lå i release-tarballene i stedet for i Git-repositoriet, og den ondsinnede koden havnet i biblioteket mens det ble bygget. Å lese kildekoden avslørte den ikke; å vite nøyaktig hvilken tarball bygget hentet, gjør det.
• CI-avhengigheter er også mål. I mars 2025 rapporterte CISA at hver versjon av GitHub Action-en tj-actions/changed-files var kompromittert i tre dager. En Action kjører inne i byggejobben din, og derfor oppgir CRACI de Actions workflowen din brukte, låst til committen som kjørte.
• Rust-crates forsvinner inn i binærfiler. Cargo kompilerer crates inn i programmene som bruker dem, så en sårbar crate leveres inne i imaget uten noen gang å dukke opp som en pakke. Hvis SBOM-en bare oppgir den som et filnavn, kan heller ikke sårbarhetsverktøy matche den. Å skanne den ferdige binærfilen i etterkant betyr å gjette hva som gikk inn; å registrere bygget gjør ikke det.
• Du kan ikke reagere på det du ikke ser. Når det kommer en advisory for en crate eller et byggeverktøy, må du vite hvilke bygg som brukte den. CRACI tar vare på SBOM-en til hvert bygg og viser hvilke bygg som inneholdt den sårbare avhengigheten, direkte eller transitiv, så du vet i hvilken periode du var berørt. Det fungerer bare når hver komponent har en package URL å matche på.
• Et bygg skal bare nå det det trenger. Egress-policyen i CRACI blokkerer tilkoblinger til verter bygget ikke trenger, så en kompromittert avhengighet som prøver å sende hemmelighetene dine til en angripers server, blir stoppet, selv i et angrep ingen har sett før.

Kunder og regelverk som Cyber Resilience Act ber også produsenter av tilkoblede enheter om å vite hva som går inn i produktene deres. En SBOM som dekker hele bygget, er dokumentasjon som holder når de spør.

Hvorfor Yocto-bygg er vanskelige å kjøre i CI

Et fullt imagebygg kompilerer en verktøykjede, en kjerne og hundrevis av pakker fra kildekode. På de vanlige 2-core-runnerne de fleste CI-tjenester tilbyr, kan det ta timer, så mange embedded-team har en egen byggeserver under en pult eller i et rack, og den serveren blir enda en maskin å patche, ta sikkerhetskopi av og forklare for en revisor.

Et Yocto-bygg laster også ned mye: kildekode-tarballer, Git-repositorier og patcher fra oppstrømsprosjekter og speil. Det er disse nedlastingene SBOM-en din må gjøre rede for, og det er dem regelverk som Cyber Resilience Act ber produsenter av tilkoblede enheter om å kjenne til og holde oversikt over.

Hva CRACI gir et Yocto-bygg

Runnere dimensjonert for BitBake

CRACI-runnere skalerer fra 1 til 32 compute units, der hver enhet er 1 vCPU og 3 GB RAM. Et Yocto-bygg kan be om den største størrelsen, 32 vCPU-er og 96 GB RAM, direkte fra workflowen. Jobber kjører i isolerte virtuelle maskiner, og kjøringene vises fortsatt i GitHub som enhver annen Actions-jobb.

Minutter måles per sekund og faktureres per vCPU-minutt, så en stor runner koster mer per minutt og blir ferdig raskere. Se priser for gjeldende satser.

Nettverkstilgang du bestemmer

BitBake kan allerede begrense fetcheren sin til en liste over verter med BB_ALLOWED_NETWORKS. CRACI legger til en kontroll til på runneren: en egress-policy som sjekkes før jobben starter, og som blokkerer ved feil, så en oppskrift, et skript eller et kompromittert verktøy som går utenom fetcheren, fortsatt ikke kan nå en vert du ikke har tillatt. CRACI varsler deg ved brudd på policyen.

En registrering av hva bygget hentet

CRACI observerer trafikken en jobb sender til pakke- og kildeverter, og registrerer den som dokumentasjon fra bygget. For et Yocto-bygg betyr det en uavhengig oversikt over kildene som faktisk kom over nettverket, ved siden av SBOM-en Yocto skriver selv.

En minimal workflow

Yocto-eksempelet i CRACI-dokumentasjonen bygger core-image-sato for qemux86-64. Det som betyr noe for CRACI, er runnerstørrelsen og en fetcher-konfigurasjon som bruker det offisielle Yocto-kildespeilet:

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

Veiledningen i dokumentasjonen har hele workflowen, inkludert vertsavhengigheter og oppsett av locale, og referansen for runner-konfigurasjon viser alle oppsettsvalg.

Greit å vite

• Bygg kjører på CRACIs administrerte runnere på europeisk infrastruktur, fra GitHub Actions. Kundehostede runnere og andre CI-systemer er på veikartet.
• Pek BitBake mot speil CRACI kan se, som det offisielle Yocto-kildespeilet, i stedet for vilkårlige verter. Veiledningen i dokumentasjonen viser et fungerende oppsett.
• Det er å beholde nedlastingskatalogen og shared state-cachen mellom kjøringer som gjør gjentatte bygg raske.
• Native ARM64-runnere er tilgjengelige til samme pris som x86-64.

Bygger du tilkoblede enheter for EU-markedet? Les hva CRA krever, og hvordan CRACI fungerer for industrielt IoT og forbrukerelektronikk. Sammenligner du SBOM-verktøy for Yocto? Se CRACI vs Timesys Vigiles.

Yocto-SBOM-er og CRACI: ofte stilte spørsmål

Genererer Yocto en SBOM?

Ja. Byggesystemet OpenEmbedded genererer som standard en SPDX-SBOM siden Yocto 4.3 (Nanbield), gjennom klassen create-spdx. For et image skriver det IMAGE-MACHINE.spdx.json til tmp/deploy/images/MACHINE/, med komponenter, lisenser, avhengigheter, kilder, påførte patcher og rettede sårbarheter. På Kirkstone (4.0) legger du til INHERIT += "create-spdx" for å slå det på.

Hvilken SPDX-versjon produserer Yocto?

SPDX 3.0 som standard siden Yocto 5.1 (Styhead), som erstattet 2.2 som standard. Scarthgap (5.0) produserer SPDX 2.2 som standard og kan bytte til 3.0 med klassen create-spdx-3.0.

Hvordan får jeg en CycloneDX-SBOM fra Yocto?

Legg til laget meta-cyclonedx på grenen for din utgivelse, og arv cyclonedx-export i local.conf. Det skriver en .cyclonedx.bom.json-SBOM og en .cyclonedx.vex.json-fil ved siden av imaget, som standard i CycloneDX 1.6.

Hva mangler i Yocto-SBOM-en?

I et bygg av core-image-sato side om side hadde SBOM-en CRACI registrerte, alle de 865 komponentene i Yoctos SBOM pluss 88 til: vertspakker på byggemaskinen, som Ubuntus cpio, kilder og Actions fra GitHub, og andre kilder som ble hentet under bygget. Yocto oppgir dessuten de 653 versjonene av Rust-crates bare med filnavn og nedlastings-URL, uten en package URL, som sårbarhetsmatching er avhengig av.

Kan jeg overvåke sårbarheter i et Yocto-bygg?

Ja, med CRACI. Sårbarhetsmatching bygger på package URL-er, og Yoctos innebygde SBOM oppgir Rust-crates bare med filnavn og nedlastings-URL, så de kan ikke matches. CRACI registrerer Rust-cratene og byggemaskinens pakker med de package URL-ene som advisories publiseres mot (pkg:cargo, pkg:deb), inkludert alle de 653 crate-versjonene i core-image-sato. Den viser sårbarhetsstatusen til hver pakke og vurderer SBOM-en fortløpende på nytt etter hvert som nye advisories publiseres.

Kan CRACI erstatte Yocto-SBOM-en?

Når det gjelder dekning av leverandørkjeden, ja. I den samme sammenligningen hadde SBOM-en fra CRACI hver komponent i Yoctos innebygde SBOM, 88 til og en package URL for hver Rust-crate, og bygget uten Yoctos SBOM-generering tok 43 % kortere tid. Yoctos SPDX-utdata inneholder likevel oppskriftsmetadata som CRACI ikke registrerer, som patchene som er påført, og CVE-ene en oppskrift markerer som rettet. Hvis du er avhengig av dem, lar du create-spdx være på.

Kan en CRACI-runner håndtere et fullt Yocto-imagebygg?

CRACI-runnere går opp til 32 vCPU-er og 96 GB RAM, angitt fra workflowen. CRACI-dokumentasjonen har et Yocto-eksempel som bygger core-image-sato på den største størrelsen.

Hvilken CI bruker et Yocto-bygg på CRACI?

GitHub Actions. Workflowen din kjører på CRACIs administrerte runnere, og kjøringene vises i GitHub som enhver annen Actions-jobb. Andre CI-systemer og kundehostede runnere er på veikartet.