Mit dem Cyber Resilience Act (CRA) setzt die EU neue Maßstäbe für die Sicherheit digitaler Produkte – und damit auch für die Transparenz in der Softwareentwicklung. Eine der konkretesten Anforderungen: Hersteller müssen eine Software Bill of Materials (SBOM) bereitstellen.
Doch was genau ist eine SBOM? Warum ist sie so wichtig für den CRA? Welche Standards gibt es – und wie lässt sich das Thema in der Praxis handhaben? Dieser Beitrag gibt einen Überblick für Softwareentwickler, Produktverantwortliche und Sicherheitsverantwortliche.
Was ist eine SBOM?
Die Software Bill of Materials (SBOM) ist vergleichbar mit einer Zutatenliste – nur eben für Software. Sie dokumentiert:
- wichtige Komponenten (z. B. Frameworks, Pakete)
- Versionen und Herkunft
- Lizenzen und Hashes
- Abhängigkeiten (direkt & transitiv)
- ggf. bekannte Schwachstellen (CVE)
Eine SBOM ermöglicht es, die Herkunft und Zusammensetzung eines Produkts transparent und rückverfolgbar darzustellen – und wird damit zur Grundlage für Sicherheit, Wartbarkeit und Compliance.
Warum ist eine SBOM unter dem CRA Pflicht?
Der CRA verpflichtet Hersteller, eine technische Dokumentation bereitzustellen. Laut Anhang II muss diese auch eine SBOM enthalten – also eine vollständige Liste aller Softwarekomponenten im Produkt.
Ohne SBOM keine vollständige CRA-Konformität.
Welche SBOM-Standards haben sich etabliert?
- SPDX (Software Package Data Exchange) – weit verbreitet, vor allem im Open-Source-Umfeld
- CycloneDX – sicherheitsfokussiert, DevSecOps-freundlich, maschinenlesbar
- SWID – ISO/IEC-Standard zur Software-Identifikation
In der Praxis dominieren derzeit SPDX und CycloneDX, da sie sich gut in moderne Build-Prozesse integrieren lassen.
Wie wird eine SBOM erstellt?
Die manuelle Pflege ist möglich – aber in der Praxis kaum skalierbar. Besser ist die automatisierte Generierung mittels:
- Build-Tools & CI/CD-Integrationen (z. B. GitHub Actions, GitLab, Azure)
- Dependency Scanner (z. B. Trivy, Syft, OWASP DC, CycloneDX CLI)
- Paketmanager-Analyse (npm, pip, Maven usw.)
Erstellung automatisieren – Verwaltung strukturieren lautet die Devise.
Was muss eine SBOM enthalten?
- Name und Version der Komponente
- Lizenz & Herkunft
- Hash (für Integritätsprüfung)
- Verknüpfung zu Schwachstellen (z. B. CVE)
- Datum der Generierung
- Abhängigkeiten & Nutzungskontext
Wie hilft ein ISMS bei der Umsetzung?
SBOMs sind nicht nur Technik – sie sind auch Teil des organisatorischen Sicherheitsmanagements. Ein ISMS (z. B. nach ISO/IEC 27001) hilft bei:
- Assetmanagement & Verantwortungsklärung
- Risikobewertung einzelner Komponenten
- Änderungskontrolle & Dokumentationspflichten
- Integration in TARA, Lieferkette & Auditstruktur
Ein ISMS liefert den organisatorischen Rahmen für eine praxisfähige SBOM-Verwaltung.
Was bedeutet das für die Praxis?
Eine SBOM muss:
- pro Produkt/Version gepflegt werden
- aktuell gehalten & geprüft werden
- in der Produktakte revisionssicher hinterlegt sein
Viele Unternehmen setzen Tools zur Erstellung ein – aber die Verwaltung, Prüfung und Nachverfolgung bleibt eine Herausforderung. Genau hier hilft ein gut verankertes ISMS und eine strukturierte Softwarelösung.
Fazit
Der CRA macht SBOMs zur Pflicht – und ISO 27001 gibt die Prozesse dafür vor. Wer jetzt handelt, ist technisch und organisatorisch bestens aufgestellt – nicht nur für das Gesetz, sondern auch für Kundenerwartungen, Supply Chain Audits und interne Transparenz.
Jetzt Strukturen schaffen – später profitieren.
Unterstützung gesucht?
Wir unterstützen Unternehmen dabei, ihre Sicherheitsstruktur CRA-konform aufzustellen. Dazu gehört auch die – eingebettet in ein ISMS, verbunden mit Risikoanalysen und Maßnahmenplanung.
Kontaktieren Sie uns – wir helfen Ihnen, SBOMs nicht nur zu dokumentieren, sondern sicher zu managen.