Was ein selbstgebautes SAST-Tool über AppSec lehrte – mehr als 13 Jahre Softwareentwicklung

Ein Softwareentwickler mit über einem Jahrzehnt Berufserfahrung in Java, C#, Kotlin und Node.js glaubte lange, solide Kenntnisse in Application Security (AppSec) zu besitzen. Doch als er beschloss, einen eigenen SAST-Scanner (Static Application Security Testing) zu entwickeln und in CI/CD-Pipelines zu integrieren, stieß er auf verblüffende Wissenslücken – nicht in der Funktionsweise von Software, sondern in der Art und Weise, wie sie scheitert.

Diese Erkenntnis prägte sein Verständnis von AppSec nachhaltig. Der folgende Artikel fasst zusammen, was er über die Sicherheitslücken moderner Software lernte und warum klassische Entwicklerkenntnisse allein nicht ausreichen, um sie zu beheben.

Vom "Wie" zum "Warum": Warum sichere Code-Muster ohne Kontext wertlos sind

Seit mindestens zehn Jahren setzte der Autor parametrisierte SQL-Abfragen ein, um SQL-Injection zu verhindern. Er wusste, dass dies die empfohlene Praxis ist – doch die genaue Funktionsweise blieb ihm lange verborgen. Auf die Frage, warum parametrisierte Abfragen sicher sind, hätte er zuvor nur vage Antworten gegeben wie: "Weil die Datenbank die Eingaben separat verarbeitet."

Doch als er begann, Regeln für einen SAST-Scanner zu entwickeln, die zwischen unsicheren und sicheren SQL-Mustern unterscheiden, musste er sich präzise mit den Mechanismen auseinandersetzen. Plötzlich wurde klar:

• Eine unsichere Abfrage wie SELECT * FROM users WHERE id = " + userId übergibt die Nutzer-ID direkt als Teil des SQL-Befehls. Die Datenbank interpretiert diese Eingabe als Code – ein klassisches Angriffsziel für SQL-Injection.
• Eine parametrisierte Abfrage wie SELECT * FROM users WHERE id = ? trennt Struktur der Abfrage und Nutzerdaten. Die Datenbank erhält zwei separate Nachrichten: eine mit der Abfrage, eine mit den Parametern. Die Daten werden nie als SQL-Syntax interpretiert.

Diese Unterscheidung mag trivial erscheinen, doch sie offenbart ein fundamentales Problem: Viele Entwickler wenden sichere Praktiken an, ohne die zugrundeliegenden Sicherheitsmechanismen zu verstehen. Für die tägliche Arbeit reicht das aus – doch für die Arbeit in der AppSec reicht es nicht.

Die zentrale Lektion: Ein Entwickler muss wissen, wie man sicheren Code schreibt. Ein AppSec-Experte muss verstehen, warum eine unsichere Implementierung scheitert – und wie Angreifer dies ausnutzen können. Nur dann lassen sich potenzielle Schwachstellen nicht nur vermeiden, sondern auch zuverlässig erkennen.

AppSec ist kein kooperatives, sondern ein adversarisches Feld

Die Softwareentwicklung ist eine weitgehend kollaborative Disziplin. Das Ziel ist es, ein System zu bauen, das wie vorgesehen funktioniert. Entwickler denken in idealen Szenarien: Eingaben sind valide, Netzwerke stabil, Nutzer verhalten sich erwartungsgemäß.

AppSec hingegen ist adversarisch. Hier geht es nicht darum, wie ein System funktioniert, sondern darum, wie es versagen kann – und zwar gezielt durch einen Angreifer. Diese Denkweise erfordert einen radikalen Perspektivwechsel.

Ein Beispiel aus dem Projekt des Autors: die Analyse von JWT-Algorithmen (JSON Web Tokens). Um eine Regel zu entwickeln, die manipulierte Tokens erkennt, musste er sich in die Rolle eines Angreifers versetzen. Nicht aus böser Absicht, sondern um zu verstehen, wie ein Angreifer einen Authentifizierungsmechanismus kompromittieren könnte.

• Welche Annahmen trifft der Code über die Gültigkeit eines Tokens?
• Welche Parameter kann ein Angreifer kontrollieren?
• Wie sieht die vollständige Angriffssequenz aus?

Die OWASP Top 10 listet genau solche Angriffsszenarien auf. Jeder Punkt repräsentiert eine Annahme, die Entwickler treffen – und die Angreifer gezielt ausnutzen.

• A03 – Injection geht davon aus, dass Eingaben reine Daten sind, nicht ausführbarer Code.
• A07 – Authentication Failures unterstellt, dass die Identitätsprüfung korrekt funktioniert.
• A02 – Cryptographic Failures setzt voraus, dass Verschlüsselung automatisch Schutz bietet.

Ohne dieses adversarische Denken bleiben Sicherheitsrisiken unsichtbar. Entwickler müssen lernen, Systeme nicht nur aus ihrer Perspektive zu betrachten, sondern auch aus der eines potenziellen Angreifers.

Die zentrale Lektion: Wer Schwachstellen finden will, muss in der Lage sein, sich vorzustellen, wie sie ausgenutzt werden könnten. Adversarisches Denken ist kein optionales Add-on, sondern eine Grundvoraussetzung für AppSec.

SAST-Tools sind Werkzeuge – keine Allheilmittel

Vor dem Bau seines eigenen SAST-Scanners nutzte der Autor bestehende Tools wie Snyk oder Semgrep. Damals behandelte er deren Ergebnisse ähnlich wie Compiler-Warnungen: Ein Hinweis erscheint, man prüft ihn, entscheidet sich für eine Lösung oder ignoriert ihn.

Doch der Bau eines eigenen Scanners veränderte diese Perspektive grundlegend. Ein SAST-Tool ist nichts weiter als eine Sammlung von Heuristiken – geschrieben von Menschen, basierend auf deren Verständnis von Schwachstellenmustern. Es kennt weder den spezifischen Codekontext noch das individuelle Bedrohungsmodell eines Unternehmens.

Das bedeutet nicht, dass SAST-Tools nutzlos sind. Im Gegenteil: Sie sind wertvolle Signalgeber. Doch ihre Aussagekraft hängt maßgeblich davon ab, wie man mit ihren Ergebnissen umgeht.

Vor dem Bau seines Tools fragte der Autor sich nach einem Scan-Ergebnis:

• Welches Muster soll diese Regel erkennen?
• Trifft dieses Muster in meinem Code aus den Gründen zu, die die Regel annimmt?
• Ist die Schwachstelle, auf die die Regel hinweist, in meinem spezifischen Kontext überhaupt ausnutzbar?
• Welche Kontrolle müsste ein Angreifer über das System haben, um die Schwachstelle auszunutzen?

Diese Fragen gehen weit über klassische DevOps-Ansätze hinaus. Für Entwickler ist ein SAST-Ergebnis oft ein Compliance-Hindernis. Für AppSec-Experten ist es der Startpunkt einer tiefergehenden Analyse.

Die zentrale Lektion: Ein SAST-Tool generiert Signale – doch wer diese Signale interpretiert, muss die kontextuellen Fragen stellen. Die Qualität der Ergebnisse hängt nicht vom Tool selbst ab, sondern von der Expertise, mit der es eingesetzt wird.

Fazit: AppSec erfordert ein neues Mindset

Die Erkenntnisse aus dem Bau eines SAST-Scanners zeigen: Application Security ist mehr als nur die Anwendung von Best Practices. Sie erfordert ein tiefes Verständnis der zugrundeliegenden Sicherheitsmechanismen, ein adversarisches Denken und die Fähigkeit, Tools kritisch zu hinterfragen.

Für Entwickler, die in die AppSec-Welt wechseln, bedeutet das einen radikalen Perspektivwechsel. Es geht nicht mehr nur darum, sicheren Code zu schreiben – sondern darum, zu verstehen, wie dieser Code unsicher werden kann. Und genau das macht den Unterschied zwischen einem Entwickler und einem AppSec-Experten aus.

Die Reise ist erst der Anfang. Mit dem wachsenden Einfluss von KI-gestützten Angriffstools und der zunehmenden Komplexität moderner Softwarearchitekturen wird adversarisches Denken in der AppSec immer wichtiger. Wer diese Denkweise heute verinnerlicht, ist morgen besser gerüstet, um die Sicherheitsherausforderungen von übermorgen zu meistern.