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:

• 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
• Teil 4: Was ist eine gute SBOM – Das Versuchssetting

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:

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

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

Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?

Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks

Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess

Teil 9: Halten SBOMs, was sie versprechen?