Software-Stückliste ist nicht gleich Software-Stückliste Die SBOM als Teil des Risikomanagements

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Eine Software-Stückliste, kurz SBOM, ist ein wichtiger Bestandteil des Risikomanagements innerhalb der Software-Lieferkette. Eine umfassende und Compliance-konforme SBOM zu erstellen und in übergreifende Risikomanagement-Prozesse einzubinden, ist alles andere als trivial.

Die Besorgnis über die geschäftlichen Auswirkungen von Angriffen auf die Software-Lieferkette ist groß. Aber auch Rechtsstreitigkeiten aufgrund von Software-Missbrauch haben die aktuelle Diskussion angeheizt und die Frage aufgeworfen, wie man die Risiken von Software-Sicherheitslücken und Lizenzverletzungen besser in den Griff bekommt.

Ein erster Schritt ist die Inventarisierung der kompletten Software, die ein Unternehmen einsetzt. Dazu gehört auch alles, was die Software enthält und zu einem potenziellen Risiko werden könnte.

Viele Firmen sind inzwischen dazu übergegangen von ihren Softwareherstellern eine Software Bill of Materials (SBOM) zu verlangen. In dieser Stückliste sind sämtliche Komponenten einer Softwareanwendung aufgelistet, ebenso wie die damit verbundenen Lizenz- und Copyright-Informationen sowie bekannte Sicherheitsprobleme für jede der betreffenden Komponenten.

Kunden- und Compliance-Vorgaben in verschiedenen Branchen

Die Forderung nach einer SBOM ist in der Automobilbranche, der Medizintechnik und auch in anderen Industriezweigen bereits fest etabliert. Bei anderen besteht Nachholbedarf. Die Softwarebeschaffer und Softwarehersteller in weiteren Branchen und Behörden lernen gerade erst, wie sie nach einer SBOM fragen, oder selbst auf eine Anfrage reagieren sollen.

Zusätzlich angetrieben wird das Interesse an SBOMs von Regierungs- und Gesetzesinitiativen. Darunter der EU Cyber Resilience Act, der ersten EU-weiten Rechtsvorschrift zur Cyberresilienz von Produkten mit digitalen Komponenten. Der EU CRA schlägt ausdrücklich vor, eine SBOM zu verwenden und anzufordern.

In den USA wird erwartet, dass unter dem Dach der Executive Order 14.028 von Softwarelieferanten, die an die US-Regierung verkaufen wollen, eine SBOM verlangt wird. Daneben sollen Firmen außerdem verpflichtet werden, solche Richtlinien für die Software-Lieferkette einzuhalten, die im Secure Software Development Framework (SSDF) des National Institute for Standards and Technology (NIST) veröffentlicht wurden.

Weitere Vorstöße gibt es im medizinischen Bereich. So verlangt die US Federal Drug Administration (FDA) eine SBOM bereits ab März 2023 bei allen neuen FDA-Anträgen für vernetzte medizinische Geräte. Ähnliche Anforderungen werden für kritische Infrastrukturen diskutiert. Im Klartext heißt das: Anbieter in den betreffenden Branchen müssen bis Ende diesen Jahres eine Software-Stückliste als Teil jeder Softwarelieferung bereitstellen.

Diejenigen, die sich gerade erst mit SBOMs und anderen Bereichen des Risikomanagements in der Software-Lieferkette vertraut machen, sollten einige zentrale Punkte berücksichtigen.

• Erstens: Jede SBOM-Anfrage muss in einem der beiden am weitesten verbreiteten Standardaustauschformate, entweder SPDX (das auch eine ISO-Norm ist) oder CycloneDX, erstellt und übermittelt werden. Die Formate lassen sich je nach Verwendung und Branchenzugehörigkeit so anpassen, dass sie bestimmte Informationen wie Lizenzen, Urheberrechte und Schwachstellen enthalten, ausschließen oder darauf verweisen.

• Zweitens sollte eine SBOM zumindest die Top-Level-Komponenten von Open Source Software (OSS) sowie deren transitive Abhängigkeiten auflisten. Diese beziehen sich auf andere Komponenten, auf die OSS-Komponenten ihrerseits angewiesen sind, um ausgeführt werden zu können. Solche Abhängigkeiten zweiter und dritter Ordnung müssen sichtbar sein, weil sie weiter oben in der Lieferkette zu Lizenzierungsproblemen und Sicherheitsrisiken führen können. Mittlerweile bestehen 75 % aller Codebasen moderner Anwendungssoftware aus Open Source. Deshalb ist eine reine OSS-SBOM sehr informativ. Wer allerdings Einblick in alle Bereiche seiner Softwareanwendung gewinnen will, braucht eine SBOM, die auch Software von Drittanbietern (z. B. kommerziellen) und proprietären Code auflistet.

• Drittens: Eine SBOM ist ein wichtiger Schritt, um Risiken innerhalb der Software-Lieferkette entgegenzuwirken, allein ausreichend ist sie nicht. Sie sollte vielmehr in die Software-Risikomanagement-Prozesse eines Unternehmens einbezogen werden. Wenn beispielsweise eine neue Zero-Day-Schwachstelle in einer bestimmten OSS-Komponente veröffentlicht wird (wie etwa Log4J), sollte ein Unternehmen über Standardprozesse verfügen, um sämtliche SBOMs zu überprüfen. Nur dann lässt sich feststellen, welche Softwareanwendung die anfällige OSS-Komponente enthält.

Eine SBOM ist zweifelsohne wichtig, aber sie reicht bei Weitem nicht aus, um die Software-Lieferkette abzusichern. Ein Softwareanbieter sollte bereits zu Beginn der Lieferkette Sicherheitsfunktionen in die Architektur einbauen und solche, die dafür sorgen, dass die gesetzlichen Vorgaben eingehalten werden.

Unabdingbar ist es auch, Entwickler in sicherer Softwareentwicklung zu schulen. Die Softwareentwicklungs-Pipeline sollte vor Manipulationen sicher sein, sodass kein Code aus unkontrollierten Quellen eingeschleust wird, und der Code sollte digital signiert sein. Dies bestätigt einerseits die Urheberschaft und stellt andererseits sicher, dass der Code seit der Signierung nicht verändert wurde.

Sicherheitsverstöße in einem derart frühen Stadium der Entwicklungspipeline haben oft weitreichende Folgen für den gesamte Downstream. Ein Beispiel ist der Vorfall bei Codecov 2021, bei dem Hunderte von Netzwerken betroffen waren. Eine Software sollte während ihrer Entwicklung auf Sicherheits- und Qualitätsmängel im Quellcode hin überprüft werden. Das gilt analog für mögliche Schwachstellen sowie Lizenzprobleme mit den betreffenden OSS-Komponenten.

Wie wichtig das ist, zeigt die Tatsache, dass annähernd 50 Prozent der geprüften Anwendungen mindestens eine hochriskante Open-Source-Schwachstelle enthalten, die behoben werden musste. Sobald möglich sollte man zusätzlich dynamische Tests und Analysen durchführen. Denn diese Tools suchen nach Schwachstellen, die erst auftreten, wenn die Software ausgeführt wird.

Nach der Freigabe einer Software liefert der Anbieter zusätzlich die SBOM aus. Sie beschreibt dem Käufer dann die komplette Struktur der Software.

Die SBOM als Nachweis gegenüber dem Anwenderunternehmen

Mit der Bereitstellung gehen die Risiken auf den Käufer über. Sie betreffen sowohl die eigentliche Softwareanwendung als auch die Umgebung, innerhalb der sie bereitgestellt wird. Jede dieser Umgebungen, ob Cloud, mobil oder Server, hat ihre eigenen inhärenten Schwachstellen. Die gilt es zu berücksichtigen, wenn Firmen eine Gefährdung der Software nach der Bereitstellung vermeiden wollen. Bei Hackerangriffen auf den Apple AppServer Store nach der Bereitstellung kam es beispielsweise zu Einnahmeeinbußen bei den betroffenen Entwicklern und Firmen.

Am Ende der Lieferkette braucht man Prozesse, mit denen man die Wartungsphase innerhalb des Software-Lebenszyklus schützt. Bei dem berüchtigten Angriff auf die Lieferkette von SolarWinds verschafften sich die Angreifer Zugang zu sensiblen Informationen in Tausenden von Unternehmen und etlichen US-Regierungsbehörden. Das Ergebnis eines Angriffs, bei dem es gelungen war, bösartigen Code in den Software-Patching-Prozess am Ende des Software-Lebenszyklus einzubringen.

Letztendlich ist eine Software Bill of Materials oder Software-Stückliste ein wichtiger, aber bei Weitem nicht der einzige Aspekt des Risikomanagement-Prozesses für die Software-Lieferkette. Damit man eine SBOM so sinnvoll wie möglich einsetzen kann, sollte sie vollständig und präzise sein, einer anerkannten Norm entsprechen und Teil eines umfassenderen Risikomanagement-Programms sein.

* Anita D’Amico ist Vice President of Cross-Portfolio Solutions and Strategy bei der Synopsys Software Integrity Group.

(ID:49214108)