Synopsys
Stücklisten für Software – ein Muss!
Software-Stücklisten bilden das Fundament für die Anwendungssicherheit bei Open-Source-Komponenten. Insbesondere für die Sicherheit von Software-Lieferketten spielen sie eine noch vielfach unterschätzte Rolle.
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 Dritt-anbieterkomponenten, Kommunikations-APIs und -Protokollen sowie Geschäftslogik. Sie alle stammen aus verschiedenen Quellen und werden in Build- und Release-Pipelines zusammengeführt.
Externer Code oft mangelhaft dokumentiert
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 Software-Stück- liste (Software Bill of Materials, kurz 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 optimiert werden sollte.
Eine solche Stückliste kann als Managementsystem fungieren, das Open- Source-Komponenten identifiziert, dokumentiert und deren Absicherung und Aktualisierung in die Pipeline integriert. Mit dabei sind auch Workflow- 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 Softwarekomponenten
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
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 nur dann sinnvoll stattfinden, wenn die im Netzwerk und der Software eingesetzten Komponenten eindeutig identifiziert sind. Das gleiche gilt für andere Sicherheitsmaßnahmen.
Lücken beseitigen
Software-Hersteller sollten für ihre Anwendungen eine Stückliste pflegen, um sämtliche darin enthaltenen Komponenten zu dokumentieren. Wichtig ist aber auch, einen Maßnahmenkatalog zu erstellen und zu planen, was passiert, wenn eine Lücke bekannt wird und in welchem Zeitraum der Entwickler die Lücke schließt. Ohne Maßnahmenplanung bleibt die SBOM nur ein Dokument.
Schwachstellen in Open-Source-Komponenten sind öffentlich zugänglich, so dass die Community schnell reagieren und die betreffenden Lücken schließen kann. Es liegt in der Natur der Sache, dass auch Angreifer Zugang zu diesen Schwachstellen haben und sie ausnutzen, um etwa eine Malware einzuschleusen. Software-Entwickler nutzen in den meisten Fällen ihre eigene SBOM. Sie dient ihnen intern dazu, Abhängigkeiten und Risiken zu dokumentieren und Gegenmaßnahmen abzuleiten. Wenn Unternehmen ihren Kunden die SBOM zur Verfügung stellen, sind diese besser gewappnet, eine lizenzierte Software so sicher wie nur möglich zu betreiben.
Käufer einer Software beschaffen sich wenn möglichst die SBOM eines Drittanbieters. Dadurch lassen sich die eingesetzten Komponenten inventarisieren und dokumentieren.
Auch Softwareentwickler, die externen Code verwenden, benötigen häufig noch die SBOM eines Drittanbieters. In der überwiegenden Zahl aller Fälle kommen in solchen Szenarien also mehrere SBOMs zum Einsatz. Das übergreifende Ziel beim Einsatz einer SBOM ist es, Sicherheitsabläufe zu automatisieren und Sicherheitslücken zu schließen. Dabei unterstützen verschiedene Vorgehensweisen, zum Beispiel intelligente Pipelines und AppSec-Tools.
Intelligente Pipelines
Alle Komponenten in einer Software-Lieferkette zuverlässig zu dokumentieren und das Schließen von Sicherheitslücken zu planen, erfordert intelligente Pipelines. Mit ihnen lässt sich die sehr zeitintensive Applikationssicherheit (AppSec) weitgehend automatisieren und intelligente Maßnahmen ergreifen. Dabei geht es nicht nur darum, die Lücken zu dokumentieren, sondern auch erfolgreich zu schließen.
AppSec-Tools in Softwareprojekten und Application-Security-Testing-Tools stellen gemeinsam mit entsprechenden Entwicklungs-Pipelines in DevOps-Umgebungen sicher, dass die gelieferten Anwendungen, inklusive aller Komponenten, maximal sicher sind und es auch bleiben. Eine Integration in CI/CD-Pipelines ist in dieser Hinsicht ein weiterer Bestandteil. Die verwendeten AppSec-Scanner laufen in der Pipeline ständig mit und untersuchen integrierte Komponenten.
Intelligente Pipelines, in denen die Sicherheit von Softwarekomponenten im Fokus steht, greifen deshalb umfassend auf AppSec-Tools zurück. Auf Basis der Daten, die ein Scanner an die Pipeline übermittelt, ist es möglich, automatisierte Maßnahmen zu ergreifen. Im Rahmen von DevSecOps ist es sinnvoll SBOM mit einem standardi- sierten Format wie SPDX (Software Package Data Exchange, entwickelt von der SPDX-Workgroup, einer Arbeitsgruppe der Linux Foundation) einzuführen. Dadurch lassen sich redundante Arbeiten verhindern, da verschiedene Komponenten an mehreren Stellen nutzbar sind. SPDX entwickelt sich derzeit zu einem beliebten Standard für den Umgang mit Open-Source-Anwendungen in Unternehmen. Nicht zuletzt deshalb, weil sich darüber Lizenzen, Copyright und die Kompatibilität von verschiedenen Komponenten gewährleisten lässt.
Das könnte Sie auch interessieren
iT Engineering Software Innovations
Condition Monitoring für die Produktion
Neue Vertriebswege im Maschinenbau
Software-Monetarisierung durch Abomodelle
Microsoft 365
Datenschützer will mit Wirtschaft über…
embedded world Conference 2023
Die Software-Themen der Konferenz
Verwandte Artikel
Synopsys
Mit Fokus: Nachhaltigkeit
Das E-Paper der Ausgabe 01/02
Synopsys SIG
Der laxe Umgang mit der Security
