SBOM-Generierung über Engineering-Teams hinweg: eine Policy, jede Pipeline

Warum Scanner pro Team kein SBOM-Programm ergeben

Setzen Sie fünf Tools auf dasselbe Produkt an, und Sie erhalten fünf SBOMs. Die Unterschiede sind strukturell, keine Fehler:

• Unterschiedliche Eingaben, zu unterschiedlichen Zeitpunkten gelesen. Ein Tool liest das Lockfile, ein anderes den installierten Abhängigkeitsbaum, ein weiteres das Container-Image, wieder ein anderes die Binärdatei. Jedes sieht einen anderen Ausschnitt des Produkts.
• Unterschiedliche Namen für dasselbe. Ein Tool identifiziert Komponenten per Package URL, ein anderes per CPE, ein weiteres nur per Dateiname. Zwei SBOMs, die dieselbe Bibliothek beschreiben, lassen sich nicht über einen gemeinsamen Schlüssel verknüpfen.
• Unterschiedliche Tiefe. Manche listen nur direkte Abhängigkeiten, manche den gesamten transitiven Baum, und manche listen auch Build-Tools. Warum Generatoren beim selben Repository zu unterschiedlichen Ergebnissen kommen, zeigt Open-Source-SBOM-Generatoren.
• Manche Tools beantworten eine andere Frage. Schwachstellenscanner für Infrastruktur melden, was auf laufenden Hosts installiert ist. Das ist für den Betrieb nützlich, und es ist keine Beschreibung des Produkts, das Sie ausliefern.

Die Folge: Sie können SBOMs nicht produktübergreifend zusammenführen, deduplizieren oder vergleichen, und Sie können einem Auditor keinen einheitlichen Prozess zeigen, weil es keinen gibt.

Methode	Gelesene Eingabe	Wann	Was fehlt	Typischer Identifikator
Lockfile- oder Manifest-Scanner	Lockfiles und Manifeste im Checkout	Vor oder nach dem Build	Alles, was in keinem Lockfile steht: Install-Hooks, Downloads durch Build-Skripte, Basis-Images	Package URL
Container-Image-Scanner	Paketdatenbanken und Dateien im Image	Nach dem Build	Reine Build-Tools, einkompilierter Code, alles ohne Paketeintrag	Package URL für Betriebssystem- und Sprachpakete
Binär- oder Firmware-Scanner	Strings und Signaturen in der Binärdatei	Nach dem Build	Gewissheit: Versionen und Komponenten werden abgeleitet	CPE oder abgeleiteter Name
Host-Schwachstellenscanner	Installierte Software auf laufenden Servern	Im Betrieb	Das Produkt, wie es an Kunden ausgeliefert wird	CPE oder Produktname des Herstellers
Aufzeichnung während des Builds	Was der Release-Build geladen hat	Während des Builds	Software, die Sie nicht selbst gebaut haben; was nicht sichtbar war, wird als unvollständig markiert	Package URL

Die SBOM-Policy: was zu standardisieren ist

Standardisieren Sie die SBOM, nicht den Scanner. Die Policy legt Ergebnis und Prozess fest; jede Pipeline erfüllt sie mit dem besten Generator, den sie ausführen kann. Jede Zeile unten ist überprüfbar.

Anforderung	Die Regel	Warum	Wie Sie es prüfen
Geltungsbereich	Jedes Produkt-Release, das an einen Kunden geht, einschließlich Firmware und Container-Images. Interne Tools optional.	Kunden und Regulierungsbehörden fragen nach dem, was Sie ausliefern.	Jedes Release im Release-Register hat eine SBOM.
Format und Version	Ein primäres Format, CycloneDX oder SPDX, mit einer Mindestversion. Das andere auf Anfrage akzeptieren.	Ein Format bedeutet ein Parser, ein Validator und ein Speicherort. BSI TR-03183-2 verlangt CycloneDX 1.6 oder neuer oder SPDX 3.0.1 oder neuer, eine sinnvolle Untergrenze für EU-Kunden.	Die Schemavalidierung meldet Format und Version.
Mindestfelder	Eine Package URL an jeder Komponente, die eine hat, eine CPE nur, wo keine existiert, Lieferant, Version, deklarierte Lizenz, Abhängigkeitsbeziehungen, Name und Version des Tools, Zeitstempel und Erzeugungskontext.	Diese Felder nutzen Abgleich, Lizenzprüfung und Audits. Richten Sie sie an den Mindestelementen auf Was ist eine SBOM aus.	Eine Feldprüfung in der Pipeline zählt fehlende Werte.
Zeitpunkt der Erzeugung	Im CI-Build, der das Release erzeugt, jedes Mal. Nicht zum Audit-Zeitpunkt, nicht auf einem Laptop.	Ein erneuter Build ist nicht derselbe Build; siehe Build-Time-SBOMs.	Die Build-ID der SBOM stimmt mit der Build-ID des Release überein.
Tiefe	Der gesamte transitive Baum, nicht nur die oberste Ebene.	Das Minimum des CRA sind die Abhängigkeiten der obersten Ebene; Schwachstellen und Kunden gehen tiefer.	Abhängigkeitsbeziehungen existieren unterhalb der ersten Ebene.
Speicherort	Beim Release-Artefakt, abrufbar nach Produkt und Version.	Eine SBOM, die niemand findet, wenn ein Advisory eintrifft, ist kein Nachweis.	Rufen Sie die SBOM eines zufälligen Release nach Produkt und Version ab.
Aufbewahrung	Mindestens der Supportzeitraum des Produkts plus die Aufbewahrungsfrist für Dokumentation, die Ihre Vorschriften verlangen.	Der CRA legt eine Aufbewahrungsfrist für die technische Dokumentation fest, und die SBOM ist Teil davon.	Vergleichen Sie die Frist der Policy mit der Aufbewahrung jedes Tools.
Validierung	Jede SBOM wird in der Pipeline gegen das Schema validiert; eine ungültige lässt den Build oder das Release-Gate fehlschlagen.	Ungültige SBOMs scheitern unbemerkt in den Tools des Kunden.	Das Log des Release-Gates zeigt einen Validierungsschritt.
Verantwortung	Das Produktteam verantwortet die Erzeugung; Product Security verantwortet die Policy, die Validierungsregeln und das Coverage-Reporting.	Die Erzeugung braucht den Pipeline-Verantwortlichen; Konsistenz braucht einen einzigen Verantwortlichen für die Regeln.	Jede Pipeline nennt einen Verantwortlichen.
Ausnahmen	Ein Register benannter, befristeter Ausnahmen: Team, Grund, Enddatum.	Die Policy übersteht Teams, die sie noch nicht erfüllen können.	Keine Ausnahme ist über ihr Enddatum hinaus.

Die Checkliste in SBOM Best Practices behandelt die Regeln für eine einzelne SBOM; diese Policy ist die Ebene darüber. Jedes Team legt in einer Datei neben der Pipeline fest, wie seine Pipeline die Policy erfüllt:

# sbom-policy.yaml, one per release pipeline
product: gateway-firmware
owner: team-gateway
format: cyclonedx
spec_version: "1.6"
generated_in: release-build
generator: build-time-recording
store: artifact-registry
validation: schema, fail-on-errors
exception: none

Im Build erzeugen, nicht nachträglich pro Team

Die Erzeugung während des Builds ist der Standard, den Sie anstreben sollten. Sie beschreibt den Build, der ausgeliefert wurde, sie erfasst versteckte Abhängigkeiten, die in keinem Lockfile stehen, und ein einziger Mechanismus erzeugt für jedes Team auf dieser Pipeline SBOMs derselben Form. Der Unterschied lässt sich am einfachsten mit einer Küche erklären: Ein Scanner probiert die Suppe und errät das Rezept; ein Recorder beobachtet, was in die Küche kommt.

Ein Scanner bleibt das richtige Werkzeug für Images, die Sie nicht selbst gebaut haben, für Binärdateien von Drittanbietern und für Altprodukte ohne CI. Halten Sie das in der Policy fest, und erfassen Sie den Erzeugungskontext, damit ein Leser weiß, was jede SBOM gesehen hat.

Situation	Erzeugungsmethode	Zu erfassender Erzeugungskontext
Release, gebaut in einer CI, die Sie kontrollieren	Den Build aufzeichnen oder einen Generator im Release-Job ausführen	„Während des Builds aufgezeichnet“ oder „nach der Installation, aus Dateien“
Container-Image, gebaut in der CI	Den Image-Build aufzeichnen; das Ergebnis auf Betriebssystempakete scannen, falls der Recorder sie nicht abdeckt	Build-ID und Image-Digest
Image oder Appliance eines Drittanbieters	Image-Scanner, dazu die SBOM des Herstellers, falls vorhanden	„Gescanntes Ergebnis, nicht von uns gebaut“
Binärdatei eines Lieferanten	Die Build-SBOM des Lieferanten anfordern; Binäranalyse als Gegenprüfung	Lieferant, Version, wie sie bezogen wurde
Altprodukt ohne Pipeline	Das ausgelieferte Artefakt scannen; eine Pipeline planen	„Gescanntes Ergebnis“ und eine Ausnahme mit Enddatum

Gemischte CI: GitHub Actions, GitLab und Jenkins in einer Organisation

Die Policy ist bewusst CI-unabhängig: Sie definiert das Ergebnis, sodass eine GitLab- oder Jenkins-Pipeline sie mit einem Generator-Schritt erfüllen kann und eine GitHub-Actions-Pipeline die Aufzeichnung während des Builds nutzen kann. Regeln für einen Generator-Schritt:

• Führen Sie ihn im Release-Job nach dem Installationsschritt aus, nicht in einem separaten Job, der erneut installiert.
• Pinnen Sie die Version des Generators, und pinnen Sie CI-Actions auf einen Commit, nicht auf einen Tag. Warum das gerade bei Scannern wichtig ist, behandelt Open-Source-SBOM-Generatoren.
• Erfassen Sie den Erzeugungskontext als „nach der Installation, aus Dateien“, damit Leser wissen, was er gesehen hat.
• Validieren Sie das Ergebnis gegen dasselbe Schema wie jede andere Pipeline.

Open-Source-Generatoren wie Syft, Trivy und cdxgen können alle CycloneDX und SPDX schreiben, die Formatregel erzwingt also keine Tool-Wahl. Einen Vergleich finden Sie unter SBOM-Tools im Vergleich.

CRACI unterstützt heute GitHub Actions; GitLab CI und Jenkins stehen auf der Roadmap, ohne Datum. Die Folge für den Rollout: Beginnen Sie mit der Aufzeichnung während des Builds dort, wo GitHub Actions genutzt wird, behalten Sie Generator-Schritte anderswo bei, und verfolgen Sie beides im selben Coverage-Report.

Wenn ein Kunde eine bestimmte Formatversion verlangt

Ein Kunde verlangt CycloneDX 1.6, und Ihre Tools schreiben 1.7. Das passiert, weil sein Import-Tool oder seine eigene Policy auf eine Version festgelegt ist; die Untergrenze des BSI ist 1.6, daher nennen EU-Kunden sie oft. Ihre Optionen:

1. Fragen Sie, ob die neuere Version akzeptiert wird. Oft ist das der Fall.
2. Konvertieren Sie mit der CycloneDX CLI, validieren Sie dann gegen die Zielversion, und prüfen Sie, was verloren ging: Felder, die nur in der neueren Spezifikation existieren, werden entfernt.
3. Bei einer SPDX-Anfrage konvertiert dieselbe CLI von und nach SPDX JSON 2.3. Ihre Dokumentation warnt, dass die Konvertierung zwischen SPDX und CycloneDX „zum Verlust einiger Informationen führen kann“.

cyclonedx convert --input-file bom.cdx.json --input-format json \
  --output-file bom-1.6.cdx.json --output-format json --output-version v1_6

cyclonedx validate --input-file bom-1.6.cdx.json --input-format json \
  --input-version v1_6 --fail-on-errors

Der Validator prüft gegen CycloneDX 1.7, sofern Sie nicht --input-version übergeben. Regel der Policy: Behalten Sie die ursprüngliche SBOM als maßgeblichen Datensatz. Eine konvertierte Kopie ist eine abgeleitete Lieferung; speichern Sie die Ableitung (Tool, Version, Datum) mit ihr. Mehr zur Beantwortung solcher Anfragen unter SBOM-Anfragen von Kunden, und zu den beiden Formaten unter CycloneDX vs. SPDX.

Lizenzdaten für die Rechtsabteilung

Dieselbe SBOM kann der Rechtsabteilung dienen, wenn die Policy die richtigen Felder verlangt. Die Rechtsabteilung braucht die Lizenz jeder Komponente, den Unterschied zwischen einer deklarierten Lizenz (was das Paket angibt) und einer festgestellten (was jemand geprüft hat), Copyleft-Pflichten und eine Liste der Komponenten ohne Lizenz. CycloneDX 1.6 kennzeichnet Lizenzen als deklariert oder festgestellt, und SPDX hat für beides eigene Felder.

• Verlangen Sie SPDX-Lizenzbezeichner oder -ausdrücke, etwa MIT oder Apache-2.0 OR MIT.
• Markieren Sie NOASSERTION und fehlende Lizenzen zur Prüfung. In SPDX bedeutet NOASSERTION, dass keine Feststellung getroffen oder keine Information angegeben wurde; es ist keine Lizenz.
• Leiten Sie Copyleft-Lizenzen vor dem Release an die Rechtsabteilung weiter, nicht danach.

Eine SBOM enthält deklarierte Lizenzen. Eine Prüfung der Lizenz-Compliance mit festgestellten Lizenzen, Hinweisen und Pflichten ist Aufgabe der Rechtsabteilung oder eines spezialisierten Tools; siehe Open-Source-Lizenz-Compliance.

Schrittweise Einführung, Team für Team

Phase	Verantwortlich	Abschlusskriterium	Typisches Hindernis
1. Bestandsaufnahme: Produkte, Pipelines, CI-Systeme und aktuelle Generatoren, eine Zeile pro Release-Pipeline	Product Security	Jedes ausgelieferte Produkt hat eine Zeile	Niemand weiß, welche Pipeline ein Release baut
2. Die Policy mit dem Ausnahmeregister veröffentlichen	Product Security	Policy freigegeben und veröffentlicht	Streit darüber, welches Tool vorgeschrieben wird (die Policy schreibt keines vor)
3. Pilot mit ein oder zwei Teams, die einen Grund haben: eine Kundenanfrage, eine Frist, ein Produkt, das das aktuelle Tool nicht bewältigt	Pilotteams	Pilot-Releases werden mit konformen SBOMs ausgeliefert	Teams ohne dringenden Grund stellen es zurück
4. Validierungs-Gates in den Pilot-Pipelines einführen	Pilotteams	Eine ungültige SBOM lässt das Release fehlschlagen	Angst, Releases zu blockieren; mit einer Warnung beginnen
5. Nach CI-System ausweiten; einen Scanner pro Team erst ablösen, wenn der Ersatz die Policy erfüllt	Produktteams	Abdeckungsziel pro CI-System erreicht	Pipelines, für die niemand verantwortlich ist
6. Abdeckung monatlich berichten	Product Security	Der Bericht geht jeden Monat an das Management	Kennzahlen werden von Hand berechnet

Die Inventartabelle aus Phase 1 sollte die letzte sein; den Abschied von Tabellenkalkulationen behandelt SBOM-Automatisierung. Ein Yocto-basiertes Produkt ist ein häufiger Pilot, weil Allzweck-Scanner damit Schwierigkeiten haben; siehe warum SBOM-Scanner Yocto-Builds übersehen.

Abdeckung messen

Die Kennzahlen, nach denen Management und Auditoren fragen, jeweils als Verhältnis definiert:

• Release-Abdeckung: mit einer policykonformen SBOM ausgelieferte Releases ÷ ausgelieferte Releases.
• Produktabdeckung: Produkte mit mindestens einer konformen SBOM im aktuellen Supportzeitraum ÷ Produkte im Support.
• Validierungs-Erfolgsquote: SBOMs, die die Validierung bestehen ÷ erzeugte SBOMs.
• Identifikator-Abdeckung: Komponenten mit einer Package URL (oder einer CPE) ÷ Komponenten.
• Lizenzabdeckung: Komponenten mit einer deklarierten Lizenz ÷ Komponenten.
• Vollständigkeit: SBOMs, deren Generator sie als vollständig ausweist ÷ SBOMs. Nur möglich, wo das Tool dies meldet.
• Zeit bis zur SBOM: Zeit vom Release bis zur verfügbaren SBOM.

Ein beispielhafter Monatsbericht (illustrative Zahlen):

Kennzahl	GitHub-Actions-Pipelines	GitLab- und Jenkins-Pipelines	Alle
Release-Abdeckung	46 / 48	19 / 27	65 / 75
Validierungs-Erfolgsquote	100%	92%	97%
Identifikator-Abdeckung	99%	88%	95%
Offene Ausnahmen	1	4	5

Als Nachweis gegenüber einer Behörde oder einem Auditor besteht das Paket aus der Policy, dem Ausnahmeregister, dem Coverage-Report und einigen Beispiel-SBOMs. Es zeigt einen Prozess, angewendet und gemessen. Für die CRA-Seite siehe den CRA-Leitfaden.

Wo CRACI passt

Für GitHub-Actions-Pipelines ist CRACI der Runner: Sie setzen runs-on: craci, und jeder Job erhält eine aufgezeichnete SBOM ohne Generator-Schritt. Jede SBOM enthält einen Vollständigkeitsstatus, die transitiven Abhängigkeiten, eine Package URL pro Paket und die deklarierte Lizenz jeder Komponente, und sie lässt sich als CycloneDX oder SPDX exportieren. Lizenz-Policy-Regeln können einen Build blockieren, überwachte SBOMs werden fortlaufend neu bewertet, und die Build-Historie zeigt, welche Builds eine verwundbare Abhängigkeit enthielten. Damit erfüllen diese Teams die Zeilen „im Release-Build erzeugt“, „Identifikator“ und „Lizenz“ der Policy standardmäßig. SBOMs von Drittanbietern lassen sich hinzufügen, sodass zugekaufte Komponenten zusammen mit Ihren Builds überwacht werden.

Siehe SBOM-Generierung mit CRACI und SBOMs in GitHub Actions.

Wann CRACI nicht die Antwort ist

• Teams auf GitLab CI oder Jenkins: heute nicht, es steht auf der Roadmap. Nutzen Sie einen Generator-Schritt, der die Policy erfüllt.
• GitHub Enterprise Server: wird heute nicht unterstützt.
• Infrastruktur- und Host-Scanning, also was auf Servern installiert ist und Fehlkonfigurationen: eine andere Aufgabe; behalten Sie diese Tools.
• Binär- oder Firmware-Analyse von Lieferanten-Images, die Sie nicht selbst bauen: CRACI zeichnet Builds auf und scannt keine Binärdateien.
• Lange Aufbewahrung: CRACI speichert Build-Daten standardmäßig 180 Tage, mit individueller Aufbewahrung im Enterprise-Plan. Wenn Ihre Policy SBOMs länger benötigt, exportieren Sie sie in Ihren eigenen Speicher.

SBOM-Generierung über Teams hinweg: häufig gestellte Fragen

Wie standardisieren wir die SBOM-Generierung über Teams hinweg, die unterschiedliche Tools nutzen?

Standardisieren Sie das Ergebnis, nicht das Tool. Schreiben Sie eine Policy, die Format und Version, Mindestfelder, den Zeitpunkt der Erzeugung, den Speicherort, die Aufbewahrungsdauer und die Verantwortung für die Validierung festlegt. Lassen Sie jede Pipeline sie mit dem besten Generator erfüllen, den sie ausführen kann, und messen Sie die Abdeckung an der Policy.

Was sollte eine SBOM-Policy enthalten?

Geltungsbereich, Format und Mindestversion, Mindestfelder (Package URL, Lieferant, Version, deklarierte Lizenz, Abhängigkeiten, Tool, Zeitstempel, Erzeugungskontext), Erzeugung im Release-Build, volle transitive Tiefe, Speicherung beim Release, Aufbewahrung, Validierung in der Pipeline, Verantwortung und ein Register befristeter Ausnahmen.

Sollte jedes Team seinen eigenen Scanner betreiben, oder sollten SBOMs aus dem Build kommen?

Aus dem Build, wo es möglich ist. Eine Build-Time-SBOM beschreibt den Build, der ausgeliefert wurde, und gibt jedem Team auf dieser Pipeline SBOMs derselben Form. Behalten Sie Scanner für das, was Sie nicht selbst gebaut haben: Images von Drittanbietern, Binärdateien von Lieferanten und Altprodukte ohne Pipeline.

Ein Kunde möchte unsere SBOM in einer älteren CycloneDX-Version. Was tun wir?

Fragen Sie zuerst, ob die neuere Version akzeptiert wird. Wenn nicht, konvertieren Sie eine Kopie mit der CycloneDX CLI (cyclonedx convert mit --output-version v1_6), validieren Sie sie gegen diese Version, und prüfen Sie, welche Felder entfernt wurden. Behalten Sie das Original als maßgeblichen Datensatz und speichern Sie, wie die Kopie abgeleitet wurde.

Wie bringen wir Lizenzdaten aus unseren SBOMs zur Rechtsabteilung?

Verlangen Sie in der Policy SPDX-Lizenzbezeichner oder -ausdrücke, markieren Sie NOASSERTION und fehlende Lizenzen zur Prüfung, und leiten Sie Copyleft-Lizenzen vor dem Release an die Rechtsabteilung weiter. Die SBOM enthält deklarierte Lizenzen; festgestellte Lizenzen, Hinweise und Pflichten erfordern eine Lizenzprüfung.

Wie messen wir die SBOM-Abdeckung über Produkte hinweg?

Als Verhältnisse: mit einer konformen SBOM ausgelieferte Releases, Produkte im Support mit einer konformen SBOM, Validierungs-Erfolgsquote, Komponenten mit einer Package URL, Komponenten mit einer deklarierten Lizenz, vollständige SBOMs, wo das Tool dies meldet, und die Zeit vom Release bis zur SBOM. Berichten Sie sie monatlich nach CI-System.

Welche Nachweise brauchen wir, um einem Auditor zu zeigen, dass die SBOM-Generierung konsistent ist?

Die Policy, das Ausnahmeregister, den monatlichen Coverage-Report und einige Beispiel-SBOMs mit ihrem Erzeugungskontext. Zusammen zeigen sie einen Prozess, angewendet auf jedes Release und gemessen, und genau das prüft ein Auditor oder ein Kunde.