Schwachstellenmanagement & sicheres Code-Scanning mit automatischer Korrektur

Sicherheitsteams ertrinken in Scanner-Befunden, von denen die meisten irrelevant sind, während Entwicklern die Zeit fehlt, die echten zu beheben. KI hilft an drei Stellen: Befunde nach tatsächlicher Ausnutzbarkeit und Geschäftskontext triagieren und priorisieren, jedes Problem im eigenen Code der Entwickler erklären und einen Patch oder Upgrade-Pull-Request entwerfen, den ein Mensch prüft. Typischer Nutzen: kürzere Zeit bis zur Behebung und ein Rückstau, der schrumpft statt wächst.

Problem & Nutzen

• Heute: SAST-, SCA-, Container-, IaC- und Secret-Scanner erzeugen jeweils lange Listen mit vielen Fehlalarmen und Dubletten. Priorisierung allein nach CVSS ignoriert, ob der Codepfad erreichbar oder das Asset exponiert ist. Korrekturen warten hinter der Funktionsentwicklung; die mittlere Zeit bis zur Behebung liegt bei Wochen oder Monaten.
• KI-Nutzen: (1) Triage - LLMs lesen den umgebenden Code und beurteilen, ob ein Befund ein echter Treffer und erreichbar ist; (2) Priorisieren - CVSS, EPSS, CISA KEV, Exposition und Kritikalität des Assets kombinieren; (3) Beheben - einen minimalen Patch samt Tests als PR erzeugen; (4) Erklären - die Hürde „was bedeutet das eigentlich“ für Entwickler ohne Sicherheitshintergrund abbauen.
• Belege: GitHub berichtet, dass Copilot Autofix Korrekturvorschläge für CodeQL-Alarme direkt in Pull Requests erzeugt, und Google DeepMind beschreibt CodeMender, einen Agenten, der validierte Patches in Open-Source-Projekte einspeist [1][2]. Von Anbietern genannte Beschleunigungen variieren je nach Sprache und Fehlerklasse; messen Sie an Ihren eigenen Repositorien, bevor Sie einer Zahl trauen.
• Regulatorischer Sog: Der EU Cyber Resilience Act (CRA) verlangt von Herstellern von Produkten mit digitalen Elementen, Schwachstellen zu behandeln und aktiv ausgenutzte zu melden, wobei die Meldepflichten im September 2026 beginnen; NIS2 und DORA verlangen Schwachstellenbehandlung von wesentlichen/wichtigen Einrichtungen und Finanzunternehmen [3][4].

Varianten

• KMU: in die Git-Plattform eingebautes Scannen von Abhängigkeiten und Secrets (Update-PRs im Stil von Dependabot, KI-Autofix) plus ein verwalteter externer Schwachstellenscanner.
• Unternehmen: Exposure-Management-Plattform über Code, Cloud, Endpunkte und OT, mit risikobasierter Priorisierung, Ticket-Integration und SLA-Verfolgung.
• Softwarehersteller / CRA-Hersteller: SBOM- und VEX-Erzeugung, Ablauf für koordinierte Offenlegung, Meldung aktiv ausgenutzter Schwachstellen an die CSIRT-/ENISA-Plattform.
• Open-Source-Maintainer: KI-gestützte Triage von Meldungen; Vorsicht vor minderwertigen maschinell erzeugten Meldungen, die Maintainer überfluten.
• Öffentliche Hand: derselbe Stack, gehostet in EU-/Souveränitätsumgebungen.
• Privatnutzung: Entwickler von Hobbyprojekten nutzen kostenloses Repository-Scanning; kein Verbraucherprodukt.

So funktioniert es

1. Quellen (Repo, PR, Container-Registry, IaC, SBOM, Cloud-Inventar)
2. Scanner (SAST, SCA, Secrets, IaC, Container, DAST)
3. Befunde normalisieren & deduplizieren (SARIF, CycloneDX/SPDX)
4. anreichern (CVE/NVD, EPSS, CISA KEV, Herstellerhinweise, Kritikalität des Assets, Internet-Exposition)
5. KI-Triage (Erreichbarkeit, echter/falscher Treffer, Erklärung, Konfidenz)
6. risikobasierte Priorität + Zuweisung des Verantwortlichen
7. KI-Korrektur-Agent (Patch + Unit-Test, Abhängigkeits-Update)
8. CI-Build/Test/erneuter Scan
9. menschliches Code-Review & Merge (verpflichtend)
10. Ticket schließen, VEX-Erklärung, Audit-Nachweis

• Triage: Ein LLM oder Agent erhält den Befund, den Code-Ausschnitt, den Aufrufgraphen und Abhängigkeitsinfos und gibt Urteil, Begründung und Konfidenz zurück; bei niedriger Konfidenz entscheidet ein Mensch.
• Korrekturerzeugung: Ein Code-LLM schlägt einen Diff vor; die Pipeline validiert ihn mit Kompilierung, vorhandenen Tests, neuen Tests und erneutem Scan, sodass eine Korrektur, die den Befund nicht beseitigt, verworfen wird.
• Mensch-in-der-Schleife (Human-in-the-Loop): Entwickler prüfen und mergen jeden KI-Patch; die Sicherheit genehmigt Ausnahmen und Risikoakzeptanzen. Auto-Merge nur für enge, risikoarme Klassen (Abhängigkeits-Updates auf Patch-Ebene mit grünen Tests).

Datenaufbereitung

Schwachstellenmanagement braucht drei Eingaben: ein Inventar von Assets und Software (Server, Endgeräte, Container, Abhängigkeiten), Scan-Ergebnisse und Code-Repositorien mit funktionierenden Tests. In einem KMU ist das Inventar oft eine veraltete Excel-Liste, Scans laufen unregelmäßig, und Code liegt in einer Mischung aus Git-Hosts und Dateiablagen.

Typische Lücken: unbekannte oder Schatten-Assets, kein Verantwortlicher pro System, keine Software-Stückliste (SBOM), fehlende automatisierte Tests (sodass Korrekturen nicht verifiziert werden können), doppelte Befunde mehrerer Scanner und keine Aufzeichnung akzeptierter Risiken.

Vorbereitungsschritte: - Das Asset-Inventar aufbauen oder auffrischen und jedem System einen Verantwortlichen und eine Kritikalität zuweisen (siehe PREP-003, PREP-004). - SBOMs erzeugen und die Scanner an einen gemeinsamen Befundspeicher anbinden (siehe PREP-005). - Automatisierte Tests für die Codebereiche ergänzen oder reparieren, in denen Auto-Fix geplant ist. - Akzeptierte Risiken und frühere Korrekturen in strukturierter Form erfassen (siehe PREP-020). - Festlegen, welcher Code an externe Modelle gesendet werden darf (siehe PREP-024).

Grober Aufwand: etwa 25 Prozent des Projekts, vor allem Inventar und Testabdeckung. Ohne Verantwortliche und Tests häufen sich KI-vorgeschlagene Korrekturen ungeprüft an. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: A - eingebaute Scanner und Auto-Fix in GitHub, GitLab oder ein verwalteter Schwachstellenscanner sind ausgereift und brauchen wenig Einrichtung.
• Unternehmen: B - Code- und Asset-Kontext sind strategisch und vielfältig; Priorisierung und Korrektur-Agenten auf Cloud-APIs sowie der eigenen CMDB und den eigenen Pipelines zu bauen, gibt Kontrolle und skaliert über viele Repositorien.
• Entwickler: C - Open-Source-Scanner mit einem selbst betriebenen Codemodell halten den Quellcode im Haus und sind leicht anzupassen.
• Öffentliche Hand: C - Quellcode und Infrastrukturdetails sind sensibel, und Beschaffungsregeln sprechen für souveränen oder lokalen Betrieb (On-Premises).

Weg A — Kaufen (Standardsoftware) (empfohlen)

• Git-plattformeigen: GitHub Advanced Security (CodeQL + Copilot Autofix, Dependabot, Secret- Scanning), GitLab Ultimate (Duo: Erklärung und Behebung von Schwachstellen).
• Application-Security-Plattformen: Snyk (DeepCode AI, Snyk Agent Fix), Semgrep (Assistant), Checkmarx One, Veracode Fix, Endor Labs (Erreichbarkeit), Aikido Security (Belgien, EU - bei KMU beliebt), SonarQube (Sonar, Schweiz; AI CodeFix), Mend.io.
• Exposure-/Schwachstellenmanagement: Tenable, Qualys, Rapid7, Wiz, Microsoft Defender Vulnerability Management; Optionen aus der EU sind unter anderem Greenbone (Deutschland, Open-Source-Kern OpenVAS), Detectify (Schweden), Outpost24 (Schweden), Intruder (UK).
• A wählen, wenn: Sie kein eigenes AppSec-Team haben; prüfen Sie Datenhaltung in der EU, ob Quellcode an ein Modell eines Drittanbieters gesendet wird, Opt-outs gegen das Training mit Kundendaten sowie die Integration von SARIF/Ticketing.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Vorhandene Scanner behalten; eine Orchestrierungsebene (CI-Job oder Agentendienst) ergänzen, die ein codefähiges Modell (Claude, GPT, Gemini, Mistral Codestral/Devstral als EU-Anbieter) für Triage und Patch-Entwürfe aufruft. EU-Regionen-Endpunkte nutzen (Azure OpenAI EU, Vertex AI EU, AWS Bedrock Frankfurt/Paris, Mistral).
• Befunde als SARIF einspeisen; dem Agenten lesenden Repository-Zugriff plus einen abgeschotteten Test-Runner geben; einen PR über die API der Git-Plattform ausgeben. Strukturierte Ausgaben für Urteile.
• Anreicherung aus offenen Daten: NVD-API, CISA-KEV-Katalog, FIRST EPSS, OSV.dev, GitHub Advisory Database [5].
• B wählen, wenn: Sie eigene Priorisierungsregeln wollen oder hauseigene Werkzeuge einbinden müssen.

Weg C — Selbst betreiben (Open Source)

• Scanner: Semgrep CE, CodeQL (nur für Open-Source-Nutzung kostenlos), Bandit, Trivy, Grype/Syft, OSV-Scanner, Gitleaks, Checkov, OWASP Dependency-Track, Greenbone/OpenVAS, Nuclei, Renovate für Update-PRs.
• Modelle: Open-Weight-Codemodelle wie Qwen3-Coder, DeepSeek-Coder-V2/V3-Familie, gpt-oss, Mistral Devstral, bereitgestellt über vLLM oder Ollama; Agentenschleife über OpenHands oder einen eigenen Runner.
• Hardware: HW3 für Coding-Modelle mit 30-120 Mrd. Parametern, die brauchbare Patch-Qualität liefern; HW2 genügt für Triage und Erklärung mit kleineren quantisierten Modellen.
• C wählen, wenn: Quellcode das Haus nicht verlassen darf (Rüstungszulieferer, kritische Infrastruktur).

Weg D — Eigenes Training

Lohnt sich selten. Feintuning auf der eigenen Historie abgeschlossener Korrekturen kann den Patch-Stil für ein bestimmtes Framework oder eine Sprache verbessern, und ein Klassifikator zur Unterdrückung von Fehlalarmen braucht einige Tausend gelabelte Befunde. Beginnen Sie mit Prompting und Retrieval über frühere Korrekturen.

Stand der Technik (2026)

• Agentisches Patchen: Systeme wie Copilot Autofix, Google CodeMender und die Finalisten-Systeme der DARPA AI Cyber Challenge (nach dem Finale 2025 als Open Source veröffentlicht) zeigen, dass LLM-Agenten echte Schwachstellen finden und beheben können, validiert durch Tests und erneutes Scannen [2][6].
• Erreichbarkeitsanalyse in Kombination mit LLM-Triage verringert das Rauschen erheblich, doch die Zahlen sind von Anbietern berichtet und hängen von der Codebasis ab.
• Priorisierung jenseits von CVSS: EPSS und CISA KEV sind Standardeingaben; Exposure-Management (Kontext von Angriffspfaden) ist die Produktrichtung 2026.
• Grenzen und Fehlerbilder: Patches beseitigen womöglich das Symptom, verändern aber das Verhalten; Modelle halluzinieren APIs oder nicht existierende Paketversionen (Risiko des Slopsquatting, siehe SEC-016); die Korrekturqualität ist bei Logikfehlern, Autorisierungsfehlern und dienstübergreifenden Problemen schwächer als bei Injection- oder Speichersicherheitsmustern; KI-generierter Code führt selbst Schwachstellen ein; Prompt Injection über Code-Kommentare oder Issue- Texte kann einen Agenten mit Schreibzugriff auf das Repository lenken.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (llm-code + agent-framework): CODE-003 KI-Code-Review, CODE-005 Modernisierung von Altsystemen - ein selbst betriebener Server für Coding-Modelle (HW3) kann alle drei bedienen.
• Vor- und nachgelagert: SEC-016 Lieferkette und Erkennung schädlicher Pakete, SEC-012 Bedrohungsmodellierung und Design-Review (findet Designfehler, die Scanner nicht finden), SEC-007 autorisierte Penetrationstests (validieren die Ausnutzbarkeit), SEC-001 SOC-Triage (Laufzeitsignal für die Priorisierung), SEC-009 Compliance- Automatisierung (Nachweise für NIS2/DORA/ISO 27001), SEC-017 Erkennung von Secrets und sensiblen Daten.
• Gemeinsame Daten: Asset-Inventar/CMDB, SBOM-Speicher, Ticketsystem.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; Lizenzen pro Entwickler oder pro Repository. Die in GitHub/GitLab eingebauten Funktionen sind oft der günstigste Einstieg.
• Weg B: 1-3 Monate für eine CI-integrierte Triage- und Korrektur-Pipeline; die Token-Kosten des Modells sind klein im Vergleich zur Entwicklerzeit, aber abgeschottete Testinfrastruktur ist ein Kostentreiber.
• Weg C: 2-4 Monate; GPU-Server plus Pflege von Scannern und Regelsätzen.
• Kennzahlen: mittlere Zeit bis zur Behebung nach Schweregrad, Anteil kritischer/KEV-Befunde, die innerhalb der SLA behoben werden, Fehl- alarmrate, Anteil der KI-Patches, die unverändert übernommen, bearbeitet oder abgelehnt werden, Regressionsrate gemergter KI-Korrekturen, Alter des Rückstaus, Scanner-Abdeckung (% Repositorien und Assets).

Menschen & Veränderung

Beziehen Sie zuerst IT-Sicherheit und IT-Betrieb ein, da sie Befunde und Patch-Fenster verantworten. Fachbereichsleitungen und Systemverantwortliche entscheiden über Risikoakzeptanz und Ausfallzeiten. Entwickler sind die täglichen Nutzer der Auto-Fix-Vorschläge und müssen an der Werkzeugauswahl beteiligt sein; das Management legt die Richtlinie fest, welche Korrekturen automatisch gemergt werden dürfen (empfohlen: keine ohne Prüfung).

Betriebsrat: in der Regel nein, da die Werkzeuge Code und Systeme analysieren, nicht Personen. Prüfen Sie es dennoch, wenn Kennzahlen zur Entwickleraktivität (Commits, Korrekturquoten je Person) erzeugt werden - dann gilt § 87 Abs. 1 Nr. 6 BetrVG. Informieren Sie den Betriebsrat, wo vorhanden, frühzeitig nach § 90 Abs. 1 Nr. 3. Datenschutz: in der Regel wenige personenbezogene Daten; die oder der Datenschutzbeauftragte sollte dennoch Commit-Metadaten und den AVV mit dem Anbieter prüfen (siehe GUIDE-005).

KI-Kompetenz: Schulen Sie Entwickler darin, KI-Patches kritisch zu prüfen, halluzinierte Abhängigkeiten zu erkennen und sicher zu prompten; die KI-Verordnung (AI Act) verlangt von Arbeitgebern, die KI-Kompetenz der Beschäftigten zu fördern (siehe GUIDE-006). Pilotieren Sie an einem unkritischen Repository, messen Sie Annahmequote und Regressionen und weiten Sie dann aus. Typische Sorge: Rauschen und Kompetenzverlust - begegnen Sie ihr mit Schweregrad-Filtern, verpflichtender menschlicher Prüfung und CI-Tests als Hürde. Menschen genehmigen jeden Merge und jede Änderung in der Produktion (siehe GUIDE-009, GUIDE-013).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko - ein defensives Entwicklerwerkzeug außerhalb von Anhang III; die KI-Kompetenz (Art. 4) gilt. Das Werkzeug ist keine Sicherheitskomponente. Der Einsatz in einem Produkt, das selbst Hochrisiko ist, ändert die Einstufung des Werkzeugs nicht.
• DSGVO: Quellcode kann personenbezogene Daten enthalten (Testdaten, Logs, Secrets); AVV des Anbieters, EU-Region und kein Training mit Kundencode. Kennzahlen zur Entwickleraktivität sind Beschäftigtendaten - stimmen Sie sich mit dem Betriebsrat ab, bevor es Dashboards je Entwickler gibt.
• CRA / NIS2 / DORA: Der CRA verlangt Schwachstellenbehandlung, SBOM und Meldung ausgenutzter Schwachstellen für Produkte mit digitalen Elementen; NIS2 Art. 21 nennt Schwachstellenbehandlung und -offenlegung als Risikomanagementmaßnahme; DORA regelt das IKT-Risiko für Finanzunternehmen [3][4].
• Sicherheitsrisiken des Werkzeugs selbst: Agenten mit Schreibzugriff sind ein Ziel für Lieferkettenangriffe; Tokens mit minimalen Rechten, abgeschottete Ausführung, kein Auto-Merge nicht trivialer Änderungen, protokollierte Diffs.
• Gegenmaßnahmen: verpflichtende menschliche Prüfung, CI-Hürden, erneuter Scan nach der Korrektur, Herkunftsangabe von KI-Patches in der Commit-Nachricht, regelmäßige Stichproben angenommener Patches.

Erste Schritte

1. Repositorien, Container-Images und aus dem Internet erreichbare Assets inventarisieren; kostenloses natives Scannen (Abhängigkeiten, Secrets, SAST) auf der Git-Plattform aktivieren.
2. EPSS und CISA KEV in die Priorisierung aufnehmen und SLAs je Prioritätsklasse festlegen.
3. KI-Autofix an 3-5 Repositorien pilotieren; Annahme- und Regressionsraten einen Monat lang verfolgen.
4. SBOMs (CycloneDX) in der CI erzeugen und für schnelle CVE-Abfragen in Dependency-Track ablegen.
5. Agenten-Tokens einschränken, bei jedem KI-PR eine Prüfung verlangen und den Prozess für NIS2-/CRA-Audits dokumentieren.

Quellen

1. GitHub Docs - Responsible use of Copilot Autofix for code scanning - https://docs.github.com/en/code-security/code-scanning/managing-code-scanning-alerts/responsible-use-autofix-code-scanning
2. Google DeepMind - Introducing CodeMender, an AI agent for code security - https://deepmind.google/discover/blog/introducing-codemender-an-ai-agent-for-code-security/
3. Regulation (EU) 2024/2847 (Cyber Resilience Act) - https://eur-lex.europa.eu/eli/reg/2024/2847/oj
4. Directive (EU) 2022/2555 (NIS2) - https://eur-lex.europa.eu/eli/dir/2022/2555/oj
5. CISA Known Exploited Vulnerabilities Catalog - https://www.cisa.gov/known-exploited-vulnerabilities-catalog ; FIRST EPSS - https://www.first.org/epss/
6. DARPA AI Cyber Challenge - https://aicyberchallenge.com/
7. OSV.dev open-source vulnerability database - https://osv.dev/
8. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj