14. Juni 2026
Das britische Government Cyber Coordination Centre hat mehrere Wochen lang KI-Modelle auf öffentliche Quellcode-Repositorys von Behörden angesetzt – mit konkreten Ergebnissen: Hunderte Schwachstellen, ein einstelliger Betrag im Vergleich zu herkömmlichen Audits und klare Lehren für den Einsatz von KI in der staatlichen IT-Sicherheit.
Wenn Regierungen über den Einsatz von KI in der Cybersicherheit sprechen, bleibt es häufig bei Absichtserklärungen. Das britische Government Cyber Coordination Centre (GC3) – eine gemeinsame Einrichtung des National Cyber Security Centre (NCSC) und des Ministeriums für Wissenschaft, Innovation und Technologie – hat hingegen einen anderen Weg gewählt: ausprobieren, messen, auswerten.
Im Rahmen des Government Cyber Action Plan führte das GC3 über mehrere Wochen wöchentliche Hackathons durch. Teams aus Spezialisten des AISI und des NCSC scannten öffentlich zugängliche Code-Repositorys britischer Behörden mithilfe aktueller KI-Modelle – mit dem Ziel, Schwachstellen zu finden, bevor Angreifer es tun.
Warum öffentlicher Code ein geeignetes Testfeld ist
Die britische Regierung verfolgt die Leitlinie, neuen Quellcode standardmäßig offen zu veröffentlichen. Das schafft Transparenz, ermöglicht externe Prüfung und reduziert Doppelarbeit. Es bedeutet aber auch, dass potenziell Angreifer denselben Code einsehen können. Gleichzeitig eignet sich öffentlich geprüfter Code besonders gut für Pilotprojekte dieser Art: Er kann ohne zusätzlichen Datenschutzaufwand an externe Modell-Anbieter weitergegeben werden.
„Die Architektur ist entscheidend – nicht das Modell.“ Kernaussage des GC3-Berichts
Drei unterschiedliche Ansätze, ein gemeinsames Prinzip
Die teilnehmenden Teams entwickelten eigene Pipelines. Drei Ansätze stachen hervor:
Adversarielle Agenten-Pipeline
Jedes Repository durchlief sechs KI-Stufen: Triage, Validierung, Prüfung, Rückverfolgung, Bewertung und Zusammenfassung. Jede Stufe hinterfragte die Ergebnisse der vorherigen. Die Eskalation blieb manuell – ein Mensch prüfte jeden Befund.
Scanner als Grundlage, Modell als Analyse
Traditionelle Tools (Gitleaks, Trivy, Semgrep, Hadolint) lieferten priorisierte Rohdaten. Darauf setzten drei Modellstufen auf: Erkennung anhand von OWASP- und CWE-Frameworks, Verknüpfung von Einzelbefunden zu Angriffspfaden und abschließende Triage.
Wiederverwendbare Skills für ganze Organisationen
Eine Abteilung kodifizierte fünf domänenspezifische Prüf-Skills, die konsistent über Hunderte von Diensten und verschiedene Betreiber hinweg eingesetzt werden konnten.
Was die Teams tatsächlich fanden
Insgesamt identifizierten die Teams 407 Befunde. Darunter waren Schwachstellen, die Dienste für unbefugten Zugriff auf Authentifizierungssysteme, die Offenlegung von Daten und die Ausführung von Fremdcode verwundbar machten. Einige waren den Behörden bereits bekannt und durch Gegenmaßnahmen abgemildert. Andere waren zuvor nicht dokumentiert. Alle als ausnutzbar eingestuften Probleme wurden behoben. Für keinen Befund gab es Hinweise auf eine aktive Ausnutzung.
Besonders deutlich wurde der Mehrwert gegenüber herkömmlichen Scannern bei der Verfolgung von Schwachstellen über Servicegrenzen hinweg. Klassische Tools prüfen in der Regel isoliert – KI-Modelle konnten Zusammenhänge zwischen Geschäftslogik und technischen Details herstellen.
Ein konkretes Beispiel: In einem Repository, das einen öffentlich zugänglichen digitalen Dienst unterstützt, fanden die Teams veraltete GitHub Actions. Die Konfiguration erlaubte es einem externen Nutzer, durch einen speziell formulierten Kommentar in einem offenen Pull-Request eine Workflow-Kette auszulösen. Da der Auslöser ein Kommentar war – nicht die Pull-Request selbst –, griffen die üblichen Schutzmaßnahmen nicht. Das Ergebnis: beliebige Code-Ausführung auf dem GitHub-Actions-Runner, potenzieller Zugriff auf gespeicherte Zugangsdaten und die Möglichkeit, weitere Aktionen im Repository auszulösen.
Was das Projekt gelehrt hat
Architektur schlägt Modellwahl
Die stärksten Ergebnisse entstanden nicht durch den Einsatz des leistungsfähigsten Modells, sondern durch klar definierte Aufgabenverteilung innerhalb einer strukturierten Pipeline. Viele aktuelle Frontier-Modelle liefern bei Code-Audits mit der richtigen Struktur vergleichbare Resultate.
Triage bleibt Engpass
KI-Agenten erzeugen potenzielle Befunde weit schneller, als menschliche Teams sie prüfen können. Ohne klare Vorab-Eingrenzung und interne Filterung mit geringer Konfidenz werden Sicherheitsteams überlastet. Entscheidend ist nicht die Menge der gefundenen Probleme, sondern ob die begrenzte menschliche Kapazität dort eingesetzt wird, wo der größte Handlungsbedarf besteht.
Finden und Beheben sind zwei Schritte
Auch nach der Identifikation einer Schwachstelle muss der Befund in die bestehende Patch-Pipeline integriert werden. KI kann bei der Priorisierung und Patch-Generierung unterstützen – die eigentliche Korrektur erfordert jedoch weiterhin abgestimmte, menschengeführte Prozesse.
Wie es weitergeht
Das GC3 plant eine zweite Phase des Pilotprojekts. Mehr Behörden, weitere Modelle und eine Ausweitung auf nicht-öffentliche Codebases sollen den Rahmen vergrößern. AISI und NCSC werden dabei tiefer eingebunden. Ziel ist es, die Lücke zwischen Labor-Benchmarks und tatsächlicher Risikominderung weiter zu schließen – und Erkenntnisse über Abteilungsgrenzen hinweg zugänglich zu machen.
Das Pilotprojekt zeigt, dass der Wert von KI in der Cyberabwehr weniger von der Modellleistung abhängt als von der Frage, wie der Einsatz gestaltet wird: klare Abgrenzung, strukturierte Pipelines, menschliche Prüfung an den richtigen Stellen.
Redaktion AllAboutSecurity
Bild/Quelle: https://depositphotos.com/de/home.html