SBOM Best Practices

SBOMs erzeugen

1. Im CI erzeugen, für jedes Release

Eine von Hand erstellte SBOM ist veraltet, bevor sie jemand liest. Machen Sie sie zu einem Schritt in der Pipeline, die das Release baut, oder nutzen Sie einen Runner, der sie ganz ohne Schritt erzeugt, damit kein Release ohne SBOM ausgeliefert wird. Für GitHub Actions siehe so erzeugen Sie eine SBOM in GitHub Actions.

2. Den Build beschreiben, der ausgeliefert wurde

Builds sind standardmäßig nicht reproduzierbar. Wer denselben Commit zweimal baut, hat keine Garantie für dieselben Abhängigkeiten, weil Versionen zur Build-Zeit aufgelöst werden und Schritte variieren können. Eine SBOM von einem Laptop oder aus einem späteren Scan beschreibt einen ähnlichen Build, nicht den, den Sie ausgeliefert haben. Nur eine SBOM aus dem CI-Build, der das Release erzeugt hat, belegt, was darin steckt. Siehe Build-Time-SBOMs.

3. Mehr abdecken als das Lockfile

Ein Lockfile ist keine Aufzeichnung dessen, was ausgeliefert wurde. Install-Skripte laden Code herunter, Rust-Build-Skripte holen Dateien, und Container-Builds bringen ein Basis-Image mit eigenen Betriebssystempaketen mit. Legen Sie fest, was die SBOM abdecken muss, und testen Sie es: Suchen Sie in Ihrer SBOM nach einem Paket aus Ihrem Basis-Image und nach einem Build-Tool.

4. Transitive Abhängigkeiten und Beziehungen einschließen

Schwachstellen sitzen meist unterhalb Ihrer direkten Abhängigkeiten. Eine flache Liste zeigt, dass eine Komponente da ist, aber nicht, was zu aktualisieren ist. Behalten Sie den Abhängigkeitsgraphen in der SBOM, damit ein Befund das Paket mitliefert, das ihn nachzieht.

5. Benennen, was Sie nicht sehen konnten

Die 2026 Minimum Elements verlangen von SBOM-Autoren, unbekannte Informationen ausdrücklich zu kennzeichnen. Eine unvollständige SBOM, die das sagt, ist mehr wert als eine unvollständige SBOM, die fertig aussieht. Halten Sie auch Tool, Version und Generierungskontext fest, damit Leser beurteilen können, was die Datei abdeckt.

SBOMs aufbewahren

6. Eine SBOM pro Release behalten, mit dem Artefakt verknüpft

Fragt ein Kunde mit einer alten Version, ob er betroffen ist, brauchen Sie die SBOM dieser Version und nicht die aktuelle. Speichern Sie jede SBOM mit dem Build und dem Artefakt, das sie beschreibt, und richten Sie die Aufbewahrungsdauer danach, wie lange Sie das Release unterstützen. Hashes in der SBOM helfen, sie dem exakten Artefakt zuzuordnen.

7. Ein Format und eine Kennung wählen und dabei bleiben

Legen Sie sich auf CycloneDX oder SPDX fest, auf eine Formatversion und auf Package-URLs als Kennungen. Die meisten Probleme beim Vergleich von SBOMs entstehen, weil Tools dasselbe unterschiedlich benennen. Validieren Sie jede Datei in der Pipeline, und verlangen Sie von Lieferanten dasselbe Format.

SBOMs nutzen

8. Überwachen, was ausgeliefert wurde, nicht nur, was Sie gerade bauen

Am wertvollsten ist eine SBOM an dem Tag, nachdem ein Advisory für Software erschienen ist, die Sie letztes Jahr veröffentlicht haben. Ein Scan in einem Pull Request hilft dann nicht. Bewerten Sie die gespeicherten SBOMs unterstützter Releases mit neuen Schwachstellendaten neu, damit aus einem neuen Advisory eine Liste betroffener Releases wird.

9. Befunde an Zuständige weitergeben und die Entscheidung festhalten

Eine SBOM mit tausend zugeordneten Schwachstellen ist eine Liste, kein Plan. Priorisieren Sie Befunde mit einer Priorisierungsmethode, geben Sie jeden an das für die Behebung zuständige Team weiter, und halten Sie fest, warum Sie beim Rest nicht gehandelt haben, zum Beispiel in einer VEX-Aussage.

10. Dieselbe SBOM für Kunden und Auditoren nutzen

Kunden, Auditoren und Regulierungsbehörden stellen ähnliche Fragen. Beantworten Sie sie aus der SBOM, die Ihre eigenen Teams nutzen, statt ein separates Dokument zu pflegen, das auseinanderläuft. Wenn Sie SBOMs teilen, legen Sie fest, wer sie sehen darf und wie Empfänger Updates erhalten, und verlangen Sie dasselbe von Ihren Lieferanten.

Häufige Fehler

Fehler	Warum er schadet	Stattdessen
Eine SBOM pro Repository	Sie sagt nichts über ein bestimmtes Release aus	Eine pro Release, mit dem Artefakt verknüpft
Nur zum Audit erzeugen	Sie beschreibt einen Build, den niemand ausgeliefert hat	Bei jedem Release, im CI
Die SBOM als abgeschlossen betrachten	Neue Advisories erscheinen nach dem Release	Weiter überwachen
Nur die Anzahl der Komponenten vergleichen	Mehr ist nicht besser, wenn die Einträge falsch sind	Gezielt Pakete prüfen, von denen Sie wissen, dass sie vorhanden sind

Wie CRACI das umsetzt

CRACI deckt die Praktiken ab, die vom Build abhängen. Es ist ein GitHub-Actions-Runner, der jedes Paket aufzeichnet, das ein Job lädt, einschließlich versteckter Abhängigkeiten, die in keinem Lockfile stehen, und daraus eine CycloneDX- oder SPDX-SBOM mit Vollständigkeitsstatus erzeugt. Es bewahrt jeden früheren Build und seine SBOM innerhalb der Aufbewahrungsfrist Ihres Plans auf, bewertet überwachte SBOMs neu, sobald neue Schwachstellen auftauchen, und zeigt, welche Builds eine verwundbare Abhängigkeit enthielten. Sicherheitsteams sichten die Befunde und geben sie an die Teams weiter, die für die Behebung zuständig sind. Wie sich Verwaltungstools unterscheiden, lesen Sie unter SBOM-Verwaltung, oder sehen Sie sich die besten SBOM-Tools an.

SBOM Best Practices: häufig gestellte Fragen

Wann sollten Sie eine SBOM erzeugen?

Während des CI-Builds, der das Release erzeugt, und zwar jedes Mal. Eine zu diesem Zeitpunkt erstellte SBOM beschreibt, was ausgeliefert wurde, eine spätere beschreibt einen Rebuild oder einen Scan.

Wie lange sollten Sie SBOMs aufbewahren?

Mindestens so lange, wie Sie das Release unterstützen, zuzüglich dessen, was Regulierungsbehörden oder Verträge verlangen. Sie brauchen die SBOM einer alten Version, um feststellen zu können, ob deren Nutzer von einer neuen Schwachstelle betroffen sind.

Sollten SBOMs automatisiert werden?

Ja. Eine manuelle SBOM ist beim nächsten Release veraltet. Erzeugen Sie SBOMs in der Pipeline, validieren Sie sie dort und speichern Sie sie mit dem Build.

Sollten Sie Ihre SBOM mit Kunden teilen?

Teilen Sie sie, wenn ein Kunde oder eine Regulierungsbehörde danach fragt, zu Bedingungen, mit denen Sie einverstanden sind. Eine SBOM verrät, was Sie einsetzen, deshalb geben viele Unternehmen sie auf Anfrage heraus, statt sie zu veröffentlichen.

Was ist der Unterschied zwischen einer SBOM und SBOM-Verwaltung?

Eine SBOM ist eine Datei. SBOM-Verwaltung ist die laufende Arbeit, SBOMs nach Release zu speichern, sie auf neue Schwachstellen zu überwachen und denjenigen zugänglich zu machen, die sie brauchen.