Philip - stock.adobe.com

Tipp

SBOM: Mit Softwarestücklisten Risiken reduzieren

Log4Shell hat eindrücklich gezeigt, wie wichtig es ist, über alle Komponenten in der von Unternehmen eingesetzten Software Bescheid zu wissen. Abhilfe versprechen SBOMs.

Ed Moyle
von
Zuletzt aktualisiert:14 Febr. 2022

Wenn Sie wissen wollen, wie wichtig die Angabe einer Inhaltsliste bei Lebensmitteln ist, müssen Sie nur mit jemandem sprechen, der eine Nahrungsmittelallergie hat. Den falschen Artikel im Lebensmittelgeschäft zu kaufen, kann für diese Menschen möglicherweise tödlich enden. Es wäre daher sehr gefährlich, wenn die Hersteller von Lebensmitteln nicht mehr alle Bestandteile aufführen würden.

Das Bedürfnis, über die Inhaltsstoffe unseres Essens informiert zu sein, ist vergleichbar mit der Situation, in der wir uns als Käufer von Software befinden. Moderne Anwendungen bestehen nur noch selten aus einem einzigen Guss. Jedes Programm, das wir installieren, jedes Softwarepaket, das wir erwerben und jeder Cloud-Dienst, den wir nutzen, hat heutzutage zahlreiche Abhängigkeiten. Diese Abhängigkeiten können viele Formen annehmen:

  • Gemeinsam genutzte Objekte oder Bibliotheken, wie zum Beispiel Dynamic Link Libraries (DLLs),
  • statisch verlinkte Bibliotheken,
  • „ausgeliehener“ Code,
  • Middleware wie MariaDB, Tomcat oder .Net,
  • Javascript-Libraries wie jQuery und React sowie
  • eingebundene Dienste wie Apache oder Nginx.

Moderne Anwendungen sind also weniger ein einzelnes Produkt, sondern eher eine eng aufeinander abgestimmte Supply Chain, die aus zahllosen über die ganze Welt verstreuten Quellen befüllt wird.

Bedauerlicherweise bedeutet das aber auch, dass sobald eine zugrundeliegende Komponente eine Schwachstelle hat, die gesamte Applikation betroffen ist. Ein aktuelles Beispiel ist die Sicherheitslücke in der Logging-Software Log4j, die seit Dezember 2021 für viel Aufregung in der Security-Welt sorgt.

Oder erinnern Sie sich noch an die Heartbleed-Lücke in der weit verbreiteten OpenSSL-Library? Einer der Gründe für die Schwere dieser Schwachstellen ist, dass diese Produkte in zahllosen anderen Anwendungen eingesetzt werden, die von ihnen mehr oder weniger abhängig sind. Große Softwarehersteller mussten teilweise Hunderte betroffene Produkte nennen, die eine der genannten Komponenten genutzt haben. Allein im Fall von Heartbleed hatte zum Beispiel der Netzwerkhersteller Cisco Systems rund 80 gefährdete Produkte aufgelistet.

Wenn Sie bedenken, dass Unternehmen nach Berechnungen von MuleSoft im Schnitt etwa 900 unterschiedliche Anwendungen einsetzen, dürfte verständlich werden, wie schwierig es für sie ist, die Kontrolle über alle Softwarezustände, gefährdeten Versionsnummern, Patches und Workarounds zu behalten.

Einsatz moderner Softwaremateriallisten

Um eine weitere mit Heartbleed- oder Log4Shell vergleichbare Situation zu vermeiden, benötigen Sie eine Liste mit tatsächlich allen verwendeten Softwarekomponenten. Ähnlich wie die aufgedruckten Inhaltsstoffe auf Lebensmitteln listet eine solche Stück- oder Materialliste, auch Software Bill of Materials (SBOM) genannt, alle in einer Anwendung enthaltenen Komponenten auf. Eine SBOM hat also Daten über alle Komponenten, auf die eine Anwendung angewiesen ist, mit denen sie zusammen verteilt wird oder die sie aus anderen Gründen für ihr Funktionieren benötigt.

Aus Anwendersicht bietet eine SBOM einen Blick in die ansonsten „schwarze Box“ Software. Auch aus Sicherheitssicht ermöglicht eine solche Liste einen besseren Einblick in die Risiken, die sich aus Schwachstellen in den verwendeten Komponenten ergeben. Entwickler profitieren darüber hinaus von einer Stückliste, weil sie damit leichter sicherstellen können, dass alle für sie relevanten Open-Source-Lizenzen eingehalten werden.

So können SBOMs etwa dabei helfen, die Bereiche zu identifizieren, in denen fremde Bestandteile genannt oder andere Anforderungen erfüllt werden müssen. Auch das mit dem IT-Betrieb befasste Team erhält mit einer solchen Liste einen besseren Einblick in die Module, die zusammen mit anderen Bestandteilen genutzt werden. So lässt sich etwa leichter herausfinden, was alles innerhalb eines Docker-Containers läuft.

Die Vorteile von Softwarestücklisten haben auch für ein großes Interesse bei Regulierungsbehörden und auf Endnutzer spezialisierten Unternehmen gesorgt. So hat zum Beispiel die US-Regierung die Behörde NTIA (National Telecommunications and Information Administration) im Rahmen der Executive Order 14028 „Improving the Nation's Cybersecurity“ beauftragt, Minimalanforderungen an ein SBOM zu verfassen.

Auch die amerikanische Food and Drug Administration hat einen Leitfaden für das Inverkehrbringen von Waren erstellt, in dem auch Softwarestücklisten als Teil einer anderen äußerst wichtigen SBOM genannt werden: Die sogenannte Cybersecurity Bill of Materials oder abgekürzt CBOM. Sie gilt für medizinische Geräte.

Das Erstellen einer Liste über alle Bestandteile einer Anwendung ist also äußerst hilfreich, bringt aber auch einige Schwierigkeiten mit sich. Ähnlich wie bei Lieferketten in der Logistik sind auch die Abhängigkeiten bei Software meist tiefer als nur eine einzige Ebene. Das bedeutet, dass jede Abhängigkeit zu einem bestimmten Modul oder einer Bibliothek möglicherweise zu weiteren Abhängigkeiten führt, von denen noch mehr Teile betroffen sind und so weiter. Eine Softwarestückliste ist also eigentlich auch keine herkömmliche Liste, sondern eher ein hierarchisch organisierter Baum aus zahlreichen Abhängigkeiten.

Wegen dieser meist sehr komplexen Situation empfiehlt die NTIA den Einsatz automatisierter Techniken zur Erstellung und Pflege eines SBOMs. Die Behörde hat in ihren Minimalanforderungen drei standardisierte Vorgehensweisen genannt, die für maschinenlesbare und leicht übertragbare Formate sorgen sollen:

Wie Softwarestücklisten die IT-Sicherheit verbessern

IT-Sicherheitsteams, die Schwachstellen in der von ihnen genutzten Software besser verstehen, tracken und verwalten wollen, profitieren von den oben genannten Ressourcen und Standards für SBOMs.

Wenn Ihr Softwareanbieter aber keine Details über die enthaltenen Komponenten zur Verbesserung Ihrer IT-Sicherheit bereitstellen kann oder will, dann sollten Sie sich erkundigen, warum das so ist. Es wird für die Hersteller immer schwieriger, keine detaillierten Daten über ihre Anwendungen mehr zu veröffentlichen, da es bereits mehrere internationale Standards und passende Tools gibt, die das Teilen dieser Daten erleichtern. Als Kunde sollten Sie genau über alle wesentlichen Details der von Ihnen erworbenen Software informiert sein und auch darauf bestehen, dass Sie benachrichtigt werden, wenn es Änderungen gibt.

Das Erstellen von Softwarestücklisten hat aber auch für die Anbieter einige Vorteile. Neben sicherheitsrelevanten Fragebögen oder Daten über die genutzten Security-Prozesse können sie ihre Kunden so über die Herkunft aller Komponenten auf dem Laufenden halten, die sie in ihren Anwendungen einsetzen. Das bedeutet allerdings, dass auch sie selbst verstehen müssen, was alles in ihren Produkten enthalten ist. Das Dokumentieren der zugrundeliegenden Bestandteile mag anfangs eine schwierige Aufgabe sein. Auf Dauer ist die Fähigkeit zum Erstellen und Aktualisieren einer SBOM jedoch auch für die Anbieter selbst nützlich.

Unabhängig davon, ob Sie nun Anbieter oder Kunde sind, es ist auf jeden Fall empfehlenswert, jetzt mit Ihren Kollegen in die interne Diskussion über Softwarestücklisten einzusteigen. Bei einem Hersteller sollte sich das Sicherheitsteam damit beschäftigen, wie SBOM-Daten sicher und zuverlässig mit den Kunden geteilt werden können. Die Kunden selbst sollten sich dagegen darum kümmern, wie sie die bereitgestellten Informationen so einsetzen können, dass die positiven Effekte am besten zum Tragen kommen. Heartbleed und Log4Shell haben gezeigt, dass Softwarestücklisten in Zukunft eine noch größere Rolle als bisher spielen sollten.

Erfahren Sie mehr über Anwendungs- und Plattformsicherheit