Security wird Continuous: Was sich ändert, wenn KI täglich 500 neue Findings ausspuckt

Wenn ein KI-Scanner morgens 500 Findings liefert, ist das kein Sicherheitsgewinn. Es ist ein Prozess-Problem. Und genau dieses Problem trifft 2026 jedes Team, das Software betreibt.

Vom Audit zum Dauerbetrieb

Security war lange ein Event. Einmal im Quartal ein Penetrationstest, einmal im Jahr ein Audit, dazwischen Hoffnung. Das funktionierte, solange Angreifer langsamer waren als der Audit-Zyklus. Diese Zeit ist vorbei.

2025 wurden 32 Prozent der aktiv ausgenutzten Schwachstellen innerhalb von 24 Stunden nach Veröffentlichung angegriffen – oder davor. Quartalsweise Audits finden Lücken, die seit Monaten offen standen. KI-gestützte Scanner finden sie in Minuten. Das verschiebt die gesamte Security-Logik: Weg vom periodischen Check, hin zum kontinuierlichen Monitoring.

Vulnerability Scanning ist 2026 continuous, cloud-aware und risikobasiert. Es beginnt beim Commit und bleibt aktiv bis in die Produktion. CI/CD-Pipelines flaggen Fehlkonfigurationen, Dependency-Drift und Änderungen an KI-generiertem Code bereits vor dem Deployment. Die Frage ist nicht mehr, ob man Schwachstellen findet. Die Frage ist, was man mit der Flut macht.

Das Triage-Problem

KI-Scanner finden Schwachstellen effizient. Was sie nicht tun: einordnen, priorisieren, Kontext liefern. Ein Scanner meldet eine veraltete Dependency mit einer bekannten CVE – einer öffentlich dokumentierten Sicherheitslücke mit eindeutiger Kennung im internationalen CVE-Verzeichnis (Common Vulnerabilities and Exposures). Aber ist diese CVE in der konkreten Konfiguration überhaupt ausnutzbar? Betrifft sie einen Code-Pfad, der in der eigenen Anwendung erreichbar ist? Steht dahinter ein Angriffsszenario, das im konkreten Deployment realistisch ist?

Ein typisches Beispiel: Eine Bildverarbeitungs-Library hat eine kritische RCE-Schwachstelle – aber nur im CLI-Tool-Teil, der Dateien direkt vom Dateisystem liest. Die eigene Anwendung nutzt ausschließlich die API-Funktionen über HTTP-Uploads mit Größen- und Typ-Validierung. Die CVE ist real, der CVSS-Score ist 9.8, aber im konkreten Kontext ist sie nicht ausnutzbar. Ohne Reachability-Analyse landet sie trotzdem als kritisches Ticket beim Team.

Nur 18 Prozent der als kritisch eingestuften Schwachstellen in einer typischen DevSecOps-Pipeline sind tatsächlich priorisierungswürdig. Der Rest ist Rauschen. Aber Rauschen, das analysiert werden muss – denn die echten Treffer verstecken sich darin.

Das Problem ist nicht neu, aber die Dimension ist es. Wenn ein Team 50 Findings pro Woche bearbeiten konnte, ist das bei 500 pro Tag eine andere Aufgabe. Ohne Automatisierung in der Triage wird Security zum Flaschenhals der gesamten Entwicklung.

500 Findings, 5 echte Probleme

Was passiert konkret, wenn morgens 500 Findings in der Queue landen? In einem funktionierenden Setup sieht der Ablauf so aus:

1. Scanner liefert Findings in eine zentrale Queue. Alle Quellen – SAST, DAST, SCA, Container-Scanning – laufen in eine einzige Plattform zusammen. Keine Silo-Dashboards, kein manuelles Zusammenklicken.
2. Automatisierte Vor-Triage filtert auf 30. Reachability-Analyse prüft, ob der betroffene Code-Pfad erreichbar ist. Asset-Kritikalität gewichtet nach Umgebung (öffentliches API-Gateway vs. internes Batch-Tool). Exploit-Status prüft, ob ein funktionierender Angriff bekannt ist. 470 Findings werden als „Low” markiert und in die Backlog-Queue verschoben.
3. LLM clustert die 30 auf 5 Tickets. 12 Findings betreffen dieselbe veraltete OpenSSL-Version in drei Container-Images – ein Ticket. 8 Findings sind Varianten desselben XSS-Patterns in der gleichen Frontend-Komponente – ein Ticket. Das LLM fügt jedem Ticket eine Zusammenfassung hinzu: betroffene Services, letzte Code-Änderungen, empfohlene Maßnahme.
4. Security Champions der betroffenen Teams bekommen je ein bis zwei Tickets mit Handlungsempfehlung und genug Kontext, um in 15 Minuten zu entscheiden: Fix sofort, nächster Sprint oder Rückfrage an das zentrale Security-Team.
5. Nur 3 Tickets landen beim zentralen Security-Team – architekturelle Risiken, teamübergreifende Patterns oder Findings, die eine Eskalation erfordern.

Von 500 Findings zu 5 Tickets in unter einer Stunde. Nicht weil 495 irrelevant wären – sondern weil die Automatisierung den Kontext liefert, den Menschen für schnelle Entscheidungen brauchen.

Intelligente Triage: Vom Rauschen zum Signal

Die Antwort auf mehr Findings ist nicht mehr Personal. Es ist bessere Filterung.

Risikobasierte Priorisierung

Nicht jede CVE ist gleich relevant. Moderne Triage-Systeme bewerten Schwachstellen anhand von:

• Exploit-Verfügbarkeit: Gibt es einen bekannten, funktionierenden Exploit? Wird die Schwachstelle aktiv ausgenutzt?
• Erreichbarkeit: Ist der betroffene Code-Pfad in der eigenen Anwendung überhaupt erreichbar? Statische und dynamische Analyse liefern hier Kontext, den ein CVE-Score allein nicht hat.
• Asset-Kritikalität: Ein XSS in einem internen Admin-Tool hat andere Priorität als eines im öffentlichen Login.
• Umgebung: Eine Schwachstelle in einem Container, der nur im internen Netz läuft und keinen Ingress hat, ist anders zu bewerten als eine im öffentlichen API-Gateway.

KI-gestützte Anreicherung

LLMs können jeden Alert mit Kontextdaten anreichern: Welcher Service ist betroffen, welche Code-Änderungen wurden kürzlich vorgenommen, wie kritisch ist das Asset. Das reduziert False Positives um rund 20 Prozent und gibt dem Security-Team die Information, die es für eine schnelle Entscheidung braucht.

KI wird dabei eingesetzt, um aus 5.000 Low-Level-Alerts die fünf herauszufiltern, die sofortige Aufmerksamkeit verdienen. Clustering, Deduplizierung und automatische Korrelation mit bekannten Angriffsvektoren machen aus einer unüberschaubaren Liste eine bearbeitbare Queue.

Wofür KI sich eignet – und wofür nicht

KI in der Security-Triage ist ein Werkzeug, kein Entscheider. Die Grenze muss klar sein.

KI eignet sich für:

• Clustering: Welche 200 Findings haben denselben Root Cause?
• Anreicherung: „Diese CVE betrifft exakt eure Auth-Middleware, weil der betroffene Code-Pfad in POST /api/login aufgerufen wird.”
• Generierung von Test-Cases, die nach einem Fix laufen sollen.
• Zusammenfassungen für Security Champions, die keine 30 Seiten CVE-Details lesen wollen.

KI darf Entscheidungen vorbereiten, aber nicht endgültig treffen bei:

• Risikoeinstufung: Ob ein Finding „kritisch” oder „mittel” ist, entscheidet ein Mensch – die Konsequenzen sind zu unterschiedlich.
• Rollout von Patches in Produktion: Automatisierte PRs ja, automatisiertes Mergen ohne Review nein.
• Ausnahmen von SLAs: Wenn ein kritisches Finding die Deadline reißt, braucht es eine bewusste menschliche Entscheidung, nicht einen Auto-Snooze.

Wer diese Grenze nicht zieht, wird irgendwann feststellen, dass ein LLM eine kritische Schwachstelle als „Low” klassifiziert hat – und niemand hat es überprüft.

Automatisierte Patch-Vorschläge

Tools wie Dependabot, Renovate oder KI-gestützte Systeme generieren automatisch Pull Requests für bekannte Schwachstellen in Dependencies. Das beschleunigt die Behebung erheblich – birgt aber Risiken:

• Breaking Changes: Ein automatisch aktualisiertes Package kann inkompatibel sein. Ohne Testabdeckung wird das erst in der Produktion sichtbar.
• Transitive Dependencies: Der Fix einer direkten Dependency kann Probleme in transitiven Dependencies erzeugen.
• Halluzinierte Fixes: KI-generierte Patches können Code einführen, der die Schwachstelle nicht behebt oder neue erzeugt.

Die Regel: Automatische Patch-Vorschläge sind eine Beschleunigung der Analyse, kein Ersatz für Review.

Wie Teams sich organisieren müssen

Continuous Security verändert nicht nur Tools, sondern Teamstrukturen.

Zur Klarstellung: Das zentrale Security-Team definiert Richtlinien, bewertet architekturelle Risiken und pflegt die Toolchain. Security Champions sind Entwickler in den Produktteams, die als erste Anlaufstelle für Findings fungieren und die Triage im Kontext ihres Services übernehmen.

Security als Shared Responsibility

Wenn Findings kontinuierlich eintreffen, kann das zentrale Security-Team nicht mehr allein triagieren. Die Verantwortung verschiebt sich: Entwickler übernehmen die erste Bewertung im Kontext ihres Services, das zentrale Security-Team konzentriert sich auf architekturelle Risiken und teamübergreifende Muster.

Das erfordert:

• Security Champions in jedem Team: Entwickler, die als Ansprechpartner für Security-Findings fungieren und die erste Triage übernehmen.
• Klare Eskalationswege: Welche Findings bearbeitet das Team selbst, welche gehen an das zentrale Security-Team? Definierte SLAs nach Schweregrad.
• Tooling, das Kontext liefert: Findings müssen automatisch dem richtigen Team zugeordnet werden, mit genug Kontext für eine schnelle Entscheidung.

SLAs nach Schweregrad

Nicht alles muss sofort gepatcht werden. Aber die Zeiten müssen definiert sein:

Schweregrad	Typische SLA	Beispiel
Kritisch (aktiv ausgenutzt)	24 Stunden	RCE in öffentlich erreichbarem Service
Hoch (Exploit verfügbar)	7 Tage	SQL-Injection in API-Endpoint
Mittel (kein bekannter Exploit)	30 Tage	XSS in internem Tool
Niedrig (theoretisch)	Nächster Sprint	Informational Disclosure ohne Nutzerdaten

Diese Werte sind Ausgangspunkte, keine Dogmen. Die passenden SLAs hängen von Branche, Regulierung und Risikoprofil ab. Ein Finanzdienstleister wird bei „Hoch” keine 7 Tage akzeptieren, ein internes Reporting-Tool braucht vielleicht keine 24-Stunden-SLA für kritische Findings. Entscheidend ist, dass die Werte existieren, dokumentiert sind und eingehalten werden.

Metriken, die zählen

Die Anzahl der Findings ist keine sinnvolle Metrik. Was zählt:

• Mean Time to Remediate (MTTR): Wie lange dauert es vom Finding bis zum Fix?
• Patch Coverage: Welcher Anteil der kritischen Findings wird innerhalb der SLA behoben?
• False-Positive-Rate: Wie viel Prozent der Findings sind nach Triage irrelevant? Sinkt die Rate über die Zeit?
• Reintroduction Rate: Wie oft tauchen bereits behobene Schwachstellen wieder auf?

Was ohne diese Voraussetzungen nicht funktioniert

Continuous Security scheitert nicht an fehlenden Tools. Es scheitert an fehlenden Grundlagen.

Ohne Testabdeckung ist jeder automatisierte Fix russisches Roulette. Renovate erstellt einen PR, der eine kritische Dependency aktualisiert. Die CI-Pipeline ist grün – aber nur, weil es keine Tests gibt, die den betroffenen Code-Pfad abdecken. Der Fix geht in Produktion, bricht die Auth-Middleware, und der Incident kostet mehr als die Schwachstelle je gekostet hätte. Automatisierte Patch-Vorschläge funktionieren nur, wenn die Test-Suite gut genug ist, um Breaking Changes zu fangen.

Ohne End-to-End-Verantwortung bleiben Findings liegen. Wenn ein Team für Features zuständig ist, aber ein anderes Team für Security-Fixes, entsteht ein Verantwortungsvakuum. Findings werden zum Schwarzen Peter: „Das ist nicht unser Service”, „Das muss Security bewerten”, „Wir warten auf Priorisierung”. Continuous Security funktioniert nur, wenn jedes Team die volle Verantwortung für seinen Service trägt – inklusive der Schwachstellen darin.

SLAs ohne Konsequenzen sind Dekoration. Wenn eine kritische Schwachstelle mit 24-Stunden-SLA auftaucht und das Management trotzdem erwartet, dass das Feature-Release pünktlich kommt, wird die SLA gebrochen. Jedes Mal. Management muss akzeptieren, dass manche Feature-Deadlines fallen, wenn kritische SLAs verletzt sind. Sonst lernt das Team schnell, dass Security-SLAs verhandelbar sind – und dann sind sie wertlos.

Continuous Security in der Supply Chain

500 Findings pro Tag kommen 2026 selten aus dem eigenen Code. Der Großteil stammt aus der Lieferkette: Third-Party-Libraries, Managed Services, SaaS-Komponenten, Upstream-Open-Source-Projekte, die selbst KI-generierten Code einchecken. Continuous Security heißt auch: permanent überwachen, welche neuen Abhängigkeiten auftauchen – nicht nur den eigenen Code.

Das betrifft drei Ebenen:

Open-Source-Dependencies: Der klassische Fall. Renovate und Dependabot überwachen direkte und transitive Dependencies. Aber wer überwacht, ob ein Upstream-Maintainer ausgebrannt ist und seit Monaten keine Patches mehr liefert? SBOM-Analyse zeigt nicht nur, was drin steckt, sondern auch, wie aktiv es gepflegt wird. Projekte ohne Commits seit sechs Monaten bei gleichzeitig offenen CVEs sind ein Risikosignal.

Third-Party-Services und SaaS: Der API-Gateway-Provider, der Identity-Service, die Payment-Lösung – all das ist Teil der Angriffsfläche, ohne dass es in der eigenen SBOM auftaucht. Vendor-Risiko-Bewertung muss automatisiert und kontinuierlich sein: Wie schnell patcht der Anbieter bekannte Schwachstellen? Gibt es eine Security-SLA im Vertrag? Liefert der Anbieter selbst eine SBOM?

Interne Platform-Dependencies: In Microservice-Architekturen baut jedes Team auf gemeinsamen Plattform-Komponenten auf. Eine Schwachstelle in der internen Auth-Library betrifft 40 Services gleichzeitig. Wer ist dann verantwortlich – das Plattform-Team oder jedes einzelne Service-Team? Ohne klare Ownership-Regeln für Plattform-Security entstehen blinde Flecken, die kein Scanner findet.

SBOMs von Lieferanten einfordern, automatisierte Vendor-Risiko-Bewertung einrichten und Alerting für kritische CVEs in Komponenten aktivieren, die man nicht selbst kontrolliert – das ist keine Kür, sondern Voraussetzung für Continuous Security in einer vernetzten Infrastruktur.

Die Tool-Landschaft 2026

Die Werkzeuge für Continuous Security existieren. Die Herausforderung liegt in der Integration.

Scanner und Discovery

• SAST/DAST mit KI-Anreicherung: Tools wie Snyk, Semgrep oder Checkmarx nutzen KI-Modelle, um Findings kontextuell zu bewerten und False Positives zu reduzieren.
• SCA (Software Composition Analysis): Dependency-Scanner wie Dependabot, Renovate oder Trivy prüfen kontinuierlich auf bekannte CVEs in Dependencies.
• SBOM-Management: Software Bill of Materials als Grundlage, um überhaupt zu wissen, welche Komponenten wo laufen.

Triage und Orchestrierung

• Security Orchestration Platforms: Systeme, die Findings aus verschiedenen Scannern aggregieren, deduplizieren und priorisieren.
• Reachability Analysis: Tools, die prüfen, ob ein verwundbarer Code-Pfad in der eigenen Anwendung tatsächlich erreichbar ist.
• Integration in bestehende Workflows: Findings als Tickets in Jira, als Alerts in Slack, als automatisierte PRs in GitHub – dort, wo das Team bereits arbeitet.

Von Null auf Continuous: Der Fahrplan

Für Teams, die heute noch mit quartalsweisen Penetrationstests arbeiten, ist hier der konkrete Weg. Die Reihenfolge zählt, das Tempo bestimmt jedes Team selbst.

Schritt 1: Sichtbarkeit schaffen

• SBOM erzeugen für ein bis zwei Kernservices. Nicht alles auf einmal – die wichtigsten Services zuerst. Trivy, Syft oder cdxgen machen das in Minuten.
• SCA-Scanner in ein bestehendes Repository integrieren, aber alle Findings zunächst nur als Report. Kein Build-Break, keine Blockade. Ziel ist ein erstes Bild der Lage, keine sofortige Behebung.

Schritt 2: Triage und Verantwortung etablieren

• Triage-Regeln definieren: Exploit-Status, Reachability und Asset-Kritikalität als Bewertungskriterien festlegen.
• Pro Produktteam einen Security Champion nominieren. Keine zusätzliche Stelle, sondern ein Entwickler, der diese Rolle neben seiner regulären Arbeit übernimmt – mit dafür reservierter Zeit.
• Erstes, bewusst simples SLA-Set einführen: „Kritisch = 24 Stunden, Hoch = 7 Tage.” Mehr braucht es am Anfang nicht. Lieber zwei Stufen konsequent einhalten als vier Stufen auf dem Papier.

Schritt 3: Automatisierung und Messung

• Automatisierte PRs für Dependencies aktivieren, mit klarer Regel: Kein Merge ohne grünen Testlauf und Review.
• Erste Metriken sichtbar machen. MTTR für kritische Findings und Patch Coverage in einem einfachen Dashboard – Grafana, Notion-Tabelle oder ein Spreadsheet reichen für den Anfang.
• Retrospektive: Was hat funktioniert? Wo hakt die Triage? Welche SLAs waren realistisch, welche nicht?

Dieser Fahrplan ist kein Endpunkt. Er ist der Startpunkt für einen Prozess, der danach iterativ besser wird – nicht durch mehr Tools, sondern durch bessere Regeln und schnellere Entscheidungen.

Wenn der Scanner 5.000 Findings liefert

Die KI-gestützte Schwachstellensuche ist da. Sie wird nicht verschwinden, und sie wird besser werden. In zwei Jahren liefert der Scanner vielleicht nicht mehr 500 Findings, sondern 5.000. Das ist kein Drama – wenn Triage, Organisation und Verantwortlichkeiten dafür gebaut sind.

Die Frage war nie, ob Teams Schwachstellen finden. Die Frage ist, ob sie schnell genug entscheiden können, welche davon gefährlich sind. Wer diese Entscheidungsfähigkeit jetzt aufbaut, hat in zwei Jahren einen Prozess, der skaliert. Wer wartet, hat 5.000 Findings pro Tag und ein Hintergrundrauschen, in dem die echten Risiken untergehen.