Software Bill of Materials: Grundlage für mehr Cybersicherheit

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. [...]

Foto: PeteLinforth/Pixabay

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.

SBOMs: Sicherheitslücken planvoll 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öglich 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 im Sinne von mehr Software-Sicherheit

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.

DevSecOps – das Ziel von sicheren Software-Lieferketten

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 standardisierten Format wie SPDX (Software Package Data Exchange, entwickelt von der SPDX-Workgroup, einer Arbeitsgruppe der Linux Foundation) einzuführen.

Dadurch verhindert man redundante Arbeit, 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 man darüber Lizenzen, Copyright und die Kompatibilität von verschiedenen Komponenten gewährleisten kann.

Fazit

Software-Stücklisten bilden das Fundament für die Anwendungssicherheit bei Open Source-Komponenten. Entwickler sind der überwiegenden Zahl nach keine IT-Sicherheitsexperten und brauchen Unterstützung. SBOMs und intelligente Pipelines mit AppSec-Tools leisten einen nicht zu unterschätzenden Beitrag für die Sicherheit.

Schon allein, weil sich SBOMs längst nicht allein auf die Dokumentation beschränken. Sie erlauben es, geeignete Maßnahmen zu ergreifen, um Sicherheitslücken zu erkennen und zu beseitigen.

Automatisierung spielt dabei eine zentrale Rolle. Intelligente Pipelines wiederum sorgen in DevSecOps-Umgebungen dafür, dass entwickelte Anwendungen und die darin enthaltenen Komponenten immer maximal sicher und aktuell sind.

powered by www.it-daily.net


Mehr Artikel

News

Bad Bots werden immer menschenähnlicher

Bei Bad Bots handelt es sich um automatisierte Softwareprogramme, die für die Durchführung von Online-Aktivitäten im großen Maßstab entwickelt werden. Bad Bots sind für entsprechend schädliche Online-Aktivitäten konzipiert und können gegen viele verschiedene Ziele eingesetzt werden, darunter Websites, Server, APIs und andere Endpunkte. […]

Frauen berichten vielfach, dass ihre Schmerzen manchmal jahrelang nicht ernst genommen oder belächelt wurden. Künftig sollen Schmerzen gendersensibel in 3D visualisiert werden (c) mit KI generiert/DALL-E
News

Schmerzforschung und Gendermedizin

Im Projekt „Embodied Perceptions“ unter Leitung des AIT Center for Technology Experience wird das Thema Schmerzen ganzheitlich und gendersensibel betrachtet: Das Projektteam forscht zu Möglichkeiten, subjektives Schmerzempfinden über 3D-Avatare zu visualisieren. […]

Be the first to comment

Leave a Reply

Your email address will not be published.


*