Ein Pull Request wird gemergt, bevor die Codezeile überhaupt in einer laufenden Umgebung landet. Wenige Wochen später klopft ein Scanner an eine produktive API und findet dort eine Schwachstelle, die im Quellcode nie auffiel. Genau zwischen diesen beiden Momenten liegt die Frage, um die es in diesem Artikel geht: SAST vs. DAST. Für DevSecOps-Teams in Deutschland, Österreich und der Schweiz ist das 2026 keine akademische Debatte mehr, sondern eine Budget- und Architekturentscheidung. Der GitHub-Actions-Vorfall CVE-2025-30066 und die npm-Wurmwelle „Shai-Hulud 2.0″ haben gezeigt, wie schnell Lücken zwischen den beiden Testmethoden ausgenutzt werden. Dieser Vergleich liefert Preise, Benchmark-Daten aus vier unabhängigen Quellen, fünf reale Vorfälle und eine klare Kaufempfehlung nach Anwendungsfall.

Was ist SAST? Statische Codeanalyse erklärt

Static Application Security Testing, kurz SAST, prüft Quellcode, Bytecode oder Binärdateien, ohne das Programm auszuführen. Ein SAST-Scanner liest jede Zeile, baut einen Kontrollflussgraphen und sucht nach Mustern wie SQL-Injection, unsicherer Deserialisierung oder hartcodierten Zugangsdaten. Weil der Scan vor dem Build läuft, lässt er sich direkt in Pull Requests, Commit-Hooks oder die IDE einbetten. Entwickler sehen die Warnung, bevor der Code überhaupt gemergt wird.

Der große Vorteil: SAST braucht keine laufende Anwendung und keine Testdaten. Der Nachteil zeigt sich bei Drittanbieter-Code. Prüft ein Team nur die eigene Codebasis, bleiben Schwachstellen in eingebundenen Bibliotheken oft unsichtbar, dafür ist in den meisten Pipelines Software Composition Analysis (SCA) zuständig, nicht SAST selbst. Tools wie Snyk Code, Semgrep, Checkmarx One, SonarQube und GitHub Advanced Security mit CodeQL zählen 2026 zu den meistgenutzten SAST-Plattformen im DACH-Raum, weil sie sich nativ in GitHub, GitLab und Azure DevOps einklinken.

Die Sprachabdeckung entscheidet in der Praxis oft mehr über die Tool-Wahl als der Funktionsumfang. Java, C#, Python, JavaScript und TypeScript decken die meisten kommerziellen SAST-Engines gut ab, bei Go, Rust oder Kotlin variiert die Regeltiefe deutlich zwischen den Anbietern. Viele Teams ergänzen die Pipeline-Integration deshalb um IDE-Plugins für VS Code oder JetBrains, damit Entwickler Warnungen sehen, während sie noch am Code sitzen, nicht erst Minuten später im Pull Request. Das verkürzt die Feedback-Schleife zusätzlich und senkt die Hürde, eine Warnung tatsächlich zu beheben statt sie zu ignorieren.

Was ist DAST? Dynamische Sicherheitstests erklärt

Dynamic Application Security Testing dreht das Prinzip um. Statt Code zu lesen, greift ein DAST-Scanner die laufende Anwendung von außen an, genau wie ein echter Angreifer über HTTP-Requests. Er braucht keinen Zugriff auf den Quellcode und funktioniert deshalb auch bei Legacy-Systemen, Drittanbieter-Software oder Microservices, deren Code ein Team gar nicht besitzt. DAST-Scanner wie OWASP ZAP oder Burp Suite senden manipulierte Eingaben an Formulare, API-Endpunkte und Header, um Reaktionen wie Fehlermeldungen, Zeitverzögerungen oder ungewollte Datenausgaben zu provozieren.

Weil DAST die Anwendung im laufenden Zustand testet, findet es Probleme, die SAST grundsätzlich nicht sehen kann, etwa fehlerhafte Serverkonfigurationen, defekte Authentifizierungsflüsse oder Session-Management-Fehler. Der Preis dafür ist Tempo: Ein vollständiger DAST-Scan gegen eine komplexe Web-Anwendung dauert oft Stunden, während SAST-Checks in der Pipeline meist in wenigen Minuten laufen. DAST läuft deshalb typischerweise nächtlich gegen Staging-Umgebungen, nicht bei jedem Commit.

Authentifizierte Scans sind dabei die größte praktische Hürde. Ein DAST-Tool muss sich mit echten Testkonten einloggen, um Bereiche hinter einem Login zu erreichen, sonst bleibt der Großteil einer modernen Web-Anwendung unsichtbar für den Scanner. Das bedeutet zusätzlichen Konfigurationsaufwand: Testdaten pflegen, Session-Cookies erneuern, mehrstufige Login-Flows abbilden. Viele Teams unterschätzen diesen Aufwand beim Einstieg und wundern sich später, warum ihr DAST-Scan nur die öffentliche Startseite testet statt der eigentlichen Anwendung dahinter.

SAST vs. DAST im Vergleich: Die technischen Unterschiede

Die folgende Tabelle stellt beide Testmethoden entlang der Kriterien gegenüber, die für eine Tool-Entscheidung in der Praxis zählen.

KriteriumSASTDAST
TestzeitpunktVor dem Build, im Commit/PRGegen laufende Anwendung, meist Staging
Zugriff auf QuellcodeZwingend erforderlichNicht nötig, Blackbox über HTTP
Erkennt unsichere Coding-PatternsJa, direkt im CodeNein, sieht nur externes Verhalten
Erkennt Laufzeit- und KonfigurationsfehlerEingeschränktJa, das ist die Stärke
Beste Trefferquote im OWASP Benchmark32,9–33 %17–18 %
SprachabhängigkeitJa, pro ProgrammierspracheNein, arbeitet auf HTTP-Ebene
Benötigt laufende AnwendungNeinJa
Typische Scan-DauerMinutenStunden
Deckt Drittanbieter-/Open-Source-Code abNur eingeschränkt, SCA übernimmt meistJa, wenn über HTTP erreichbar
CI/CD-IntegrationstiefeNativ bei jedem Commit oder PRMeist nächtlich oder wöchentlich
Adoption laut GitLab-Report 202433 % der Teams34 % der Teams
Geeignet für Legacy-Systeme ohne QuellcodeNeinJa

Auffällig: Die Adoptionsraten liegen mit 33 zu 34 Prozent laut dem GitLab Global DevSecOps Report fast gleichauf. Kein Verfahren hat sich als klarer Standard durchgesetzt, was in der Praxis meist bedeutet, dass beide gebraucht werden, nur an unterschiedlichen Stellen der Pipeline.

Ein Punkt fehlt in der Tabelle bewusst, weil er sich nicht sauber in Ja/Nein-Kategorien pressen lässt: Viele Teams fahren heute einen hybriden Ansatz, bei dem SAST-Funde und DAST-Funde in derselben Plattform korreliert werden. Findet SAST eine potenzielle SQL-Injection im Code und bestätigt DAST anschließend, dass der betroffene Endpunkt tatsächlich erreichbar und angreifbar ist, steigt die Priorität eines Tickets erheblich gegenüber einem isolierten SAST-Fund ohne Laufzeitbestätigung. Genau diese Korrelation treibt aktuell die Konsolidierung der beiden Tool-Kategorien voran.

Erkennungsraten und Fehlalarme: Was Benchmarks wirklich zeigen

Zahlen zur Erkennungsrate stammen selten aus einer einzigen Quelle, und genau das macht sie belastbar, wenn sie sich wiederholen. Das OWASP Benchmark Project testet SAST- und DAST-Tools gegen eine synthetische Testsuite mit bekannten Schwachstellenklassen. In der letzten öffentlich ausgewerteten Runde erreichte das beste SAST-Tool eine Trefferquote von 32,9 bis 33 Prozent, während das beste DAST-Tool nur 17 bis 18 Prozent schaffte. Der Kategoriedurchschnitt lag bei SAST bei rund 20 Prozent, bei DAST bei mageren 5,35 Prozent.

Eine zweite, unabhängige Quelle bestätigt das Muster aus einer anderen Richtung. Eine Contrast-Security-Auswertung des OWASP Benchmarks beziffert die Fehlalarmquote von DAST-Tools in diesem Testkontext auf 82 Prozent, ein Wert, der zeigt, wie viele gemeldete Funde in der Praxis manuell verworfen werden müssen. Eine dritte Quelle, eine arXiv-Studie zum Vergleich von SAST, DAST und Interactive Application Security Testing (IAST), misst konkrete Präzisionswerte: SAST erreichte eine Präzision von 0,98 (nur 20 Fehlalarme bei 962 Meldungen), DAST kam auf lediglich 0,23 (2.625 Fehlalarme bei 3.412 Meldungen). IAST lag mit 0,40 dazwischen.

Eine vierte, in einem PubMed-indexierten Fachjournal veröffentlichte Untersuchung relativiert das Bild etwas. Sie ordnet DAST für vier der zehn OWASP-Top-10-Risikokategorien als die bessere Wahl ein, SAST für drei, und für zwei Kategorien eignen sich beide gleichermaßen. OWASP ZAP schnitt in dieser Studie bei Broken Access Control, Insecure Design und Security Misconfiguration am stärksten ab. Die Lehre daraus: SAST liefert in Benchmarks konstant weniger Fehlalarme und eine höhere Trefferquote, DAST punktet dafür bei genau den Laufzeitrisiken, die statischer Code niemals zeigt.

Eine Einschränkung gehört zu jeder dieser Zahlen dazu: Das OWASP Benchmark Project arbeitet mit einer synthetischen Testsuite, absichtlich konstruiert, um Scanner an ihre Grenzen zu bringen, nicht mit echtem Produktionscode. OWASP selbst weist darauf hin, dass die veröffentlichten Ergebnisse mehrere Jahre alt sind und aktuelle Versionen kommerzieller Tools nicht mehr vollständig abbilden. Für die Tool-Auswahl heißt das: Die relative Rangfolge zwischen SAST und DAST bleibt über mehrere unabhängige Quellen stabil, absolute Prozentwerte sollten Teams aber nicht eins zu eins auf die eigene Codebasis übertragen, sondern durch einen eigenen Pilottest mit realem Code ergänzen.

Preisvergleich 2026: Was kosten SAST- und DAST-Tools?

Die meisten Enterprise-Anbieter in diesem Segment veröffentlichen keine festen Listenpreise mehr. Die folgende Tabelle fasst öffentlich bestätigte Preispunkte sowie glaubwürdige Marktbeobachtungen zusammen. Alle Preise stammen aus den offiziellen Herstellerangaben oder aus mehrfach bestätigten Marktanalysen, primär in US-Dollar notiert, wie in diesem Marktsegment international üblich. DACH-Käufer sollten bei Vertragsabschluss zusätzlich Mehrwertsteuer und mögliche Währungsschwankungen einkalkulieren, gerade bei mehrjährigen Enterprise-Verträgen mit Checkmarx oder Veracode.

ToolKategorieEinstiegspreisPreismodell
OWASP ZAPDAST0 €Open Source, kostenlos
SemgrepSAST/SCA0 $ bis 10 MitwirkendeAb 30 $/Mitwirkende/Monat für Team
Snyk CodeSASTKostenloser Einstieg25 $/Entwickler/Monat (Team, jährlich 1.260 $)
SonarCloudSAST-nahca. 30 €/MonatBis 100.000 Codezeilen im Team-Tarif
GitHub Code SecuritySAST (CodeQL)30 $/aktiver Committer/MonatGetrennt von Secret Protection (19 $)
Burp Suite ProfessionalDAST (Einzelplatz)ca. 499 $/JahrPro Nutzer, jährlich
Burp Suite Enterprise/DASTDASTca. 6.995 $/Jahr (5 Agenten)Quote-basiert, skaliert mit Scan-Agenten
AcunetixDASTab ca. 7.000 $/JahrPro gescanntes Ziel, quote-basiert
InvictiDASTca. 4.000–6.000 $/Ziel/JahrMedian-Vertragswert rund 21.600 $/Jahr
VeracodeSAST/DAST-Suiteca. 15.000 $/Jahr (SAST)DAST separat ca. 20.000–25.000 $/Jahr
Checkmarx OneSAST-Plattformab ca. 30.000 $/JahrSkaliert bis 130.000–280.000 $+ im Mittelstand

Das Muster ist eindeutig: SAST-Tools sind heute überwiegend pro Entwickler oder pro Codezeile bepreist, was kleine Teams mit ein paar Hundert Euro im Monat starten lässt. DAST-Tools rechnen fast immer pro gescanntem Ziel oder pro Scan-Agent ab, was den Einstieg teurer macht, sobald mehrere APIs oder Umgebungen abgedeckt werden müssen. Aktuelle Preise für Snyk, SonarQube, Semgrep und Burp Suite Enterprise lassen sich direkt bei den Anbietern nachvollziehen.

Was in keiner Preistabelle steht, sind die Folgekosten. Ein SAST-Tool, das ungefiltert Hunderte Warnungen pro Repository ausgibt, bindet schnell mehr Entwicklerzeit für die Triage als das Lizenzmodell auf den ersten Blick vermuten lässt. Dasselbe gilt für DAST mit seiner deutlich höheren Fehlalarmquote: Ein Tool für 7.000 Dollar im Jahr, das ein Team zwei zusätzliche Wochenstunden für das Aussortieren falscher Treffer kostet, ist über zwölf Monate gerechnet teurer als die reine Lizenzsumme. Bei der Tool-Auswahl lohnt sich deshalb ein kurzer Pilotlauf über zwei bis drei Sprints, bevor ein Jahresvertrag unterschrieben wird.

SAST und DAST im Licht von NIS2 und dem Cyber Resilience Act

Für DACH-Teams ist die Tool-Frage 2026 nicht mehr rein technisch, sie hat einen regulatorischen Zeitplan bekommen. Der EU Cyber Resilience Act (CRA) verlangt von Herstellern von Produkten mit digitalen Elementen ab dem 11. September 2026 eine aktive Schwachstellenmeldung: eine erste Frühwarnung innerhalb von 24 Stunden nach Bekanntwerden, eine vollständige Meldung innerhalb von 72 Stunden und einen Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme. Wer diese Fristen einhalten will, braucht eine kontinuierliche Scanning-Pipeline und keine punktuellen, manuellen Prüfungen mehr, denn eine Schwachstelle, die erst beim jährlichen Penetrationstest auffällt, lässt sich unmöglich innerhalb eines Tages melden.

In Deutschland selbst bleibt die Lage komplizierter. Die nationale Umsetzung der NIS2-Richtlinie über das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) war laut aktuellem Stand im August 2026 noch nicht final und bindend verabschiedet, Deutschland lag damit weiterhin in der Übergangsphase. Für betroffene Unternehmen ändert das wenig an der praktischen Konsequenz: SAST liefert die dokumentierte, auditierbare Spur im Code, die Prüfer künftig erwarten, DAST liefert den Nachweis, dass eine gemeldete Schwachstelle in der laufenden Anwendung tatsächlich behoben wurde. Beide Testarten werden damit vom „Nice-to-have” zum Compliance-Baustein.

Für Einkaufsabteilungen bedeutet die CRA-Frist konkret, dass Lieferantenverträge ab September 2026 Klauseln zur Meldefrist enthalten sollten, gerade bei eingekaufter Software mit digitalen Komponenten. Ein Lieferant, der selbst kein SAST oder DAST betreibt und deshalb Schwachstellen erst durch externe Meldungen erfährt, wird die 24-Stunden-Frühwarnung kaum verlässlich einhalten können. Für DACH-Unternehmen, die Software einkaufen statt selbst zu entwickeln, lohnt sich deshalb eine gezielte Nachfrage im Beschaffungsprozess: Welche Testmethoden setzt der Lieferant ein, und wie schnell kann er tatsächlich melden?

Fünf reale Vorfälle: Hätten SAST oder DAST geholfen?

Zahlen aus Benchmarks sind das eine, reale Vorfälle sind das andere. Die folgenden fünf Fälle stammen aus den vergangenen neun Jahren, decken unterschiedliche Schwachstellenklassen ab und zeigen, wo SAST und DAST tatsächlich geholfen hätten und wo beide Methoden strukturell an ihre Grenzen stoßen.

1. Equifax, 2017 (CVE-2017-5638). Eine ungepatchte Remote-Code-Execution-Lücke in Apache Struts kostete 145,5 bis 148 Millionen Menschen ihre Daten. Laut einer 2026 veröffentlichten AppSec-Analyse hatte Equifax bereits DAST-Tools im Einsatz, kritische Funde wurden aber nicht abgearbeitet. Der Fall zeigt: Ein Tool hilft nichts, wenn Prozesse fehlen, um seine Ergebnisse umzusetzen.

2. Log4Shell, 2021 (CVE-2021-44228). Die Lücke steckte tief in einer Drittanbieter-Bibliothek, nicht im eigenen Anwendungscode. SAST auf proprietärem Code hätte sie kaum gefunden, weil moderne Anwendungen laut Synopsys-OSSRA-Daten zu 70 bis 90 Prozent aus Fremdcode bestehen. Hier zeigte sich vor allem der Wert von Software Composition Analysis, nicht klassischem SAST oder DAST.

3. tj-actions/changed-files, März 2025 (CVE-2025-30066). Angreifer kompromittierten das Repository der populären GitHub Action und verschoben rückwirkend die Tags v1 bis v45.0.7 auf einen manipulierten Commit. Ein eingeschleustes Python-Skript dumpte den Speicher von CI-Runnern und druckte doppelt Base64-kodierte Secrets in Build-Logs, laut Analysen von StepSecurity betraf das über 23.000 Repositories. Weder klassisches SAST noch DAST auf die eigene Anwendung hätte das erkannt, weil die kompromittierte Komponente in der CI-Pipeline lief, nicht als netzwerkexponierter Web-Endpunkt.

4. MOVEit Transfer, 2023 (CVE-2023-34362). Eine klassische SQL-Injection in der Managed-File-Transfer-Software Progress MOVEit betraf hunderte Organisationen weltweit. SQL-Injection zählt zu den Schwachstellenklassen, die sowohl SAST im Quellcode als auch DAST an der laufenden Anwendung grundsätzlich erkennen können, ein Lehrbuchbeispiel dafür, warum beide Testarten in einer Pipeline ihren Platz haben.

5. Shai-Hulud 2.0, November 2025. Eine zweite Welle des selbstreplizierenden npm-Wurms übernahm laut einer technischen Analyse von Datadog 796 einzelne npm-Pakete mit zusammen über 20 Millionen wöchentlichen Downloads und verteilte sich über gestohlene GitHub-Tokens und Cloud-API-Keys weiter. Auch dieser Fall liegt außerhalb der klassischen SAST/DAST-Reichweite und erklärt, warum 2026 zunehmend über eine dritte Kategorie gesprochen wird: Supply-Chain-bewusstes Scanning von Abhängigkeiten und CI/CD-Komponenten selbst.

Drei der fünf Fälle, Struts, tj-actions und Shai-Hulud, betreffen Code, den ein Team nicht selbst geschrieben hat. Das relativiert eine verbreitete Annahme: Selbst ein perfekt eingerichtetes SAST-plus-DAST-Setup schützt nicht automatisch vor der Mehrheit realer Vorfälle, wenn die eigentliche Schwachstelle in Drittanbieter-Abhängigkeiten oder CI/CD-Komponenten sitzt. SCA und eine harte Trennung von CI-Secrets bleiben deshalb kein optionales Extra, sondern die dritte tragende Säule neben SAST und DAST.

Marktadoption: Wie viele DevSecOps-Teams nutzen SAST und DAST wirklich?

Der GitLab Global DevSecOps Report für 2024 zeigt eine Adoption von 33 Prozent für SAST und 34 Prozent für DAST, ein Anstieg gegenüber jeweils 26 Prozent im Vorjahr 2023. Eine spätere Analyse des 2025er-Reports beziffert die Werte auf 29 Prozent SAST und 30 Prozent DAST, was insgesamt bedeutet: Weniger als ein Drittel aller befragten Organisationen setzt eine der beiden Methoden konsequent ein, obwohl Sicherheitsverantwortliche in Umfragen regelmäßig hohes Vertrauen in ihre Pipeline-Sicherheit äußern.

Der leichte Rückgang zwischen den beiden GitLab-Erhebungen lässt sich nicht eindeutig auf eine einzelne Ursache zurückführen, plausibel ist eine Kombination aus wachsender Stichprobe und neu hinzugekommenen kleineren Organisationen, die noch am Anfang ihrer DevSecOps-Reise stehen. Für die Einordnung zählt vor allem der Trend über mehrere Jahre: Die Adoption wächst, bleibt aber deutlich unter dem, was viele Sicherheitsverantwortliche in Selbstauskünften als „ausreichend abgesichert” bezeichnen würden.

Eine von Practical DevSecOps zusammengetragene Statistik nennt höhere Werte, über 50 Prozent der Teams mit aktivem SAST, 44 Prozent mit DAST, rund die Hälfte mit Container- und Abhängigkeitsprüfungen. Die Differenz zu den GitLab-Zahlen erklärt sich vermutlich durch unterschiedliche Stichproben, das Grundmuster bleibt aber gleich: Tool-Sprawl ist real. Laut GitLab-Daten nutzen 55 Prozent der Sicherheitsteams sechs oder mehr voneinander getrennte AppSec-Werkzeuge, fast die Hälfte nennt genau diese Zersplitterung als größtes Hindernis. Bei der Software Composition Analysis ist die Dringlichkeit besonders klar belegt: Laut Synopsys OSSRA 2025 enthalten 84 Prozent aller untersuchten Codebasen mindestens eine bekannte Open-Source-Schwachstelle.

Für Teams, die in einem Zwei-Wochen-Sprint-Rhythmus arbeiten, ist diese Zersplitterung mehr als eine Verwaltungsfrage. Jedes zusätzliche Dashboard bedeutet einen weiteren Kontextwechsel für Entwickler, die ohnehin schon zwischen Ticketsystem, Code-Review und Deployment-Pipeline pendeln. Teams, die SAST- und DAST-Ergebnisse in ein einziges, zentrales Backlog überführen, statt zwei getrennte Sicherheits-Dashboards zu pflegen, berichten in Praxisberichten von deutlich kürzeren Zeiten bis zur Behebung, weil Entwickler Funde dort sehen, wo sie ohnehin schon arbeiten.

Shift-Left-Ökonomie: Was ein Bug in Produktion wirklich kostet

Die wirtschaftliche Begründung für SAST früh in der Pipeline stützt sich auf Zahlen, die IBM über sein Systems Sciences Institute erhoben hat und die seither in zahlreichen Studien reproduziert werden. Der Kern: Ein Fehler, der erst in Produktion behoben wird, kostet grob das Hundertfache dessen, was seine Behebung in der Design- oder Anforderungsphase gekostet hätte. Eine gängige Aufschlüsselung setzt 100 Dollar in der Anforderungsphase an, 300 bis 500 Dollar im Design, 600 Dollar während der Implementierung, 1.500 Dollar im Testing und 10.000 Dollar in Produktion.

Detailliertere IBM- und Ponemon-Zahlen aus Whitepapers zu Application Security beziffern die Kosten pro Defekt auf durchschnittlich 80 Dollar bei früher Entdeckung während der Entwicklung gegenüber 7.600 Dollar, wenn derselbe Defekt erst in Produktion auffällt, fast das Hundertfache. NIST wiederum schätzt in seinem Planning Report 02-4, dass unzureichende Software-Testinfrastruktur die US-Wirtschaft jährlich mit rund 59,5 Milliarden Dollar belastet, bei durchschnittlich 18,4 Arbeitsstunden pro Defekt. Für DACH-Teams heißt das konkret: SAST und SCA, integriert direkt in Commit und CI, senken die Reparaturkosten strukturell gegenüber einem Modell, das sich allein auf DAST in der Staging-Phase verlässt.

Die Zahlen erklären auch, warum reine DAST-Strategien in wachsenden Organisationen an ihre Grenzen stoßen. Ein Scan, der erst gegen Staging läuft, findet einen Fehler frühestens Tage oder Wochen nach dem eigentlichen Commit, oft nachdem mehrere weitere Features darauf aufgebaut wurden. Die Behebung berührt dann nicht mehr nur eine Codezeile, sondern womöglich abhängigen Code, der in der Zwischenzeit entstanden ist. Je später ein Fund auftaucht, desto mehr Kontext muss ein Entwickler sich erst wieder erarbeiten, ein Aufwand, der in keiner der zitierten Kostenrechnungen explizit auftaucht, in der Praxis aber spürbar ist.

Die wichtigsten Tools im Überblick: SAST- und DAST-Anbieter 2026

Auf der SAST-Seite dominieren fünf Namen den DACH-Markt. Checkmarx One gilt laut Gartner als Leader im Magic Quadrant für Application Security Testing 2025, bereits zum siebten Mal in Folge, und positioniert sich unter 16 bewerteten Anbietern am weitesten auf der Achse „Completeness of Vision”. Veracode wurde zum elften Mal in Folge als Leader geführt. Snyk Code punktet mit einem klaren, öffentlichen Preismodell und tiefer IDE-Integration. Semgrep hat sich als Open-Source-freundliche Alternative etabliert, kostenlos bis zehn Mitwirkende. SonarQube/SonarCloud bleibt der Standard für Code-Qualität mit integrierten Sicherheitsregeln, während GitHub Advanced Security mit CodeQL seit April 2025 als eigenständiges Produkt „Code Security” separat von „Secret Protection” verkauft wird.

Auf der DAST-Seite bleibt OWASP ZAP die kostenlose Referenz, getragen von der OWASP-Community. Burp Suite von PortSwigger dominiert kommerziell, mit einer Desktop-Professional-Lizenz für rund 499 Dollar im Jahr und einer Enterprise-DAST-Linie, deren Preise inzwischen ausschließlich auf Anfrage vergeben werden. Invicti (vormals Netsparker) und Acunetix runden das kommerzielle Feld ab, beide pro gescanntem Ziel bepreist. Ein bemerkenswertes Ereignis aus dem Dezember 2025: Checkmarx übernahm Tromzo, einen Pionier für „AI-native autonomous security agents”, um ab Anfang 2026 autonome Triage-Funktionen in Checkmarx One zu integrieren, ein deutliches Signal, dass KI-gestützte Priorisierung von Funden zum Standardfeature wird.

Ein Kriterium, das im DACH-Raum überproportional Gewicht bekommt, ist die Datenresidenz. Cloud-gehostete SAST-Dienste wie SonarCloud oder GitHub Code Security verarbeiten Quellcode auf Servern des Anbieters, was bei Behörden, Banken oder Gesundheitsdienstleistern mit strengen Datenschutzauflagen häufig zusätzliche vertragliche Prüfungen auslöst. Selbstgehostete Alternativen wie SonarQube Enterprise Edition oder eine On-Premises-Installation von Checkmarx One vermeiden diese Diskussion von vornherein, verlangen im Gegenzug aber eigenen Betriebsaufwand für Updates, Skalierung und Backups.

Manuelles Pentesting: Wo automatisierte Tools nicht ausreichen

Weder SAST noch DAST ersetzt einen erfahrenen Penetrationstester vollständig. Automatisierte Scanner arbeiten musterbasiert, sie erkennen bekannte Schwachstellenklassen zuverlässig, scheitern aber regelmäßig an Business-Logic-Fehlern, die sich nur aus dem Verständnis eines konkreten Workflows ergeben, etwa wenn ein Rabattcode mehrfach einlösbar ist, obwohl jede einzelne Anfrage für sich technisch korrekt aussieht. Genau deshalb bleibt Burp Suite Professional trotz Konkurrenz durch vollautomatisierte Enterprise-Plattformen bei manuellen Pentestern so verbreitet: Das Tool ist als Proxy und Werkzeugkasten für Menschen gebaut, nicht als vollautomatischer Scanner.

Die praktische Konsequenz für DACH-Teams: SAST und DAST decken die Breite ab, laufend, automatisiert, bei jedem Commit oder jeder Nacht. Ein manueller Pentest, meist ein- bis zweimal im Jahr oder vor größeren Releases, deckt die Tiefe ab, gezielt auf die kritischsten Workflows einer Anwendung fokussiert. Beide Ansätze schließen sich nicht aus, sie ergänzen sich, und regulierte Branchen mit CRA- oder NIS2-Bezug verlangen ohnehin häufig beides: kontinuierliches automatisiertes Testing plus einen dokumentierten, von Menschen durchgeführten Pentest als zusätzlichen Nachweis.

Vor- und Nachteile von SAST und DAST

Zusammengefasst aus allen bisherigen Abschnitten ergeben sich zwei klar unterscheidbare Stärken-Schwächen-Profile. Wer die Tool-Entscheidung an ein Management-Team erklären muss, findet hier die kompakte Version für eine Folie oder ein internes Memo.

SAST: Stärken und Grenzen

  • Vorteil: Findet Schwachstellen vor dem Merge, direkt an der Codezeile
  • Vorteil: Läuft in Minuten, passt in jeden Pull-Request-Workflow
  • Vorteil: Höhere Präzision in Benchmarks, weniger Fehlalarme als DAST
  • Nachteil: Braucht Sprachunterstützung pro Programmiersprache
  • Nachteil: Sieht keine Laufzeit-, Konfigurations- oder Session-Fehler
  • Nachteil: Deckt Drittanbieter-Code nur eingeschränkt ab, SCA muss ergänzen

DAST: Stärken und Grenzen

  • Vorteil: Testet die echte, laufende Anwendung wie ein Angreifer
  • Vorteil: Braucht keinen Quellcode, funktioniert bei Legacy- und Fremdsystemen
  • Vorteil: Findet Auth-, Session- und Serverkonfigurationsfehler zuverlässig
  • Nachteil: Deutlich höhere Fehlalarmquote, in Benchmarks bis zu 82 Prozent
  • Nachteil: Scan-Dauer von Stunden verhindert Einsatz bei jedem Commit
  • Nachteil: Erkennt Schwachstellen erst spät, wenn Code bereits läuft

Fünf Anwendungsfälle: Wann SAST, wann DAST, wann beides?

Die Tool-Entscheidung hängt selten allein an technischen Kriterien, sondern an der Situation eines Teams: Wie viel Budget steht bereit, wie sieht die Codebasis aus, und welche regulatorischen Pflichten gelten. Die folgenden sechs Szenarien decken die häufigsten Konstellationen im DACH-Raum ab.

Frühe Entwicklungsphase und Pull-Request-Checks. Teams, die Schwachstellen vor dem Merge stoppen wollen, setzen auf SAST-Tools wie Snyk Code oder Semgrep direkt in der PR-Pipeline. Das passt zu kurzen Feedback-Zyklen und agilen Sprints.

Regulierte Branchen mit Audit-Pflicht. Banken, Versicherer und Gesundheitsdienstleister im DACH-Raum brauchen dokumentierte, auditierbare Nachweise. Gartner-MQ-Leader wie Checkmarx oder Veracode liefern die Reporting-Tiefe, die Prüfer erwarten.

APIs und Microservices in Produktion. Wer öffentlich erreichbare Endpunkte absichern muss, kommt an DAST nicht vorbei. Burp Suite Enterprise oder Invicti scannen laufende Systeme gegen Broken Authentication, die laut Wallarm-ThreatStats-Daten für 52 Prozent aller dokumentierten API-Breaches 2025 verantwortlich war.

Kleine Teams und Open-Source-Projekte. Mit begrenztem Budget liefert die Kombination aus OWASP ZAP (kostenlos) und Semgrep Free-Tier (bis zehn Mitwirkende) eine solide Grundabsicherung ohne Lizenzkosten.

Legacy-Anwendungen ohne Quellcode-Zugriff. Bei zugekaufter Software oder alten Systemen ohne verfügbaren Code bleibt DAST oft die einzige realistische Option, weil SAST zwingend Quellcode voraussetzt.

GitHub-zentrierte Organisationen. Wer bereits vollständig auf GitHub setzt, profitiert von der nativen Integration von GitHub Advanced Security mit CodeQL, bei der SAST-Scans automatisch bei jedem Push laufen, ohne separate Tool-Verwaltung.

Migrationsleitfaden: SAST und DAST in die CI/CD-Pipeline integrieren

Der Umstieg von reinem manuellem Pentesting auf automatisiertes SAST und DAST gelingt in überschaubaren Schritten. Diese Reihenfolge hat sich in DevSecOps-Teams bewährt, die 2026 von Null auf eine funktionierende Pipeline umstellen. Realistisch sollten Teams für den vollständigen Umstieg drei bis sechs Monate einplanen, nicht ein einzelnes Sprint-Wochenende. Der größte Zeitfresser ist fast immer die Tuning-Phase, in der ein Team lernt, welche Regeln für die eigene Codebasis Sinn ergeben und welche nur Rauschen erzeugen.

  1. Bestandsaufnahme: Alle Repositories, Programmiersprachen und laufenden Umgebungen erfassen
  2. Ein SAST-Tool mit kostenlosem Einstiegstarif wählen (Semgrep oder Snyk Code) und auf einem Pilot-Repository testen
  3. SAST-Scan als Pflichtschritt in den Pull-Request-Workflow einbauen, zunächst nur als Warnung, nicht als Blocker
  4. Nach zwei bis vier Wochen Tuning-Phase: Fehlalarme in Regeln ausschließen, dann auf „Merge blockieren bei kritischen Funden” umstellen
  5. OWASP ZAP als kostenloses DAST-Tool gegen eine Staging-Umgebung einrichten, zunächst als nächtlicher Baseline-Scan
  6. DAST-Ergebnisse mit dem Ticketsystem verknüpfen, damit Funde nicht wie bei Equifax folgenlos bleiben
  7. SCA ergänzen, um die 70 bis 90 Prozent Drittanbieter-Code abzudecken, die weder SAST noch DAST vollständig erfassen
  8. Nach drei Monaten stabilem Betrieb: Wechsel von Burp Suite Professional auf eine Enterprise/DAST-Lizenz erwägen, sobald mehrere Ziele gescannt werden müssen

Ein minimaler Einstieg in GitHub Actions kombiniert SAST und einen DAST-Baseline-Scan in einem Workflow:

name: appsec-pipeline
on: [pull_request]
jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Semgrep SAST Scan
        uses: semgrep/semgrep-action@v1
        with:
          config: p/owasp-top-ten
  dast-baseline:
    runs-on: ubuntu-latest
    needs: sast
    steps:
      - name: OWASP ZAP Baseline Scan
        uses: zaproxy/[email protected]
        with:
          target: 'https://staging.example.de'

Wichtig bei der Migration: SAST zuerst blockierend schalten, DAST erst als Beobachtungsmodus laufen lassen. Wer DAST von Tag eins an als Merge-Blocker einrichtet, riskiert bei der hohen Fehlalarmquote von bis zu 82 Prozent, dass Entwickler die Warnungen ignorieren, genau das Muster, das laut der Equifax-Analyse zum Ausfall der Kontrolle führte.

Ein häufiger Stolperstein bei der Migration ist die Reihenfolge der Verantwortlichkeiten. Wird ein Sicherheitsteam zentral mit der Pflege aller Regeln betraut, entsteht schnell ein Flaschenhals, sobald mehrere Entwicklungsteams gleichzeitig neue Repositories anbinden wollen. Bewährt hat sich stattdessen ein föderiertes Modell: Das Sicherheitsteam definiert die Baseline-Regeln und eskaliert kritische Funde, einzelne Entwicklungsteams verwalten aber ihre eigenen Ausnahmen und Tuning-Entscheidungen selbst, mit einem Sicherheitsteam als Reviewer statt als Flaschenhals.

KI-gestützte Sicherheitstests: Was sich 2026 ändert

Die Übernahme von Tromzo durch Checkmarx im Dezember 2025 markiert einen klaren Trend: Autonome Triage-Agenten, die Funde priorisieren und Fehlalarme automatisch aussortieren, wandern von Forschungsprojekten in produktive Enterprise-Plattformen. Checkmarx kündigt für Anfang 2026 neue „Assist”-Agenten an, die auf Tromzos Reasoning-Engine aufbauen und laut eigener Darstellung Entwicklungskosten senken sowie die Geschwindigkeit erhöhen sollen.

Für DACH-Teams heißt das praktisch: Die klassische Trennung zwischen SAST, DAST und SCA verschwimmt zunehmend in einer gemeinsamen Plattform, die alle drei Signale zusammenführt und per KI priorisiert. Der Gartner Magic Quadrant für Application Security Testing behandelt SAST, DAST, SCA und IAST 2025 bereits unter einem gemeinsamen „AST”-Dach, mit Synopsys/Black Duck, OpenText, Veracode und Checkmarx als wiederkehrende Leader. Wer heute ein Tool auswählt, sollte deshalb weniger fragen „SAST oder DAST”, sondern eher, welche Plattform beide Signale sauber korreliert.

Skepsis bleibt trotzdem angebracht. Ein Triage-Agent, der automatisch entscheidet, welche Funde ein Entwicklerteam sieht und welche er verwirft, verlagert einen Teil der Verantwortung vom menschlichen Reviewer auf ein Modell, dessen Fehlerquote sich nicht so leicht messen lässt wie die klassische Fehlalarmquote eines Scanners. Für regulierte Branchen mit CRA-Meldepflicht wird deshalb entscheidend sein, ob Anbieter wie Checkmarx nachvollziehbar dokumentieren, warum ein KI-Agent einen Fund als irrelevant einstuft, nicht nur, dass er es tut.

Das Urteil: SAST vs. DAST für DACH-Teams

Die Datenlage lässt sich nicht zu einem einzigen Gewinner zusammenfassen, und genau das ist die eigentliche Erkenntnis. SAST gewinnt bei Präzision (0,98 gegenüber 0,23 in der arXiv-Studie), bei Geschwindigkeit und bei den Kosten für kleine Teams, ab 0 Dollar mit Semgrep oder 25 Dollar pro Entwickler und Monat mit Snyk Code. DAST gewinnt dort, wo SAST blind ist: bei Laufzeitfehlern, bei Systemen ohne verfügbaren Quellcode und bei den 52 Prozent der API-Breaches, die auf Broken Authentication zurückgehen, ein Fehlerbild, das nur eine laufende Anwendung überhaupt zeigen kann.

Die Praxisempfehlung für 2026: Start mit SAST als Pflichtschritt im Pull Request, weil die Kosten für frühe Fixes laut IBM/Ponemon-Daten bei rund 80 Dollar statt 7.600 Dollar in Produktion liegen. DAST folgt als nächtlicher oder wöchentlicher Scan gegen Staging, sobald die Anwendung öffentlich erreichbare Endpunkte hat. Reine SAST- oder reine DAST-Strategien decken laut GitLab-Daten jeweils nur rund ein Drittel der Organisationen zufriedenstellend ab, wer beide kombiniert, schließt die Lücke, die 2025 bei tj-actions/changed-files und Shai-Hulud 2.0 schmerzhaft sichtbar wurde: Supply-Chain-Komponenten, die weder klassisches SAST noch klassisches DAST je zu Gesicht bekommen.

Für ein kleines Team mit begrenztem Budget bleibt die pragmatischste Kombination 2026 dieselbe wie im Vorjahr: Semgrep oder Snyk Code kostenlos für den Einstieg in SAST, OWASP ZAP kostenlos für die ersten DAST-Baseline-Scans. Wächst das Unternehmen in regulierte Bereiche mit CRA-Meldepflichten hinein, wird der Wechsel zu einer Plattform mit dokumentiertem Reporting, etwa Checkmarx One oder Veracode, zur Frage von Monaten statt Jahren. Die Tools ändern sich, das Grundprinzip bleibt: Code prüfen, bevor er läuft, und die laufende Anwendung prüfen, weil kein statischer Scan die Realität einer Produktionsumgebung vollständig vorhersagen kann.

Am Ende entscheidet nicht die Marketingfolie eines Anbieters, sondern die eigene Vorfallshistorie. Ein Team, das in den letzten zwölf Monaten vor allem Fehler im eigenen Code fand, sollte zuerst in SAST investieren. Ein Team, dessen letzte Sicherheitsvorfälle Konfigurations- oder Auth-Fehler in Produktion waren, sollte DAST priorisieren. Die 33 zu 34 Prozent Adoption zeigen, dass die Branche insgesamt noch keine endgültige Antwort gefunden hat, umso wichtiger ist es, die eigene Datenlage vor der Tool-Entscheidung ehrlich zu prüfen statt einer generischen Empfehlung blind zu folgen.

Häufig gestellte Fragen

Was ist der Hauptunterschied zwischen SAST und DAST?

SAST prüft Quellcode ohne Ausführung, meist vor dem Merge. DAST testet die laufende Anwendung von außen über HTTP-Requests, ohne Zugriff auf den Code zu benötigen. Der Unterschied zeigt sich am deutlichsten in der Fehlerklasse: SAST findet unsichere Coding-Patterns direkt in der Codezeile, DAST findet Fehler, die erst entstehen, wenn Code, Konfiguration und Infrastruktur zusammen laufen.

Brauche ich SAST und DAST gleichzeitig?

Für die meisten produktiven Anwendungen ja. Laut GitLab-Daten decken beide Methoden zusammen deutlich mehr Schwachstellenklassen ab als jede für sich, weil sie an unterschiedlichen Punkten der Pipeline ansetzen. Ausnahmen sind kleine interne Tools ohne Internetzugriff, bei denen ein reines SAST-Setup oft ausreicht, oder reine Blackbox-Audits von Fremdsoftware, bei denen SAST mangels Quellcode gar nicht infrage kommt.

Ist OWASP ZAP so gut wie Burp Suite Professional?

OWASP ZAP ist kostenlos und für Baseline-Scans sowie kleine Teams gut geeignet. Burp Suite Professional bietet für rund 499 Dollar im Jahr tiefere manuelle Testfunktionen und einen größeren Plugin-Markt, was in professionellen Pentests häufig den Ausschlag gibt.

Wie viel kostet die Einführung von SAST in einem kleinen Team?

Mit Semgrep kostenlos bis zehn Mitwirkende, danach ab 30 Dollar pro Mitwirkendem und Monat. Snyk Code bietet ebenfalls einen kostenlosen Einstieg vor dem Wechsel auf den Team-Tarif für 25 Dollar pro Entwickler und Monat.

Erkennt SAST auch Schwachstellen in Open-Source-Bibliotheken?

Nur eingeschränkt. Dafür ist eigentlich Software Composition Analysis zuständig, die oft als separates Modul neben SAST läuft, etwa bei Semgrep Supply Chain oder Checkmarx SCA.

Welche Rolle spielt IAST gegenüber SAST und DAST?

Interactive Application Security Testing kombiniert Elemente beider Ansätze und lief in einer arXiv-Studie mit einer Präzision von 0,40, zwischen SAST (0,98) und DAST (0,23). IAST bleibt 2026 aber ein Nischenprodukt gegenüber den etablierten SAST- und DAST-Kategorien.

Wie lange dauert ein typischer DAST-Scan?

Ein vollständiger Scan gegen eine komplexe Web-Anwendung dauert oft mehrere Stunden, weshalb DAST meist nächtlich oder wöchentlich läuft statt bei jedem Commit.

Ist SAST oder DAST besser gegen Supply-Chain-Angriffe wie Shai-Hulud?

Keines von beiden zuverlässig. Sowohl der tj-actions/changed-files-Vorfall als auch Shai-Hulud 2.0 spielten sich in CI/CD-Komponenten und npm-Paketen ab, außerhalb der klassischen Reichweite von Anwendungs-SAST und -DAST. Dafür braucht es zusätzlich Supply-Chain-bewusstes Scanning von Abhängigkeiten und Actions.