Sicherheit und Compliance auf Codeebene – Was Sie über die Software-Bill-of-Materials (SBOM) wissen müssen
Autorin/Redakteur: Nicole Segerer, SVP and General Manager bei Revenera/gg
Wer seine Software schützen will, muss wissen, was in ihr steckt. Tatsächlich haben Softwareanbieter jedoch oft wenig Einblick in die Nutzung von Open Source Software-Komponenten (OSS) und Drittanbieter-Code in ihren Anwendungen. Sicherheits- und Compliance-Risiken sind da vorprogrammiert. Die Software-Bill-of-Materials (SBOM) soll das ändern.
Die Software-Stückliste gilt als Kernelement von Compliance- und Sicherheitsprogrammen rund um Open Source. Die detaillierte Auflistung aller in einer Software eingesetzten Code-Komponenten einschließlich Lizenzierung, Versionen und Herkunft soll Anbietern wie Käufern gleichermaßen helfen, den Überblick zu bewahren und die Software Supply Chain sicherer zu machen. Die formale und klar strukturierte SBOM gibt dabei nicht nur Aufschluss über die jeweiligen Codebasen. Auch die Beziehungen innerhalb der Softwarelieferkette werden offengelegt. Aufgeführt finden sich Pakete und Abhängigkeiten, Binärdateien ohne Manifest-Dateien, Multimedia-Dateien, Bilder/Icons, Codecs und Copy/Paste-Codes sowie die von den Entwicklern genutzten Source Libraries und Drittanbieter-Bibliotheken.
Code-Verzeichnis für mehr Sicherheit und Compliance
Die Inventarliste hilft, zwei Fliegen mit einer Klappe zu schlagen: Zum einen lässt sich anhand der SBOM genau einsehen, wo und wie der betroffene Code in die Software-Supply-Chain gelangt ist, welche Lizenzierung für die jeweiligen Komponenten vorliegen und wo die Verwendung eventuell zu Compliance-Problemen führen kann. Zum andern können Sicherheitsteam schneller überprüfen, ob eine Anwendung von neu veröffentlichten Sicherheitslücken und Exploits betroffen ist. Log4j bleibt hier ein abschreckendes Beispiel: Die Bedrohung durch die kritische Sicherheitslücke wurde zum Teil dadurch verschärft, dass viele Unternehmen nicht einmal wussten, ob sie betroffen waren.
Beide Use Cases der SBOM sind dringend notwendig. Nach einem Report von Revenera hat sich die Zahl der Sicherheitslücken auf Codeebene mehr als verdreifacht. Die Analysten identifizierten pro Audit durchschnittlich 282 Schwachstellen, ein Anstieg von 217 Prozent (2021: 89). Von den aufgedeckten Schwachstellen stellten 27 Prozent ein „hohes“ CVSS-Risiko dar (Common Vulnerability Scoring System) und damit eine unmittelbare Bedrohung für IT-Sicherheit und Cyberschutz. Wenig besser sieht es bei den in Audits aufgespürten Compliance-Verstößen aus. Hier wuchs die Zahl der als kritisch eingestuften Risiken mit 9.500 um 6 Prozent (2021: 9.000), während Vorfälle der Prioritätsstufe 2 (zum Beispiel sekundäre Probleme mit kommerziellen Lizenzen) sogar um ganze 50 Prozent zulegten.
Was gehört in eine SBOM?
Welche Informationen in welchem Umfang in einer SBOM aufgelistet hängt von der Anwendung selbst und von Faktoren wie Branche (zum Beispiel KRITIS), der Open Source Governance-Strategie des Anbieters sowie den Kundenanforderungen ab. Beim Erstellen einer SBOM empfiehlt es sich, zunächst mit einem Basissatz an Daten zu beginnen, um so schnell zentrale Informationen mit anderen Stakeholdern (beispielsweise IT Sicherheit) teilen zu können. Im weiteren Verlauf wird die Liste dann kontinuierlich mit weiteren Daten angereichert und ausgebaut.
Im Allgemeinen enthält die Stückliste Details zu Softwarekomponenten und -versionen, den Namen des Verfassers sowie des Anbieters/Herstellers, Schwachstellen, Lizenzen, Bekanntmachungen von Dritten, Nutzungsdaten, Alerts und Meldungen sowie Aufgaben. Um die Komponenten eindeutig zuzuordnen und innerhalb der SBOM zu identifizieren, können Unternehmen zusätzlich sogenannte Unique Identifiers (UI) wie kryptografischen Hashes hinzufügen.
