SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 6: Was können die Vulnerability Scanner Trivy und Grype?

SBOMs helfen, Sicherheitslücken zu erkennen, die sich im eigenen Code befinden. Dafür werden Vulnarability Scanner gebraucht. Im Folgenden möchten wir zwei Tools vorstellen, die bei diesem Problem helfen können:

Name Mögliche Scan-Ziele Verwendete Datenbanken
Trivy fs, image, sbom Trivy-db siehe Sources
Grype fs, image, sbom https://github.com/anchore/grype#grypes-database

 

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

Was können die Scanner von SBOM-Dateien?

Scanner wie Trivy und Grype unterstützen das Scannen verschiedenster Ziele. Hierbei ist allerdings zu beachten, dass die Scanner – je nach Ziel des Scans – verschiedene Ansätze haben. Im Falle einer SBOM versucht der Scanner nicht selbst, weitere Softwareabhängigkeiten zu ermitteln, sondern gibt nur für die in der SBOM eingetragenen Abhängigkeiten CVEs aus.

Vergleich der Vulnerability Scanner Trivy und Grype 

In diesem Abschnitt werden die Ergebnisse der Tools Trivy und Grype gegenübergestellt. Dabei wurden beide Scanner jeweils gegen die mit verschiedenen Werkzeugen generierten SBOMs sowie gegen das zugrunde liegende Java Maven-Projekt ausgeführt. 

Trivy

Ziel des Scans
Anzahl gefundener CVEs
Anmerkungen
Dateisystem  Low: 0
Medium: 6

High: 7
Critical: 0
Gesamt: 13 
Cdxgen SBOM
spring-pestclinic-rest 
Low: 0
Medium: 7

High: 8
Critical: 2
Gesamt: 17 
Zusätzlich werden CVEs gefunden in:
org.springframework.security:spring-security-config 
org.springframework.boot:spring-boot-actuator-autoconfigure
 
Maven Cyclonedx Plugin
SBOM spring-pestclinic-rest
Low: 0
Medium: 7

High: 8
Critical: 2
Gesamt: 17 
Identisch zu cdxgen-java-bom.json
Syft SBOM 

spring-pestclinic-rest 

Low: 1
Medium: 9

High: 22
Critical: 13
Gesamt: 45
Findet zusätzliche CVEs  in:
com.fasterxml.jackson.core:jackson-databind
mysql:mysql-connector-java
org.postgresql:postgresql
org.hsqldb:hsqldb 
SBOM Tool SBOM 

spring-pestclinic-rest 

Low: 0
Medium: 6

High: 8
Critical: 0
Gesamt: 14
Zusätzliche CVE in:
net.minidev:json-smart
Trivy SBOM 

spring-pestclinic-rest

Projekt pom.xml:
Low: 0
Medium: 7

High: 8
Critical: 2
Gesamt: 1
/target/generated/pom.xml:
Low: 0
Medium: 8
High: 10
Critical: 0
Gesamt: 18
 
Scannt die pom.xml im Projekt und die generierte in
/target/generated-sources/openapi/pom.xml
 

Grype

Ziel des Scans
Anzahl gefundener CVEs
Anmerkungen
Dateisystem  Low: 1
Medium: 15

High: 32
Critical: 23
Gesamt: 71
Grype erkennt hier nicht immer die tatsächlich installierte Version einer Bibliothek und findet so False Positives. 
Cdxgen SBOM
spring-pestclinic-rest 
Low: 0
Medium: 7

High: 8
Critical: 2
Gesamt: 17 
Identisches Ergebnis wie Trivy 
Maven Cyclonedx Plugin
SBOM spring-pestclinic-rest
Low: 0
Medium: 7

High: 8
Critical: 2
Gesamt: 17 
Identisches Ergebnis wie Trivy 
Syft SBOM 

spring-pestclinic-rest 

Low: 1
Medium: 9

High: 22
Critical: 13
Gesamt: 45
Identisches Ergebnis wie Trivy 
SBOM Tool SBOM 

spring-pestclinic-rest 

Low: 0
Medium: 6

High: 8
Critical: 0
Gesamt: 14
Identisches Ergebnis wie Trivy 
Trivy SBOM 

spring-pestclinic-rest

Low: 0
Medium: 13

High: 12
Critical: 2
Gesamt: 27 
Reportet mehr CVEs als Trivy für die im Projekt verwendeten Bibliotheken

Fazit

Vergleicht man die Resultate des SBOM Scannings, sieht man direkt, dass sich beide Tools nicht viel nehmen. Dies liegt nach unserem Verständnis daran, dass die zugrundeliegenden CVE-Datenbanken nahezu identisch sind. Entscheidender scheint vielmehr zu sein, mit welchem Tool die SBOM erstellt wurde.

  • Beim Scannen der SBOMs von syft fällt auf, dass mehr CVEs gefunden werden. Dies liegt aber daran, dass syft für einige Softwareabhängigkeiten keine Version findet und in der Folge CVEs gefunden werden, von denen du nicht betroffen bist.
  • Eine Besonderheit von Trivy sei an dieser Stelle hervorgehoben: Trivy kann selbst SBOMs in den gängigen Standards generieren. Deshalb könnte das Tool eine „Rundumlösung“ darstellen.
  • Grype findet beim Scannen des Filesystems mehr CVEs als Trivy. Das liegt daran, dass es mit seinem „Katalog“ mehr Softwarekomponenten erkennt. Allerdings findet er nicht immer ihre Version. Das heißt das Ergebnis ist garantiert nicht frei von „falsch positiven“ Treffern.
  • Beide Tools haben eine JSON-Ausgabe, um einen Custom Report mit anderen Tools zu erstellen. 

Bewertung und Empfehlung

Möchte man sich möglichst umfassend und korrekt absichern, macht die Kombination von Syft und Grype Sinn. Beide Tools sind Open Source und kommen von der Firma Anchore. Im Gegensatz zu Trivy kannst du mit Syft mehr Einfluss darauf nehmen, wie Abhängigkeiten im Projekt erkannt werden. Hierfür stellt Anchore verschiedene Mechanismen (sogenannte„Kataloge“) zur Verfügung.  

Möchtest du nur ein Tool einsetzten, empfehlen wir Trivy. Denn Trivy kann beide Aufgaben erledigen und stellt damit wie oben erwähnt eine Rundum-Lösung dar. Allerdings solltest du immer auch die Nachteile beachten, die bei der Generierung der SBOM mit Trivy entstehen.

Wie geht es weiter?

Im nächsten Teil werfen wir einen Blick auf die Möglichkeit, mithilfe von SBOMs die Kompatibilität von Lizenzen auszuwerten.

Danach geht es weiter mit Fragen wie diesen:

  • 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?

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