3 Parameter zur Messung von SAST-Tests

In unserem vorherigen Blogbeitrag darüber, warum Sie SAST-Tools nicht ausschließlich anhand von Listen, Testsuiten und Benchmarks vergleichen können, haben wir die verschiedenen Tools und Metriken beleuchtet, die heute üblicherweise zur Bewertung und zum Vergleich von SAST-Testtools eingesetzt werden. Außerdem haben wir einige Gründe dafür betrachtet, warum diese Tools uneinheitliche Ergebnisse liefern und sich für die Bewertung eines SAST-Testtools möglicherweise gar nicht eignen.

Stattdessen sollten Sie bei der Bewertung eines SAST-Testtools drei Parameter berücksichtigen:

• Genauigkeit

• Vollständigkeit

• spezifische zusätzliche Mehrwerte

In diesem Blogbeitrag sehen wir uns diese Parameter und Möglichkeiten zu ihrer Messung an. Bei der Bewertung eines SAST-Testtools sind zwei Arten von Messungen relevant: quantitative (Anzahl der Ergebnisse im Verhältnis zum „Rauschen“) und qualitative (insbesondere Sprachabdeckung und -tiefe).

Quantitative Aspekte

Die folgenden Definitionen von Genauigkeit und Vollständigkeit wirken zunächst etwas komplex, da sie zwei Seiten derselben Medaille sind. Eine perfekte statische Programmanalyse ist mathematisch unmöglich (gemäß dem Satz von Rice). Man könnte meinen, dass mehr Vorschläge alle möglichen Probleme aufdecken würden. Leider steigt dadurch auch die Zahl der falsch positiven Ergebnisse (FPs) so stark an, dass das Rauschen die Ergebnisse unbrauchbar macht. Anbieter von SAST-Tests können einige Tricks anwenden, um die Ergebnisse zu verbessern. Perfektion ist jedoch mathematisch unmöglich.

Genauigkeit

Im Kontext von SAST-Tests bedeutet Genauigkeit vereinfacht gesagt, möglichst viele TPs (richtig positive Ergebnisse, also tatsächliche Probleme) zu erzielen und gleichzeitig möglichst wenige FPs (Ergebnisse, bei denen es sich nicht um Schwachstellen handelt und die daher falsch sind).

Genauigkeit ist besonders wichtig. Eine hohe Genauigkeitsrate bedeutet mehr umsetzbare Ergebnisse und weniger „Rauschen“ (irrelevante, nicht umsetzbare Meldungen). „Rauschen“ ist auch der Hauptgrund dafür, dass Entwickler:innen von SAST-Testprodukten abgeschreckt werden. Je höher die Genauigkeit, desto besser ist also insgesamt die Developer Experience.

Um die Genauigkeit zu berechnen, müssen Sie zunächst die Ergebnisse triagieren. Die Formel lautet dann TP*100/(TP+FP). Das ergibt einen Wert zwischen 1 und 100. Je höher der Wert, desto größer die Genauigkeit. Ein Tool, das beispielsweise 140 TPs und 40 FPs findet, erreicht eine Genauigkeitsrate von 77,7 %.

Vollständigkeit

Das NIST definiert: „Vollständigkeit, manchmal auch Trefferquote (Recall Rate) genannt, misst die Zahl der gefundenen tatsächlichen Probleme (TPs) im Verhältnis zu allen möglichen Problemen (TPs und falsch negativen Ergebnissen). Je höher die Vollständigkeit (bis zum theoretischen Maximum von 1), desto besser deckt ein Tool die im Code vorhandenen Probleme ab.“ Konkret geht es um die Anzahl der übersehenen tatsächlichen Probleme, also der falsch negativen Ergebnisse (FNs).

Je vollständiger das Tool ist, desto besser sind Ihre Transparenz und Ihr Schutz. Das kann natürlich auch zu mehr Ergebnissen führen. In Verbindung mit einer hohen Genauigkeitsrate sollten die meisten davon jedoch relevant sein. Dabei spielt der Schweregrad der Ergebnisse immer eine wichtige Rolle für die Vollständigkeit: Tausend FNs mit niedrigem Schweregrad sind nicht unbedingt problematisch, wenn Sie das Rauschen minimieren möchten. Als Faustregel gilt: Je weniger FNs, desto besser. Wichtig ist außerdem zu wissen, wie Sie sie erkennen können, damit tatsächliche Schwachstellen nicht übersehen werden.

Diese Metrik lässt sich nur ermitteln, wenn Ihnen Schwachstellen in Ihrem Code bekannt sind oder wenn Sie mehrere Tools vergleichen und Unterschiede bei den Ergebnissen feststellen. Alternativ können Sie den Schweregrad der FNs betrachten und sich zunächst auf die mit der höchsten Priorität konzentrieren. FNs sind schwer zu messen, da sie unbekannte Unbekannte sind. Kompromisse sind unvermeidbar. Die Erfahrung zeigt, dass in nicht trivialen Projekten immer mit FNs zu rechnen ist. In der Cybersicherheit können Sie es sich nicht leisten, sich in falscher Sicherheit zu wiegen.

Der qualitative Aspekt

Bei der qualitativen Messung geht es darum, wie Sprach- und Schwachstellenabdeckung umgesetzt werden. Wie wir im vorherigen Blogbeitrag gezeigt haben, ergibt es ein unvollständiges Bild, wenn Sie sich nur auf bekannte Schwachstellenlisten, Testsuiten und absichtlich verwundbare Repositories stützen. Ein gutes SAST-Tool geht deshalb über solche Listen hinaus.

Diese Messung lässt sich in zwei Bereiche unterteilen: Sprach- und Schwachstellenabdeckung sowie Tiefe und Genauigkeit.

Wie wird die Sprachabdeckung bestimmt?

Es ist wichtig zu verstehen, wie die Sprachabdeckung für das von Ihnen bewertete SAST priorisiert und bestimmt wird.

Wir wissen bereits, dass Schwachstellenlisten nicht ausreichen. Ein umfassenderer Ansatz führt Daten aus mehreren Quellen zusammen, um eine solide Sprachabdeckung zu schaffen, die sowohl den aktuellen Cyberrisiken entspricht als auch kontextuell relevant ist.

Listen können zwar als Referenz dienen, doch es gibt weitere Quellen, die Sie berücksichtigen sollten:

• Nachrichtenquellen: Sicherheitslücken, die gerade im Trend liegen, und neu veröffentlichte Angriffsvektoren werden mit größerer Wahrscheinlichkeit ausgenutzt

• Bekannte Schwachstellendatenbanken und Exploit-Daten wie die NVD-Datenbank und die Snyk Vulnerability Database.

• Best Practices und kontextbezogene Informationen zu bestimmten Sprachen und Frameworks

• Forschung zu Zero-Day-Schwachstellen, etwa zu neuen oder bestehenden Mustern

Um zu bestimmen, welche Sprachen und Frameworks Snyk Code unterstützen sollte, nutzen wir all diese und weitere Quellen, um eine Liste der relevantesten Probleme zu erstellen, die für unsere Kund:innen wichtig sind.

Wie werden Sprachabdeckung, -tiefe und Genauigkeit umgesetzt?

Eine umfassende Liste unterstützter Sprachen und Schwachstellen ist zwar ein wichtiger erster Schritt, aber Sie müssen auch berücksichtigen, wie gut sich diese Unterstützung in den Ergebnissen widerspiegelt.

Ein SAST-Tool beispielsweise, das sich darauf verlässt, dass die Open-Source-Community neue Regeln entwickelt und bereitstellt, ohne dass diese streng geprüft werden, ist anfällig für eine hohe Zahl von FPs und liefert häufig uneinheitliche Ergebnisse für verschiedene Sprachen und Schwachstellen.

Bei Snyk Code arbeitet ein Team engagierter Sicherheitsforscher:innen kontinuierlich daran, weitere Sprachen und Schwachstellen zu unterstützen und die bestehende Abdeckung durch mehr Tiefe und Genauigkeit zu verbessern.

Wie schnell entwickelt und wartet sich das SAST?

Wie oben gezeigt, sind Wartung und kontinuierliche Weiterentwicklung einer SAST-Lösung wichtig. Dabei spielen zwei Bereiche eine Rolle: die Produkt-Roadmap und die Fähigkeit des Unternehmens oder der Community, sie umzusetzen. Angesichts der jüngsten Fortschritte im maschinellen Lernen ist es interessant zu sehen, wie diese in die Roadmap einfließen. Wichtig sind außerdem die Unterstützung moderner Sprachen, der Einsatz einer modernen Engine und die Geschwindigkeit, mit der neue Sprachen hinzugefügt werden.

Zweitens ist es wichtig zu verstehen, wie gut ein Unternehmen oder eine Community die SAST-Wissensdatenbank pflegen kann. Wie bereits erwähnt, erfordert Sicherheit kontinuierliche Beobachtung und Reaktionen auf verschiedene Quellen.

Alles zusammenführen

Nach der quantitativen Bewertung möchten Sie nun wissen, wie sich das Tool in der Praxis bewährt. Die beste Sprach- und Schwachstellenabdeckung reicht nicht aus, wenn das Tool zu viele Ergebnisse liefert (selbst wenn es TPs sind) oder umgekehrt viel Rauschen (FPs) erzeugt. Sicherheitsfachkräfte wünschen sich ein hohes Maß an Vollständigkeit, Entwickler:innen hingegen eher praktische Hinweise, mit denen sie Probleme konkret beheben können. Wichtig ist daher ein ausgewogenes Verhältnis zwischen der Zahl der Vorschläge, ihrer Priorisierung und der Fähigkeit des Entwicklungsteams, sie umzusetzen. Unsere Erfahrung und Forschung zeigen, dass eine Flut von Vorschlägen Entwickler:innen demotiviert und den Prozess sogar verlangsamt – insbesondere bei geringer Genauigkeit.

Aus qualitativer Sicht empfehlen wir, eine Liste der für Ihre Umgebung relevanten Aspekte zu erstellen, eine Matrix aufzubauen und die Werte der einzelnen Mitbewerber einzutragen.

Für die quantitative Messung empfehlen wir, echte Projekte auszuwählen, mit denen Sie vertraut sind. Am besten eignet sich ein eher kleines bis mittelgroßes Projekt. Wie im vorherigen Blogbeitrag erwähnt, sollten Sie auf absichtlich verwundbare Apps verzichten, da sie den tatsächlichen Nutzen des Tools wahrscheinlich nicht widerspiegeln.

Nachdem Sie das SAST ausgeführt und die Ergebnisse erhalten haben, müssen Sie sie triagieren. Bei der Triage wird festgestellt, ob ein bestimmtes Ergebnis ein TP (ein tatsächliches Problem) oder ein FP (kein tatsächliches Problem) ist. SAST-Ergebnisse sind oft kontextabhängig. Deshalb ist es wichtig, das gescannte Projekt gut zu kennen. Letztlich lassen sich persönliche Fachkenntnis und praktische Arbeit nicht durch vorgefertigte Benchmark-Ergebnisse ersetzen.

Zum Schluss müssen Sie die Genauigkeit und Vollständigkeit anhand der zuvor in diesem Beitrag genannten Formeln berechnen.

Warum nicht einfach alle Tools sammeln und ausführen?

Wie oben gezeigt, liefert jedes Tool TPs und FPs. Es mag sinnvoll erscheinen, einfach alle verfügbaren Tools einzusetzen. In der Praxis übersteigt der Aufwand, das Rauschen herauszufiltern, jedoch den Mehrwert eines weiteren Tools. Entwickler:innen müssen doppelte Vorschläge aus verschiedenen Tools in unterschiedlichen Formaten bearbeiten. Das verursacht viel zusätzlichen Aufwand, ganz zu schweigen von Laufzeitbeschränkungen. Zwar lassen sich so FN- und FP-Zahlen ermitteln, für den kontinuierlichen Betrieb ist das jedoch nicht praktikabel. Unserer Erfahrung nach ist eine entwicklerfreundliche Plattform am wichtigsten. Wenn Sie in einer besonders sicherheitskritischen oder regulierten Umgebung arbeiten, können Sie später im CI/CD-Prozess spezialisierte Tools ergänzen.

Ein SAST-Tool ist zweifellos ein leistungsstarkes Werkzeug, das in den „Werkzeugkasten“ jeder entwickelnden Person gehört und die Anwendungssicherheit entscheidend verbessern kann. Daher ist es unerlässlich, das beste Tool für Sie und Ihre Organisation auszuwählen. Wir hoffen, dass Ihnen die Informationen und Schritte in diesem und im vorherigen Blogbeitrag dabei helfen, fundiertere Entscheidungen zu treffen.