Die Software Bill of Materials (SBOM) hat sich schneller vom optionalen Artefakt zur vertraglichen Pflicht entwickelt, als die meisten Verteidigungsauftragnehmer erwartet hatten. 2021 war sie eine Empfehlung, vergraben in der Executive Order 14028. 2026 ist sie eine Gate-Bedingung — jedes an einen U.S.- oder NATO-Kunden ausgelieferte Binärartefakt muss eine aktuelle, signierte, maschinenlesbare SBOM beigelegt haben, und die Pipeline, die das Binärartefakt produziert hat, muss zur Audit-Zeit nachweisen können, dass die SBOM aus denselben Quellen, im selben Build erzeugt wurde, der das Artefakt erzeugt hat. Dieser Artikel geht die Engineering-Entscheidungen durch, die bestimmen, ob Ihre CI/CD-Pipeline dieses Audit übersteht.

1. Warum SBOM zur Pflicht in der Verteidigung wurde

Vier regulatorische Stränge sind zusammengeflossen. Executive Order 14028 (Mai 2021) verlangte von Bundessoftwarelieferanten die Bereitstellung von SBOMs und legte das Fundament für die NTIA-„Minimum Elements". NDAA Section 1655 (FY2023, durch FY2026-Ergänzungen verfeinert) dehnte SBOM-Anforderungen auf Verteidigungsbeschaffungen aus und schrieb DoD-Hauptauftragnehmern und Unterauftragnehmern vor, für jede an das Department gelieferte Software SBOMs vorzulegen, mit spezifischen Bestimmungen zu Komponenten chinesischer Herkunft und Lieferanten aus gegnerischen Nationen. NIS2 übte parallelen Druck auf die EU-Verteidigungsbasis aus und verlangte dokumentiertes Lieferkettenrisikomanagement für wesentliche und wichtige Einheiten. NIST SP 800-218 — das Secure Software Development Framework (SSDF) — kodifizierte SBOM-Erzeugung als erwartete Praxis für jeden Anbieter, der nach OMB M-22-18 und M-23-16 selbst-attestiert.

Die praktische Auswirkung ist, dass ein Verteidigungs-Softwareanbieter ohne SBOM-Tooling in 2026 kein wettbewerbsfähiger Anbieter ist. Ausschreibungen enthalten SBOM-Klauseln. Audits umfassen SBOM-Prüfungen. Und eine fehlende SBOM wird genauso behandelt wie ein fehlender Testbericht — als Beweis dafür, dass der Engineering-Prozess des Lieferanten unvollständig ist. Die gute Nachricht für Engineering-Teams ist, dass SBOM-Erzeugung, einmal korrekt instrumentiert, billig zu warten ist. Die schlechte Nachricht ist, dass „korrekt instrumentiert" eine lange Liste architektonischer Entscheidungen verbirgt, von denen die meisten beim ersten Mal falsch getroffen werden.

2. CycloneDX vs. SPDX

Zwei SBOM-Formate sind relevant: CycloneDX (ursprünglich bei OWASP, jetzt ein Ecma-Standard) und SPDX (ursprünglich bei der Linux Foundation, ISO/IEC 5962:2021). Sie decken denselben konzeptionellen Boden ab — Komponenten, Versionen, Lizenzen, Hashes, Beziehungen — aber die Dialekte divergieren in Punkten, die für Tooling relevant sind.

CycloneDX ist für Sicherheitsanwendungsfälle optimiert: native VEX-Unterstützung, erstklassige Schwachstellenfelder, leichtgewichtiges JSON, enge Integration mit dem OWASP-Ökosystem (Dependency-Track, dependency-check). Es ist das Format, das die meisten Sicherheitsteams standardmäßig produzieren. SPDX ist für Lizenz- und Provenance-Anwendungsfälle optimiert: reichere Lizenzausdruckssprache, längere Tradition in Open-Source-Compliance-Audits, der ISO-Stempel, den Rechts- und Beschaffungsteams in regulierten Branchen verlangen.

Verteidigungskunden verlangen beide. NDAA-konforme Verträge spezifizieren zunehmend „SPDX 2.3 oder neuer, oder CycloneDX 1.5 oder neuer" und überlassen die Formatauswahl dem Lieferanten — bis das Downstream-Tooling des Kunden eines davon erzwingt. Das pragmatische Muster ist Dual-Emit: eine CycloneDX-SBOM im Build für internes Schwachstellen-Tooling erzeugen, dann zur Auslieferung in SPDX umwandeln über einen Konverter (das Open-Source-cyclonedx-py, cdx2spdx oder die SPDX-Toolchain). Behandeln Sie eines als Source-of-Truth und das andere als abgeleitetes Artefakt; halten Sie beide versioniert neben dem Binärartefakt.

3. Build-Zeit- vs. Post-Build-SBOM-Erzeugung

Der größte einzelne Determinant für die SBOM-Glaubwürdigkeit ist der Zeitpunkt in der Pipeline, an dem die SBOM erzeugt wird. Es gibt zwei Lager. Post-Build-Scanner (Trivy, Snyk, GitHub native Dependency-Graph im Scan-Modus) konsumieren ein fertiges Container-Image oder Binärartefakt und reverse-engineeren dessen Komponenten. Build-Zeit-Generatoren (Syft, wenn in den Build eingebunden, cdxgen, sprachspezifische Tools wie cargo cyclonedx, mvn cyclonedx, npm sbom) beobachten den tatsächlichen Build-Prozess und emittieren die SBOM aus dem aufgelösten Abhängigkeitsgraphen, den der Build verwendet hat.

Nur Build-Zeit-Erzeugung ist beim Audit glaubwürdig. Der Grund ist einfach: ein Post-Build-Scanner identifiziert, was er sehen kann — er kann nicht zwischen einer Bibliothek unterscheiden, die statisch in das Binärartefakt gelinkt wurde, und einer Bibliothek, die für ein Build-Tool gezogen wurde, aber nie ausgeliefert wurde. Er kann private Registries nicht sehen, für die der Scanner keine Anmeldedaten hat. Er kann Compile-Zeit-Codegenerierung nicht sehen. Ein Reviewer, der fragt: „Woher wissen Sie, dass diese SBOM vollständig ist?", bekommt nur dann eine handlungsfähige Antwort, wenn die SBOM vom Build selbst erzeugt wurde, mit Provenance bis zu den Lockfiles zurück. Post-Build-Scanning ist eine nützliche zweite Meinung. Es ist nicht das primäre Artefakt.

In der Praxis konvergieren Teams auf einem Stack aus Syft für OS- und Container-Schichten, sprachnativen Generatoren (cargo, npm, pip, mvn, go-licenses mit CycloneDX-Ausgabe) für Quellkomponenten, cdxgen, wenn polyglotte Repos einen einzigen Durchlauf benötigen, und Trivy oder GitHubs native SBOM-Export als Post-Build-Gegenprüfung. Die Build-Pipeline merged die sprachnativen Ausgaben in ein einzelnes CycloneDX-Dokument, signiert es und hängt es an das ausgelieferte Artefakt.

4. SBOM-Signierung und Attestation

Eine unsignierte SBOM ist kein Beweis. Ein Reviewer kann nicht verifizieren, dass sie von dem Build erzeugt wurde, der das Binärartefakt erzeugt hat; er kann nicht verifizieren, dass sie nicht editiert wurde; er kann nicht beweisen, dass die Build-Umgebung vertrauenswürdig war. Die Lösung ist Attestation — eine vom Build-System produzierte signierte Aussage, die die SBOM an einen spezifischen Artefakt-Hash bindet.

Die dominanten Primitive sind sigstore/cosign für schlüssellose Signierung (OIDC-gebundene Zertifikate, Transparenz-Log in Rekor) und in-toto-Attestationen für das Aussageformat. Eine in-toto-Attestation hat drei Teile: das Subjekt (der attestierte Artefakt-Hash), den Predikat-Typ (z. B. https://cyclonedx.org/bom oder den SLSA-Provenance-Typ) und den Predikat-Körper (die SBOM selbst oder die Build-Provenance). Cosign signiert die Attestation, hängt sie als OCI-Artefakt neben dem Container-Image an und schiebt die Signatur in das Rekor-Transparenz-Log.

Das SLSA-Framework (Supply-chain Levels for Software Artifacts) ist das Reifemodell, auf das Verteidigungskunden verweisen, wenn sie eine einzelne Zahl als Anker für ihre Anforderungen wollen. SLSA 1 bedeutet, Provenance existiert. SLSA 2 bedeutet, sie ist signiert und der Build-Dienst ist gehostet. SLSA 3 bedeutet, der Build ist isoliert und die Provenance ist vom Projekt selbst nicht fälschbar. SLSA 4 bedeutet zweiseitige Überprüfung und hermetische, reproduzierbare Builds. Die meisten Verteidigungsverträge in 2026 verlangen SLSA 3 als Untergrenze für Software, die in operative Umgebungen geliefert wird; SLSA 2 ist akzeptabel für nicht-deployte Tools. SLSA 4 bleibt außerhalb der höchsten Klassifizierungs-Workloads selten.

5. Schwachstellen-Korrelationsschicht

Eine SBOM ist eine Liste von Komponenten; sie ist für sich genommen kein Schwachstellenbericht. Die Korrelationsschicht verbindet die SBOM mit Schwachstellendatenbanken (NVD, OSV, GitHub Advisory Database), um eine artefaktspezifische Schwachstellenliste zu erzeugen. Hier entdecken die meisten Teams, dass 80 % der in ihrer SBOM gemeldeten Schwachstellen in ihrem Kontext nicht ausnutzbar sind — die anfällige Funktion wird nie aufgerufen, die betroffene Konfiguration nie aktiviert oder der Pfad ist von keiner externen Oberfläche aus erreichbar.

Der standardisierte Weg, dies zu kommunizieren, ist VEX (Vulnerability Exploitability eXchange). Eine VEX-Aussage erklärt für eine spezifische CVE gegen eine spezifische Produktversion einen von vier Statuswerten: not_affected, affected, fixed oder under_investigation, mit einer Begründung (z. B. vulnerable_code_not_in_execute_path). CycloneDX unterstützt VEX nativ; SPDX unterstützt es über das Begleitformat CSAF (Common Security Advisory Framework). Ein Verteidigungskunde, der Ihre SBOM überprüft, erwartet VEX-Aussagen, die die offenen CVEs erklären — nicht Schweigen.

Der operative Workflow sieht so aus: SBOM im Build erzeugt → Schwachstellenscan gegen OSV/NVD → Triage in einem Tool wie Dependency-Track → Ingenieur reicht VEX-Aussage mit Begründung ein → VEX als signierte in-toto-Attestation neben der SBOM angehängt. Der Auditor des Kunden sieht eine kohärente Story für jede CVE.

Kernaussage: Eine Verteidigungs-Pipeline, die SBOMs ohne VEX-Aussagen ausliefert, ertränkt den Kunden im Rauschen. Innerhalb von sechs Monaten hört der Kunde auf, SBOMs zu lesen, weil er Signal nicht von Hintergrund unterscheiden kann. Der Lieferant, der SBOM + VEX ausliefert, bekommt die Akkreditierung; der Lieferant, der allein SBOM ausliefert, bekommt eine Behebungsanforderung für jedes „high" CVE in einem transitiven Go-Modul. Triagieren Sie Ihre eigenen Schwachstellen — Ihre DevSecOps- und Zero-Trust-Haltung wird daran gemessen, wie gut Sie korrelieren, nicht wie viele CVEs Sie aufwerfen.

6. CI-Gate-Logik

SBOMs und VEX-Aussagen erzwingen Lieferketten-Hygiene nur, wenn die Pipeline darauf blockiert. Das Gate sitzt zwischen „Build erfolgreich" und „Release-Artefakt promoted". Moderne Teams schreiben das Gate als Policy in Rego (Open Policy Agent) oder Kyverno, evaluiert gegen die SBOM- und VEX-Eingaben.

Eine funktionierende Policy erzwingt vier Regeln. Erstens: keine kritischen CVEs ohne VEX-Begründung. Zweitens: keine Komponenten aus einer Denylist von Lizenzfamilien (AGPL in proprietären Lieferleistungen, alles mit einer U.S.-exportkontrollierten Ursprungsklausel). Drittens: keine Komponenten aus Registries sanktionierter Nationen (hier lebt NDAA 1655 — Pakete chinesischer Herkunft automatisch markiert). Viertens: die SBOM muss signiert sein, die Build-Provenance muss SLSA 3 oder höher beanspruchen, und der Rekor-Transparenz-Log-Eintrag muss existieren.

Verzicht (Waivers) sind der Ort, an dem die meisten Policies in der Praxis scheitern. Eine pauschale „Ignoriere diese CVE für immer"-Übersteuerung ist das Audit-Fehlermuster. Das Muster, das ein Audit übersteht, ist Verzicht mit Begründung und Ablauf: die Verzichtsdatei lebt im Repo, wird in einem Pull Request überprüft, nennt die CVE und das Artefakt, enthält eine schriftliche Begründung (dieselben VEX-Begründungsfelder) und hat ein Ablaufdatum. Die Pipeline akzeptiert den Verzicht nur, solange er nicht abgelaufen ist. Auditoren lieben dieses Muster, weil es eine schriftliche Spur von Risikoentscheidungen produziert; Ingenieure tolerieren es, weil es endliche Arbeit ist.

7. Kundenauslieferung

Die SBOM ist nicht nur ein Build-Artefakt — sie ist eine vertragliche Lieferleistung. Verteidigungsverträge in 2026 enthalten routinemäßig Klauseln zu SBOM-Format, Signierung, Liefermechanismus und Update-Kadenz. Die Formatverhandlung passiert typischerweise beim Vertragsentwurf: der Lieferant schlägt CycloneDX 1.5 JSON vor, der Kunde kontert mit SPDX 2.3, weil sein Downstream-Tool es verlangt, und der Lieferant verpflichtet sich zu Dual-Emit. Die Auslieferung erfolgt meist über eine kundenkontrollierte Registry oder ein Portal — niemals per E-Mail-Anhang, was die Informationssicherheits-Policy des Kunden verbietet.

Die wiederkehrende Update-Verpflichtung ist die Klausel, die die meisten Lieferanten unterschätzen. NDAA-konforme Verträge verlangen typischerweise eine aktualisierte SBOM mit jedem Patch-Release, jedem vierteljährlichen Maintenance-Drop und innerhalb von 72 Stunden nach jeder im Scope befindlichen CVE-Offenlegung. Wenn Ihr Release-Prozess eine Woche dauert, können Sie keinen 72-Stunden-Takt einhalten. Die Lösung ist, die SBOM-Emission auf jedes Release automatisch zu machen, einschließlich Patch-Releases, damit die SBOM immer mit dem Binärartefakt aktuell ist, das der Kunde betreibt. Lieferanten, die versuchen, SBOMs nach dem Release manuell zu regenerieren, erklären am Ende Akkreditierungs-Reviewern Lücken — siehe auch wie Sicherheitsfreigabe- und Personalbeschränkungen beeinflussen, was Ihr Team ausliefern kann.

8. Audit-Überleben

Der Akkreditierungs-Reviewer trifft ein. Er stellt drei Fragen. Zeigen Sie mir die SBOM für Version 2.4.1, die wir in Produktion betreiben. Ihre Registry liefert das signierte CycloneDX-Dokument mit einer in-toto-Attestation, die auf den Binär-Hash zeigt, den der Kunde installiert hat. Zeigen Sie mir die VEX-Aussagen für jedes „high"-CVE in dieser SBOM. Ihre Registry liefert das VEX-Bundle mit Begründungen und Datumsangaben. Zeigen Sie mir, wie Sie heute wissen würden, ob eine neue CVE gegen eine Komponente in dieser SBOM offengelegt wurde. Sie zeigen ihm den kontinuierlichen Scan, der gegen den SBOM-Korpus läuft, und das SLA zur Kundenbenachrichtigung.

Die Pipeline, die diese drei Fragen sauber beantwortet, ist die Pipeline, die überlebt. Die Pipeline, die das nicht kann — weil die SBOM nachträglich erzeugt wurde, oder die VEX-Aussagen in einer Tabelle leben, oder niemand CVE-Offenlegungen gegen released SBOMs verfolgt — ist die Pipeline, die den Vertrag bei Verlängerung verliert. Die Investition ist endlich; die Konsequenz, sie nicht zu tätigen, ist es nicht. Für das breitere Lieferkettenbild siehe unsere Übersicht zu SBOM in Verteidigungssoftware, den vollständigen Leitfaden zur Verteidigungs-Cybersicherheit und den DevSecOps + Zero-Trust-Deep-Dive, der eine Schicht über dieser Pipeline-Arbeit liegt.