Yocto-SBOM und Builds auf CRACI

So erzeugen Sie eine SBOM mit Yocto

Das OpenEmbedded-Build-System schreibt SPDX-SBOMs über die Klasse create-spdx. Ob sie eingeschaltet ist und welche SPDX-Version sie schreibt, hängt vom Yocto-Release ab:

• Kirkstone (4.0): standardmäßig aus. Fügen Sie INHERIT += "create-spdx" hinzu. SPDX 2.2.
• Nanbield (4.3): Ab diesem Release ist die SBOM-Generierung standardmäßig eingeschaltet.
• Scarthgap (5.0): standardmäßig an, SPDX 2.2. SPDX 3.0 ist über die Klasse create-spdx-3.0 verfügbar.
• Styhead (5.1) und neuer: standardmäßig an, SPDX 3.0.

Eingestellt wird das in einer Konfigurationsdatei wie conf/local.conf. In einem aktuellen Release müssen Sie meist nichts hinzufügen; zum Ausschalten verwenden Sie 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"

Weitere SPDX_-Variablen ergänzen Details. SPDX_INCLUDE_SOURCES beschreibt die Quelldateien hinter jedem Host-Tool und Zielpaket, was die Ausgabe deutlich vergrößert. Neuere Releases bringen Optionen für die Kernel-Konfiguration, PACKAGECONFIG-Features, Lieferanteninformationen und Package-URLs für Quellen aus Cargo, Go, PyPI, npm und CPAN.

Wo die SBOM-Dateien landen

Bauen Sie ein Image, erscheint die übergeordnete SBOM daneben, als IMAGE-MACHINE.spdx.json in tmp/deploy/images/MACHINE/ innerhalb des Build-Verzeichnisses. Zugehörige Dateien liegen im selben Verzeichnis und in tmp/deploy/spdx. Unter Kirkstone kommen die Dokumente pro Rezept als Archiv 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 mit meta-cyclonedx

Yocto selbst schreibt nur SPDX. Für CycloneDX erzeugt der Layer meta-cyclonedx eine SBOM aus dem Root-Dateisystem des Images, dazu eine separate VEX-Datei mit den gepatchten und ignorierten CVEs, die das Build-System kennt. Checken Sie den Branch des Layers für Ihr Release aus, fügen Sie ihn zu Ihren Layern hinzu und erben Sie seine 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"

Die Dateien landen neben dem Image in DEPLOY_DIR_IMAGE, mit den Endungen .cyclonedx.bom.json und .cyclonedx.vex.json. Standard ist CycloneDX 1.6, einstellbar über CYCLONEDX_SPEC_VERSION. Standardmäßig sind nur Laufzeitpakete enthalten. Das hält die SBOM klein, kann aber Komponenten auslassen, die ins Image gelangen, ohne als Paket installiert zu werden.

Was die Yocto-SBOM auslässt

Die SBOM von Yocto ist gründlich bei dem, was BitBake baut. In SPDX 3 umfasst sie das Image, jedes Rezept einschließlich der nativen Rezepte für die Build-Zeit, deren Quellen, die angewendeten Patches und die als behoben markierten Schwachstellen. Für core-image-sato waren das 1,632 einzelne Dateien. Um zu sehen, was sie auslässt, haben wir das Image auf einem CRACI-Runner gebaut, nativ ARM64 mit 32 vCPUs, und die SBOM von Yocto Komponente für Komponente mit der von CRACI aufgezeichneten verglichen, nachdem wir die Namen über all diese Dateien hinweg normalisiert hatten.

Von 953 Komponenten in der SBOM von CRACI waren 865 auch in der von Yocto. Keine war nur in der von Yocto. Die Unterschiede liegen in dem, was Yocto nicht sehen kann, und darin, wie es das identifiziert, was es auflistet.

Rust-Crates ohne Package-URL

Beide SBOMs enthalten dieselben 653 Versionen von 559 Rust-Crates, etwa cairo-rs und zune-jpeg, die librsvg einkompiliert. Yocto listet jedes nur als .crate-Datei mit einer Download-URL von crates.io, innerhalb des Rezepts, das es verwendet. Keines trägt eine Package-URL pkg:cargo. CRACI zeichnet jedes Crate mit einer auf.

Davon hängt ab, ob Sie sie auf Schwachstellen überwachen können. Der Schwachstellenabgleich arbeitet mit Package-URLs: Eine Sicherheitsmeldung für ein Crate benennt es als pkg:cargo/..., und ein Dateiname in der Quellenliste eines anderen Rezepts gibt SBOM- und Schwachstellen-Tools nichts, womit sie abgleichen könnten. Mit der SBOM von Yocto allein bleibt ein verwundbares Crate in Ihrem Image ungemeldet.

Mit der von CRACI wird jedes Crate mit Sicherheitsmeldungen abgeglichen, jedes Paket im Build zeigt seinen Schwachstellenstatus, und CRACI bewertet die SBOM laufend neu, sobald neue Sicherheitsmeldungen veröffentlicht werden, lange nachdem der Build abgeschlossen ist.

Was nur CRACI gefunden hat

Die 88 Komponenten, die in der SBOM von Yocto fehlten, stammten von außerhalb der BitBake-Metadaten:

• 23 Host-Pakete, die auf der Build-Maschine installiert sind, etwa Ubuntus cpio 2.15, libc6, locales und python3-jinja2. BitBake läuft mit ihnen, und die SBOM von Yocto listet sie nicht.
• 10 GitHub-Quellen, darunter patchelf, btrfs-progs und die GitHub Action actions/upload-artifact, festgelegt auf den Commit, mit dem der Workflow lief
• Andere Quellen und Tools, die während des Builds geladen wurden, etwa pseudo-prebuilt, tzdata und Python-Build-Tools wie hatchling und setuptools_scm

Keine davon ist im Image installiert, aber alle liegen im kritischen Pfad des Builds: Ein kompromittiertes Host-Tool oder eine kompromittierte Action kann Ihr Image kompromittieren, ohne je Teil davon zu sein. CRACI listet sie, weil es den Datenverkehr sieht, der in den Build hineinkommt.

Was die eingebaute SBOM kostet

Die SBOM-Generierung von Yocto ist nicht kostenlos. Auf demselben Runner mit 32 vCPUs dauerte der Build mit ihr 155 min 40 s und schrieb die SBOM als 1,632 einzelne SPDX-Dateien. Der Build ohne sie, mit Aufzeichnung durch CRACI, dauerte 88 min 48 s. Beim CRACI-Preis von $0.002 pro vCPU-Minute sind das etwa $9.96 gegenüber $5.68 pro Build, noch bevor man die Zeit rechnet, die Ihr Team auf ihn wartet.

Gegenüber GitHub-gehosteten Runnern ist der Abstand größer. CRACI führt Builds etwa doppelt so schnell aus, dank schnellerer Hardware, kürzerer Wartezeiten in der Warteschlange und Caching. Derselbe Build mit der Yocto-SBOM würde auf einem GitHub-gehosteten 32-Core-ARM64-Runner also etwa 5 h 11 min dauern. Bei $0.050 pro Minute sind das $15.60. Der CRACI-Build kostet $5.68: 64% weniger, also etwa 2,7-mal günstiger. GitHub-Listenpreise Stand September 2026; enthaltene Minuten gelten nicht für größere Runner.

Die SPDX-Ausgabe von Yocto enthält allerdings Dinge, die CRACI nicht aufzeichnet, etwa die Patches, die ein Rezept anwendet, und die CVEs, die es als behoben markiert. Wenn Ihr Prozess davon abhängt, lassen Sie create-spdx eingeschaltet und nutzen Sie die SBOM von CRACI daneben. Wenn nicht, deckt die SBOM von CRACI für sich allein jede Komponente ab, die in der von Yocto stand, und mehr.

Warum das für die Lieferkettensicherheit wichtig ist

Was in einen Build hineingeht, bestimmt, was herauskommt, ob es nun im Image installiert ist oder nicht. Angreifer wissen das, und über den Build sind jüngste Angriffe auf die Lieferkette eingedrungen:

• Angriffe verstecken sich im Build. Die Hintertür in xz utils (CVE-2024-3094) steckte in den Versionen 5.6.0 und 5.6.1. Ihr Auslöser lag in den Release-Tarballs statt im Git-Repository, und der Schadcode gelangte während des Builds in die Bibliothek. Das Lesen des Quellcodes brachte ihn nicht ans Licht; das Wissen, welchen Tarball der Build genau geladen hat, schon.
• Auch CI-Abhängigkeiten sind Ziele. Im März 2025 meldete die CISA, dass jede Version der GitHub Action tj-actions/changed-files drei Tage lang kompromittiert war. Eine Action läuft in Ihrem Build-Job. Deshalb listet CRACI die Actions, die Ihr Workflow genutzt hat, festgelegt auf den Commit, der lief.
• Rust-Crates verschwinden in Binärdateien. Cargo kompiliert Crates in die Programme, die sie verwenden. Ein verwundbares Crate wird also im Image ausgeliefert, ohne je als Paket aufzutauchen. Listet die SBOM es nur als Dateinamen, können auch Schwachstellen-Tools es nicht abgleichen. Wer die fertige Binärdatei nachträglich scannt, muss raten, was hineingeflossen ist; wer den Build aufzeichnet, nicht.
• Auf das, was Sie nicht sehen, können Sie nicht reagieren. Erscheint eine Sicherheitsmeldung zu einem Crate oder einem Build-Tool, müssen Sie wissen, welche Builds es verwendet haben. CRACI bewahrt die SBOM jedes Builds auf und zeigt, welche Builds die verwundbare Abhängigkeit enthielten, direkt oder transitiv, sodass Sie den Zeitraum kennen, in dem Sie betroffen waren. Das funktioniert nur, wenn jede Komponente eine Package-URL hat, über die sie sich abgleichen lässt.
• Ein Build sollte nur erreichen, was er braucht. Die Egress-Richtlinie von CRACI blockiert Verbindungen zu Hosts, die der Build nicht braucht. Eine kompromittierte Abhängigkeit, die versucht, Ihre Secrets an den Server eines Angreifers zu schicken, wird so gestoppt, selbst bei einem Angriff, den noch niemand gesehen hat.

Auch Kunden und Regelwerke wie der Cyber Resilience Act verlangen von Herstellern vernetzter Geräte, dass sie wissen, was in ihren Produkten steckt. Eine SBOM, die den gesamten Build abdeckt, ist ein Nachweis, der standhält, wenn sie nachfragen.

Warum Yocto-Builds im CI schwierig sind

Ein vollständiger Image-Build kompiliert eine Toolchain, einen Kernel und Hunderte Pakete aus dem Quellcode. Auf den Standard-Runnern mit 2 Kernen, die die meisten CI-Dienste anbieten, kann das Stunden dauern. Viele Embedded-Teams betreiben deshalb einen eigenen Build-Server unter dem Schreibtisch oder im Rack, und dieser Server wird zu einer weiteren Maschine, die gepatcht, gesichert und einem Auditor erklärt werden muss.

Ein Yocto-Build lädt außerdem sehr viel herunter: Quell-Tarballs, Git-Repositories und Patches von Upstream-Projekten und Spiegeln. Über genau diese Downloads muss Ihre SBOM Auskunft geben, und genau sie sollen Hersteller vernetzter Geräte nach Regelwerken wie dem Cyber Resilience Act kennen und im Blick behalten.

Was CRACI einem Yocto-Build bietet

Runner in der passenden Größe für BitBake

CRACI-Runner skalieren von 1 bis 32 Compute-Einheiten, wobei jede Einheit 1 vCPU und 3 GB RAM hat. Ein Yocto-Build kann die größte Größe, 32 vCPUs und 96 GB RAM, direkt im Workflow anfordern. Jobs laufen in isolierten virtuellen Maschinen, und die Läufe erscheinen weiterhin in GitHub wie jeder andere Actions-Job.

Minuten werden pro Sekunde gemessen und pro vCPU-Minute abgerechnet. Ein großer Runner kostet also mehr pro Minute und ist früher fertig. Die aktuellen Preise finden Sie unter Preise.

Netzwerkzugriff nach Ihren Vorgaben

BitBake kann seinen Fetcher bereits mit BB_ALLOWED_NETWORKS auf eine Liste von Hosts beschränken. CRACI fügt am Runner eine zweite Kontrolle hinzu: eine Egress-Richtlinie, die vor dem Start des Jobs geprüft wird und im Zweifel blockiert (fail closed). So kann auch ein Rezept, ein Skript oder ein kompromittiertes Tool, das den Fetcher umgeht, keinen Host erreichen, den Sie nicht erlaubt haben. CRACI warnt Sie bei Richtlinienverstößen.

Eine Aufzeichnung dessen, was der Build geladen hat

CRACI beobachtet den Datenverkehr, den ein Job an Paket- und Quell-Hosts sendet, und zeichnet ihn als Build-Nachweis auf. Für einen Yocto-Build bedeutet das eine unabhängige Aufstellung der Quellen, die tatsächlich über das Netzwerk kamen, neben der SBOM, die Yocto selbst schreibt.

Ein minimaler Workflow

Das Yocto-Beispiel in der CRACI-Dokumentation baut core-image-sato für qemux86-64. Für CRACI entscheidend sind die Runner-Größe und eine Fetcher-Konfiguration, die den offiziellen Yocto-Quellspiegel nutzt:

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

Die Anleitung in der Dokumentation enthält den vollständigen Workflow, einschließlich Host-Abhängigkeiten und Locale-Einrichtung, und die Referenz zur Runner-Konfiguration listet jede Setup-Option.

Gut zu wissen

• Builds laufen aus GitHub Actions heraus auf den verwalteten Runnern von CRACI auf europäischer Infrastruktur. Vom Kunden gehostete Runner und weitere CI-Systeme sind auf der Roadmap.
• Richten Sie BitBake auf Spiegel aus, die CRACI sehen kann, etwa den offiziellen Yocto-Quellspiegel, statt auf beliebige Hosts. Die Anleitung in der Dokumentation zeigt ein funktionierendes Setup.
• Wenn Sie das Download-Verzeichnis und den Shared-State-Cache zwischen den Läufen behalten, werden wiederholte Builds schnell.
• Native ARM64-Runner gibt es zum selben Preis wie x86-64.

Sie bauen vernetzte Geräte für den EU-Markt? Lesen Sie, was der CRA verlangt und wie CRACI für industrielles IoT und Unterhaltungselektronik funktioniert. Sie vergleichen SBOM-Tools für Yocto? Siehe CRACI vs. Timesys Vigiles.

Yocto-SBOMs und CRACI: häufig gestellte Fragen

Erzeugt Yocto eine SBOM?

Ja. Das OpenEmbedded-Build-System erzeugt seit Yocto 4.3 (Nanbield) standardmäßig eine SPDX-SBOM, über die Klasse create-spdx. Für ein Image schreibt es IMAGE-MACHINE.spdx.json nach tmp/deploy/images/MACHINE/, mit Komponenten, Lizenzen, Abhängigkeiten, Quellen, angewendeten Patches und behobenen Schwachstellen. Unter Kirkstone (4.0) fügen Sie INHERIT += "create-spdx" hinzu, um sie einzuschalten.

Welche SPDX-Version erzeugt Yocto?

Seit Yocto 5.1 (Styhead) standardmäßig SPDX 3.0, das 2.2 als Standard abgelöst hat. Scarthgap (5.0) erzeugt standardmäßig SPDX 2.2 und kann mit der Klasse create-spdx-3.0 auf 3.0 umgestellt werden.

Wie bekomme ich eine CycloneDX-SBOM aus Yocto?

Fügen Sie den Layer meta-cyclonedx im Branch für Ihr Release hinzu und erben Sie cyclonedx-export in local.conf. Er schreibt eine SBOM .cyclonedx.bom.json und eine Datei .cyclonedx.vex.json neben das Image, standardmäßig in CycloneDX 1.6.

Was fehlt in der Yocto-SBOM?

Bei einem direkten Vergleichs-Build von core-image-sato enthielt die von CRACI aufgezeichnete SBOM alle 865 Komponenten der Yocto-SBOM und 88 weitere: Host-Pakete auf der Build-Maschine wie Ubuntus cpio, GitHub-Quellen und Actions sowie andere Quellen, die während des Builds geladen wurden. Außerdem listet Yocto seine 653 Rust-Crate-Versionen nur mit Dateiname und Download-URL, ohne Package-URL, auf die der Schwachstellenabgleich angewiesen ist.

Kann ich Schwachstellen in einem Yocto-Build überwachen?

Ja, mit CRACI. Der Schwachstellenabgleich arbeitet mit Package-URLs, und die eingebaute SBOM von Yocto listet Rust-Crates nur mit Dateiname und Download-URL, sodass sie sich nicht abgleichen lassen. CRACI zeichnet die Rust-Crates und die Pakete der Build-Maschine mit den Package-URLs auf, gegen die Sicherheitsmeldungen veröffentlicht werden (pkg:cargo, pkg:deb), darunter alle 653 Crate-Versionen in core-image-sato. Es zeigt den Schwachstellenstatus jedes Pakets und bewertet die SBOM laufend neu, sobald neue Sicherheitsmeldungen veröffentlicht werden.

Kann CRACI die Yocto-SBOM ersetzen?

Was die Abdeckung der Lieferkette angeht, ja. Im selben Vergleich enthielt die SBOM von CRACI jede Komponente der eingebauten Yocto-SBOM, 88 weitere und eine Package-URL für jedes Rust-Crate, und der Build ohne die SBOM-Generierung von Yocto brauchte 43% weniger Zeit. Die SPDX-Ausgabe von Yocto enthält aber Rezept-Metadaten, die CRACI nicht aufzeichnet, etwa die angewendeten Patches und die CVEs, die ein Rezept als behoben markiert. Wenn Sie darauf angewiesen sind, lassen Sie create-spdx eingeschaltet.

Schafft ein CRACI-Runner einen vollständigen Yocto-Image-Build?

CRACI-Runner reichen bis 32 vCPUs und 96 GB RAM, eingestellt im Workflow. Die CRACI-Dokumentation enthält ein Yocto-Beispiel, das core-image-sato auf der größten Größe baut.

Welches CI nutzt ein Yocto-Build auf CRACI?

GitHub Actions. Ihr Workflow läuft auf den verwalteten Runnern von CRACI, und die Läufe erscheinen in GitHub wie jeder andere Actions-Job. Weitere CI-Systeme und vom Kunden gehostete Runner sind auf der Roadmap.