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:
- 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 versus SPDX
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
Alle Teile ansehen:
Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX
Teil 4: Was ist eine gute SBOM? – Das Versuchssetting
Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks
Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess
2 Kommentare
Pingback: Was machen SBOMs mit der Softwareentwicklung?
Pingback: Mit SBOMs die Lizenzierung überprüfen - The Cattle Crew Blog