SBOM für Rust- und Cargo-Projekte nach dem CRA

Der Cyber Resilience Act verlangt von jedem Hersteller eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene des Produkts erfasst (Anhang I Teil II Nummer 1). Rust startet von einer guten Position: Cargo.lock pinnt jedes Crate mit seiner Prüfsumme, und die RustSec-Datenbank nennt oft genau die Funktionen, die eine Schwachstelle betrifft. Sorgfalt braucht, was die Lock-Datei auflistet, aber nicht ausgeliefert wird, und was ausgeliefert wird, ohne aufgelistet zu sein.

Zur Verordnung selbst siehe SBOM für den Cyber Resilience Act.

Cargo.lock einchecken

Checken Sie für jedes Binary, das Sie verteilen, Cargo.lock ein und bauen Sie mit cargo build --locked. Die Lock-Datei hält dann die genauen Crates und Versionen der Version fest. Direkte Abhängigkeiten sind die, die in jeder Cargo.toml des Workspace deklariert sind.

Die SBOM erzeugen

Das Cargo-Plugin des CycloneDX-Projekts fragt Cargo nach dem aufgelösten Abhängigkeitsgraphen:

cargo install cargo-cyclonedx
cargo cyclonedx --format json

Es schreibt eine Datei neben jede Cargo.toml des Workspace. Zwei Optionen sind für eine genaue SBOM wichtig:

--target: Cargo.lock listet die Abhängigkeiten aller Plattformen, sodass die Lock-Datei eines Linux-Builds trotzdem windows-sys enthält. Geben Sie das Ziel an, für das Sie bauen (Standard ist der Host), um wegzulassen, was nicht einkompiliert wird.
Features: Das Plugin folgt der Feature-Auswahl von Cargo. Verwenden Sie dieselbe Wahl von --features oder --all-features wie im Release-Build.

Entwicklungsabhängigkeiten werden weggelassen, da sie das Binary nicht erreichen können.

Die Liste ins Binary legen

cargo-auditable bettet die Abhängigkeitsliste in einem kleinen komprimierten Abschnitt in die kompilierte Programmdatei ein:

cargo install cargo-auditable
cargo auditable build --release

Das Binary beschreibt sich dann selbst. cargo audit bin ./target/release/app prüft es gegen RustSec, und Syft, Trivy und Grype lesen es ebenfalls. Für den CRA ist das nützlich, wenn Binaries an Orten landen, an denen die ursprüngliche SBOM von ihnen getrennt wird, etwa in Firmware-Images, auf Kundenservern und in Container-Images.

Cargo arbeitet selbst an einer nativen Unterstützung: Ein instabiles Flag -Z sbom schreibt „SBOM-Vorstufen“-Dateien neben die Build-Ausgabe, und seine Stabilisierung ist eines der Ziele des Rust-Projekts für 2026.

Was die Lock-Datei nicht zeigt

C-Code in -sys-Crates. openssl-sys mit dem Feature vendored kompiliert OpenSSL aus dem Crate openssl-src; libsqlite3-sys mit bundled kompiliert SQLite. Die SBOM listet das Crate, während die Sicherheitshinweise der C-Bibliothek unter dem Namen OpenSSL oder SQLite erscheinen. openssl-src trägt die OpenSSL-Version in der eigenen Versionsnummer (300.x.y+3.x.y), sodass Sie sie dort ablesen können; bei anderen Crates vermerken Sie die gebündelte Bibliothek und ihre Version selbst in der SBOM.
Build-Skripte und prozedurale Makros. build.rs und Proc-Macro-Crates laufen zur Kompilierzeit und stecken als solche nicht im Binary, formen aber den Code, der darin steckt. Sie gehören als Build-Komponenten in die Aufzeichnung.
Die Rust-Toolchain. Die Standardbibliothek wird in Ihr Binary kompiliert. Ihre seltenen Sicherheitshinweise werden in neuen Rust-Versionen behoben, also halten Sie die Compiler-Version jeder Version fest.

Von der SBOM zu den Schwachstellen

cargo audit prüft Cargo.lock gegen die RustSec-Datenbank, die auch OSV weiterveröffentlicht. RustSec-Hinweise nennen oft die betroffenen Funktionen (smallvec::SmallVec::insert_many), sodass Sie vor einer Entscheidung prüfen können, ob Ihr Code sie aufruft. Schauen Sie zuerst auf die in freier Wildbahn ausgenutzten Schwachstellen, die die Meldeuhr starten können, und halten Sie in einer VEX-Aussage fest, warum eine verwundbare Funktion, die Sie nie aufrufen, das Produkt nicht betrifft.

Wie Provetry hilft

Provetry liest Cargo.lock aus Ihrer CI oder aus den hochgeladenen Dateien, entnimmt die direkten Abhängigkeiten den Cargo.toml-Dateien, schreibt die SBOM jeder Version in CycloneDX, in den kostenpflichtigen Tarifen auch in SPDX, und überwacht jedes Crate auf neue und ausgenutzte Schwachstellen, täglich in den kostenpflichtigen Tarifen und wöchentlich im kostenlosen. Sein CI-Schritt geht bei Rust eine Ebene weiter: Wenn RustSec die betroffenen Funktionen nennt, nur Ihr eigener Code vom Crate abhängt, keines seiner Makros genutzt wird und keine der Funktionen irgendwo in Ihrem Repository vorkommt, schlägt er „nicht betroffen“ mit diesem Nachweis vor. Er zieht keinen Schluss, wenn Rust sie aufrufen könnte, ohne dass ihr Name im Quelltext steht: Trait-Methoden, Operatoren, Makros, Derives, Re-Exports und zur Build-Zeit erzeugter Code. Erwähnt eine Datei eine davon, nennt er Datei und Zeile, die Sie zuerst prüfen sollten. Jeder Befund ist ein Vorschlag, den Sie übernehmen oder nicht.