Software-Stückliste (SBOM)

Eine Software-Stückliste (SBOM) ist eine strukturierte Bestandsaufnahme aller Komponenten, Bibliotheken, Abhängigkeiten und Module, aus denen ein Softwareprodukt besteht. Es listet jede Komponente mit Version, Lizenz, Lieferant und bekannten Schwachstellen auf. SBOMs gibt es in Standardformaten: CycloneDX (OWASP-Standard, bevorzugt für Cybersicherheit), SPDX (ISO/IEC 5962-Standard, bevorzugt für Lizenzkonformität) und SWID (ISO/IEC 19770-2). SBOMs sind im EU Cyber ​​Resilience Act (DORA) vorgeschrieben und werden zunehmend von Unternehmenskäufern für die Due-Diligence-Prüfung der Cybersicherheit in der Lieferkette gefordert.

Moderne Softwareprodukte bestehen hauptsächlich aus Open-Source- und Drittanbieterkomponenten – oft 80–90 % der Codebasis. Ohne ein SBOM wissen Unternehmen nicht, was in ihrer Software enthalten ist, was es unmöglich macht, Cybersicherheitsrisiken einzuschätzen, Lizenzverpflichtungen zu verwalten oder auf Offenlegungen von Schwachstellen zu reagieren. Der EU Cyber ​​Resilience Act (CRA) schreibt SBOMs für alle in der EU verkauften Produkte mit digitalen Elementen vor und verpflichtet Hersteller dazu, Komponentenbestände zu führen und Schwachstellen zu melden. DORA verlangt von Finanzunternehmen die Führung von IKT-Vermögensregistern, die Softwarekomponentenbestände enthalten. Unternehmenskäufer verlangen zunehmend SBOMs als Beschaffungsbedingung, was sie für den Marktzugang im B2B-Softwaremarkt unerlässlich macht.

CycloneDX SBOMs sind das von OWASP empfohlene Format für Cybersicherheits-Compliance – sie umfassen Komponenteninventare, Abhängigkeitsdiagramme, Schwachstellenreferenzen (durch Integration mit Schwachstellendatenbanken) und Daten zu Lieferkettenbeziehungen. SPDX SBOMs sind das ISO/IEC 5962-Standardformat, das sich auf Softwarepaket-Metadaten, Lizenzinformationen und Sicherheitsreferenzen konzentriert – bevorzugt für die Einhaltung von Open-Source-Lizenzen und Softwaretransparenz. Berichte zur Offenlegung von Sicherheitslücken verfolgen koordinierte Richtlinien zur Offenlegung von Sicherheitslücken, Bug-Bounty-Programme und Register bekannter Sicherheitslücken – gemäß Artikel 13 der CRA für Sicherheitsverpflichtungen der Hersteller erforderlich. Open-Source-Lizenzregister verfolgen Komponentenlizenzen (MIT, GPL, Apache usw.) und den Compliance-Status – wichtig für die Compliance bei der Softwareverteilung und die IP-Governance.

SBOM-Dateien im CycloneDX-, SPDX- oder CSV-Format werden auf Sustalium hochgeladen. Das System extrahiert Komponentenbestände, Abhängigkeitsbeziehungen, Lizenzinformationen und Schwachstellenreferenzen und ordnet sie den relevanten Compliance-Frameworks zu. Komponentendaten fließen in CRA-Konformitätsaufzeichnungen (Verpflichtungen zur Meldung von Schwachstellen gemäß Artikel 13), in DORA-IKT-Register (Anforderungen an den Bestand an Software-Assets) und in die Due-Diligence-Prüfung der Software-Lieferkette gemäß DSGVO ein. Lizenzinformationen unterstützen Open-Source-Compliance und IP-Governance-Assets. Schwachstellendaten steuern laufende Schwachstellenmanagementprozesse. SBOM-Daten werden mit Produkt-SKUs und Versionsmanagement verknüpft und ermöglichen so eine Compliance-Verfolgung auf Produktebene im gesamten Software-Portfolio.

Der EU Cyber ​​Resilience Act (CRA) ist der wichtigste Regulierungsfaktor – er verlangt von Herstellern von Produkten mit digitalen Elementen, SBOMs zu erstellen und zu pflegen, Schwachstellen zu melden und sicherzustellen, dass Komponenten frei von bekannten ausnutzbaren Schwachstellen sind. DORA (Digital Operational Resilience Act) verlangt von Finanzunternehmen die Führung umfassender IKT-Asset-Register, die auch Softwarekomponentenbestände enthalten. Artikel 32 der DSGVO erfordert angemessene Sicherheitsmaßnahmen für die Verarbeitung personenbezogener Daten – SBOMs helfen bei der Bewertung und Überprüfung der Sicherheit von Software, die personenbezogene Daten verarbeitet. Das EU-KI-Gesetz verlangt Softwarekomponenten-Assets für Hochrisiko-KI-Systeme. ISO 27001 Annex A Control A.8.8 erfordert das Management technischer Schwachstellen – SBOMs sind die Grundlage. Die US Executive Order 14028 schreibt SBOMs für alle an die US-Regierung verkaufte Software vor.