Mehr Sicherheit für die Software-Supply-Chain

Die US-Regierung hat auf SolarWinds-Hack mit einer strengeren Gesetzgebung reagiert, um die Sicherheit der Software-Supply-Chain im öffentlichen Sektor zu verbessern. Software-Zulieferer müssen künftig eine Software Bill of Materials (SBOM) zur Verfügung stellen und damit offenlegen, welche Komponenten in ihren Anwendungen stecken. IT-Sicherheitsexperten sollten darauf vorbereitet sein.

Warum SBOM?

Eine SBOM ist eine Stückliste von Bestandteilen und Bibliotheken, die eine Software verwendet. Unternehmen müssen also sicherstellen, dass ihnen diese Informationen lückenlos vorliegen. Das klingt nach einer Selbstverständlichkeit, die es aber nicht ist. Beispiel Log4j: Das Framework zum Loggen von Anwendungsmeldungen in Java ist ein Standard, der in vielen Open-Source- und kommerziellen Software-Lösungen steckt. Eine kritische Schwachstelle führte Ende 2021 zu einem erheblichen Bedrohungspotenzial. Die Situation wurde dadurch verschärft, dass viele Unternehmen nicht einmal wussten, ob und wo sie Log4j einsetzten. Solche Bedrohungsszenarien sollen dank SBOMs der Vergangenheit angehören. Mit der Norm ISO 5962 wurde ein SBOM-Format international standardisiert. SBOMs werden in den kommenden Jahren zu einem unverzichtbaren Tool für die Sicherheit und Compliance von Wertschöpfungsketten werden.

Status quo: Die Definitionsphase läuft noch

Die Phase der Definition von Spezifikationen und Standards läuft noch. SBOMs benötigen eine sichere Backend-Schicht für die Speicherung und Integration. Entwickler wiederum benötigen ein Frontend, das Sicherheit in ihren Arbeitsablauf integriert, ohne die Produktivität zu beeinträchtigen. Noch gibt es keine marktreifen Implementierungen, doch das dürfte sich noch im laufenden Jahr 2022 ändern. In einigen Branchen fordern Kunden schon heute SBOMs von ihren SaaS-Lieferanten. In Deutschland führt das novellierte IT-Sicherheitsgesetz 2.0 (IT-SiG 2.0) zu neuen Auflagen für Betreiber Kritischer Infrastrukturen (KRITIS), Bundesbehörden und Unternehmen im besonderen öffentlichen Interesse sowie deren Zulieferer. Diese Einrichtungen werden die ersten großen Nutzer von SBOMs sein und diese verstärkt nachfragen.

Kontrolle über Komponenten

Die Log4j-Schwachstelle machte deutlich, welches Risiko von fehlenden Kontrollmechanismen hinsichtlich der „Zutaten“ von IT-Produkten ausgeht. Und dieses Ereignis war nur eines von zahlreichen sicherheitsrelevanten Vorkommnissen: Ripple20 – eine Serie von teils kritischen Sicherheitslücken in einer TCP/IP-Implementierung – etwa gefährdete im Internet der Dinge vernetzte Geräte in Haushalt, Industrie und sogar Krankenhäusern und anderen Einrichtungen des Gesundheitswesens. Diese Fälle machten deutlich, dass Hersteller teils nicht oder nur mit hohem Aufwand ermitteln können, welche Bibliotheken und andere „Third Party“-Komponenten in ihren Produkten stecken.SBOMs stellen dagegen eine kontinuierliche Überwachung aller eingesetzten Software-Komponenten sicher.

Mehr Kooperation und bessere Vernetzung

SBOMs besitzen das Potenzial, die Abstimmung zwischen Sicherheitsfachleuten zu erleichtern und zu beschleunigen, indem sie einen besseren und vollständigeren Informationsaustausch über Sicherheitslücken gewährleisten. Log4j, Ripple 20 und SolarWinds warfen ein deutliches Schlaglicht auf die Gefahren, die von unsicheren Software-Komponenten ausgeht. Seitens öffentlicher Einrichtungen und Unternehmen, die IT-Lösungen für den öffentlichen Sektor liefern, ist das Interesse an sicheren Lieferketten hoch, um Ausfallrisiken mit potenziell schwerwiegenden Folgen (etwa im Bereich der kritischen Infrastrukturen) zu minimieren. SBOMs erleichtern den Austausch über relevante Informationen zu identifizierten Schwachstellen.

Automatisierung ist ein unerlässlicher Bestandteil für die Erstellung von SBOMs

Das BSI gibt in seinem Report zur Lage der IT-Sicherheit in Deutschland 2021 an, dass der Prozess der Überprüfung, ob eine bekannte Schwachstelle ein Produkt betrifft, in Kombination mit dem Common Security Advisory Framework (CSAF) innerhalb der Wertschöpfungsnetzwerke automatisiert werden kann. SBOMs sind vor allem dann effizient, wenn sie in Verbindung mit Automatisierungslösungen bei der Erfassung und Erstellung eingesetzt werden. Dabei helfen so genannte SCA-Tools (Software Composition Analysis): Sie analysieren und verwalten Open-Source-Elemente von Anwendungen. Entwickler setzen sie ein, um die Lizenzierung zu überprüfen und Schwachstellen zu bewerten, die mit einzelnen Open-Source-Komponenten verbunden sind.

Kein einheitliches SBOM-Rahmenwerk

Ein klar definierter, einheitlicher und gestraffter SBOM-Prozess trägt zu einer reibungslosen Implementierung und zur Akzeptanz bei. Allerdings haben in den USA das staatliche National Institute of Standards and Technology (NIST) und die private OWASP (Open Web Application Security Project) Foundation bereits unterschiedliche Rahmenwerke definiert. Weitere dürften hinzukommen. Unternehmen müssen deshalb agil genug sein, um unterschiedlicheRahmenwerke nutzen zu können. Sicherheitsverantwortliche erhalten dadurch eine Wahlmöglichkeit und können die beste Lösung für die Bedürfnisse ihres Unternehmens nutzen.

Fazit

SBOMs werden zu einem unverzichtbaren Baustein für die Softwaresicherheit und das kollaborative Risikomanagement in der Software-Wertschöpfungskette werden. Ihre Implementierung betrifft längst nicht nur Hersteller mit Geschäftsbeziehungen zum öffentlichen Sektor in den USA: Angesichts der weiter gestiegenen Bedrohungslage ist die Sicherheit der Softwarelieferkette inzwischen für nahezu alle Unternehmen ein Thema, und der Kreis der rechtlich zur Bereitstellung der in SBOMs standardisierten Informationen verpflichteten Betriebe wurde mit dem IT-SiG 2.0 deutlich erweitert. Unternehmen sollten SBOMs – die es bereits seit 2018 gibt – spätestens jetzt in ihre Entwicklungspraxis integrieren.

Lena Smart
verfügt über mehr als 20 Jahre Erfahrung im Bereich Cybersicherheit. Sie war Global Chief Information Security Officer des FinTech-Unternehmens Tradeweb. Außerdem CIO und CSO des  Stromversorgungsunternehmens New York Power Authority. Lena ist Gründungsmitglied des Konsortiums Cybersecurity at MIT Sloan.