SBOM 2026:
Software Bill of Materials für KMU

Kurz vorweg: SBOM = maschinenlesbare „Stückliste" einer Software inkl. Open-Source-Abhängigkeiten und Versionen. CRA ab 11.12.2027 Pflicht für vernetzte Produkte (auch Schweizer Hersteller, die in die EU liefern). NIS2 ab Essential/Important Entity nutzbar als Lieferketten-Werkzeug. Formate: CycloneDX (Security-fokussiert), SPDX (Lizenz-fokussiert). VEX ergänzt für Ausnutzbarkeits-Statements. Tool-Empfehlung KMU: Syft + Dependency-Track + Sigstore Cosign. Aufwand realistisch: 6–12 Wochen für reifes Programm.

• CycloneDX (OWASP-Standard): security-fokussiert, schlankes Schema, JSON/XML/Protobuf. Eingebautes VEX-Format, ML-BOM-Erweiterung, SaaSBOM-Erweiterung. Standard in DevSecOps-Tools wie Dependency-Track, Snyk, Sonatype.
• SPDX (Linux Foundation, ISO/IEC 5962): lizenz-fokussiert, detaillierteres Schema, JSON/YAML/RDF/Tag-Value. Stark in Open-Source-Compliance-Audits. Bevorzugt von US-Behörden und manchen Enterprise-Kunden.
• CRA-Konformität: beide werden von ENISA/EU-Kommission als anerkannte Formate kommuniziert. Praktisch wählt man eines als Master, generiert das andere bei Bedarf.
• Tools für Konvertierung: cyclonedx-cli (CycloneDX), spdx-tools, syft (kann beide ausgeben).
• Praxis-Empfehlung KMU: CycloneDX als Default – leichter zu generieren, in Security-Tooling breiter integriert, ml-bom/vex eingebaut. SPDX nur bei expliziter Anforderung.
• Versionierung: SBOM pro Build, pro Release, idealerweise als versionierter Artefakt im Artefakt-Speicher (OCI Registry, Artifactory). Eindeutige IDs (serial number) zwingend.
• Format-Fehler vermeiden: CycloneDX 1.5+ und SPDX 2.3+ verwenden – ältere Versionen haben Lücken (z. B. fehlende PURL-Unterstützung).
• Signatur: SBOM-Datei selbst signieren (Sigstore Cosign, GPG) – verhindert Manipulation der „Stückliste".
• Distribution: SBOMs im Artefakt-Container mitliefern (OCI Reference Type), in Release-Notes verlinken, auf Kunden-Anfrage maschinenlesbar bereitstellen.
• Sprach-Stack-Unterstützung: CycloneDX und SPDX decken npm, PyPI, Maven, Gradle, NuGet, RubyGems, Go-Module, Cargo, Composer, OCI-Container.

• VEX (Vulnerability Exploitability eXchange) = maschinenlesbares Statement: ist eine CVE in einem konkreten Produkt ausnutzbar? Vier Status: not_affected, affected, fixed, under_investigation.
• Begründungen bei not_affected: component_not_present, vulnerable_code_not_present, vulnerable_code_cannot_be_controlled_by_adversary, vulnerable_code_not_in_execute_path, inline_mitigations_already_exist.
• Praktischer Effekt: Kunden sehen, dass Sie die CVE bewertet haben – Anrufe und RFP-Anhänge sinken massiv. False-Positives in Scan-Tools werden korrekt unterdrückt.
• CycloneDX VEX: eingebaut in CycloneDX 1.4+, gleiche Datei oder separater VEX-Artefakt. Sehr einfach zu erzeugen.
• OASIS CSAF VEX: alternativer Standard, weiter verbreitet im Vendor-Bereich (Cisco, Red Hat, Microsoft). Toolunterstützung via vex-tools, csaf-tools.
• OpenVEX: alternativer Standard, einfacheres Schema, fokussiert auf VEX-Aspekt (ohne SBOM-Kopplung).
• Workflow KMU: bei jedem Scan-Treffer mit niedriger Ausnutzbarkeit ein VEX-Statement schreiben, signieren, ausliefern. Wiederverwendung für Folge-Releases.
• Auditierung: Begründungen sollten technisch nachvollziehbar sein – „not_affected because we say so" reicht nicht. Code-Pfad-Analyse, Konfigurations-Belege.
• Distribution: VEX-Datei zusammen mit SBOM ausliefern (OCI Reference Type, GitHub Release, Security-Advisory-Seite).
• Trade-off: VEX braucht Aufwand pro CVE-Befund – nur lohnenswert, wenn Kunden/Behörden Fragen stellen oder Patch-Verschiebung legitimieren werden soll.

• Einmalige SBOM statt pro Build: SBOM altert mit jeder Library-Aktualisierung – nur automatisierte Erzeugung pro Build liefert Wahrheit.
• Transitive Abhängigkeiten ignoriert: 80% des Schadens kommt aus transitiven Abhängigkeiten – Tools müssen tief scannen, nicht nur top-level package.json.
• Container-Layer übersehen: Base-Image hat eigene OS-Pakete – Syft mit Container-Mode oder Trivy ergänzen, sonst halber Truth-Set.
• Build-Time vs Run-Time: gleiche Library kann verschiedene Versionen auflösen – SBOM aus Build-Manifest UND aus Run-Time-Container vergleichen.
• Keine Signatur: unsignierte SBOM ist manipulierbar – Cosign keyless ist Pflicht für CRA-relevante Releases.
• VEX-Statements ohne Begründung: „not_affected" ohne Code-Pfad-Analyse ist Audit-Risiko – Begründungen technisch belegen.
• Lizenz-Konflikte: GPL-3.0 in proprietären Produkten = Compliance-Vorfall. SBOM ermöglicht früh Erkennung, Policy in Pipeline durchsetzen.
• Closed-Source-Komponenten vergessen: kommerzielle Libraries gehören auch in SBOM (Telerik, DevExpress, Highcharts) – nicht nur OSS.
• Embedded-/Firmware-Komponenten ausgeklammert: bei IoT/Embedded auch Firmware-SBOMs (z. B. via Binwalk + Syft) – CRA gilt für Hardware mit Software.
• SBOM-Ausgabe an Kunde, aber keine Pflege im Haus: SBOM ist auch internes Werkzeug für Patch-Reaktion – wenn nur „für Kunden" gemacht, wird Wert nicht gehoben.