Auf dieser Seite
Sicherheitslücken entstehen nicht, weil Entwickler nachlässig sind. Sie entstehen, weil Software komplex ist, Abhängigkeiten täglich wachsen und jede neue Codezeile potenziell eine Angriffsfläche öffnet. Das Problem ist strukturell. Strukturelle Probleme brauchen strukturelle Antworten.
KI-Modelle verändern gerade fundamental, was möglich ist. Nicht nur auf Seiten der Verteidiger: Wer glaubt, KI sei ein reines Werkzeug für Security-Teams, übersieht die andere Seite. Angreifer nutzen dieselbe Technologie, und das mit wachsendem Erfolg.
Das Wichtigste auf einen Blick
- KI-Agenten wie Googles „Big Sleep" finden bislang unbekannte Schwachstellen eigenständig, ohne menschliche Anleitung.
- Angreifer nutzen ungefilterte LLMs (WormGPT, FraudGPT) zur automatisierten Schwachstellensuche. Der Zeitraum zwischen CVE-Veröffentlichung und erstem Exploit schrumpft messbar.
- GitHub Copilot Autofix, Snyk und Semgrep Assistant integrieren KI-gestützte Fix-Vorschläge direkt in Pull Requests und CI/CD-Pipelines.
- Vier Integrationsmodelle sind in der Praxis erprobt: Scan on PR, Auto-Fix PR, Inline-Suggestion, Policy Gate.
- Entscheidend ist nicht die Technologie selbst, sondern ob Security als Eigenschaft des Entwicklungsprozesses oder als nachgelagerte Prüfinstanz verstanden wird.
Wie KI Sicherheitslücken findet
Klassische Static Application Security Testing (SAST)-Tools arbeiten regelbasiert. Sie kennen Muster wie SQL Injection, Cross-Site Scripting oder unsichere Deserialisierung und flaggen Code, der diesen Mustern entspricht. Das funktioniert gut für bekannte Schwachstellenklassen. Es versagt bei neuen Angriffsvektoren und bei kontextabhängigen Fehlern, die erst im Zusammenspiel mehrerer Komponenten kritisch werden.
LLM-basierte Systeme denken in Zusammenhängen. Google DeepMind bewies das Ende 2024 eindrucksvoll: Das Projekt „Big Sleep", eine KI-Agenten-Architektur, fand eigenständig einen Stack-Buffer-Underflow in SQLite, einer der meistgenutzten Embedded-Datenbanken der Welt. Kein Mensch hatte diese Lücke zuvor identifiziert. Die KI analysierte den Code kontextuell, verstand den Datenfluss und erkannte die Anomalie. Ohne explizite Suchanweisung, allein durch strukturiertes Reasoning über den Quellcode.
Das ist kein Einzelfall. Google hat OSS-Fuzz, sein Open-Source-Fuzzing-Programm, mit LLM-generierten Fuzz-Targets erweitert. 2024 wurden damit 26 neue Schwachstellen in weit verbreiteten Open-Source-Projekten gefunden, vollautomatisch, ohne menschliche Anleitung.
Ein weiteres Beispiel: Trail of Bits identifizierte 2023 mit KI-gestützter GPU-Speicheranalyse die Schwachstelle CVE-2023-4969 („LeftoverLocals"), die GPU-Arbeitsspeicher zwischen Prozessen lesbar machte. Betroffen waren Apple-, AMD- und Qualcomm-Chips. Der Fund erforderte systematisches Querdenken über Hardwaregrenzen hinweg, das klassische SAST-Tools strukturell nicht leisten können.
Auch die Priorisierung von CVEs hat sich durch ML verändert. Das Exploit Prediction Scoring System (EPSS) v3 nutzt Maschinelles Lernen, um vorherzusagen, welche CVEs tatsächlich aktiv ausgenutzt werden. EPSS identifiziert 82 Prozent der real ausgenutzten Schwachstellen in seinem Top-10-Prozent-Bereich. Das ist deutlich präziser als der klassische CVSS-Score, der Schwere misst, aber keine Exploitation-Wahrscheinlichkeit.
Regelbasiertes SAST
- Bekannte Muster werden erkannt
- Deterministische Ergebnisse
- Hohe False-Positive-Rate bei Kontext
- Keine Reasoning-Fähigkeit
- Versagt bei Zero-Days
LLM-gestützte Analyse
- Kontextabhängiges Reasoning
- Versteht Datenflüsse über Module hinweg
- Erklärt die Schwachstelle in natürlicher Sprache
- Findet bisher unbekannte Angriffsvektoren
- Höhere kognitive Last, höhere Trefferquote
Die andere Seite: KI als Angriffswerkzeug
Dieselbe Technologie, die Schwachstellen findet, kann auch genutzt werden, um sie auszunutzen. WormGPT und FraudGPT sind ungefilterte Sprachmodelle, die im Darknet als Service angeboten werden. Sie generieren Malware, scannen Systeme auf bekannte CVEs und unterstützen gezielte Phishing-Kampagnen.
Die US-amerikanische CISA und die NSA haben 2024 offiziell bestätigt: KI senkt die Einstiegshürde für Angreifer mit geringen technischen Kenntnissen signifikant. Staatliche Akteure wie die chinesische Hackergruppe Charcoal Typhoon und die russische Fancy Bear nutzen nachweislich LLMs zur Unterstützung ihrer Sicherheitsforschung.
Das verändert die Threat-Landscape grundlegend. Vulnerabilitäten, für deren Entdeckung ein menschlicher Angreifer früher Tage brauchte, können heute in Minuten identifiziert werden. Der Zeitraum zwischen der Veröffentlichung eines CVEs und dem ersten aktiven Exploit schrumpft. Unternehmen, die Security noch immer als reaktive Disziplin betreiben, verlieren diesen Wettlauf.
Besonders kritisch sind Supply-Chain-Angriffe. Tools wie Socket.dev analysieren bei jedem Pull Request, ob neu hinzugefügte npm- oder PyPI-Pakete bekannte Schadroutinen, Typosquatting-Muster oder ungewöhnliche Berechtigungsanforderungen enthalten. KI-gestützte Dependency-Analyse ist damit nicht mehr optional. Sie ist die einzige skalierbare Antwort auf ein strukturell gewachsenes Angriffsszenario.
KI in der CI/CD-Pipeline: Vom Fund zum Fix
Das eigentlich Transformative passiert nicht beim Finden von Lücken, sondern beim Schließen. Klassische Workflows sehen so aus: Ein SAST-Tool findet eine Schwachstelle, ein Ticket wird erstellt, ein Entwickler priorisiert es irgendwann, ein Fix wird geschrieben und gereviewed. Zwischen Fund und Deployment vergehen oft Wochen.
KI-gestützte CI/CD-Integrationen komprimieren diesen Prozess drastisch.
GitHub Copilot Autofix ist seit März 2024 allgemein verfügbar und direkt in GitHub Advanced Security integriert. CodeQL analysiert den Code beim Pull Request. Findet CodeQL eine Schwachstelle, generiert Copilot Autofix sofort einen konkreten Fix-Vorschlag als Inline-Kommentar. Der Entwickler sieht nicht nur das Problem, sondern die Lösung. In Pilotdaten von GitHub Universe 2023 akzeptierten Entwickler diese Vorschläge in rund 65 Prozent der Fälle ohne weitere Anpassung.
Snyk integriert sich in GitHub Actions, GitLab CI und Jenkins. Bei kritischen CVEs in Abhängigkeiten wird der Build blockiert und gleichzeitig ein automatisierter Pull Request mit dem Fix erstellt. Snyk berichtet, dass seine automatisierten Fixes etwa 70 Prozent der behebbaren Schwachstellen abdecken, ohne menschliches Eingreifen.
Semgrep Assistant nutzt GPT-4, um SAST-Findings zu triagieren. Es unterscheidet automatisch zwischen echten Schwachstellen und False Positives, verfasst Erklärungen für Entwickler und priorisiert nach Kritikalität. Das Ergebnis laut Semgrep: rund 20 Prozent weniger Alert-Fatigue im Security-Team. Ein Problem, das viele Organisationen lähmt, weil zu viele Warnungen dazu führen, dass echte Funde übersehen werden.
JFrog Xray ergänzt das Bild auf der Artefakt-Seite: SBOM-bewusste Analyse aller Build-Artefakte, integriert in JFrog Pipelines. Jedes Artifact wird gegen die NVD, den OSS-Index und proprietäre Datenbanken geprüft, bevor es das Repository verlässt.
Ohne KI-gestützte Pipeline
- Schwachstelle → Ticket → Warteschlange
- Tage bis Wochen bis zum Fix
- Entwickler muss Kontext neu aufbauen
- Hohe Reibungsverluste im Review
- Security als Engpass im Release-Prozess
Mit KI-gestützter Pipeline
- Schwachstelle → Inline-Fix-Vorschlag
- Minuten bis zum Deployment
- Kontext ist im PR-Kommentar enthalten
- 65 % Akzeptanzrate ohne Anpassung
- Security als automatisierter Qualitätsschritt
Vier Integrationsmodelle für die Praxis
Die Werkzeuge sind vorhanden. Die Frage ist, wie sie sinnvoll eingesetzt werden. Es haben sich vier Muster etabliert, die in der Praxis funktionieren.
1. Scan on Pull Request. SAST- oder SCA-Tools laufen als obligatorischer Schritt in der GitHub-Actions-Pipeline. Bei kritischen Findings schlägt der Build fehl. Der PR kann nicht gemerged werden. Das macht Security zu einem technischen Gate, nicht zu einer optionalen Prüfung.
2. Auto-Fix Pull Request. Tools wie Dependabot, Snyk oder Mend Renovate erstellen bei gefundenen CVEs in Abhängigkeiten automatisch einen separaten PR mit der gepatchten Version. Der Entwickler reviewed nur noch den Vorschlag, nicht das Problem.
3. Inline-Suggestion. GitHub Copilot Autofix injiziert Fixes direkt in die PR-Ansicht. Der Reviewer sieht im Diff, was geändert werden müsste. Das reduziert den Kontextwechsel auf ein Minimum.
4. Policy Gate. Tools wie Snyk und Wiz erzwingen Policies als Required Status Check: kein Deployment ohne sauberes SBOM, kein Base-Image mit bekannten Critical CVEs. Security-Standards werden strukturell durchgesetzt, nicht kommunikativ.
Was das für Unternehmen bedeutet
KI in der Security-Pipeline ist kein Nice-to-have. Es ist eine Notwendigkeit, die sich aus der Asymmetrie der Bedrohungslage ergibt. Angreifer setzen KI ein. Wer auf der Verteidigungsseite weiterhin manuell arbeitet, verliert strukturell. Nicht weil einzelne Entwickler zu langsam sind, sondern weil das Verhältnis von Angriffsfläche zu Prüfkapazität nicht mehr stimmt.
Die Werkzeuge sind ausgereift, gut dokumentiert und in bestehende Workflows integrierbar. GitHub Advanced Security mit Copilot Autofix, Snyk in der CI-Pipeline, Semgrep Assistant für die Triage, EPSS für die Priorisierung. Das sind keine experimentellen Technologien mehr, sondern produktionsreife Lösungen, die heute in Produktion sind.
Die entscheidende Entscheidung ist nicht technischer Natur. Es ist eine Entscheidung über Reife. Unternehmen, die Security als strukturelle Eigenschaft ihrer Entwicklungsprozesse verstehen, profitieren doppelt: weniger Schwachstellen in Produktion und schnellere Remediation, wenn trotzdem etwas durchrutscht.
In regulierten Branchen wie Versicherung, Logistik oder Energie ist das keine theoretische Debatte. Dort bedeutet eine kritische Schwachstelle in Produktion Compliance-Verstöße, Meldepflichten und Reputationsschäden. Wer KI-Systeme in solchen Umgebungen betreibt, muss Security-Automatisierung nicht nur einsetzen, sondern auch erklären und auditieren können. Das ist lösbar. Es erfordert aber eine bewusste Architekturentscheidung, nicht nur ein installiertes Plugin.
Wie KI-Systeme verlässlich eingesetzt werden und wo die Grenzen der Automatisierung liegen, ist ein Thema, das wir aus eigener Projekterfahrung in regulierten Branchen kennen. Die Auswahl der richtigen KI-Werkzeuge ist dabei der erste, nicht der letzte Schritt. Weitere Perspektiven zu diesen Fragen finden Sie in unserem Blog.