Warum SBOM-Scanner verfehlen, was in Yocto-Builds steckt

Wie sich ein Yocto-Build von dem unterscheidet, was Scanner erwarten

Ein Yocto-Build ist keine Installation per Paketmanager. Das meiste, was auf dem Gerät landet, wird zur Build-Zeit entschieden, innerhalb von BitBake, in fünf Schichten. Scanner betrachten im Nachhinein eine Schicht und müssen den Rest raten.

1. Der Build-Host

BitBake läuft mit Tools der Build-Maschine. Die Variable HOSTTOOLS listet die Tools auf dem Build-Host, die Build-Tasks aufrufen dürfen, und das Build-System verlinkt sie per Symlink nach ${TMPDIR}/hosttools. BitBake baut außerdem eigene Tools über -native- und -cross-Recipes. Host-Tools beeinflussen das Image und sind konstruktionsbedingt nicht Teil davon.

2. Laden der Quellen

Recipes nennen ihre Quellen in SRC_URI, und der Fetcher lädt sie nach DL_DIR herunter. Er sucht zuerst in DL_DIR, dann in PREMIRRORS, dann upstream, dann in MIRRORS. Rust-Crates kommen über den Fetcher crate://, aufgeführt in einer Datei -crates.inc, die cargo-update-recipe-crates aus Cargo.lock erzeugt. Go-Module kommen über die Klasse go-mod oder werden mit go-vendor vendort. BB_NO_NETWORK und BB_ALLOWED_NETWORKS steuern, was der Fetcher erreichen darf.

3. Recipes und Patches

Jedes Recipe legt in PV eine Upstream-Version fest und wendet Patches darauf an. Ein Patch mit einer Zeile CVE: im Header markiert diese CVE als gepatcht. Die Versionsnummer bleibt die Upstream-Version, sodass das Recipe behoben sein kann, während seine Version etwas anderes sagt.

4. Kompilierter Code

Statische Bibliotheken (die -staticdev-Pakete), Rust-Crates und Go-Module landen in den Binaries, die sie verwenden. Der Kernel und seine Module werden aus einer produktspezifischen Konfiguration gebaut, sodass zwei Plattformen mit derselben Kernel-Version unterschiedlichen Code enthalten.

5. Das Image

Das Root-Dateisystem. Das Image-Feature package-management installiert Paketverwaltungstools und behält die Datenbank des Paketmanagers. Ohne es werden die Datendateien des Paketmanagers aus dem Root-Dateisystem gelöscht, was bei Produktiv-Images üblich ist.

Der Cache shared state (sstate), der gemeinsame Zustandscache

BitBake kann die Ausgabe eines Tasks aus dem sstate-Cache wiederherstellen, statt ihn auszuführen. Das Overview-Handbuch von Yocto sagt es klar: Wenn die vorgebauten Objekte verfügbar sind, wird der Compiler nicht gebraucht, „daher wird der Compiler nicht einmal heruntergeladen“. Aus sstate wiederhergestellte Tasks überspringen Fetch, Compile und Install, was für jedes Tool zählt, das darauf angewiesen ist, diese Schritte zu beobachten. Mehr dazu im Abschnitt zu Caches weiter unten.

Warum Image- und Dateisystem-Scanner das meiste verfehlen

• Keine Paketdatenbank. Ein Produktiv-Image ohne package-management gibt einem Scanner keine Liste zum Lesen, sodass er auf Datei-Heuristiken zurückfällt oder fast nichts meldet. Das Ergebnis sieht vollständig aus und ist nahezu leer.
• Statischer und vendorter Code. Eine statische Bibliothek oder ein Crate, kompiliert in /usr/bin/foo, hinterlässt keinen Paketeintrag. librsvg ist ein Beispiel: Das aktuelle oe-core-Recipe listet mehr als 350 Rust-Crates, und auf dem Gerät ist es eine einzige Shared Library.
• Build-Host und geladene Tools. Sie sind nie im Image, also nie in einem Image-Scan, obwohl ein kompromittiertes Host-Tool oder eine kompromittierte GitHub Action das Image kompromittieren kann. Die Backdoor in xz utils (CVE-2024-3094) gelangte in die Bibliothek, während sie gebaut wurde, aus Release-Tarballs statt aus dem Git-Repository. Im März 2025 meldete die CISA, dass jede Version der GitHub Action tj-actions/changed-files drei Tage lang kompromittiert war.
• Angewendete Patches. Das Image nennt openssl in einer Upstream-Version. Das Recipe hat den Fix für eine CVE, die diese Version betrifft, angewendet und den Patch mit CVE: markiert. Ein Abgleich über Versionsbereiche meldet sie trotzdem. Das ist die Yocto-Form des Backport-Problems von Distributionen und eine der Hauptquellen des Rauschens, das unter Schwachstellenrauschen reduzieren behandelt wird.

In der Summe ergibt das eine Mischung aus fehlenden Komponenten und falschen Befunden, und nichts im Ergebnis sagt Ihnen, was was ist. Dasselbe Argument gilt für Container in SBOMs für Docker-Images und für Sprachprojekte in Open-Source-SBOM-Generatoren.

Warum Binäranalyse von Firmware raten muss

Binäranalyse gleicht Strings, Symbole und Code-Signaturen in extrahierter Firmware mit bekannten Komponenten ab und schließt dann auf Versionen. Wo das Binary klare Hinweise enthält, funktioniert das. In einem Yocto-Image muss sie oft raten:

• gestrippte Binaries ohne Versions-Strings;
• statisch gelinkter Code, bei dem die Grenzen zwischen Bibliotheken verschwunden sind;
• kompiliertes Rust, bei dem die Crate-Grenzen in einer einzigen ausführbaren Datei aufgehen;
• zurückportierte Patches, die in einer Versionsnummer unsichtbar sind;
• Kernel-Code, den die Konfiguration hinein- oder herauskompiliert hat.

Binäranalyse ist das richtige Tool für Firmware, die Sie nicht selbst gebaut haben: Blobs von Zulieferern, zugekaufte Module, ein Gerät, das Sie evaluieren. Wenn Sie den Build nicht haben, ist die Analyse des Binarys die einzige Option. Die Entscheidungsregel ist einfach: Wenn Sie es bauen, zeichnen Sie es auf; wenn Sie es nur erhalten, analysieren Sie es und fordern beim Zulieferer eine SBOM aus dessen Build an.

Was Yoctos eigene SBOM- und CVE-Tools gut machen

Die SBOM-Arbeit des Yocto Project ist gute Ingenieursarbeit und weiß Dinge, die kein externes Tool wissen kann. Laut Dokumentation ist die SBOM „eine Beschreibung aller Komponenten, die Sie verwendet haben, ihrer Lizenzen, ihrer Abhängigkeiten, ihrer Quellen, der Änderungen, die an ihnen vorgenommen wurden, und der bekannten Schwachstellen, die behoben wurden“.

create-spdx nach Release

• 4.3 (Nanbield): SPDX-Erzeugung ist standardmäßig eingeschaltet.
• 5.1 (Styhead): standardmäßig SPDX 3.0 statt 2.2 und eine Klasse vex, die externen CVE-Tools die nötigen Informationen liefert.
• 5.3 (Whinlatter): SPDX_INCLUDE_COMPILED_SOURCES, das nur die zum Kompilieren verwendeten Quellen einbezieht.
• 6.0 (Wrynose, Long-Term Support): SPDX 2.2 entfernt; SPDX_INCLUDE_KERNEL_CONFIG und SPDX_INCLUDE_PACKAGECONFIG hinzugefügt; Recipes, die mit den Klassen für Cargo, Go, PyPI, npm und CPAN gebaut werden, erhalten eine Package-URL ihres Ökosystems.

Die SBOM deckt ab, was BitBake baut, einschließlich der nativen Tools, die es für den Host baut. Sie ist gründlich bei allem, was ein Recipe hat.

CVE-Status als VEX in der SBOM

In SPDX 3 schreibt das Build-System den CVE-Status jedes Recipes als VEX-Beziehungen: Eine gepatchte CVE wird zu „fixed“, verknüpft mit den Patch-Dateien; eine ungepatchte zu „affected“; eine ignorierte zu „not affected“, mit dem Grund als Impact Statement. SPDX_INCLUDE_VEX legt fest, wie viel hineinkommt: none, current (der Standard, Schwachstellen, die im Upstream-Quellcode noch nicht behoben sind) oder all.

CVE_STATUS und das Patch-Tag

CVE_STATUS hält eine Entscheidung pro CVE fest, als Grund und optionale Beschreibung. Die Gründe ordnen sich gepatcht (backported-patch, cpe-stable-backport, fixed-version und weitere), ungepatcht (vulnerable-investigating) und ignoriert (cpe-incorrect, disputed, not-applicable-config, not-applicable-platform, upstream-wontfix) zu. CVE_STATUS_GROUPS wendet eine Entscheidung auf eine Gruppe von CVEs an, und CVE_PRODUCT legt den Produktnamen für den Abgleich fest.

# In a recipe or .bbappend
CVE_STATUS[CVE-2020-15523] = "not-applicable-platform: Issue only applies on Windows"

# In the header of a patch file
CVE: CVE-2022-3341
Upstream-Status: Backport [link to the upstream commit]

Von cve-check zu sbom-cve-check

cve-check glich Recipe-Namen (CVE_PRODUCT) und Versionen mit Schwachstellendaten ab. Die Release Notes zu 5.2 warnen, dass die NVD-Maintainer seit Anfang 2024 viele CVEs nicht mehr mit den betroffenen CPEs annotieren, sodass „die aktuellen CVE-Berichte gut aussehen mögen, in Wirklichkeit aber manche Schwachstellen einfach nicht gemeldet werden“. Mit 5.2 wurde außerdem der FKIE-Feed statt der NVD zum Standard. Yocto 6.0 hat cve-check entfernt und durch die Klasse sbom-cve-check ersetzt, die Bootlins sbom-cve-check auf der SPDX-Ausgabe ausführt. Unter 5.0 bis 5.3 haben Sie noch cve-check; behandeln Sie es als Altlast.

Wo Yoctos SBOM aufhört

Was Yocto nicht sehen kann, ist alles außerhalb der Metadaten von BitBake. Wir haben core-image-sato zweimal auf einem nativen ARM64-Runner mit 32 vCPUs gebaut, einmal mit Yoctos SBOM-Erzeugung und einmal ohne, und Yoctos SBOM in SPDX 3.0.1, geschrieben als 1.632 Dateien, mit der CycloneDX-SBOM verglichen, die CRACI aufgezeichnet hat:

• Komponenten. Die von CRACI aufgezeichnete SBOM enthielt jede Komponente der Yocto-SBOM und 88 weitere, die ihr fehlten: 23 Host-Pakete auf der Build-Maschine (etwa Ubuntus cpio), 10 GitHub-Quellen, darunter die GitHub Action actions/upload-artifact, und 55 andere Quellen und Tools, die während des Builds geladen wurden.
• Rust-Crates. Beide listeten dieselben 653 Rust-Crate-Versionen. In dem Release, das wir gebaut haben, listete Yoctos SBOM sie nur als .crate-Dateien mit Download-Ort, ohne pkg:cargo-Package-URL, sodass sie sich nicht mit Advisories abgleichen ließen. Seit Yocto 6.0 tragen Recipes, die mit der Cargo-Klasse gebaut werden, eine Package-URL für das Recipe selbst, etwa pkg:cargo/librsvg; im aktuellen Code haben die einzelnen Crate-Downloads weiterhin keine. Prüfen Sie, was Ihr Release schreibt.
• Kosten. Der Build mit Yoctos SBOM-Erzeugung dauerte 155 min 40 s und schrieb 1.632 SPDX-Dateien. Ohne sie dauerte der Build 88 min 48 s, 43 % weniger. SPDX_INCLUDE_SOURCES, SPDX_INCLUDE_COMPILED_SOURCES, SPDX_INCLUDE_KERNEL_CONFIG und SPDX_INCLUDE_PACKAGECONFIG waren eingeschaltet, eine Standardkonfiguration kostet also weniger. Yoctos eigene Dokumentation warnt, dass die unkomprimierte SBOM von core-image-minimal mit einbezogenen kompilierten Quellen „von Hunderten Megabyte auf mehrere Gigabyte anwachsen kann“.

Native Recipes wie cmake, llvm, ninja und qemu sind in Yoctos SBOM enthalten. Die Methode, beide SBOMs und der vollständige Bericht stehen unter Yocto-Builds auf CRACI.

CVEs im Linux-Kernel: das Problem pro Konfiguration

Das Linux-Kernel-Projekt gab am 13. Februar 2024 bekannt, dass es CVE Numbering Authority geworden ist, und es vergibt CVEs großzügig für Fixes. Seine CVE-Dokumentation sagt, die Anwendbarkeit einer bestimmten CVE „muss der Linux-Anwender selbst bestimmen“, denn „wir kennen Ihren Anwendungsfall nicht, und wir wissen nicht, welche Teile des Kernels Sie verwenden“.

Ein Abgleich der Kernel-Version erzeugt daher Hunderte Befunde, die meisten für Code, den Ihre Konfiguration nie kompiliert. Vier Hardware-Plattformen mit vier Kernel-Konfigurationen ergeben vier verschiedene Antworten für dieselbe Kernel-Version. Es gibt vier Wege, damit umzugehen:

1. Nur Versionsabgleich. Jede CVE für die Version wird gemeldet. Maximales Rauschen.
2. Kuratierte Ausschlusslisten. CVE_STATUS-Einträge, erzeugt aus den CVE-Daten des Kernels. Im Mai 2026 hat oe-core seine erzeugte Liste für linux-yocto entfernt, weil sbom-cve-check das selbst aus der CVE-Liste des Kernels erledigt, mit unverändertem CVE-Bericht und einer fast 20 MB kleineren SPDX.
3. Filtern nach dem, was kompiliert wurde. Mit SPDX_INCLUDE_COMPILED_SOURCES für das Kernel-Recipe prüft improve_kernel_cve_report.py, ob die Dateien, die eine CVE betrifft, zum Bauen des Kernels verwendet wurden. Laut Yoctos Security-Handbuch „reduziert es falsch-positive CVEs um 70 % bis 80 %“.
4. Die Konfiguration aufzeichnen. SPDX_INCLUDE_KERNEL_CONFIG (6.0) schreibt die Kernel-Konfiguration in die SBOM, sodass sich die Antwort später prüfen lässt.

Ein durchgerechnetes Beispiel. Eine Kernel-CVE in einem Netzwerktreiber. Plattform A baut den Treiber, Plattform B nicht.

Plattform	Treiber kompiliert?	Versionsabgleich	Filter nach kompilierten Quellen
A	Ja	Gemeldet	Gemeldet: Die betroffenen Dateien wurden gebaut
B	Nein	Gemeldet	Nicht gemeldet: Die betroffenen Dateien wurden nicht gebaut

Für Kernel-CVE-Berichte pro Plattform führen Sie heute Yoctos Tools für kompilierte Quellen einmal pro Maschinenkonfiguration aus. Die Konfiguration entscheidet über die Antwort, also muss der Bericht aus dem Build jeder Konfiguration stammen.

Caches, Mirrors und Vendoring: wo jeder Recorder vorsichtig sein muss

• Ein Build, der alles aus sstate oder aus einem befüllten DL_DIR wiederherstellt, lädt wenig oder nichts. Ein Recorder, der Downloads sieht, muss seine Nachweise mit diesen Caches mitführen, sonst schrumpft die Aufzeichnung.
• Ein Recipe, das auf einen vorab vendorten Tarball zeigt, zeigt einen Download, nicht die Crates oder Module darin.
• Was auch immer Sie verwenden: Bauen Sie Release-Images aus einem bekannten Cache-Zustand, betreiben Sie Mirrors unter Ihrer Kontrolle und vergleichen Sie die Anzahl der Komponenten zwischen Builds.

Auf CRACI bleiben Pakete, die aus CI-Caches wiederhergestellt werden, in der SBOM, und der Vollständigkeitsstatus jedes Jobs kennzeichnet, was die Aufzeichnung nicht sehen konnte.

Was Sie einsetzen sollten: eine Entscheidungstabelle

Situation	Was Sie einsetzen	Was Sie bekommen	Was Ihnen noch fehlt
Sie bauen das Image in GitHub Actions	Den Build aufzeichnen (CRACI); create-spdx behalten, wenn Sie auf dessen Patch- und CVE-Status angewiesen sind	Host-Pakete, geladene Quellen und Actions, eine pkg:cargo-URL pro Crate, laufende Überwachung	Kernel-Filterung pro Konfiguration: Yoctos Tools verwenden
Sie bauen mit Yocto in einem anderen CI-System oder auf einem Build-Server	create-spdx mit sbom-cve-check (oder cve-check bei älteren Releases), Kernel-Filterung mit kompilierten Quellen	Recipes, Patches, CVE-Status als VEX	Ein Inventar der Host-Pakete und geladenen Tools, separat geführt
Sie erhalten Firmware, die Sie nicht bauen	Binäranalyse und eine Build-SBOM vom Zulieferer	Aus dem Binary erschlossene Komponenten	Gewissheit über Versionen, Patches und Build-Inputs
Sie brauchen Kernel-CVEs pro Plattform	Yoctos Tools für kompilierte Quellen, pro Maschinenkonfiguration	CVEs für den Code, den jede Konfiguration baut	Komponenten außerhalb des Kernels, aus Ihrer SBOM
Sie haben nur einen Image-Scanner	Für installierte Pakete nutzen, wenn die Paketdatenbank erhalten bleibt	Einen Teil der Laufzeit-Paketliste	Alles, was hineinkompiliert, gepatcht oder auf dem Build-Host geblieben ist; ein sauberes Ergebnis ist kein Nachweis

Was jede Methode sieht

Komponentenklasse	Image-Scanner	Binäranalyse	Yocto create-spdx	Build-Aufzeichnung (CRACI)
Installierte Pakete	Nur wenn die Paketdatenbank erhalten bleibt	Aus Dateien erschlossen	Ja	Ja, aus den Quellen, die der Build geladen hat
Statische Bibliotheken	Nein	Aus Signaturen erschlossen	Ja, als Recipes	Ja, aus den Quellen, die der Build geladen hat
Rust-Crates	Nein	Erschlossen; Crate-Grenzen verschwinden	Als .crate-Downloads, ohne Package-URL pro Crate	Ja, jeweils mit einer pkg:cargo-Package-URL
Go-Module	Nein	Aus dem Binary erschlossen	Als Modul-Downloads des Recipes	Ja, wenn sie während des Builds geladen werden
Angewendete Patches und CVE-Status	Nein	Nein	Ja, als VEX	Nein
Kernel-Konfiguration	Nein	Nein	Ja, mit SPDX_INCLUDE_KERNEL_CONFIG (6.0)	Nein
Host-Tools auf der Build-Maschine	Nein	Nein	Nein (native Recipes ja)	Ja
Außerhalb von Recipes geladene Build-Tools und GitHub Actions	Nein	Nein	Nein	Ja

Wo CRACI passt

Für Yocto-Builds, die in GitHub Actions laufen, ist CRACI der Runner, mit bis zu 32 vCPUs und 96 GB RAM. CRACI zeichnet auf, was der Build hereingeholt hat, einschließlich Host-Paketen, GitHub-Quellen und Actions sowie anderer geladener Quellen, mit einer Package-URL für jedes Rust-Crate: im veröffentlichten Vergleich jede Komponente der Yocto-SBOM und 88 weitere, die ihr fehlten. CRACI gleicht die Komponenten mit Advisories ab, bewertet die SBOM laufend neu, sobald neue veröffentlicht werden, und zeigt, welche Builds eine verwundbare Abhängigkeit enthielten.

BitBake kann seinen Fetcher bereits mit BB_ALLOWED_NETWORKS einschränken. Die Egress-Policy von CRACI fügt eine zweite Kontrolle am Runner hinzu, geprüft vor dem Start des Jobs und im Fehlerfall sperrend, sodass ein Skript oder Tool, das den Fetcher umgeht, trotzdem keinen Host erreicht, den Sie nicht erlaubt haben.

Für die Abdeckung der Supply Chain kann die SBOM von CRACI create-spdx ersetzen. Yoctos SPDX enthält weiterhin die angewendeten Patches und die als behoben markierten CVEs, die CRACI nicht aufzeichnet. Lassen Sie create-spdx also eingeschaltet, wenn Sie darauf angewiesen sind. Die CRACI-Dokumentation enthält ein Beispiel, das core-image-sato baut. Warum Aufzeichnen generell besser ist als Scannen, steht unter Build-Time-SBOMs; Yocto-Tools werden unter Embedded-Security-Tools im Vergleich und CRACI vs. Timesys Vigiles verglichen.

Wann CRACI nicht die Antwort ist

• Sie sind auf den CVE-Status auf Patch-Ebene angewiesen, etwa auf Entscheidungen in CVE_STATUS und gepatchte oder ignorierte CVEs als VEX. Das steckt in Yoctos SPDX: Behalten Sie es.
• Sie brauchen heute Kernel-CVE-Berichte pro Konfiguration. Verwenden Sie Yoctos Tools für kompilierte Quellen.
• Sie bauen die Firmware nicht selbst. Verwenden Sie Binäranalyse.
• Ihre Yocto-Builds laufen außerhalb von GitHub Actions oder müssen auf Ihrer eigenen Infrastruktur laufen. CRACI bietet heute verwaltete Runner auf europäischer Infrastruktur; andere CI-Systeme und vom Kunden gehostete Runner stehen auf der Roadmap.
• Sie brauchen die SBOM des Yocto-Jobs speziell in SPDX. Die SBOM von CRACI im veröffentlichten Vergleich war CycloneDX; Yoctos eigene SBOM ist SPDX.

Sie bauen vernetzte Geräte für den EU-Markt? Lesen Sie, was der CRA verlangt, wie VEX funktioniert und wie CRACI zu Telekommunikations- und Netzwerkausrüstung, Industrial IoT und Unterhaltungselektronik passt.

Yocto-CVE-Checks und SBOMs: häufig gestellte Fragen

Warum kann mein SCA-Tool unsere Yocto-basierten Produkte nicht scannen?

Weil die meisten SCA-Tools Manifeste, Lockfiles oder die Paketdatenbank eines Images lesen, und ein Yocto-Build seinen Inhalt innerhalb von BitBake festlegt. Produktiv-Images verzichten oft auf die Paketdatenbank, statische Bibliotheken und Rust-Crates werden in Binaries kompiliert, Recipe-Patches lassen die Upstream-Versionsnummern stehen, und die Tools des Build-Hosts gelangen nie ins Image.

Kann ich ein Yocto-Image oder Firmware mit Trivy, Grype oder einem Binärscanner scannen?

Das können Sie, und Sie bekommen eine Teilantwort. Ein Image-Scanner liest die installierten Pakete, wenn die Paketdatenbank erhalten bleibt, und verfehlt, was hineinkompiliert ist. Ein Binärscanner erschließt Komponenten aus Strings und Signaturen und muss bei gestrippten Binaries, statischem Code und kompiliertem Rust raten. Keiner von beiden sieht den Build-Host oder die Patches, die ein Recipe angewendet hat.

Enthält Yoctos SBOM Rust-Crates und Go-Module?

Sie listet sie als Quellen des Recipes, das sie verwendet. In dem Release, das wir gebaut haben, erschien jedes Rust-Crate als .crate-Download mit Download-Ort und ohne pkg:cargo-Package-URL. Seit Yocto 6.0 erhalten Recipes, die mit den Klassen für Cargo und Go gebaut werden, eine Package-URL ihres Ökosystems für das Recipe selbst, nicht für jeden einzelnen Crate- oder Modul-Download.

Warum meldet mein Scanner CVEs, die unsere Yocto-Recipes bereits patchen?

Weil er Versionsnummern abgleicht. Ein Yocto-Recipe behält die Upstream-Version und wendet Sicherheitsfixes als Patches an, markiert mit einer Zeile CVE: oder festgehalten in CVE_STATUS. Ein Abgleich über Versionsbereiche kann den Patch nicht sehen. Yoctos eigene SPDX hält diese CVEs als behoben fest, verknüpft mit den Patch-Dateien.

Was hat cve-check in Yocto ersetzt?

Die Klasse sbom-cve-check, in Yocto 6.0. Sie führt Bootlins sbom-cve-check auf der SPDX-Ausgabe des Builds aus. Die Releases 5.0 bis 5.3 haben noch cve-check, das Recipe-Namen und Versionen abglich; die Release Notes zu 5.2 warnen, dass dessen Berichte Schwachstellen verfehlen können, weil viele CVEs keine CPE-Daten mehr tragen.

Wie bekomme ich die CVEs des Linux-Kernels für meine eigene Kernel-Konfiguration?

Schalten Sie SPDX_INCLUDE_COMPILED_SOURCES für das Kernel-Recipe ein und führen Sie improve_kernel_cve_report.py aus, das prüft, ob die Dateien, die jede CVE betrifft, kompiliert wurden. Laut Yoctos Security-Handbuch reduziert es falsch-positive CVEs um 70 % bis 80 %. Führen Sie es pro Maschinenkonfiguration aus, da jede Konfiguration anderen Code baut.

Beeinflusst der Shared-State-Cache die SBOM?

Das kann er. Aus sstate wiederhergestellte Tasks überspringen Fetch und Compile, sodass ein Tool, das darauf angewiesen ist, diese Schritte zu beobachten, weniger sieht. Yoctos create-spdx arbeitet mit den Metadaten der Recipes. Bauen Sie bei jeder Methode Release-Images aus einem bekannten Cache-Zustand und vergleichen Sie die Anzahl der Komponenten zwischen Builds.

Reicht Yoctos eingebaute SBOM für den CRA?

Der CRA verlangt eine SBOM, die mindestens die Top-Level-Abhängigkeiten abdeckt, und Yoctos SBOM ist gründlich bei dem, was BitBake baut. Sie listet keine Host-Pakete auf der Build-Maschine, keine GitHub Actions und keine außerhalb von Recipes geladenen Tools. Ob das genügt, entscheiden Sie; die SBOM ist ein Nachweis für Ihren Prozess, nicht für sich allein schon Compliance.