SBOM e build Yocto su CRACI

Come generare una SBOM con Yocto

Il sistema di build OpenEmbedded scrive le SBOM SPDX tramite la classe create-spdx. Se sia attiva, e quale versione di SPDX scriva, dipende dalla release di Yocto:

• Kirkstone (4.0): disattivata per impostazione predefinita. Aggiunga INHERIT += "create-spdx". SPDX 2.2.
• Nanbield (4.3): da questa release la generazione della SBOM è attiva per impostazione predefinita.
• Scarthgap (5.0): attiva per impostazione predefinita, SPDX 2.2. SPDX 3.0 è disponibile tramite la classe create-spdx-3.0.
• Styhead (5.1) e successive: attiva per impostazione predefinita, SPDX 3.0.

La si imposta in un file di configurazione come conf/local.conf. Su una release attuale di solito non c'è nulla da aggiungere; per disattivarla, usi 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"

Altre variabili SPDX_ aggiungono dettagli. SPDX_INCLUDE_SOURCES descrive i file sorgente alla base di ogni strumento host e pacchetto target, il che rende l'output molto più grande. Le release recenti aggiungono opzioni per la configurazione del kernel, le funzionalità PACKAGECONFIG, le informazioni sul fornitore e i package URL per le sorgenti Cargo, Go, PyPI, npm e CPAN.

Dove finiscono i file della SBOM

Compili un'immagine e la SBOM di primo livello compare accanto a essa, come IMAGE-MACHINE.spdx.json in tmp/deploy/images/MACHINE/ all'interno della directory di build. I file correlati si trovano nella stessa directory e in tmp/deploy/spdx. Su Kirkstone i documenti per ricetta arrivano come archivio 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 con meta-cyclonedx

Yocto di per sé scrive solo SPDX. Per CycloneDX, il layer meta-cyclonedx genera una SBOM dal root filesystem dell'immagine, più un file VEX separato con le CVE corrette tramite patch e ignorate di cui il sistema di build è a conoscenza. Faccia il checkout del branch del layer per la Sua release, lo aggiunga ai Suoi layer ed erediti la sua classe:

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

I file finiscono accanto all'immagine in DEPLOY_DIR_IMAGE, con i suffissi .cyclonedx.bom.json e .cyclonedx.vex.json. Il valore predefinito è CycloneDX 1.6, impostabile con CYCLONEDX_SPEC_VERSION. Per impostazione predefinita sono inclusi solo i pacchetti di runtime, il che mantiene piccola la SBOM ma può tralasciare componenti che arrivano nell'immagine senza essere installati come pacchetti.

Che cosa tralascia la SBOM di Yocto

La SBOM di Yocto è accurata su ciò che BitBake compila. In SPDX 3 copre l'immagine, ogni ricetta comprese quelle native usate in fase di build, le loro sorgenti, le patch applicate e le vulnerabilità segnate come corrette. Per core-image-sato si è arrivati a 1,632 file separati. Per vedere che cosa tralascia, abbiamo compilato l'immagine su un runner CRACI, ARM64 nativo con 32 vCPU, e confrontato la SBOM di Yocto con quella registrata da CRACI, componente per componente, dopo aver normalizzato i nomi in tutti quei file.

Dei 953 componenti nella SBOM di CRACI, 865 erano presenti anche in quella di Yocto. Nessuno era presente solo in quella di Yocto. Le differenze stanno in ciò che Yocto non può vedere e nel modo in cui identifica ciò che elenca.

Crate Rust senza package URL

Entrambe le SBOM contengono le stesse 653 versioni di 559 crate Rust, come cairo-rs e zune-jpeg, che librsvg compila al proprio interno. Yocto elenca ciascuno solo come file .crate e URL di download da crates.io, all'interno della ricetta che lo usa. Nessuno riporta un package URL pkg:cargo. CRACI registra ogni crate con il suo.

È questo che decide se è possibile monitorarli per le vulnerabilità. Il matching delle vulnerabilità funziona sui package URL: un advisory per un crate lo indica come pkg:cargo/..., e un nome file all'interno dell'elenco di sorgenti di un'altra ricetta non dà agli strumenti SBOM e di vulnerabilità nulla con cui abbinarlo. Con la sola SBOM di Yocto, un crate vulnerabile nella Sua immagine non viene segnalato.

Con quella di CRACI, ogni crate viene confrontato con gli advisory, ogni pacchetto della build mostra il proprio stato di vulnerabilità e CRACI continua a rivalutare la SBOM man mano che vengono pubblicati nuovi advisory, anche molto tempo dopo la fine della build.

Che cosa ha trovato solo CRACI

I 88 componenti assenti dalla SBOM di Yocto provenivano dall'esterno dei metadati di BitBake:

• 23 pacchetti host installati sulla macchina di build, come cpio 2.15, libc6, locales e python3-jinja2 di Ubuntu. BitBake gira con questi pacchetti, e la SBOM di Yocto non li elenca.
• 10 sorgenti GitHub, tra cui patchelf, btrfs-progs e la GitHub Action actions/upload-artifact, fissate al commit eseguito dal workflow
• Altre sorgenti e strumenti scaricati durante la build, come pseudo-prebuilt, tzdata e strumenti di build Python come hatchling e setuptools_scm

Nessuno di questi è installato nell'immagine, ma tutti si trovano sul percorso critico della build: uno strumento host o un'Action compromessi possono compromettere la Sua immagine senza mai farne parte. CRACI li elenca perché vede il traffico in ingresso nella build.

Quanto costa la SBOM integrata

La generazione della SBOM di Yocto non è gratuita. Sullo stesso runner da 32 vCPU, la build con questa funzione ha richiesto 155 min 40 s e ha scritto la SBOM in 1,632 file SPDX separati. La build senza, con la registrazione di CRACI, ha richiesto 88 min 48 s. Alla tariffa di CRACI di $0.002 per vCPU-minuto, si tratta di circa $9.96 contro $5.68 per build, senza contare il tempo che il Suo team passa ad aspettare.

Il divario è più ampio rispetto ai runner ospitati da GitHub. CRACI esegue le build circa due volte più velocemente, grazie a hardware più veloce, code più brevi e caching, quindi la stessa build con la SBOM di Yocto su un runner ARM64 a 32 core ospitato da GitHub richiederebbe circa 5 h 11 min. A $0.050 al minuto fanno $15.60. La build su CRACI costa $5.68: il 64% in meno, ovvero circa 2,7 volte più economica. Prezzi di listino di GitHub a settembre 2026; i minuti inclusi non coprono i runner più grandi.

L'output SPDX di Yocto riporta comunque informazioni che CRACI non registra, come le patch che una ricetta applica e le CVE che segna come corrette. Se il Suo processo dipende da questi dati, lasci attivo create-spdx e usi la SBOM di CRACI in parallelo. Altrimenti, la SBOM di CRACI copre da sola ogni componente di quella di Yocto, e altri ancora.

Perché è importante per la sicurezza della supply chain

Ciò che entra in una build determina ciò che ne esce, che sia installato nell'immagine o no. Gli attaccanti lo sanno, e la build è il punto da cui sono entrati i recenti attacchi alla supply chain:

• Gli attacchi si nascondono nella build. La backdoor di xz utils (CVE-2024-3094) era presente nelle versioni 5.6.0 e 5.6.1. Il suo innesco si trovava nei tarball di release anziché nel repository Git, e il codice malevolo è entrato nella libreria durante la compilazione. Leggere il sorgente non lo rivelava; sapere esattamente quale tarball ha scaricato la build sì.
• Anche le dipendenze della CI sono un bersaglio. Nel marzo 2025 la CISA ha segnalato che tutte le versioni della GitHub Action tj-actions/changed-files sono state compromesse per tre giorni. Un'Action gira all'interno del job di build, ed è per questo che CRACI elenca quelle usate dal Suo workflow, fissate al commit eseguito.
• I crate Rust scompaiono nei binari. Cargo compila i crate all'interno dei programmi che li usano, quindi un crate vulnerabile viene distribuito nell'immagine senza mai comparire come pacchetto. Se la SBOM lo elenca solo come nome file, neanche gli strumenti di vulnerabilità possono abbinarlo. Scansionare il binario finito a posteriori costringe a indovinare che cosa vi è entrato; registrare la build no.
• Non si può reagire a ciò che non si vede. Quando arriva un advisory per un crate o uno strumento di build, deve sapere quali build lo hanno usato. CRACI conserva la SBOM di ogni build e mostra quali build contenevano la dipendenza vulnerabile, diretta o transitiva, così conosce il Suo periodo di esposizione. Funziona solo quando ogni componente ha un package URL su cui fare il matching.
• Una build dovrebbe raggiungere solo ciò di cui ha bisogno. La policy di egress di CRACI blocca le connessioni verso host di cui la build non ha bisogno, così una dipendenza compromessa che tenta di inviare i Suoi secret al server di un attaccante viene fermata, anche in un attacco mai visto prima.

Anche i clienti e normative come il Cyber Resilience Act chiedono ai fabbricanti di dispositivi connessi di sapere che cosa entra nei loro prodotti. Una SBOM che copre l'intera build è un'evidenza che regge quando la richiedono.

Perché le build Yocto sono difficili da eseguire in CI

La build di un'immagine completa compila dai sorgenti una toolchain, un kernel e centinaia di pacchetti. Sui runner standard a 2 core offerti dalla maggior parte dei servizi di CI, può richiedere ore, per questo molti team embedded tengono un server di build dedicato sotto una scrivania o in un rack, e quel server diventa un'altra macchina da aggiornare, di cui fare il backup e da spiegare a un auditor.

Una build Yocto scarica anche moltissimo: tarball di sorgenti, repository Git e patch da progetti upstream e mirror. Questi download sono ciò di cui la Sua SBOM deve rendere conto, e ciò che normative come il Cyber Resilience Act chiedono ai fabbricanti di dispositivi connessi di conoscere e tenere sotto controllo.

Che cosa offre CRACI a una build Yocto

Runner dimensionati per BitBake

I runner CRACI scalano da 1 a 32 unità di calcolo, dove ogni unità corrisponde a 1 vCPU e 3 GB di RAM. Una build Yocto può richiedere la dimensione più grande, 32 vCPU e 96 GB di RAM, direttamente dal workflow. I job girano in macchine virtuali isolate e le esecuzioni compaiono comunque in GitHub come qualsiasi altro job di Actions.

I minuti sono misurati al secondo e fatturati per vCPU-minuto, quindi un runner grande costa di più al minuto e finisce prima. Veda i prezzi per le tariffe attuali.

Accesso alla rete deciso da Lei

BitBake può già limitare il suo fetcher a un elenco di host con BB_ALLOWED_NETWORKS. CRACI aggiunge un secondo controllo sul runner: una policy di egress verificata prima dell'avvio del job e fail-closed, così una ricetta, uno script o uno strumento compromesso che aggira il fetcher non può comunque raggiungere un host che Lei non ha autorizzato. CRACI La avvisa in caso di violazioni della policy.

Un record di ciò che la build ha scaricato

CRACI osserva il traffico che un job invia verso gli host di pacchetti e sorgenti e lo registra come evidenza di build. Per una build Yocto significa un resoconto indipendente delle sorgenti effettivamente arrivate dalla rete, accanto alla SBOM che Yocto scrive da sé.

Un workflow minimo

L'esempio Yocto nella documentazione di CRACI compila core-image-sato per qemux86-64. Le parti che contano per CRACI sono la dimensione del runner e una configurazione del fetcher che usa il mirror ufficiale dei sorgenti 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

La guida nella documentazione contiene il workflow completo, comprese le dipendenze host e la configurazione del locale, e il riferimento per la configurazione dei runner elenca tutte le opzioni di setup.

Da sapere

• Le build girano sui runner gestiti di CRACI su infrastruttura europea, da GitHub Actions. I runner ospitati dal cliente e altri sistemi di CI sono in roadmap.
• Indirizzi BitBake verso mirror che CRACI può vedere, come il mirror ufficiale dei sorgenti Yocto, anziché verso host arbitrari. La guida nella documentazione mostra una configurazione funzionante.
• Conservare la directory dei download e la shared state cache tra un'esecuzione e l'altra è ciò che rende veloci le build successive.
• I runner ARM64 nativi sono disponibili alla stessa tariffa di x86-64.

Sviluppa dispositivi connessi per il mercato UE? Legga che cosa richiede il CRA e come funziona CRACI per l'IoT industriale e l'elettronica di consumo. Sta confrontando strumenti SBOM per Yocto? Veda CRACI e Timesys Vigiles a confronto.

SBOM Yocto e CRACI: domande frequenti

Yocto genera una SBOM?

Sì. Il sistema di build OpenEmbedded genera per impostazione predefinita una SBOM SPDX da Yocto 4.3 (Nanbield), tramite la classe create-spdx. Per un'immagine scrive IMAGE-MACHINE.spdx.json in tmp/deploy/images/MACHINE/, con componenti, licenze, dipendenze, sorgenti, patch applicate e vulnerabilità corrette. Su Kirkstone (4.0), aggiunga INHERIT += "create-spdx" per attivarla.

Quale versione di SPDX produce Yocto?

SPDX 3.0 per impostazione predefinita da Yocto 5.1 (Styhead), che ha sostituito la 2.2 come predefinita. Scarthgap (5.0) produce SPDX 2.2 per impostazione predefinita e può passare alla 3.0 con la classe create-spdx-3.0.

Come ottengo una SBOM CycloneDX da Yocto?

Aggiunga il layer meta-cyclonedx sul branch della Sua release ed erediti cyclonedx-export in local.conf. Il layer scrive una SBOM .cyclonedx.bom.json e un file .cyclonedx.vex.json accanto all'immagine, in CycloneDX 1.6 per impostazione predefinita.

Che cosa manca nella SBOM di Yocto?

In una build affiancata di core-image-sato, la SBOM registrata da CRACI conteneva tutti gli 865 componenti della SBOM di Yocto più altri 88: pacchetti host sulla macchina di build, come il cpio di Ubuntu, sorgenti e Actions di GitHub e altre sorgenti scaricate durante la build. Inoltre Yocto elenca le sue 653 versioni di crate Rust solo per nome file e URL di download, senza un package URL, su cui si basa il matching delle vulnerabilità.

Posso monitorare le vulnerabilità in una build Yocto?

Sì, con CRACI. Il matching delle vulnerabilità funziona sui package URL, e la SBOM integrata di Yocto elenca i crate Rust solo per nome file e URL di download, quindi non possono essere abbinati. CRACI registra i crate Rust e i pacchetti della macchina di build con i package URL rispetto ai quali vengono pubblicati gli advisory (pkg:cargo, pkg:deb), comprese tutte le 653 versioni di crate in core-image-sato. Mostra lo stato di vulnerabilità di ogni pacchetto e continua a rivalutare la SBOM man mano che vengono pubblicati nuovi advisory.

CRACI può sostituire la SBOM di Yocto?

Per la copertura della supply chain, sì. Nello stesso confronto, la SBOM di CRACI conteneva ogni componente della SBOM integrata di Yocto, altri 88 e un package URL per ogni crate Rust, e la build senza la generazione della SBOM di Yocto ha richiesto il 43% di tempo in meno. L'output SPDX di Yocto riporta comunque metadati delle ricette che CRACI non registra, come le patch applicate e le CVE che una ricetta segna come corrette. Se Lei si basa su questi dati, lasci attivo create-spdx.

Un runner CRACI può gestire la build completa di un'immagine Yocto?

I runner CRACI arrivano fino a 32 vCPU e 96 GB di RAM, impostabili dal workflow. La documentazione di CRACI include un esempio Yocto che compila core-image-sato sulla dimensione più grande.

Quale CI usa una build Yocto su CRACI?

GitHub Actions. Il Suo workflow gira sui runner gestiti di CRACI e le esecuzioni compaiono in GitHub come qualsiasi altro job di Actions. Altri sistemi di CI e i runner ospitati dal cliente sono in roadmap.