SBOMs, die Software-Stückliste für mehr IT-Sicherheit
– Teil 5: Tools für die SBOM-Erzeugung im Vergleich

Am Beginn unserer Reise durch die SBOM-Welt steht die Erzeugung der SBOMs. Aber welches Werkzeug hat die Nase vorn, wenn es um die Erzeugung präziser und aussagekräftiger SBOMs geht?

Um das herauszufinden, sind wir in diesem Teil der Blogserie in die Welt der SBOM-Erstellungstools eingetaucht. Wir haben getestet, welches Werkzeug unsere Anforderungen am besten erfüllt. Wir wollten herausfinden, welche Tools wirklich gute SBOMs herstellen – und damit uns allen (hoffentlich!) die Auswahl des optimalen Werkzeugs erleichtern.

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

Bei unseren Tests der Erstellungstool für SBOMs ging es um eine Reihe von Fragen: Welche Werkzeuge eignen sich, um gute SBOMs zu erzeugen? Gibt es das eine Werkzeug für alles oder sind es eher mehrere Werkzeuge, die sich je nach Situation am besten eignen?

Welche Werkzeuge eignen sich?

Hier zunächst die Liste der Werkzeuge für die Erzeugung von SBOMs, die wir nach intensiverer Recherche gefunden und entsprechend geprüft haben:

Werkzeug URL Einsatzbereich
cdxgen https://github.com/CycloneDX/cdxgen Maven, NPM, Docker, OS
cyclonedx-maven-plugin https://github.com/CycloneDX/cyclonedx-maven-plugin Maven
build-info-go https://github.com/jfrog/build-info-go Maven, NPM
Syft https://github.com/anchore/syft Java, NPM, Docker
sbom-tool https://github.com/microsoft/sbom-tool Java, NPM, Docker
spdx-sbom-generator https://github.com/opensbom-generator/spdx-sbom-generator Maven, NPM
spdx-maven-plugin https://github.com/spdx/spdx-maven-plugin Maven
scancode-toolkit https://github.com/nexB/scancode-toolkit Maven, NPM
cyclonedx/cyclonedx-npm https://www.npmjs.com/package/@cyclonedx/cyclonedx-npm NPM
Trivy https://aquasecurity.github.io/trivy/ Maven, NPM, Docker

 

Diese Werkzeuge haben wir für unsere Tests entweder auf Linux oder Windows installiert und eine SBOM mittels eines  entsprechenden Aufruf auf Basis der Dokumentation erzeugt. Die daraus resultierenden SBOMs wurden dann gemäß unserer Testkriterien miteinander verglichen. Die Bewertungen fielen sehr unterschiedlich aus:

Prädikat: Durchgefallen!

Drei Tools sind in unseren Tests durchgefallen. Sie erfüllten die Kriterien nicht oder unzureichend und sind daher aus unserer Sicht aktuell nicht zweckdienlich:

spdx-sbom-generator

  • Die erzeugte SBOM beinhaltete keine Lizenzinformationen für die Maven Artefakte.
  • Vereinzelt fehlten Versionsnummern, was vermuten lässt, dass die durch Maven dokumentierten  Abhängigkeiten nicht sauber ausgewertet werden.
  • Das Projekt an sich scheint aktuell nicht im aktiven Zustand zu sein: Es gab keine signifikanten Commits in der letzten Zeit dafür eine Reihe offener Pull Requests.
  • Vereinzelt hatten wir Abstürze.

scancode-toolkit:

  • Das Maven Projekt wird nicht im Ansatz vollständig abgebildet (es wurde nur eine Dependency gefunden).
  • Die SBOM beinhaltet auch hier keine Lizenzen für die Maven Artefakte.
  • Die Ausführung dauerte sehr viel länger als bei anderen Tools (ohne entsprechendem „mehr“ an Qualität).
  • Das Projekt hat eine große Anzahl offener Tickets. Bei dem NPM-Projekt haben wir die Ausführung nach langer Zeit abgebrochen. Hier scheint scantool überfordert.

build-info-go:

  • Der SBOM fehlen aktuell die Lizenzinformationen der einzelnen Maven Artefakte.
  • Sie beinhaltet gefühlt nur das Notwendigste.
  • Für Angular scheint das Werkzeug Dependencies und auch Vulnerabilities zu finden, die SBOM ist aber faktisch leer (siehe z. B. https://github.com/jfrog/build-info-go/issues/210).

Diese Tools erfüllten in unterschiedlicher Güte unsere Kriterien von „Empfehlenswert!“ über „Ganz in Ordnung“ bis „Naja …“:

Prädikat: Empfehlenswert!

  • cdxgen für Maven und NPM-basierende Projekte. (wobei für Maven Projekte intern das cyclonedx-maven-plugin nutzt, in der Nachverarbeitung aber in Details patzt). Hier hat auch der Detailierungsgrad der Informationen beeindruckt, wenn man cdxgen eine SBOM für eine Betriebssystem (Linux, Windows) erstellen lässt. Für Docker-Images liefert syft bei mehr Distribution die gewünschte Qualität.
  • Eben das besagte cyclonedx-maven-plugin für Maven Projekte.
  • cyclonedx-npm für NPM-Projekte.
  • syft für Docker-Images (hier klar bevorzugt vor cdxgen, welches nicht alle getesteten Distributionen unterstützt) aber grundsätzlich auch mit leichten Abstrichen für Maven -Projekte. Hier ist wichtig zu verstehen, dass die Auswertung der Maven POM von syft „naiv“ ist, syft in der Praxis die SBOM aber nahezu gleichwertig durch die Auswertung der gebauten Jars erstellen kann. Hier ist die SBOM genau zu analysieren und ggf. die Cataloger entsprechend zu konfigurieren. Im NPM-Kontext werden die Dev-Dependencies mit gelistet, was uns nicht sinnvoll erscheint.
  • Trivy für Docker-Images mit leichten Abstrichen gegenüber syft (manuelle installierte JDKs nicht erkannt). Ebenso nutzbar für Maven Projekte und NPM-Projekte, wobei bei NPM-Projekten oft die Lizenzangaben fehlten.
  • spdx-maven-plugin: Im direkten Vergleich sehen wir das cyclonedx-maven-plugin als besser an und nehmen es auch als aktiveres Projekt war.

Prädikat: Ganz In Ordnung

Wesentlicher formaler Mangel bei cylonedx-npm, cyclonedx-maven-plugin sowie cdxgen ist die unzureichende Unterstützung für CPEs. Das scheint aber bei der Auswertung bzgl. CVEs aktuell nicht entscheidend zu sein.

Prädikat: Naja …

Das sbom-tool konnte uns in keiner der Projektarten wirklich überzeugen. Es liefert in allen Varianten eher rudimentäre Informationen.

Summary

Wir waren von der doch stark unterschiedlichen Qualität zugegebenermaßen überrascht, sind doch die Werkzeuge entweder schon länger verfügbar oder haben eine kommerzielle Firma im Rücken.

Unser Gefühl ist, dass viele Werkzeuge ihren Schwerpunkt auf die Analyse von Inhalten von Docker-Images setzen, was aus unserer Sicht nicht falsch ist (den die dort manuell installierte Software oder in den Paketen der genutzten Linux-Distribution können ja auch Sicherlücken haben).

Allerdings sieht man auch klar, dass bzgl. der abhängigen Software-Komponenten die Werkzeuge, die die Build-Informationen sauber auswerten, zu vollständigen und auch qualitativ besseren Informationen kommen,

Daher wird man aktuell entweder in der Praxis mit mehreren Werkzeugen arbeiten müssen, oder eben bei einem Tool ggf. qualitative Abstriche in Kauf nehmen müssen.

Wie geht es weiter?

Im nächsten Teil werdet ihr sehen, inwiefern die Qualität des Vulnerability Scannings direkt mit der Qualität der SBOM zu tun hat.

Danach geht es weiter mit Fragen wie diesen:

  • 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

Avatar-Foto
Alle Beiträge von Dominik Kloke

Dominik ist leidenschaftlicher Softwareentwickler aus Berlin. Mit fundierten Kenntnissen in Informatik schafft er innovative Lösungen für reale Probleme.

Alle Beiträge von Tim Teulings

Tim Teulings ist als Senior Solution Architekt bei OPITZ CONSULTING tätig. Er unterstützt Software-Entwicklungsteams dabei, schnell, einfach und entspannt Software aufzubauen, die perfekt zum Kunden passt. Am Ende stehen Ergebnisse, die der Kunde wirklich haben will – nicht nur eine Version 1.0. Die Themenbereiche Modernisierung und Integration gehören in dieser Funktion zu seinem täglichen Geschäft. Zu Tims Schwerpunkten zählen entsprechende Tools, Frameworks, Methoden, Vorgehen, Architekturen und Techniken.

Schreibe einen Kommentar