SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 2: Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten

Um Angriffe auf IT-Systeme, mit denen kriminelle Banden uns in Gefahr bringen, und auf die wir leider oft nur unzureichend reagieren können, darum ging es im ersten Teil dieser Serie über die Software-Stückliste SBOMs. Aber was macht uns so handlungsunfähig? Klar, Kriminelle sind schwer in den Griff zu bekommen, wohl aber unseren Umgang mit bekannten Sicherheitsproblemen! Hier kommen SBOMs ins Spiel.

Was SBOMs können, und mit welchen Grundfunktionalitäten, sie helfen, unsere IT im Griff zu behalten, darum geht es in diesem 2. Teil der Serie.

SBOMs als Pflichtprogramm

In den Vereinigten Staaten führte die Gefährdungslage 2021 zu einer Anordnung des Präsidenten, der Executive Order 14028. Darin ist eine Auflistung zahlreicher konkreter Maßnahmen zu finden mit recht kurzfristigen Zielterminen von 30 bis 120 Tagen.

Unter anderem diese:

Behörden werden angewiesen, Verträge zu prüfen und zu überarbeiten
Neue Konzepte und Strategien sind aufzusetzen
Informationen werden eingefordert
Kommunikationsketten werden definiert
Sicherheitsmaßnahmen wie Multi-Faktor-Authentifizierung werden grundsätzlich verpflichtend gemacht

Die Maßnahmen dieser Anordnung dienen dem Ziel, die Sicherheit im Software-Umfeld in kürzester Zeit drastisch zu verbessern. Zumindest im Kontext diverser Regierungsdienste und deren Partner, Lieferanten und Dienstleister. Mit der Executive Order 14028 wird – um zum eigentlichen Thema zu kommen – auch die Lieferung von sogenannten Software Bills of Material, kurz: SBOMs verpflichtend. Bei diesen SBOMs handelt es sich dabei genau um die Stücklisten über den Inhalt von Softwarekomponenten, die wir im ersten Teil erwähnt haben.

Welche Informationen liefern SBOMs?

SBOMs beinhalten Informationen wie diese:

Beschreibung der Komponente
Verwendete (abhängige) Software-Komponenten und deren Lizenzen
Beschreibung von Services und einzelnen Dateien
Jeweils eindeutige Koordinaten zur eindeutigen Identifikation, wie Name und Version
Hashes für alle Elemente

Damit dienen SBOMs als standardisiertes Austauschformat für die sicherheitsrelevanten Elemente einer Software. Mit folgenden großen Vorteilen:

Einfachheit: Die zentrale Sammlung von Informationen zu eigenen und Fremdprodukten in einer Datenbank wird vereinfacht
Transparenz: Hersteller und Nutzende erhalten entsprechende Informationen, ohne, dass die Software an sich „offen“ gelegt wird.

Weniger Aufwand und schnellere Prozesse

Ein weiterer Vorteil ist die Vereinfachung einiger Prozesse – sowohl bei Herstellern als auch bei Nutzenden oder ggf. zwischengeschalteten Dienstleistern.

Hier drei Beispiele:

Eine schnellen Suche nach der Verwendung eines bestimmten, vulnerablen Software-Artefakts im Bestand wird möglich. Also eine schnelle Antwort auf die Fragen „Nutzen wird das?“ und „Wo und in welcher Version nutzen wir das?“.
Regelmäßig wird ein Scan der eigenen und fremden Software-Komponenten auf bekannte Sicherheitslücken durchgeführt. D. h. wir haben wir immer eine Antwort auf die Frage „Sind wir vulnerable?“, ohne eigene Detailanalysen anstellen zu müssen.
Software-Komponenten werden auf Aktualität geprüft. So bekommen wir Antworten auf die Fragen “Benutzen wir die aktuelle Version?“, „Wie viele neue Versionen gibt es?“ und „Müssen wir jetzt aktualisieren?“.

Standarddaten und ein darauf aufbauendes Tooling schrauben den Aufwand, insbesondere für Softwarenutzende, erheblich herunter.

Schutz vor selbstgemachten Sicherheitsproblemen

Damit schützen SBOMs nicht vor Sicherheitslücken – diese verschwinden dadurch ja nicht und die Software wird auch nicht automatisch besser. Wovor SBOMs uns schützen, sind selbstgemachte Sicherheitsprobleme durch Ignorieren bekannter Fixes.

So spricht der „9th Annual State of the Software Supply Chain“ von Sonartype – bekannt durch das statische Codeanalyse Werkzeug SonarQube – von im Schnitt 150 Abhängigkeiten, die ein Software-Projekt besitzt, mit in Summe pro Jahr 1500 Änderungen in den Abhängigkeiten. Ebenso haben 96 % der heruntergeladenen Software-Artefakte im Java-Umfeld bekannte Sicherheitsprobleme, obwohl bereits ein Fix existiert.

Diese unnötigen Lücken lassen sich mithilfe von SBOMs schließen.

Software als lebendes Produkt verstehen

Die Verwendung von SBOMs ermöglicht also großen Teilen der Software-produzierenden oder -konsumierenden Gesellschaft, autonomer, schneller, dezentraler und auch aktiver auf bekannte Sicherheitslücken zu reagieren. Darüber hinaus führt es zu einem anderen Qualitätsanspruch, zu einer anderen Erwartungshaltung und zu einem anderen Verständnis von Software –nämlich als dauerhaftes, lebendes Produkt.

Damit sind Softwaresysteme nicht mehr etwas, das wie ein Möbelstück in einem Möbelhaus gekauft, aufgestellt und genutzt wird, sondern eher vergleichbar mit einem Auto, das regelmäßig überprüft und gewartet werden muss und bei dem hin und wieder schadhafte Teile ausgetauscht werden.

Auch in Deutschland gibt es mit der „Technical Guideline TR-03183, Part 2: Software Bill of Materials (SBOM)“ eine erste Einschätzung und Einordnung durch das BSI. Diese Richtlinie verweist explizit auf den aktuell noch im Entscheidungsprozess befindlichen Cyber Resilience Act der EU, der ggf. für Organisationen im öffentlichen Bereich die Erstellung und Auslieferung von SBOMs verpflichtend machen würde.

Fazit

SBOMs sind mehr als nur der Traum einiger Technikfreaks, die gerne alles dokumentieren, in Schubladen packen und kategorisieren wollen. SBOMs geben uns schnell und automatisiert Antworten auf Fragen, die für unsere Sicherheit entscheidend sein können. Spätestens bei der nächsten Gefährdungslage werden wir heilfroh sein, dass wir sie eingesetzt haben. Doch es geht nicht nur um die großen Angriffe: Wie wir gesehen haben, helfen SBOMs bereits jetzt, hier und heute, unsere IT sicherer zu machen.

Aber wie sieht eine SBOM denn jetzt genau aus? Welche Formate gibt es? Welche Tools gibt es? Und welche davon sollten wir verwenden? Was ist möglich, wie gut funktioniert es und was geht ggf. noch nicht so gut? Und wie kann ich entsprechende Werkzeuge integrieren?

Denn oft steht und fällt mit der Wahl der Werkzeuge die Qualität des Ergebnisses. Aber auch auf die richtige Umsetzung von Prozessen und ein gesundes Maß an Pragmatismus kommt es an.

Auf diese Fragen wollen wir in den folgenden Teilen dieser Blog-Serie eingehen. Dafür haben wir uns einige Tools angeschaut und schildern unseren Eindruck … und natürlich sprechend wir die ein oder andere Empfehlung aus.