Yocto-SBOM og builds på CRACI

Sådan genererer du en SBOM med Yocto

OpenEmbedded-buildsystemet skriver SPDX-SBOM'er via klassen create-spdx. Om den er slået til, og hvilken SPDX-version den skriver, afhænger af Yocto-releasen:

• Kirkstone (4.0): slået fra som standard. Tilføj INHERIT += "create-spdx". SPDX 2.2.
• Nanbield (4.3): SBOM-generering er slået til som standard fra denne release.
• Scarthgap (5.0): slået til som standard, SPDX 2.2. SPDX 3.0 er tilgængelig via klassen create-spdx-3.0.
• Styhead (5.1) og senere: slået til som standard, SPDX 3.0.

Du angiver det i en konfigurationsfil som conf/local.conf. På en aktuel release er der som regel intet at tilføje; for at slå det fra bruger 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 tilføjer flere detaljer. SPDX_INCLUDE_SOURCES beskriver kildefilerne bag hvert værktøj på værten og hver målpakke, hvilket gør outputtet langt større. Nyere releases tilføjer muligheder for kernekonfigurationen, PACKAGECONFIG-features, leverandøroplysninger og package URLs for Cargo-, Go-, PyPI-, npm- og CPAN-kilder.

Hvor SBOM-filerne havner

Byg et image, så dukker SBOM'en på øverste niveau op ved siden af det, som IMAGE-MACHINE.spdx.json i tmp/deploy/images/MACHINE/ inde i build-mappen. Tilhørende filer ligger i samme mappe og i tmp/deploy/spdx. På Kirkstone kommer dokumenterne pr. recipe 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 skriver selv kun SPDX. Til CycloneDX genererer meta-cyclonedx-laget en SBOM ud fra imagets rodfilsystem plus en separat VEX-fil med de patchede og ignorerede CVE'er, som buildsystemet kender til. Tjek lagets branch til din release ud, tilføj det til dine lag, og nedarv dets klasse:

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

Filerne havner ved siden af imaget i DEPLOY_DIR_IMAGE med endelserne .cyclonedx.bom.json og .cyclonedx.vex.json. Standarden er CycloneDX 1.6, som angives med CYCLONEDX_SPEC_VERSION. Som standard medtages kun runtime-pakker, hvilket holder SBOM'en lille, men kan udelade komponenter, der når ind i imaget uden at være installeret som pakker.

Hvad Yocto-SBOM'en udelader

Yoctos SBOM er grundig med hensyn til det, BitBake bygger. I SPDX 3 dækker den imaget, hver recipe inklusive de native recipes til build-tid, deres kilder, de anvendte patches og de sårbarheder, der er markeret som rettede. For core-image-sato blev det til 1,632 separate filer. For at se, hvad den udelader, byggede vi imaget på en CRACI-runner, native ARM64 med 32 vCPU'er, og sammenlignede Yoctos SBOM med den, CRACI registrerede, komponent for komponent, efter at have normaliseret navnene på tværs af alle disse filer.

Af 953 komponenter i CRACI's SBOM var 865 også i Yoctos. Ingen var kun i Yoctos. Forskellene ligger i det, Yocto ikke kan se, og i hvordan den identificerer det, den faktisk angiver.

Rust crates uden en package URL

Begge SBOM'er indeholder de samme 653 versioner af 559 Rust crates, såsom cairo-rs og zune-jpeg, som librsvg kompilerer ind. Yocto angiver hver af dem kun som en .crate-fil og en download-URL fra crates.io inde i den recipe, der bruger den. Ikke én har en pkg:cargo-package URL. CRACI registrerer hver crate med én.

Det afgør, om du kan overvåge dem for sårbarheder. Sårbarhedsmatchning bygger på package URLs: En advisory for en crate navngiver den som pkg:cargo/..., og et filnavn i en anden recipes kildeliste giver SBOM- og sårbarhedsværktøjer intet at matche den mod. Med Yoctos SBOM alene bliver en sårbar crate i dit image ikke rapporteret.

Med CRACI's SBOM matches hver crate mod advisories, hver pakke i buildet viser sin sårbarhedsstatus, og CRACI genvurderer løbende SBOM'en, efterhånden som nye advisories offentliggøres, længe efter at buildet er færdigt.

Hvad kun CRACI fandt

De 88 komponenter, der manglede i Yoctos SBOM, kom fra uden for BitBakes metadata:

• 23 værtspakker installeret på buildmaskinen, såsom Ubuntus cpio 2.15, libc6, locales og python3-jinja2. BitBake kører med dem, og Yoctos SBOM angiver dem ikke.
• 10 GitHub-kilder, inklusive patchelf, btrfs-progs og GitHub Action'en actions/upload-artifact, fastlåst til det commit, workflowet kørte
• Andre kilder og værktøjer hentet under buildet, såsom pseudo-prebuilt, tzdata og Python-buildværktøjer som hatchling og setuptools_scm

Ingen af dem er installeret i imaget, men alle ligger i buildets kritiske sti: Et kompromitteret værktøj på værten eller en kompromitteret Action kan kompromittere dit image uden nogensinde at være en del af det. CRACI angiver dem, fordi CRACI ser trafikken, der kommer ind i buildet.

Hvad den indbyggede SBOM koster

Yoctos SBOM-generering er ikke gratis. På den samme runner med 32 vCPU'er tog buildet med den 155 min 40 s og skrev SBOM'en som 1,632 separate SPDX-filer. Buildet uden den, med CRACI's registrering, tog 88 min 48 s. Med CRACI's pris på $0.002 pr. vCPU-minut er det omkring $9.96 mod $5.68 pr. build, før den tid, dit team bruger på at vente.

Forskellen er større over for GitHub-hostede runnere. CRACI kører builds omtrent dobbelt så hurtigt takket være hurtigere hardware, kortere køtider og caching, så det samme build med Yoctos SBOM på en GitHub-hostet 32-core ARM64-runner ville tage omkring 5 h 11 min. Til $0.050 pr. minut er det $15.60. CRACI-buildet koster $5.68: 64% mindre, eller omkring 2,7 gange billigere. GitHubs listepriser pr. september 2026; inkluderede minutter dækker ikke større runnere.

Yoctos SPDX-output indeholder ting, som CRACI ikke registrerer, såsom de patches, en recipe anvender, og de CVE'er, den markerer som rettede. Afhænger din proces af dem, så lad create-spdx være slået til, og brug CRACI's SBOM ved siden af. Hvis ikke, dækker CRACI's SBOM alene hver komponent fra Yoctos og mere til.

Hvorfor det betyder noget for forsyningskædesikkerheden

Det, der går ind i et build, afgør, hvad der kommer ud af det, uanset om det er installeret i imaget eller ej. Det ved angribere, og buildet er der, hvor nyere angreb på forsyningskæden er trængt ind:

• Angreb gemmer sig i buildet. Bagdøren i xz utils (CVE-2024-3094) var i version 5.6.0 og 5.6.1. Udløseren lå i release-tarballs frem for i Git-repositoryet, og den ondsindede kode kom ind i biblioteket, mens det blev bygget. Kildekoden afslørede den ikke; at vide præcis, hvilken tarball buildet hentede, gør.
• CI-afhængigheder er også mål. I marts 2025 rapporterede CISA, at alle versioner af GitHub Action'en tj-actions/changed-files var kompromitteret i tre dage. En Action kører inde i dit build-job, og derfor angiver CRACI dem, dit workflow brugte, fastlåst til det commit, der kørte.
• Rust crates forsvinder ind i binærfiler. Cargo kompilerer crates ind i de programmer, der bruger dem, så en sårbar crate leveres inde i imaget uden nogensinde at optræde som en pakke. Hvis SBOM'en kun angiver den med et filnavn, kan sårbarhedsværktøjer heller ikke matche den. At scanne den færdige binærfil bagefter kræver, at man gætter, hvad der gik ind; at registrere buildet gør ikke.
• Du kan ikke reagere på det, du ikke kan se. Når der kommer en advisory for en crate eller et buildværktøj, skal du vide, hvilke builds der brugte den. CRACI gemmer hvert builds SBOM og viser, hvilke builds der indeholdt den sårbare afhængighed, direkte eller transitiv, så du ved, i hvilken periode du var berørt. Det virker kun, når hver komponent har en package URL at matche på.
• Et build bør kun kunne nå det, det har brug for. CRACI's egress-politik blokerer forbindelser til værter, som buildet ikke har brug for, så en kompromitteret afhængighed, der forsøger at sende dine secrets til en angribers server, bliver stoppet, selv i et angreb, som ingen har set før.

Kunder og regler som Cyber Resilience Act kræver også, at producenter af forbundne enheder ved, hvad der går ind i deres produkter. En SBOM, der dækker hele buildet, er dokumentation, der holder, når de spørger.

Hvorfor Yocto-builds er svære at køre i CI

Et fuldt image-build kompilerer en toolchain, en kerne og hundredvis af pakker fra kildekode. På de almindelige 2-core-runnere, som de fleste CI-tjenester tilbyder, kan det tage timer, så mange embedded-teams har en dedikeret buildserver under et skrivebord eller i et rack, og den server bliver endnu en maskine at patche, tage backup af og forklare for en revisor.

Et Yocto-build downloader også meget: kilde-tarballs, Git-repositories og patches fra upstream-projekter og spejle. Det er de downloads, din SBOM skal redegøre for, og som regler som Cyber Resilience Act kræver, at producenter af forbundne enheder kender til og holder styr på.

Hvad CRACI giver et Yocto-build

Runnere dimensioneret til BitBake

CRACI-runnere skalerer fra 1 til 32 compute units, hvor hver unit er 1 vCPU og 3 GB RAM. Et Yocto-build kan bede om den største størrelse, 32 vCPU'er og 96 GB RAM, direkte fra workflowet. Jobs kører i isolerede virtuelle maskiner, og kørslerne vises stadig i GitHub som ethvert andet Actions-job.

Minutter måles pr. sekund og faktureres pr. vCPU-minut, så en stor runner koster mere pr. minut og bliver hurtigere færdig. Se priser for de aktuelle takster.

Netværksadgang, du selv bestemmer

BitBake kan allerede begrænse sin fetcher til en liste over værter med BB_ALLOWED_NETWORKS. CRACI tilføjer en ekstra kontrol på runneren: en egress-politik, der tjekkes, før jobbet starter, og blokerer ved fejl, så en recipe, et script eller et kompromitteret værktøj, der går uden om fetcheren, stadig ikke kan nå en vært, du ikke har tilladt. CRACI sender dig en alarm ved brud på politikken.

En registrering af, hvad buildet hentede

CRACI observerer den trafik, et job sender til pakke- og kildeværter, og registrerer den som dokumentation for buildet. For et Yocto-build betyder det en uafhængig redegørelse for de kilder, der faktisk kom over netværket, ved siden af den SBOM, som Yocto selv skriver.

Et minimalt workflow

Yocto-eksemplet i CRACI's dokumentation bygger core-image-sato til qemux86-64. Det, der betyder noget for CRACI, er runner-størrelsen og en fetcher-konfiguration, der bruger det officielle Yocto-kildespejl:

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

Vejledningen i dokumentationen har hele workflowet, inklusive afhængigheder på værten og opsætning af locale, og referencen til runner-konfiguration viser alle opsætningsmuligheder.

Godt at vide

• Builds kører på CRACI's administrerede runnere på europæisk infrastruktur, fra GitHub Actions. Kundehostede runnere og andre CI-systemer er på roadmappen.
• Peg BitBake mod spejle, som CRACI kan se, såsom det officielle Yocto-kildespejl, frem for vilkårlige værter. Vejledningen i dokumentationen viser en fungerende opsætning.
• Det er ved at beholde downloads-mappen og shared state-cachen mellem kørsler, at gentagne builds bliver hurtige.
• Native ARM64-runnere er tilgængelige til samme pris som x86-64.

Bygger du forbundne enheder til EU-markedet? Læs hvad CRA kræver, og hvordan CRACI fungerer til industriel IoT og forbrugerelektronik. Sammenligner du værktøjer til Yocto-SBOM'er? Se CRACI vs Timesys Vigiles.

Yocto-SBOM'er og CRACI: ofte stillede spørgsmål

Genererer Yocto en SBOM?

Ja. OpenEmbedded-buildsystemet genererer som standard en SPDX-SBOM siden Yocto 4.3 (Nanbield) via klassen create-spdx. For et image skriver det IMAGE-MACHINE.spdx.json til tmp/deploy/images/MACHINE/ og dækker komponenter, licenser, afhængigheder, kilder, anvendte patches og rettede sårbarheder. På Kirkstone (4.0) tilføjer du INHERIT += "create-spdx" for at slå det til.

Hvilken SPDX-version producerer Yocto?

SPDX 3.0 som standard siden Yocto 5.1 (Styhead), som erstattede 2.2 som standard. Scarthgap (5.0) producerer SPDX 2.2 som standard og kan skifte til 3.0 med klassen create-spdx-3.0.

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

Tilføj meta-cyclonedx-laget på branchen til din release, og nedarv cyclonedx-export i local.conf. Det skriver en .cyclonedx.bom.json-SBOM og en .cyclonedx.vex.json-fil ved siden af imaget, som standard i CycloneDX 1.6.

Hvad mangler i Yocto-SBOM'en?

I et build af core-image-sato side om side havde CRACI's registrerede SBOM alle 865 komponenter fra Yoctos SBOM plus 88 mere: værtspakker på buildmaskinen som Ubuntus cpio, GitHub-kilder og Actions og andre kilder hentet under buildet. Yocto angiver desuden sine 653 Rust crate-versioner kun med filnavn og download-URL, uden en package URL, som sårbarhedsmatchning er afhængig af.

Kan jeg overvåge sårbarheder i et Yocto-build?

Ja, med CRACI. Sårbarhedsmatchning bygger på package URLs, og Yoctos indbyggede SBOM angiver kun Rust crates med filnavn og download-URL, så de kan ikke matches. CRACI registrerer Rust crates og buildmaskinens pakker med de package URLs, som advisories udgives under (pkg:cargo, pkg:deb), inklusive alle 653 crate-versioner i core-image-sato. CRACI viser hver pakkes sårbarhedsstatus og genvurderer løbende SBOM'en, efterhånden som nye advisories offentliggøres.

Kan CRACI erstatte Yocto-SBOM'en?

Hvad angår dækning af forsyningskæden, ja. I samme sammenligning havde CRACI's SBOM hver komponent fra Yoctos indbyggede SBOM, 88 mere og en package URL for hver Rust crate, og buildet uden Yoctos SBOM-generering tog 43 % mindre tid. Yoctos SPDX-output indeholder stadig recipe-metadata, som CRACI ikke registrerer, såsom de anvendte patches og de CVE'er, en recipe markerer som rettede. Er du afhængig af dem, så lad create-spdx være slået til.

Kan en CRACI-runner klare et fuldt Yocto-image-build?

CRACI-runnere går op til 32 vCPU'er og 96 GB RAM, angivet fra workflowet. CRACI's dokumentation indeholder et Yocto-eksempel, der bygger core-image-sato på den største størrelse.

Hvilket CI bruger et Yocto-build på CRACI?

GitHub Actions. Dit workflow kører på CRACI's administrerede runnere, og kørslerne vises i GitHub som ethvert andet Actions-job. Andre CI-systemer og kundehostede runnere er på roadmappen.