Warum Developer-first-SAST-Tools die Zukunft der Code-Sicherheit sind
28. April 2021
0 Min. LesezeitApplication Security umfasst zahlreiche Bereiche für Teams, die Cloud-native-Anwendungen entwickeln und bereitstellen. Die Bandbreite reicht von vielen Prozessen, Tools und Teammitgliedern bis hin zur Automatisierung von sicheren Pipelines (DevSecOps lässt grüßen), Open-Source-Sicherheit und Sicherheitstests für Cloud-Infrastrukturen. Einige dieser Methoden für Application-Security-Tests konzentrieren sich auf die Code-Sicherheit und sind offiziell als Tools für Static Application Security Testing (SAST) anerkannt – manchmal auch als Tools für statische Codeanalyse bezeichnet.
Wenn Ihnen der Fachbegriff SAST nicht geläufig ist, beginnen wir mit einer Einführung in die Grundlagen. Anschließend erfahren Sie, wie Developer-first-SAST-Tools die gesamte Sicherheitsbranche prägen werden.
Was sind SAST-Tools?
SAST-Tools sind Tools für Static Application Security Testing, die Quellcode analysieren, um nachzuvollziehen, wie Daten von potenziellen Benutzereingaben bis hin zu sensiblen Operationen der Application Programming Interface fließen. Ein SAST-Tool kann beispielsweise erkennen, ob eine Benutzereingabe in einem Suchfeld möglicherweise eine datenbankbezogene Funktion auslöst, die eine Abfrage auf unsanitisierte, unsichere und unbeabsichtigte Weise ausführt (auch bekannt als Sicherheitslücke durch SQL-Injection).
Herkömmliche SAST-Tools und warum sie gescheitert sind
Static Application Security Testing ist kein neues Konzept. Tatsächlich beschäftigen sich bereits seit Jahrzehnten zahlreiche Tools und Unternehmen mit diesem Bereich. Um zu verstehen, wie die Zukunft der Code-Sicherheit aussieht, müssen wir uns zunächst ansehen, wie herkömmliche SAST-Tools funktionieren und warum sie nicht so weit verbreitet eingesetzt werden, wie wir es uns gewünscht hätten.
Traditionelle SAST-Tools laufen langsam
In herkömmlichen Security- und DevOps-Teams hört man oft Rückmeldungen wie: „Der SAST-Scan dauert viel zu lange“ oder „Continuous Integration? Eher ständiges Warten, bis der SAST-Scan abgeschlossen ist!“ Es war üblich, dass SAST-Tools in der Build- oder Continuous-Integration-Phase (CI) stunden- oder sogar tagelang liefen, während sie Quellcode-Repositories analysierten.
Es wurden einige Anpassungen vorgenommen, um schneller Ergebnisse zu liefern, etwa durch die Arbeit mit Quellcode-Deltas oder indem der SAST-CI-Job für die Nacht oder das Wochenende geplant wurde. Dabei handelt es sich jedoch um Behelfslösungen, die zeigen, dass ein Tool unzureichend ist und sich nicht an moderne Entwicklungsprozesse und Erwartungen anpassen kann.
Security ist im SDLC meist am falschen Platz
Um mit den bereits erwähnten verzögerten Feedbackschleifen umzugehen, wurden SAST-Tools als separater CI-Prozess implementiert, damit sie Entwickler nicht mit lang laufenden Prüfungen ausbremsen. Doch dieser Schritt, SAST-Tools in eine CI einzubetten, widerspricht stark der ursprünglichen Absicht: SAST-Tools sollten sich auf den Quellcode konzentrieren können. Das bedeutet: SAST-Tools sollten während der Softwareentwicklung zum Einsatz kommen und nicht erst nachträglich in CI überprüft werden.
Security-Tools sowohl in den Build- als auch in den Continuous-Integration-Prozess einzubetten, ist eine hervorragende Möglichkeit, Security zu integrieren. Damit die Produktivität von Entwicklern nicht leidet, müssen diese Tools jedoch schnell sein und umsetzbares Feedback liefern.
False Positives führen dazu, dass SAST-Tools aufgegeben werden
Ein weiteres großes Problem für SAST-Anwender ist die Genauigkeit – genauer gesagt deren Mangel. Traditionelle SAST-Tools erzeugen oft zu viele Fehlalarme und damit unnötige Benachrichtigungen. Security-Warnungen erfordern die volle Aufmerksamkeit von Entwicklern. Sind viele dieser Benachrichtigungen Fehlalarme, wird die eigentliche Entwicklung ausgebremst.
False Positives sorgen für Frust und verärgern das Application-Security-Team. Letztendlich führt dies dazu, dass Entwickler Security-Warnungen generell ignorieren und das Tool ganz aufgeben.
Traditionelle SAST-Tools finden Probleme, können sie aber nicht beheben
Und schließlich verraten die Ergebnisse eines SAST-Tools selbst dann nicht, wie Sie ein Problem beheben können, wenn sie korrekt sind. Das Problem liegt in der ursprünglichen Konzeption von SAST-Tools. Sie wurden ursprünglich für das Security-Team, AppSec und ähnliche Bereiche entwickelt. Daher fehlt den Ergebnissen möglicherweise der Kontext zum Ausführungsfluss, oder sie melden das Problem lediglich mit einem CWE-Code (Common Weakness Enumeration, einer Beschreibung einer potenziellen Schwachstelle). Wenn Sie jedoch kein Security-Experte sind, hilft Ihnen ein SAST-Tool nicht dabei, ein Problem zu beheben oder eine Schwachstelle zu beseitigen.
Die Security-Probleme konnten nur erfahrene Application-Security-Experten und ihre Community beheben. Dadurch entstand ein weiterer Engpass bei der Behebung von Sicherheitsproblemen. Außerdem waren Entwickler frustriert, wenn sie die Ergebnisse eines SAST-Scans erhielten, aber nichts unternehmen konnten, um die Probleme zu beheben.
Moderne Developer-first-SAST-Tools müssen die Produktivität von Entwicklern steigern
Im Kern konzentriert sich ein SAST-Tool auf die Code-Sicherheit. SAST-Tools finden Probleme wie die Offenlegung sensibler Daten, SQL-Injection, Code-Injection und andere Arten von Schwachstellen. Wer hat diese Sicherheitsprobleme verursacht? Entwickler wie Sie und ich. Wer sollte sie also beheben? Genau: die Entwickler selbst.
Developer-first ist das Erfolgsgeheimnis erstklassiger SAST-Tools – und so revolutioniert Snyk den Bereich Application Security. Snyk basiert auf einer Developer-first-Mentalität.
Sehen wir uns an, was ein SAST-Tool leisten muss, um Entwicklern ein produktives Security-Erlebnis zu bieten.
Code-Sicherheit, integriert in Entwickler-Workflows
Wenn Entwickler eine entscheidende Rolle bei der Behebung von Sicherheitslücken spielen, muss sich ein SAST-Tool möglichst entwicklerfreundlich integrieren lassen.
Wo verbringen Entwickler die meiste Zeit (abgesehen von Google und StackOverflow)?
In ihrer IDE, etwa IntelliJ oder Visual Studio Code
In der Kommandozeile (CLI), wo sie mit ihren Git-Repositories interagieren, Befehle ausführen, Fehler beheben sowie den Quellcode und die Routinen ihrer Projekte verwalten
Bei Code-Reviews
Damit SAST-Tools angenommen werden, müssen sie Entwicklern helfen, Sicherheitsprobleme direkt in den bereits verwendeten Tools zu finden und zu beheben. Die Ergebnisse müssen außerdem reich an Kontext sein, damit Entwickler Sicherheitslücken in ihrem Code finden und beheben können.
Für Entwickler, die den Großteil ihres Tages in einer IDE verbringen, zeigt dieses Beispiel das Snyk Code-SAST-Tool im Einsatz und veranschaulicht, wie nahtlos integrierte Security-Tools aussehen:
Auf der linken Seite sehen Sie eine Liste potenzieller Schwachstellen, die auf mangelhafte Praktiken für sicheres Coding zurückzuführen sind. Rechts im unteren Bereich wird zeilenweise dargestellt, wie ein anfälliger Datenfluss auftritt und ausgenutzt werden kann.
Wenn Sie als Entwickler am liebsten die meiste Zeit in Terminal-Benutzeroberflächen verbringen, ist eine Kommandozeile möglicherweise besser für Sie geeignet. In diesem Fall können Sie die Snyk Code CLI genau dafür verwenden.
Wenn Sie Git-Hooks nutzen, etwa um einen Linter, eine Testsuite oder andere Automatisierungen auszuführen, bevor Entwickler ihren Code committen oder pushen, können Sie dafür ebenfalls die Snyk CLI verwenden.
Das folgende Beispiel zeigt die Ausgabe eines Code-Sicherheitstests mit der Snyk CLI für dasselbe Projekt:
Security-Scan-Ergebnisse in Echtzeit
Damit ein SAST-Tool die oben genannten Entwickler-Workflows unterstützt, muss es schnell genug sein, um Security-Scan-Ergebnisse in Echtzeit zu liefern. Diese Geschwindigkeit ermöglicht sicheres Coding von Anfang an. Entwickler können Sicherheitsprobleme beim Programmieren finden und beheben, statt erst nach einem Code-Push durch das Security-Team oder eine DevSecOps-Integration darauf aufmerksam gemacht zu werden. Letzteres kann zu zusätzlichem Frust führen, da der Code nun umgeschrieben werden muss. Das verursacht unnötige Änderungen und verzögert insgesamt die Bereitstellung.
Unser reibungsloser Ansatz für sicheres Coding macht Snyk Code einzigartig und hebt es als Tool für statische Codeanalyse hervor. Wie schnell ist Snyk Code? Probieren Sie es aus und überzeugen Sie sich selbst.
Hohe Genauigkeit, wenige False Positives
Integrierte Workflows und schnelle Feedbackschleifen sind wichtig. Ein oft übersehener Faktor für eine gute Developer Experience sind jedoch die Daten selbst.
Entwickler müssen ihren Tools vertrauen, damit sie diese vollständig in ihre Workflows integrieren und nutzen. Die Qualität der von einem SAST-Tool gemeldeten Security-Daten entscheidet darüber, ob Entwickler das Tool gern einbinden oder es aufgrund zahlreicher False Positives aufgeben.
Snyk Code erzielt branchenführende Genauigkeit dank Machine Learning, das mit realen Code-Sicherheitsproblemen aus allen Open-Source-Projekten auf GitHub trainiert wurde. Dieses Wissen lässt sich dann auf Muster im eigenen Code anwenden. Um die Machine-Learning-Modelle weiter zu trainieren, nutzt die KI-Engine von Snyk Code außerdem die von Snyk sorgfältig kuratierte Schwachstellendatenbank sowie Referenz-Commits als Trainingsdaten. All das trägt dazu bei, False Positives deutlich zu reduzieren.
Entwickler befähigen, Probleme mit der Code-Sicherheit zu beheben
Ein StackOverflow-Thread ist der beste Freund eines Entwicklers, oder? Nur halb im Scherz: Entwickler schätzen hilfreiche Beispiele, in denen andere zeigen, wie sich Coding-Probleme lösen lassen. Warum sollte das bei Security-Problemen anders sein?
Betrachten wir ein Beispiel, in dem ein SAST-Tool eine potenzielle Command-Injection-Schwachstelle meldet, die häufig als CWE-78 bezeichnet wird: unzureichende Neutralisierung von Sonderzeichen in einem Betriebssystembefehl („OS Command Injection“). Ganz schön kompliziert, oder? Entwickler verfügen in der Regel nicht über den Security-Hintergrund, um CVEs und CWEs sowie deren Auswirkungen zu verstehen oder zu wissen, wie sie die Probleme beheben und dabei sichere Coding-Praktiken einhalten können. Genau dieses Problem hat sich Snyk zur Aufgabe gemacht.
Es ist gut möglich, dass Sie als Entwickler nicht über die Security-Expertise verfügen, um die Command-Injection-Schwachstelle in Zeile 86 zu beheben, in der eine unsichere Node.js-API verwendet wird: exec(). Was tun Sie also, wenn Sie einen solchen Security-Bericht erhalten?
Hier zeigt sich ein weiterer Vorteil von Snyk Code gegenüber herkömmlichen SAST-Tools: Es hilft Ihnen, die gefundenen Probleme mit der Code-Sicherheit zu lösen. Unten rechts im folgenden Screenshot aus der IntelliJ-IDE sehen Sie, dass Snyk Code für dieses Node.js-Projekt Commit-Diffs aus mehreren Open-Source-Projekten anzeigt, die das hier gemeldete Code-Injection-Problem beheben.
Mit diesen Informationen können Entwickler sehen, wie andere ähnliche Sicherheitsprobleme behoben haben. Dieser umfassendere Kontext zu den Lösungsvorschlägen ermöglicht es Entwicklern, fundiertere Entscheidungen zu treffen.
Zusammenfassung
Zusammenfassend lässt sich sagen: Entwickler brauchen ein SAST-Tool, das Sicherheitsprobleme sowohl in ihrem Code als auch in den verwendeten Open-Source-Abhängigkeiten findet. Darüber hinaus muss es umsetzbare Lösungen für die gefundenen Schwachstellen empfehlen können. Damit Entwickler es annehmen, muss ein SAST-Tool schnell und präzise sein und sich in ihre Tools und Workflows integrieren lassen. Das mag nach viel verlangt klingen, aber ein Developer-first-SAST-Tool muss all diese Funktionen bieten, um wirksam zu sein – genau deshalb bietet Snyk Code sie alle. In unserem SAST-Käuferleitfaden erfahren Sie, wie Sie das richtige SAST-Tool für Ihre Organisation auswählen.
Sie sind bis hierhin gekommen und möchten wissen, wie SAST- und DAST-Tests zusammenhängen?
Was sind SAST- und DAST-Tests?
SAST steht für Static Application Security Testing. Dabei benötigt ein Tool lediglich den Quellcode einer Anwendung, um eine Source-to-Sink-Analyse durchzuführen und anhand des Datenflusses potenzielle Sicherheitslücken oder Schwachstellen zu ermitteln. DAST ist ein dynamisches Verfahren zum Testen der Anwendungssicherheit. Dafür muss die Anwendung in einer geeigneten Umgebung live ausgeführt werden. Ein Tool kann dann den Datenverkehr beobachten, Webseiten crawlen und die Interaktion mit der Anwendung weitgehend automatisieren, um festzustellen, ob Sicherheitsprobleme vorliegen. Erfahren Sie mehr über SAST vs. DAST: Was ist der Unterschied und wie lassen sich beide kombinieren?.
Starten Sie mit Capture the Flag
Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Herausforderungen lösen.
