SBOM – die Stückliste für Software

„Unverzichtbar für Softwaresicherheit und Risikomanagement“

Wer im öffentlichen Sektor der USA künftig Software vermarktet, muss eine Software Bill of Materials (SBOM) über die verwendeten Komponenten mitliefern. Ist diese Executive Order 14028 der US-Regierung auch für deutsche Firmen relevant? Die IT-Sicherheitschefin von MongoDB, Lena Smart, ordnet das ein – und verweist dabei auf das IT-Sicherheitsgesetz 2.0.

 (Bild: MongoDB Deutsche GmbH)
(Bild: MongoDB Deutsche GmbH)

Frau Smart, was ist denn eine SBOM?

Lena Smart: Eine SBOM ist im Wesentlichen ein Inventar über Bestandteile und Bibliotheken, die eine Software verwendet. Unternehmen müssen gewährleisten, dass Sie diese Informationen vorlegen können. Dazu müssen sie, auch wenn das überraschend klingt, Daten erheben, die sie in der Vergangenheit oft nicht erhoben haben. Nehmen Sie das Beispiel der Log4j-Schwachstelle: Das ist ein Standard, der in vielen Open-Source- und auch in kommerziellen Softwarelösungen steckt. Viele Unternehmen wussten damals lange Zeit nicht nur nichts von der Schwachstelle, sie wussten nicht einmal, ob und wo sie Log4j nutzten. Das sollen SBOMs ändern. Sie sollen den Informationsaustausch verbessern und die Sicherheit und Compliance von Wertschöpfungsketten deutlich verbessern.

Unternehmen können also aktuell gar nicht alle Komponenten, die in ihren Softwarelösungen stecken, einsehen?

Smart: Die Log4j-Schwachstelle führte Fachleuten, aber auch der betroffenen Öffentlichkeit vor Augen, welches Risiko von fehlenden Mechanismen zur Kontrolle der Bestandteile von IT-Lösungen ausgeht. Und dieses Ereignis war nur eines von vielen Bedrohungsszenarien. Die Folgen können je nach betroffenem Bereich weitreichend sein. Ripple20, eine Serie von teils kritischen Sicherheitslücken in einer TCP/IP-Implementierung, gefährdete im IoT vernetzte Geräte in der Industrie, aber auch in Krankenhäusern. Anhand dieser Fälle wurde deutlich, dass Hersteller teils nur mit hohem Aufwand herausfinden können, welche Komponenten in ihren Produkten verbaut sind – und was das für Folgen haben kann. SBOM sorgen für eine lückenlose Überwachung.

SBOM sind Teil einer Regelung der US-Regierung. Sind sie für in Deutschland oder der EU ansässige Unternehmen überhaupt relevant?

Smart: SBOM werden für die Softwaresicherheit und das kollaborative Risikomanagement in der Softwarewertschöpfungskette unverzichtbar werden. Jenseits gesetzlicher Auflagen fordern Kunden in einigen Branchen schon heute SBOM von ihren SaaS-Lieferanten. Ihre Implementierung betrifft auch längst nicht mehr nur Hersteller mit Geschäftsbeziehungen zum öffentlichen Sektor in den USA. Die Sicherheit der Softwarelieferkette ist 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 novellierten IT-Sicherheitsgesetz 2.0 (IT-SiG 2.0) auch in Deutschland deutlich erweitert. Unternehmen sollten SBOM – die es übrigens bereits seit 2018 gibt – spätestens jetzt in ihre Entwicklungspraxis integrieren.

Wie ermitteln Unternehmen die in der SBOM enthaltenen Informationen?

Smart: Der Prozess der Überprüfung, ob eine bekannte Schwachstelle ein Produkt betrifft, kann mit dem Common Security Advisory Framework (CSAF) innerhalb der Wertschöpfungsnetzwerke automatisiert werden. SBOM sind vor allem dann effizient, wenn sie auf Basis eines hohen Automatisierungslevels bei der Erfassung und Erstellung erzeugt und eingesetzt werden. Hier kommen Tools zur Software Composition Analysis ins Spiel. SCA-Tools analysieren und verwalten Open-Source-Elemente von Anwendungen. Entwickler setzen sie ein, um Lizenzen zu überprüfen und Schwachstellen zu bewerten, die mit einzelnen Komponenten verbunden sind.

Sie haben den Informationsaustausch erwähnt. Wie tragen SBOM dazu bei, ihn zu verbessern?

Smart: SBOM können die Abstimmung erleichtern und beschleunigen, indem sie einen schnelleren, besseren und vollständigeren Informationsaustausch über Sicherheitslücken ermöglichen. Log4j und Ripple 20 waren ein Weckruf hinsichtlich der Gefahren, die von Software-Komponenten ausgehen. Es liegt im Eigeninteresse von öffentlichen Einrichtungen und deren IT-Providern, Ausfallrisiken etwa im Bereich der kritischen Infrastrukturen zu minimieren. Sicherheitsverantwortliche sollten sich mit SBOM nicht nur aufgrund der zu erwartenden rechtlichen Vorgaben auseinandersetzen, sondern auch, um Gefahren für Gesundheit und Sicherheit der Bevölkerung und last not least enorme finanziellen Schäden abzuwenden. Auch das IT-ISAC – dessen Aufgabe es ist, die Zusammenarbeit und den Austausch von Informationen über Cyberrisiken zu verbessern – zeigt großes Interesse am Thema SBOM-Implementierung, weil sie diesen Austausch vereinfachen.

Sie sprechen aktuelle und kommende rechtliche Vorgaben an. Wie ist denn der status quo?

Smart: Das Bundesamt für Sicherheit in der Informationstechnik unterstützt die Implementierung von SBOM ausdrücklich. In Deutschland führt auch das novellierte T-SiG 2.0 zu neuen Auflagen für Betreiber Kritischer Infrastrukturen (KRITIS), Bundesbehörden und ‘Unternehmen im besonderen öffentlichen Interesse sowie deren Zulieferer’. Diese Unternehmen werden die ersten großen Nutzer von SBOMs sein und sollten sich spätestens jetzt mit dem Thema befassen.

Welche Standards für SBOM gibt es im Moment?

Smart: Die Phase der Definition von Spezifikationen und Standards läuft noch. Mit der Norm ISO5962 wurde inzwischen ein SBOM-Format international standardisiert. Noch gibt es keine marktreifen Implementierungen, doch das dürfte sich bis Ende 2022 ändern. In der Praxis benötigen SBOM 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. Eine Herausforderung ist, dass es kein einheitliches Rahmenwerk gibt. Ein klar definierter, einheitlicher und gestraffter SBOM-Prozess trägt zu einer reibungslosen, raschen Implementierung und zu einer hohen 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.

Was bedeutet das für Unternehmen?

Smart: Sie müssen agil genug sein, um unterschiedliche Rahmenwerke nutzen zu können. Als positiven Effekt erhalten Sicherheitsverantwortliche eine Wahlmöglichkeit und können die beste Lösung für die Bedürfnisse ihres Unternehmens nutzen.