Thought Leadership
Software-Stücklisten (Software Bill of Materials, kurz SBOM) bilden ein wichtiges Fundament für die Sicherheit von Software-Lieferketten, aber auch für andere Bereiche der IT-Sicherheit im Unternehmen. Deshalb kann heute kein Unternehmen auf SBOMs verzichten.
Die meisten proprietären Anwendungen und viele Open Source-Programme enthalten nicht nur eigenen Quellcode, sondern oft auch weiteren, externen Code für bestimmte Funktionen. Moderne Softwareanwendungen sind eine komplexe Mischung aus proprietären, Open-Source- und Drittanbieterkomponenten, Kommunikations-APIs und -Protokollen sowie Geschäftslogik. Sie alle stammen aus verschiedenen Quellen und werden in Build- und Release-Pipelines zusammengeführt.
Externen Code dokumentieren, Maßnahmen ableiten
Dieser externe Code ist leider nicht immer dokumentiert. Gerade Open Source-Projekte bieten eine hohe Transparenz. Um diesen Vorteil für sich zu nutzen, ist es sinnvoll, wichtige Informationen der eingesetzten Open Source-Komponenten zu dokumentieren. Das trägt dazu bei, die Software-Lieferkette auf stabile Beine zu stellen.
Die IT-Sicherheit von Software-Lieferketten beschränkt sich aber nicht auf die Dokumentation der enthaltenen Komponenten. Eine SBOM hat eine Schlüsselfunktion innerhalb des Risikomanagementkonzepts für die gesamte Software-Lieferkette. SBOMs sind über die Dokumentation hinaus ein Prozess, der ständig abläuft und stetig optimiert werden sollte.
Eine SBOM kann als Management-System fungieren, das Open Source-Komponenten identifiziert, dokumentiert und deren Absicherung und Aktualisierung in die Pipeline integriert. Mit dabei sind auch Workflows- und Benachrichtigungsfunktionen. Einfach ausgedrückt, sorgt eine SBOM dafür, auf Basis der gewonnen Informationen zu den eingesetzten Software-Komponenten entsprechende Maßnahmen abzuleiten.
Sicherheitslücken in nicht dokumentierten Softwarekomponenten sind ein hohes Sicherheitsrisiko
Unternehmen, die eine Software aus unterschiedlichen Quellen und Komponenten nutzen, wissen nie genau, wo mögliche Sicherheitslücken liegen und welche das genau sind. Das Risiko ist immens. Eines der jüngsten Beispiele ist die Lücke in der Open Source-Java-Bibliothek Log4j. Immer noch wissen etliche Unternehmen nicht, dass sie diese Bibliothek in ihren Anwendungen einsetzen und können folglich nicht richtig reagieren.
Bei einer Software-Stückliste gibt es für jede Anwendung eine umfassende Liste von externen Komponenten inklusive der verschiedenen Versionen. So lässt sich jederzeit exakt nachverfolgen, wo Nacharbeiten, Aktualisierungen oder Verbesserungen anstehen. Das macht nicht nur die Anwendung sicherer, sondern auch das gesamte Netzwerk.
Software muss sicherer werden – SBOMs sind die Basis
Wenn Sicherheitslücken in Open Source-Bibliotheken auftauchen, ist in den meisten Fällen nicht einmal bekannt, wo überall diese spezifische Open Source-Bibliothek im Einsatz ist. Oft fehlt eine Liste der im Unternehmen eingesetzten Anwendungen, in den meisten Fällen auch eine der verwendeten Softwarekomponenten.
Ein zuverlässiges Sicherheitskonzept kann es aber nur geben, wenn eindeutig klar ist, welche Anwendungen und Anwendungskomponenten verwendet werden, inklusive der genutzten Version. Wenn dann Sicherheitslücken bekannt werden, ist es für die Verantwortlichen leichter, sofort zu reagieren. Das Installieren von Updates kann natürlich nur dann sinnvoll stattfinden, wenn die im Netzwerk und der Software eingesetzten Komponenten eindeutig identifiziert sind. Das gleiche gilt für andere Sicherheitsmaßnahmen.
