SAST-Tools im Geschwindigkeitsvergleich: Snyk Code vs. SonarQube und LGTM

Wir wurden gebeten, die Scan-Zeiten von Snyk Code und zwei verbreiteten SAST-Tools zu vergleichen: LGTM und SonarQube. Für unsere Untersuchung haben wir einige Annahmen getroffen. Um transparent zu sein, legen wir die Details offen.

Kurz zusammengefasst 

Static Application Security Testing (SAST) ist nur dann entwicklerfreundlich, wenn es nahezu in Echtzeit Feedback liefert und Ihre Entwicklungsprozesse nicht verzögert. Snyk Code ist bis zu 106-mal schneller als LGTM. Im Durchschnitt ist Snyk Code fünfmal schneller als SonarQube und 14-mal schneller als LGTM. Zusammenfassend erweist sich Snyk Code als eine der schnellsten semantischen Scan-Engines auf dem Markt.

Testfeld

Wir haben 48 Open-Source-Repositories mit JavaScript ausgewählt (siehe Liste unten). Damit wollten wir typische moderne Entwickler-Codebasen nachbilden. JavaScript schien dafür eine geeignete gemeinsame Grundlage zu sein. Um reale Herausforderungen abzubilden, haben wir eine zufällige Stichprobe aus den am besten bewerteten Repositories auf GitHub ausgewählt.

Als Scanner haben wir die Community Edition von SonarQube verwendet, ein weit verbreitetes Open-Source-Tool für statische Analysen. Da es lokal ausgeführt wird, brauchten wir einen recht leistungsfähigen PC. Frühere Tests mit der kostenlosen SonarCloud-Edition haben gezeigt: SonarQube ist auf einem guten PC schneller als die kostenlose SonarCloud-Version. Es ist daher fair, statt der Cloud-Version die lokale Engine zu verwenden. Wir mussten dafür auf einen der vorhandenen Entwicklerrechner zurückgreifen (Details unten). Der zweite Kandidat ist LGTM, das ursprünglich von Semmle stammt, einem von GitHub übernommenen Unternehmen. LGTM verwendet eine tiefgehende semantische Codesuche auf Basis von CodeQL. Wir haben das LGTM-SaaS-Angebot genutzt.

Schließlich ist Snyk Code die SAST-Lösung von Snyk. Sie basiert auf der früheren DeepCode-Scan-Engine, die inzwischen mehrere Monate zusätzlicher Entwicklungsarbeit bei Snyk durchlaufen hat. Neben ihrer Entwicklerfreundlichkeit und hohen Genauigkeit ist eines der Designziele von Snyk Code eine besonders hohe Geschwindigkeit. Dafür kommt eine proprietäre Constraint-Engine zum Einsatz. Wir haben dieses Testfeld ausgewählt, weil (1) die Lizenzen Vergleichstests erlauben, (2) es sich um semantische Engines und nicht um Linter wie ESLint handelt, (3) diese Engines weit verbreitet sind und (4) sowohl eine lokal ausgeführte Engine als auch ein SaaS-Angebot vertreten sind.

Geschwindigkeit ist entscheidend, wenn eine SAST-Lösung entwicklerfreundlich sein soll. Es ist allgemein bekannt, dass Entwickler am effizientesten arbeiten, wenn Sicherheitsprobleme während der Entwicklung erkannt werden und sich beheben lassen, bevor der Code eingecheckt wird. Dann ist ihnen der Code noch präsent. Snyk Code bietet IDE-Plugins, die sich nahtlos in den Entwickler-Workflow integrieren. Darüber hinaus stellt Snyk Code leicht verständliche Datenflussdiagramme und ausführliche Erklärungen bereit, einschließlich Beispielen für Korrekturen in Open-Source-Bibliotheken mit demselben Kontext. Für diesen Test haben wir uns jedoch auf die Geschwindigkeit konzentriert.

Für unseren Test haben wir jedes Repository einmal gescannt: SonarQube lokal, LGTM und Snyk Code als SaaS. Wie oben erwähnt, haben wir die Repositories so ausgewählt, dass die Scan-Zeiten nicht von der Netzwerkbandbreite abhängen.

Außerdem haben wir reale Open-Source-Repositories statt Benchmarks ausgewählt, da wir nachbilden wollten, was Entwickler tatsächlich tun. Benchmarks für den Vergleich von SAST-Tools bringen eigene Probleme mit sich und hätten uns in diesem Fall nicht weitergeholfen.

Testergebnisse

Unten finden Sie die allgemeinen statistischen Werte (gerundet) für die Scan-Zeit in Sekunden (n=48, auf ganze Zahlen gerundet):

Hier sehen Sie die Ergebnisse als Streudiagramm (niedrigere Werte sind besser, logarithmische Skala, erstellt mit R und ggplot2):

Die logarithmische Achse überbetont die Streuung im unteren Bereich. Die Standardabweichung von Snyk Code ist beispielsweise tatsächlich deutlich geringer als die von SonarQube.

Unten sehen Sie ein Boxplot der Werte (niedrigere Werte sind besser; für die Darstellung aller Werte im Diagramm haben wir eine logarithmische Skala verwendet; erstellt mit R und ggplot2; Median und Durchschnitt sind eingezeichnet):

Das Diagramm zeigt deutlich, dass Snyk in den meisten Fällen dramatisch schneller ist als die beiden anderen Tools. Der Median von Snyk ist 6,7-mal (SonarQube) bis 16,4-mal (LGTM) schneller. Das zeigt, dass die Ergebnisse nicht auf einigen besonders guten Ausreißern beruhen, sondern allgemein gelten.

Im obigen Diagramm fällt die Streuung der Werte in der LGTM-Spalte auf. Sie reicht ungefähr von 2 Minuten (noch akzeptabel) bis zu mehr als 17 Minuten (nicht akzeptabel). Entwickler werden während ihres Arbeitstags nicht mehrere Minuten auf Ergebnisse warten. Zum Glück liegt der LGTM-Median bei etwa 3 Minuten.

Im Vergleich zum ersten Geschwindigkeitstest, den wir damals noch als DeepCode und jetzt als Snyk Code durchgeführt haben, stellten wir deutliche Leistungsverbesserungen fest. In den vergangenen Monaten haben wir das Laden in den Cloud-Service erheblich optimiert. Außerdem war SonarQube diesmal schneller, wahrscheinlich weil wir im Vergleich zum ersten Test einen leistungsfähigeren PC mit mehr Parallelisierungsmöglichkeiten verwendet haben.

Eine weitere interessante Beobachtung: SaaS-Engines und lokal installierte Engines unterscheiden sich in puncto Geschwindigkeit gar nicht so sehr.

Annahmen und Einschränkungen

• Wir haben SonarQube (Community Edition 8.9.1) und LGTM ausgewählt, da die Lizenzen solche Vergleiche erlauben und beide Tools weit verbreitet sind.

• Wir haben 48 mittelgroße JavaScript-Repositories ausgewählt, da dieses Testfeld die Arbeit typischer Entwickler abzubilden scheint. Die zufällige Stichprobe stammt aus den rund 200.000 nach Sternen sortierten GitHub-Repositories. Die Codegröße war kein Auswahlkriterium.

• Wir haben einen vollständigen Scan erzwungen und keinen differentiellen Scan verwendet. Snyk Code führt beispielsweise in IDE-Plugins nach einem ersten Scan differentielle Scans durch und spart dadurch Bandbreite.

• Wir haben einen Intel Xeon mit 2 GHz, 16 Kernen und 64 GB RAM verwendet.

Rohdaten

Wir stellen auch die Rohdaten bereit, damit Sie Ihre eigenen statistischen Auswertungen vornehmen können. (Zeiten in Sekunden)