SBOM (Software Bill of Materials)

Seit dem "SolarWinds"-Hack und "Log4Shell" fordern Regierungen (US Executive Order) eine SBOM. Tools erstellen sie automatisch beim Kompilieren: syft oder cyclonedx-cli. Format: JSON oder XML (Standards: CycloneDX oder SPDX). Du als Entwickler siehst sie selten, aber dein Sicherheits-Team braucht sie dringend.

1. Transitive Abhängigkeiten

Das Problem ist nicht dein Code. Das Problem ist, dass dein Code Bibliothek A nutzt. Bibliothek A nutzt Bibliothek B. Bibliothek B nutzt Bibliothek C (die von einem Hobby-Entwickler in Nebraska gepflegt wird). Eine gute SBOM zeigt den kompletten Baum bis ganz unten ("Deep Dependency Tree").

2. VEX (Vulnerability Exploitability Exchange)

Nur weil eine veraltete Lib in der SBOM steht, heißt das nicht, dass man hackbar ist. Vielleicht nutzt man die kaputte Funktion gar nicht. VEX ist ein Zusatz-Dokument zur SBOM: "Ja, wir haben Log4j, aber wir sind NICHT betroffen, weil wir Feature X deaktiviert haben." (False Positive Reduction).

1. Dependency Confusion & Supply Chain Integrity

Das größte Risiko, das eine SBOM aufdeckt, ist Dependency Confusion. Angreifer laden Pakete mit dem gleichen Namen wie interne Firmen-Bibliotheken (z. B. @mycorp/internal-ui) auf öffentliche Register wie npm hoch, aber mit einer höheren Versionsnummer. Ohne SBOM und striktes Pinning saugt die CI/CD-Pipeline das bösartige Paket von extern anstatt von intern. Eine moderne SBOM nutzt PURL (Package URL), um Komponenten eindeutig zu identifizieren, und kombiniert dies mit VDR (Vulnerability Disclosure Reports). So wird nicht nur gelistet, was drin ist, sondern auch der gerichtsfeste Beweis geliefert, dass die Pipeline nur verifizierte Quellen genutzt hat.

2. CycloneDX vs. SPDX: Der Standard-Krieg

Es gibt zwei dominierende Formate, die man kennen sollte:

• SPDX (Software Package Data Exchange): Ein ISO-Standard, der ursprünglich von der Linux Foundation für Lizenz-Compliance (Open Source Compliance) entwickelt wurde. Sehr detailliert, aber oft sperrig für automatisierte Security-Tools.
• CycloneDX: Von der OWASP-Community entwickelt. Es ist für Security und Supply-Chain-Analysen optimiert. Es ist schlanker, moderner und unterstützt nativ Konzepte wie SaaS-BOMs (S-BOM) und Hardware-BOMs (HBOM). In der modernen DevSecOps-Praxis gewinnt CycloneDX gerade massiv an Boden, da es sich leichter in JSON-basierten Web-Pipelines verarbeiten lässt.

3. VEX: Die Antwort auf "Vulnerability Fatigue"

Sicherheitsteams leiden unter zehntausenden Fehlalarmen. Eine SBOM zeigt eine Komponente mit einer bekannten Lücke (CVE). Der Entwickler weiß aber: "Wir nutzen die Funktion überhaupt nicht, der Code ist sicher." Hier kommt VEX (Vulnerability Exploitability Exchange) ins Spiel. Es ist ein maschinenlesbarer Begleitzettel zur SBOM. Darin deklariert der Hersteller offiziell: "CVE-2024-XXXX ist in unserem Produkt nicht ausnutzbar (Not Affected)." Tools können diesen VEX-Report einlesen und den Alarm automatisch unterdrücken, was die tägliche Arbeit der Security-Analysten massiv entspannt.