Marktanalyse 2026. Der Blick gilt nicht den Cloud-SaaS-Tools, die in jeder Top-10-Liste stehen, sondern der Frage, die in Behörden und Konzernen über Einsatz oder Nicht-Einsatz entscheidet: Was läuft im eigenen Rechenzentrum — und was nur in fremder Cloud?

Worum es geht — und worum nicht

In einem Architektur-Gespräch mit einem öffentlichen Auftraggeber kam neulich die Frage: „Welches KI-Tool für Code-Security empfehlen Sie?“ Die ehrliche Antwort war eine Gegenfrage: „Darf der Quellcode Ihr Rechenzentrum verlassen?“

Damit war die Hälfte des Marktes raus.

Statische Codeanalyse — Static Application Security Testing, kurz SAST — ist kein neues Thema. Die Werkzeuge gibt es seit Jahrzehnten. Neu ist, dass nahezu jeder Anbieter inzwischen „KI“ auf die Verpackung schreibt. Das Problem dabei: Der Begriff verdeckt mehr, als er erklärt. Für eine Organisation mit Daten-Souveränitäts-Anforderungen ist die Marketing-Frage „Hat das Tool KI?“ irrelevant. Die relevante Frage lautet: Wo läuft diese KI, und was genau macht sie.

Dieser Beitrag ordnet den Markt 2026 ein — mit dem Fokus, der für Konzerne und den öffentlichen Sektor zählt: On-Premises-Fähigkeit und digitale Souveränität. Ich gehe vier Fragen durch: Was gibt es? Was kann es? Wie bindet man es ein? Und: Was davon läuft im eigenen Haus?

Die wichtigste Unterscheidung: KI-augmented vs. KI-native

Bevor wir über einzelne Produkte reden, eine begriffliche Trennung, die den ganzen Markt sortiert. Sie ist wichtiger als jede Feature-Liste.

Es gibt zwei grundverschiedene Arten, KI in die Codeanalyse zu bringen. Branchenanalysen formulieren es so: KI-augmented SAST verbessert, wie Teams die Ergebnisse einer klassischen Analyse konsumieren, während KI-native SAST neu denkt, wie Schwachstellen überhaupt gefunden werden.[1]

KI-augmented heißt: Eine bewährte, deterministische Engine findet die Schwachstellen wie bisher. Die KI sitzt oben drauf und macht die Ergebnisse erträglich — sie priorisiert, erklärt, schlägt Fixes vor, reduziert Rauschen. Die Detektion selbst bleibt regelbasiert und nachvollziehbar.

KI-native heißt: Das Sprachmodell ist die Detektions-Engine. Es liest den Code und entscheidet selbst, was verdächtig ist.

Für Souveränitäts-Szenarien ist diese Unterscheidung doppelt relevant. Eine augmented-Architektur lässt sich oft sauber trennen: deterministische Engine on-prem, KI-Layer optional. Bei einer KI-nativen Lösung steht und fällt alles mit der Frage, wo das Modell läuft — und ob es ein selbst-hostbares Modell überhaupt gibt.

Marktüberblick: drei Lager

Der Markt 2026 zerfällt grob in drei Gruppen.

Lager 1: Etablierte Plattformen mit KI-Layer

Das sind die klassischen Enterprise-AppSec-Plattformen, die KI nicht zur Detektion, sondern zur Remediation und Priorisierung nutzen.

Checkmarx One ist hier der Platzhirsch. Die Plattform bündelt neun Scanning-Capabilities — SAST, SCA, DAST, IaC, Container, API, Secrets, Malicious-Package-Detection und Repository-Health — unter einer ASPM-Schicht und ist nach eigenen Angaben bei 40 Prozent der Fortune 100 im Einsatz.[2] KI kommt bei der Anpassung von Detektions-Queries und bei der Remediation ins Spiel, nicht als Ersatz der Engine.

Veracode zentriert seine KI-Story auf Veracode Fix, das statische Findings mit Leitplanken in Patches überführt.[3] Die Stärke liegt traditionell bei Legacy- und Binary-only-Codebasen über mehr als hundert Sprachen hinweg.[4]

GitHub Advanced Security nutzt CodeQL für die semantische Analyse und Copilot Autofix für die Remediation. Letzteres schlägt nach Herstellerangaben für rund 90 Prozent der Alert-Typen automatisch Fixes vor.[3]

Lager 2: KI-native SAST

Hier ist das Modell der Kern.

Snyk Code mit seiner DeepCode-Engine ist IDE-first und stark in der Echtzeit-Analyse — mit einem für unsere Zielgruppe entscheidenden Haken, zu dem ich gleich komme.

Semgrep ist ein interessanter Hybrid: regelbasierter Kern, KI zur Reduktion der Fehlalarme. Semgrep Code beansprucht eine Fehlalarm-Reduktion von bis zu 98 Prozent über Cross-File-Dataflow-Analyse.[2]

Dazu eine wachsende Generation jüngerer, LLM-zentrierter Anbieter — Corgea, Aikido, DryRun, CodeAnt — die bewusst am Pull Request ansetzen statt in der Pipeline.

Lager 3: Orchestrierung

Ein eigenes Segment bilden scanner-agnostische Layer, die selbst nicht scannen, sondern über mehreren Scannern sitzen. Pixee etwa integriert ein Dutzend native Scanner plus universelle SARIF-Ingestion und lässt sich self-hosted, im VPC oder air-gapped betreiben — letzteres mit einem selbst-gehosteten LLM.[8] Der ehrliche Hinweis dazu: Das ist kein Scanner. Man braucht weiterhin mindestens ein Detektions-Tool, das die Findings erzeugt.

Was die KI wirklich kann — ein nüchterner Blick auf die Zahlen

Der eigentliche Treiber hinter dem KI-Hype ist kein neues Feature, sondern ein altes Problem: Fehlalarme. Traditionelle SAST-Tools produzieren Fehlalarm-Raten zwischen 30 und 70 Prozent.[5] Wenn jeder dritte Alert ein Fehlalarm ist, hören Security-Teams auf, dem Tool zu vertrauen, und Entwickler ignorieren es. Das erklärt, warum SAST trotz jahrzehntelanger Verfügbarkeit in vielen Organisationen schlecht adoptiert ist — nicht aus Unkenntnis, sondern aus Erfahrung.

Hier setzt die KI an. Und hier lohnt der nüchterne Blick statt der Marketing-Folie.

Die akademische Befundlage ist ermutigend, aber differenziert. Eine vielzitierte empirische Studie der Universität Wuhan kommt zu dem Ergebnis, dass LLMs in der Security-Code-Review state-of-the-art-Static-Analysis-Tools deutlich übertreffen — und dass reasoning-optimierte Modelle besser abschneiden als Allzweck-Modelle.[12] Im Detail aber zeigt dieselbe Studie die Grenzen: Vortrainierte LLMs haben nur begrenzte Fähigkeiten in der Security-Review, und die getesteten Modelle produzierten häufig weitschweifige oder nicht-aufgaben-konforme Antworten.[12] Übertreffen heißt hier also nicht „lösen“, sondern „besser als eine niedrige Messlatte“.

Eine industrielle Studie auf einem Tencent-Datensatz bringt die für Enterprise-Kontexte zentrale Nuance: Unternehmen priorisieren in der Regel Recall über Precision — also lieber einen Fehlalarm zu viel als eine echte Lücke übersehen.[13] Die rohen Werte einfacher Prompts sind dabei ernüchternd: Basic-Prompt-Konfigurationen erreichen Precision-Werte um 0,26 bis 0,29. Erst spezialisierte, kontextangereicherte Verfahren heben die Genauigkeit deutlich — die Studie berichtet für ihren Ansatz Accuracy-Werte über 0,93.[13] Die Lehre: Nicht das Modell allein entscheidet, sondern wie viel Kontext und Struktur man ihm gibt.

Was bleibt menschliche Arbeit? Business-Logik-Schwachstellen und komplexe Multi-System-Angriffsketten erfordern weiterhin menschliches Verständnis.[5] Eine KI, die einzelne Dateien bewertet, sieht den Angriff nicht, der sich über fünf Services und drei Vertrauensgrenzen zieht.

Konkret zieht man aus diesen Systemen drei Arten von Ergebnissen: priorisierte Findings auf Basis der Ausnutzbarkeit statt roher CVE-Masse; kontextbezogene Auto-Fix-Vorschläge; und Reachability-Analysen. Letztere sind unterschätzt — Semgrep Supply Chain etwa prüft, ob eine verwundbare Funktion vom eigenen Code überhaupt aufgerufen wird, statt jedes CVE im Dependency-Baum zu melden.[6] Das reduziert die Triage-Last erheblich.

Einbindung: IDE, Pull Request, Pipeline

Es gibt drei Punkte, an denen man Codeanalyse einhängt — und der Trend 2026 verschiebt das Gewicht zwischen ihnen.

In der IDE. Echtzeit-Hinweise beim Tippen, ganz links im Prozess. Snyk Code und vergleichbare Tools liefern das in VS Code und IntelliJ. Gut für die Entwickler-Akzeptanz, weil der Hinweis kommt, bevor der Code überhaupt committed ist.

Am Pull Request. Das ist das eigentliche Gate. Die jüngere Werkzeug-Generation setzt bewusst hier an: DryRun Security etwa sitzt im Workflow am Pull Request und ermöglicht Auto-Remediation mit Kontext über den breiteren Code.[11] Der PR ist der Moment, in dem genug Kontext vorhanden ist (der ganze Change, nicht nur eine Zeile), aber noch nichts im Hauptzweig steht.

In der CI/CD-Pipeline. Das harte Quality-Gate. Hier lief SAST traditionell — und hier liegt auch sein Ruf begraben. Teams haben schmerzhaft gelernt, dass „in CI einschalten“ oft eine Mauer aus Alerts und niedriges Vertrauen produziert.[1] Die Pipeline bleibt wichtig als letzte, nicht umgehbare Instanz, aber sie ist nicht mehr der primäre Interaktionspunkt.

Für die Werkzeugauswahl heißt das: Ein Tool, das nur in der Pipeline lebt, ist 2026 ein halbes Tool. Semgrep CE etwa läuft bewusst überall — lokal, in CI/CD, auf air-gapped Systemen, mit null Abhängigkeiten.[6]

Der Souveränitäts-Filter: Was läuft on-prem?

Jetzt zur Kernfrage. Wer Code nicht in fremde Cloud geben darf — sei es wegen BSI-Grundschutz, Verschlusssachen-Einstufung, NDA oder schlicht Konzern-Policy — für den sortiert sich der Markt schlagartig neu. Viele der gehypten Tools fallen heraus.

Die klare Bruchlinie: Snyk Code, Semgrep Cloud und Veracode sind SaaS-first, CodeQL läuft normalerweise in GitHub.[10] Snyk Code im Besonderen verlangt das Senden des Quellcodes an Snyks Cloud-Infrastruktur; Organisationen mit Daten-Souveränitäts-Anforderungen, air-gapped Umgebungen oder einer Policy gegen Cloud-Verarbeitung von Quellcode können es schlicht nicht nutzen.[7]

Was bleibt für den souveränen Betrieb?

CodeQL CLI. Die Kommandozeilen-Variante läuft vollständig on-premises, ohne Code an externe Dienste zu senden — für strikte Daten-Souveränität die fähigste freie SAST-Option.[7] Das ist die wichtigste Unterscheidung zum GitHub-gehosteten CodeQL.

Semgrep CE. Die OSS-Engine läuft air-gapped mit null Abhängigkeiten.[6] Aber mit einer ehrlichen Einschränkung: Die Community Edition erkennt in standardisierten Testsuiten nur 44 bis 48 Prozent der Schwachstellen — beeindruckend für ein freies Tool, aber durch den Single-File-Scope begrenzt.[6] Cross-File- und Taint-Analyse gibt es erst in der Pro-Engine.

SonarQube Server. Der Klassiker für Regulierte. Für Banken, Healthcare, Defense und alle mit Souveränitäts-Constraints ist die Fähigkeit, eine volle SAST-und-Quality-Plattform on-prem ohne ausgehende Netzwerk-Calls zu betreiben, schwer zu ersetzen.[10] Die Taint-Analyse über Dateigrenzen hinweg steckt in der Developer Edition und darüber.

Fortify. Deckt mehr als 33 Sprachen ab, inklusive COBOL und ABAP, und bietet On-Premises- sowie air-gapped Deployment — die Default-Wahl für Government- und Defense-Programme.[4]

AccuKnox. Bietet On-Premise- oder air-gapped Deployment und adressiert Compliance-Anforderungen wie SOC2 und NIST explizit.[9]

Für eine souveräne Mindest-Konfiguration ohne Lizenzkosten lässt sich die Veracode-Funktionalität nach einer Branchenanalyse durch Semgrep für SAST, Snyk für SCA und ZAP für DAST ersetzen — günstiger, wenngleich mit dem Snyk-Cloud-Vorbehalt für den SCA-Teil.[4]

Die KI-on-prem-Falle

Hier wird es interessant — und hier ist der Punkt, an dem ich vor zu schnellem Optimismus warne.

„KI“ und „air-gapped“ zusammen klingt nach der idealen Lösung: ein lokales Sprachmodell via Ollama, das den Code reviewt, ohne dass ein Byte das Netzwerk verlässt. Volle Souveränität, keine Per-Seat-Kosten, kein Vendor-Lock-in. Das Versprechen ist real — aber die Praxis hat Kanten.

Erstens die Werkzeug-Reife. Ein 2026er Test populärer Open-Source-Review-Tools fand, dass das Versprechen air-gapped Deployment zwar theoretisch besteht, kritische Konfigurations-Bugs Self-Hosted-Deployments in der Praxis aber untergraben: PR-Agent etwa defaultete auf hartcodierte Modelle, selbst wenn ein eigener Endpoint konfiguriert war — die entsprechenden Issues waren über vier Monate ungelöst.[14] Das ist kein Randdetail, sondern ein Blocker für genau die air-gapped Nutzung, die man eigentlich will.

Zweitens, und gravierender: die neue Angriffsfläche. Ein Pre-Commit-Hook, der zu einer KI-API durchreicht, wirft Trust-Boundary-Fragen auf. Was passiert, wenn der gereviewte Diff eine Prompt-Injection-Payload enthält? Was, wenn der Modell-Output in ein Shell-Kommando gepiped wird?[15] Die Integrationsschicht zwischen Git-Plattform und Modell — mit ihren Tokens, Webhook-Secrets und Service-Accounts — wird selbst zum Ziel.[15] Man baut ein Werkzeug ein, um Sicherheit zu erhöhen, und schafft dabei eine neue Klasse von Schwachstellen.

Das passt zur aktuellen BSI-Linie: Die Behörde behandelt KI-Agenten nicht als Software-Features, sondern als autonome Akteure mit eigener Identität, eigenen Berechtigungen und eigenem Schadensradius — und hat gemeinsam mit der französischen ANSSI ein Zero-Trust-Framework für LLM-Systeme erarbeitet.[17] Wer ein lokales Code-Review-LLM einführt, sollte es genau so behandeln: als nicht-menschliche Identität mit Least-Privilege, Sandboxing und Audit.

Wer es trotzdem tut: Self-hostbare Code-Modelle existieren in brauchbarer Qualität. Devstral Small 2 mit 24 Milliarden Parametern erreicht 68 Prozent auf SWE-bench Verified und läuft als kleinerer Ableger fürs Self-Hosting; DeepSeek-Coder in der 6,7B-Variante läuft auf Consumer-Hardware via Ollama.[16] Die Hardware ist nicht mehr das Hindernis. Die Integration und ihre Absicherung sind es.

Der regulatorische Rahmen: NIS2, C5, EU AI Act

Für die Zielgruppe öffentlicher Sektor und Konzern ist die Werkzeugfrage untrennbar von der Regulatorik. Drei Entwicklungen prägen 2026.

NIS2. Das NIS2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Kraft, die BSI-Registrierungsfrist lief am 6. März 2026 ab. Bei Verstößen drohen Bußgelder bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes, und die Geschäftsleitung haftet persönlich.[19] Für die Softwareentwicklung relevant: NIS2 fordert für Neuentwicklung einen Secure-by-Design-Ansatz mit strukturiertem Secure SDLC, der Code-Reviews und automatisierte Schwachstellenanalysen einschließt.[20] Damit wird SAST von der Kür zur dokumentationspflichtigen Pflicht. Und über die Lieferkettenpflicht trifft das auch Zulieferer, die selbst nicht direkt unter NIS2 fallen.[18]

C5:2026. Der BSI-Kriterienkatalog C5, seit 2016 der deutsche Referenzrahmen für sicheres Cloud Computing, wurde überarbeitet und erweitert die Anforderungen unter anderem an Container-Runtime-Security, Image-Scanning und Netzwerk-Policies expliziter als zuvor.[21]

EU AI Act. Die Hochrisiko-Regeln greifen ab August 2026.[17] Wer KI-Werkzeuge in sicherheitskritische Prozesse einbaut, baut damit potenziell selbst ein reguliertes System.

Ein Punkt verdient Hervorhebung, weil er gern übersehen wird: Sicherheit und Souveränität sind nicht dasselbe. Man kann eine sehr sichere Cloud nutzen und gleichzeitig zu null Prozent souverän sein.[22] Diese Unterscheidung ist der Kern jeder ernsthaften Werkzeug-Entscheidung im regulierten Umfeld. Ein SaaS-SAST-Tool mit makelloser ISO-Zertifizierung ändert nichts daran, dass der Quellcode auf fremder Infrastruktur in fremder Jurisdiktion liegt.

Takeaways

  • „Hat KI“ ist die falsche Frage. Relevant ist die Trennung zwischen KI-augmented (Engine bleibt deterministisch, KI räumt auf) und KI-nativ (Modell ist die Engine). Erstere lässt sich für Souveränitäts-Szenarien meist sauberer trennen.
  • Der Souveränitäts-Filter halbiert den Markt. CodeQL CLI, Semgrep CE, SonarQube Server, Fortify und AccuKnox laufen on-prem oder air-gapped. Snyk Code, Semgrep Cloud und Veracode sind SaaS-first.
  • Der Wert der KI liegt in der Rauschreduktion, nicht in der Magie. Studien zeigen: LLMs schlagen klassisches SAST, sind aber selbst limitiert. Genauigkeit entsteht durch Kontext und Struktur im Prompt, nicht durch das Modell allein.
  • Lokale KI-Review schafft eine neue Angriffsfläche. Prompt-Injection über Diffs, kompromittierbare Integrationsschichten — ein Code-Review-LLM ist nach BSI-Logik eine nicht-menschliche Identität und gehört entsprechend gehärtet.
  • NIS2 macht SAST zur dokumentierten Pflicht. Secure SDLC inklusive automatisierter Analyse ist seit Dezember 2025 regulatorisch verankert — mit persönlicher Haftung der Geschäftsleitung und Durchgriff auf die Lieferkette.

Wenn du gerade vor genau dieser Entscheidung stehst — souveräner Betrieb, regulatorischer Druck, eine Werkzeugkette, die hält — dann ist das eine Frage, die man besser einmal sauber durchdenkt als zweimal falsch. Schreib mir, wenn du dazu eine zweite Meinung brauchst.

Quellen

  1. Corgea — Top 6 AI SAST tools in 2026
  2. AppSec Santa — Semgrep vs Checkmarx (2026)
  3. Corgea — Best SAST Tools in 2026: Compared & Ranked
  4. AppSec Santa — Veracode Alternatives: Top Competitors (2026)
  5. Offensive360 — AI-Powered SAST: The Future of Code Security in 2026
  6. DEV Community / R. Singh — Semgrep vs Checkmarx (2026)
  7. DEV Community / R. Singh — Snyk vs CodeQL: Free SAST Tools Compared (2026)
  8. Pixee — Best SAST Tools 2026: 9 Scanners Compared
  9. AccuKnox — Best SAST Tools For 2026
  10. TECHSY — SonarQube Review 2026
  11. DryRun Security — Top 10 AI SAST Tools for 2026
  12. Yu, Liang et al. (Wuhan University u.a.) — An Insight into Security Code Review with LLMs: Capabilities, Obstacles, and Influential Factors, arXiv:2401.16310 (v4/v5, rev. Dez. 2025)
  13. Reducing False Positives in Static Bug Detection with LLMs: An Empirical Study in Industry, arXiv:2601.18844 (Jan. 2026)
  14. Augment Code — 10 Open Source AI Code Review Tools Tested on a 450K-File Monorepo (2026)
  15. Redfox Cybersecurity — Self-Hosted AI Code Review with Ollama: Security Risks & Hardening
  16. Pinggy — Best Open Source Self-Hosted LLMs for Coding in 2026
  17. Paperclipped — BSI KI-Agenten Sicherheitsregeln / NIS2, EU AI Act & AIC4 Compliance 2026
  18. Skill-Sprinters — NIS2 und KI-Sicherheit für den Mittelstand 2026
  19. Skill-Sprinters — NIS2 BSI-Prüfung 2026
  20. it-daily.net — NIS2: Von der Registrierungsfrist zur belastbaren Sicherheitsarchitektur
  21. cloudmagazin.com — BSI KRITIS 2026: NIS2, Dachgesetz und C5
  22. CSO Online — NIS2-Umsetzung: Neues BSI-Portal geht an den Start

Stand der Recherche: Mai 2026. Alle Quellen-Aussagen sind Hersteller- bzw. Drittangaben und sollten vor Tool-Auswahl gegen die jeweils aktuelle Produktdokumentation geprüft werden.