SBOM für Verteidigungsbeschaffung: Transparenz in der Software-Lieferkette

Software Bill of Materials (SBOM) — ein formales Inventarisierungsdokument, das jede Komponente, Bibliothek und Abhängigkeit in einem Softwareprodukt aufführt — hat sich schnell von einer technischen DevOps-Praxis zu einer regulatorischen Anforderung für Verteidigungsbeschaffungen entwickelt. Die US-amerikanische Executive Order 14028 "Improving the Nation's Cybersecurity" (2021) schreibt vor, dass Softwarelieferanten, die an Bundesbehörden verkaufen, SBOMs bereitstellen müssen. Der EU Cyber Resilience Act (CRA), der 2024 in Kraft trat, führt verbindliche Sicherheits- und SBOM-Anforderungen für Produkte mit digitalen Elementen ein, die auf dem EU-Markt verkauft werden.

Für Verteidigungsauftragnehmer konvergieren beide regulatorischen Anforderungen: Verteidigungsprogramme sind kritische Systeme, die den strengsten Compliance-Regimen unterliegen, und SBOM wird zum Standard-Vertragsartefakt neben der System-Sicherheitsdokumentation und Testberichten. Im deutschen BMVg-Kontext wird Software-Lieferkettensicherheit zunehmend in ITC-Beschaffungsanforderungen einbezogen.

SBOM-Formate: SPDX und CycloneDX

SPDX (Software Package Data Exchange) ist ein ISO-Standard (ISO/IEC 5962:2021) für SBOM, entwickelt von der Linux Foundation Community. SPDX definiert ein Schema zur Beschreibung von Softwarepaketen, ihren Abhängigkeiten und Lizenzinformationen. SPDX-Dokumente können in mehreren Formaten ausgedrückt werden: Tag-Value (menschenlesbares Textformat), JSON, RDF und YAML.

CycloneDX ist ein OWASP-Standard für BOM-Spezifikationen (Bill of Materials), der mit direktem Fokus auf Sicherheitsanwendungen entwickelt wurde. CycloneDX unterstützt nicht nur SBOM, sondern auch HBOM (Hardware), MBOM (Machine Learning) und CBOM (Kryptografie) — was es für Verteidigungssysteme besonders relevant macht, wo Hardware- und Kryptografie-Transparenz wichtig ist. CycloneDX enthält die VEX-Erweiterung (Vulnerability Exploitability eXchange), die Lieferanten ermöglicht zu kommunizieren, ob spezifische bekannte Schwachstellen in ihrem Produkt tatsächlich ausnutzbar sind.

SBOM-Generierung: Syft und cdxgen

Syft von Anchore ist das führende Open-Source-Tool zur SBOM-Generierung. Es unterstützt eine breite Palette von Paket-Ökosystemen (Alpine, DEB, RPM, Maven, npm, PyPI, Go-Module, NuGet und andere) und kann Dateisystem-Verzeichnisse, Container-Images und OCI-Artefakte analysieren. Syft generiert SBOMs in SPDX- und CycloneDX-Formaten, was Flexibilität bei der Erfüllung verschiedener Auditor- und Kundenanforderungen bietet.

Für CI/CD-Pipelines kann Syft als Post-Build-Schritt integriert werden: Nach dem erfolgreichen Build eines Container-Images generiert Syft ein SBOM für dieses Image, das dann signiert (mit Cosign) und zusammen mit dem Image in der Container-Registry veröffentlicht wird.

cdxgen (CycloneDX Generator) ist ein alternativer Generator, der für CycloneDX optimiert ist, mit besonders starker Unterstützung für Java/Kotlin (Maven/Gradle), JavaScript/TypeScript (npm/yarn) und Python (pip/poetry) Projekte. cdxgen analysiert Paket-Manifest-Dateien und Lock-Dateien, um transitive Abhängigkeiten zu bestimmen — nicht nur direkte Abhängigkeiten, sondern Abhängigkeiten ihrer Abhängigkeiten über die gesamte Tiefe des Abhängigkeitsbaums.

VEX: Kommunikation über Ausnutzbarkeit von Schwachstellen

SBOM identifiziert Komponenten; SBOM in Kombination mit NVD oder anderen Schwachstellen-Datenbanken identifiziert, welche bekannten CVEs diese Komponenten betreffen. Aber das Vorhandensein eines CVE in einer Komponente bedeutet nicht automatisch, dass die eingesetzte Software anfällig ist: Der anfällige Code-Pfad könnte unerreichbar sein; die Minderungskonfiguration könnte die Schwachstelle nicht ausnutzbar machen; der Lieferant könnte bereits einen Fix integriert haben, ohne die Paketversion zu aktualisieren.

VEX (Vulnerability Exploitability eXchange) löst dieses Problem, indem es Lieferanten einen Mechanismus bietet, den Ausnutzbarkeits-Status von Schwachstellen in ihren spezifischen Produkten zu kommunizieren. Ein VEX-Dokument kann feststellen, dass ein spezifisches CVE: "Nicht betroffen" — anfällige Funktion ist nicht vorhanden oder nicht genutzt; "Betroffen" — die Schwachstelle ist tatsächlich ausnutzbar mit empfohlenen Maßnahmen; "In Bearbeitung" — der Lieferant hat die Schwachstelle bestätigt und plant einen Fix; "Behoben" — die Schwachstelle wurde mit Details zur spezifischen Version behoben.

SBOM-Anforderungen in der Verteidigungsbeschaffung

Für Auftragnehmer des BMVg, die Software an Verteidigungskunden in der EU und den USA verkaufen oder dies planen, wird SBOM-Compliance zur Vertragsanforderung. Praktische Anforderungen umfassen: Vorhandensein eines SBOM-Dokuments in einem maschinenlesbaren Standardformat (SPDX oder CycloneDX), das alle Abhängigkeiten einschließlich transitiver Abhängigkeiten abdeckt; das SBOM muss zur Integritätsverifizierung signiert werden; das SBOM muss mit jedem Release aktualisiert werden; Schwachstellen müssen mit entsprechenden VEX-Aussagen und Behebungszeitplänen offengelegt werden.

SBOM-Integration in das Schwachstellenmanagement

SBOM ist am wertvollsten in Kombination mit kontinuierlichem Schwachstellenmanagement. Der automatisierte Prozess sieht folgendermaßen aus: Wenn ein neues CVE veröffentlicht wird, wird das SBOM automatisch abgefragt, um festzustellen, ob das betroffene Paket ein eingesetztes Produkt betrifft; wenn ja, wird automatisch ein Schwachstellenmanagement-Incident eröffnet mit Nachweisen zu Produkt, Version und betroffenen Deployments; VEX-Aussagen werden aktualisiert, während die Untersuchung voranschreitet; Fix-Aufzeichnungen werden gegen das CVE im finalen VEX-Status dokumentiert.