SAST-Tools lassen sich nicht allein anhand von Listen, Testsuiten und Benchmarks vergleichen

Bei der Suche nach dem besten SAST-Tool für Ihr Team gibt es viele Herausforderungen. Doch wie lässt sich etwas messen, das Unbekanntes aufspüren soll? Woher wissen Sie, ob das Tool Ihren Anforderungen entspricht? Wie vergleichen Sie verschiedene Tools? Kein Wunder, dass wir oft gefragt werden: „Deckt Snyk Code die OWASP Top 10 ab?“  Darauf folgt meist die Frage: „Wie empfehlen Sie uns, verschiedene SAST-Tools zu bewerten und zu vergleichen?“

Wir alle wünschen uns einfache Antworten. Deshalb werden im Zusammenhang mit SAST-Vergleichen am häufigsten Studien und Listen der verbreitetsten Schwachstellen herangezogen, vor denen man sich schützen sollte (OWASP Top 10, SANS-25 usw.). Es mag naheliegend erscheinen, die Ergebnisse zweier SAST-Tools anhand dieser Listen zu vergleichen. Die Antwort ist jedoch nicht so einfach. In diesem Blogbeitrag beleuchten wir die Grenzen solcher Maßstäbe.

Bevor wir uns die einzelnen Standards genauer ansehen, klären wir zunächst einige grundlegende Begriffe.

• OWASP Top 10 ist eine Liste der zehn wichtigsten Risiken, die Entwickler beim Erstellen einer Webanwendung kennen sollten. Sie wird von der OWASP® Foundation veröffentlicht. Die letzte Überarbeitung stammt aus dem Jahr 2017.

• SANS-25 ist eine Liste der 25 gefährlichsten Arten von Softwarefehlern. Sie wird vom SANS Institute veröffentlicht. Die letzte Überarbeitung stammt aus dem Jahr 2011. 

• CWE Top 25 ist eine weitere Liste, die der SANS-25 sehr ähnlich ist, aber häufiger aktualisiert wird. Sie wird vom CWE Team veröffentlicht. Die letzte Überarbeitung stammt aus dem Jahr 2020.

• Benchmark ist eine Open-Source-Testsuite, die speziell für das Testen von SAST-Tools entwickelt wurde. Sie testet ausschließlich Java und wird aktiv gepflegt, auch wenn die letzte Hauptversion 2016 veröffentlicht wurde.

• Absichtlich verwundbare Apps sind Repositories oder Projekte, die aufklären und Beispiele für Schwachstellen bereitstellen sollen. Sie orientieren sich möglicherweise auch an einem der verschiedenen Standards. Diese Projekte wurden nicht für SAST-Tools entwickelt. Beispiele sind OWASP/NodeGoat, appsecco/dvna, WebGoat und juice-shop.

Legen wir los!

Warum sich Schwachstellenlisten nicht zur Bewertung von SAST-Tools eignen

Es gibt mehrere Gründe, warum verschiedene Schwachstellenlisten nicht geeignet sind, um SAST-Tools zu bewerten oder SAST-Funde zu priorisieren:

• Begrenzter Umfang: Manche Listen decken oft nur einen bestimmten Bereich ab. Die OWASP Top 10 bezieht sich beispielsweise ausschließlich auf die Sicherheit von Webanwendungen.

• Zu allgemein: SANS-25 und CWE Top 25 unterscheiden dagegen nicht zwischen Umgebungen und Programmiersprachen. Daher können die Listen viele Schwachstellen (oder CWEs) aufführen, die nicht für alle Sprachen relevant sind. CWE-416: Use After Free ist beispielsweise nur für Low-Level-Sprachen wie C, C++, Rust usw. relevant.

• Möglicherweise veraltet: Diese Listen werden oft nicht regelmäßig aktualisiert. Die OWASP Top 10 wurde zuletzt 2017 aktualisiert, SANS-25 zuletzt 2011. Die Listen spiegeln daher nicht unbedingt den aktuellen Stand der Anwendungssicherheit wider. Ein bemerkenswertes Beispiel ist die jüngste Zunahme von Supply-Chain-Angriffen und Typosquatting-Angriffen – keine der beiden Listen erwähnt diese Probleme.

• Für SAST nicht relevant – Manche Probleme sind im SAST-Kontext nicht unbedingt von Bedeutung (was nicht heißt, dass sie generell unwichtig sind). Die OWASP Top 10 führt beispielsweise unzureichendes Logging und Monitoring auf, was für sich genommen keine Schwachstelle ist.

Warum sich Testsuiten und absichtlich verwundbare Apps nicht zur Bewertung von SAST-Tools eignen

Testsuiten wie OWASP Benchmark und verwundbare Repositories haben ebenfalls ihre Grenzen:

• Begrenzte Auswahl an Programmiersprachen: Es gibt keine Testsuite und keine absichtlich verwundbare App, mit der sich mehrere Programmiersprachen testen lassen. OWASP Benchmark enthält beispielsweise ausschließlich Java-Schwachstellen.

• Überanpassung: Gibt es einen „Marktstandard“ an Testsuiten oder absichtlich verwundbaren Apps, können Unternehmen ihre SAST-Funktionen gezielt auf diese bestimmten Probleme ausrichten. Dadurch schneiden ihre Produkte in diesen Benchmarks außergewöhnlich gut ab. Das bedeutet leider nicht unbedingt, dass sie in der Praxis genauso präzise und umfassend sind.

• Semantisch ganzheitlich:Die Beispiele in Benchmarks und verwundbaren Apps spiegeln häufig nicht die Realität wider: In echten Anwendungen sind Datenflüsse oft komplexer.

Also … wie vergleichen Sie SAST-Tools?

Wir haben uns die verschiedenen verfügbaren Tools angesehen und erläutert, warum sie sich nicht ideal zur Bewertung von SAST-Tools eignen. Das bedeutet jedoch nicht, dass solche Listen, Testsuiten und Benchmarks nutzlos sind. Die meisten dieser Tools wurden entwickelt, um Entwickler aufzuklären und das Bewusstsein für gängige Sicherheitsprobleme zu schärfen. Auch wenn sie sich nicht gut zur Messung der Leistung eines SAST-Tools eignen, können sie unserer Ansicht nach entscheidend dazu beitragen, die Sicherheitskompetenz in Ihrem Unternehmen zu verbessern.

Vielleicht fragen Sie sich jetzt: Wenn sich die oben genannten Standards als unzureichend erwiesen haben, wie lässt sich die Leistung von SAST-Tools dann messen? In unserem Folgeblog erfahren Sie mehr über 3 Parameter zur Messung von SAST-Tests.