SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 4: Das Versuchssetting

Nach grundsätzlichen Fragen rund um die Software-Stücklisten und dem Vergleich der beiden führenden SBOM-Formate, CycloneDX und SPDX stellen wir in diesem vierten Teil unser Versuchssetting vor. Das Setting war die Basis für diverse Tests, mit denen wir in dieser Blogserie der Frage nach einer guten SBOM auf den Grund gehen wollen.

Du bist neu dabei? Hier kannst du einen Blick in die ersten drei Teile der Blogserie werfen:

Welche Ziele haben wir uns gesetzt?

Ziel dieser Blogserie ist es, unterschiedliche Werkzeuge für die Erstellung von SBOMs unter die Lupe zu nehmen. Dazu gehörte es, uns die Auswertung bzgl. potenzieller CVEs, Reportings von Software-Lizenzen oder die Erkennung von Lizenzverstößen näher anzuschauen. Auch wenn grundsätzlich mit einer SBOM mehr möglich ist, scheinen uns diese die essenziellen Kernprozesse zu sein.

Welche Werkzeuge haben wir getestet?

Getestet wurden vor allem:

(kostenlose) Open-Source-Werkzeuge
Werkzeuge, die sich grundsätzlich in eine CI-Pipeline integrieren lassen und damit den Wunsch nach Automatisierung unterstützen
die korrekte Aufzählung von Software-Abhängigkeiten eines Software-Produkts. D. h. wir hatten nicht den Anspruch, dass jedes Dateiartefakt korrekt erkannt, aufgezählt und verarbeitet wird. Ebenso bewerteten wir nicht die Erkennung von CVEs von Distributionspaketen des Betriebssystems der Docker-Images. Der Fokus lag also auf dem Erkennen von Abhängigkeiten einer Software, nicht der Umgebung, in der sie ausgeführt wird.
Rein SBOM-basierende Prozesse. D. h. wir haben die Strecken außer Acht gelassen, in denen ein Werkzeug scannt und CVEs auswertet, ohne dabei intermediär eine SBOM zu nutzen.
Praktikabilität der Werkzeuge. D. h. wir haben nicht die Korrektheit der SBOM validiert, sondern untersucht, wie gut Werkzeuge mit der SBOM in der Praxis arbeiten können.

Welcher Technologie-Stack wurde untersucht?

Bei der Wahl des Technologie-Stacks haben wir uns an einen typischen Stack orientiert, den wir bei unseren Kunden immer wieder vorfinden.

Java Maven Projekte
Angular / NPM Projekte
Docker Images (hier wiederum mit Fokus auf den dort installierten Software-Artefakt)
Die Dokumentation einer Betriebssysteminstallation

Welcher Code stand im Fokus?

Welchen Code galt es zu begutachten bzw. anhand von welchem Code wollten wir die Werkzeuge prüfen? Hier haben wir uns für Varianten der PetClinic entschieden, eines der Demo-Projekte im Java-Umfeld.

Konkret:

Das Projekt https://github.com/spring-petclinic/spring-petclinic-rest zum Stand von Mitte Dezember (also ohne die nachfolgende Spring-Boot-Aktualisierung).
Das Projekt https://github.com/spring-petclinic/spring-petclinic-angular ebenfalls zum Stand von Mitte Dezember.
Folgende Docker-Images: tomcat:9, tomcat:9-alpine, tomcat:9-jdk21-corretto-al2
Der Arbeitsrechner unter Windows 11 sowie eine WSL2-Umgebung auf Basis von Ubuntu 22.04.

Unsere Testkriterien

Eine Empfehlung braucht klare Kriterien. Deshalb haben wir unsere Anforderungen an die Werkzeuge vorab definiert. Drei Gütekriterien wurden dabei unterschieden:

1. Eignung für Continuous Integration (CI)

Die Integrationsfähigkeit in einen CI-Build ist maßgeblich. Generierung und Prüfung sollte bei Änderungen automatisch neu angestoßen werden können.
Dies bedingt auch, dass z. B. sinnvolle Warnungen oder Fehler erzeugt werden und die Verarbeitung abgebrochen werden kann, wenn im Test ein Fehler entdeckt wird. D. h. auch die Ausgaben sollten „CI-geeignet“ sein.
Das Werkzeug sollte möglichst wenig Installations- und Pflege-Aufwand bei der Installation auf einem Arbeitsrechner oder einem CI-Rechner erzeugen

2. Qualität

Von Vulnerability Scannern erwarten wir, dass die gängige Bewertung einer Sicherheitslücke mit angegeben wird.
Grundsätzlich erwarten wir ein Minimum an „false positive“- und „false negative“-Meldungen und natürlich eine vollständige Liste der korrekt identifizierten Vulnerabilities.
Die Präsentation des Ergebnisses muss auch für Nicht-Techniker nachvollziehbar sein

3. Geschwindigkeit

Die Ausführung sollte zügig erfolgen. Das hieß für uns: Die Ausführung sollte mit Blick auf die Gesamtausführungszeit der Build-Pipeline angemessen sein. Idealerweise liegt die Ausführung bei einigen wenigen Sekunden.

Woran erkennen wir eine gute SBOM?

Fangen wir mit den Eigenschaften einer guten SBOM an: Zunächst sollte die SBOM grundsätzlich vollständig und korrekt sein – in Bezug auf die zu dokumentierende Komponente sowie auf die oben genannten Ziele.

Um diese Eigenschaft zu bewerten, haben wir in unseren Tests vier Punkte gecheckt:

1. Alle relevanten Abhängigkeiten müssen aufgezählt werden!

Dokumentieren wir ein Software-Projekt, sollten alle Komponenten sowie deren transitiven Abhängigkeiten vollständig aufgelistet werden.
Dokumentieren wir einen Docker-Container sollten z. B. alle Packages der Linux Distribution sowie zusätzlich manuell installierte Software, wie ein JDK, aufgezählt werden.
Dokumentieren wir ein Betriebssystem, gilt das gleiche für Software-Packages, Systemkonfigurationen und Systemeigenschaften.

2. Die Listeneinträge müssen eindeutig sein!

Es sollten eindeutige IDs verwendet werden, um eine Komponente schnell unterscheiden zu können von

anderen Komponenten,
anderen Komponentenversionen
oder gleichnamigen Komponenten anderer Hersteller.

3. Folgende Informationen sollten vorliegen, damit die SBOM entsprechend ihrem Zweck ausgewertet werden kann!

Jede Komponente ist eindeutig über Namen und Version zu identifizieren.
Am besten werden weitere IDs wie die Common Platform Enumeration (CPE) verwendet.
Die Quelle des Artefakts wird eindeutig genannt, z. B. mit der Download-URL.
Angaben zu Lizenzen oder Lizensierungsmöglichkeiten der Komponente werden gemacht.
Informationen bzgl. Nutzung oder Einbindung der Komponente, wie Typ („Library“) oder Einbindungsart im Kontext des Builds („scope: test“) stehen zur Verfügung.

4. Die Korrektheit der Angaben muss überprüfbar sein!

Über Hashes kann geprüft werden, ob die vormals dokumentierte Komponente und die Komponente, die uns aktuell vorliegt, inhaltlich identisch sind – die Komponente also nicht modifiziert wurde.

Summary

Mit den Kriterien, die wir oben genannt haben, setzten wir bei unserer Analyse den Fokus schwerpunktmäßig auf diese Aspekte:

praktische Nutzbarkeit bzgl. der Identifikation von CVEs bzgl. Lizenzen,
Korrektheit der Angaben,
typische Software-Stacks
und abhängige Software-Artefakte.

Wie geht es weiter?

Für den nächsten Teil dieser Blogserie haben wir Tools für die Erzeugung von SBOMs getestet. Die Ergebnisse rangieren von „empfehlenswert“ bis „durchgefallen“.

Danach geht es weiter mit Fragen wie :

Was können die Vulnerability Scanner?
Wie steht es um die Kompatibilität von Lizenzen?
Wie integriere ich SBOMs in den Software-Development-Prozess?
Was ist beim Start in die SBOM-Welt zu beachten?
Was ist von den Konzepten hinter SBOM zu halten?
Summary und Tipps für den Start

Bisherige Teile ansehen:

Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken

Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten

Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX

Teil 4: Was ist eine gute SBOM? – Das Versuchssetting

Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich

Was ist eine gute SBOM?