GitHubs KI-Sicherheitsagent findet Schwachstellen jetzt im großen Stil. Am 28. September gab das GitHub Security Lab in seinem offiziellen Blog bekannt: Forscher, die Android-Apps mit seinem Open-Source-KI-Sicherheitsagenten auditieren, haben 24 Schwachstellen gefunden und gemeldet – darunter zwei bereits öffentlich offengelegte Fälle mit hohem Schweregrad: einer erlaubt es einer beliebigen App, den genauen Standort eines Nutzers zu verfolgen, der andere ermöglicht die komplette Übernahme eines Wikipedia-Kontos.
Das Tool heißt seclab-taskflow-agent, die zugehörigen Audit-Taskflows seclab-taskflows sind vollständig Open Source. Die Idee: nicht die gesamte Codebasis einem großen Modell hinzuwerfen und auf Glück zu hoffen, sondern mit YAML-Prompts das Audit in inkrementelle Schritte zu zerlegen und das „Wie" des Auditierens in wiederverwendbare Taskflows zu verpacken. Für Android kamen zwei eigene Taskflows hinzu: gather_mobile_entry_point_info findet die Code-Einstiegspunkte, durch die angreifergesteuerte Daten fließen können, und trennt mobile von nicht-mobilen Angriffsflächen; classify_application_local listet dann pro Einstiegspunkttyp die gängigen Schwachstellenklassen auf, die zu prüfen sind – sieht es etwa einen Intent-basierten Einstiegspunkt, erinnert es das Modell an mobile Spezialitäten wie Confused Deputy oder unsichere Broadcasts.
Der Start ist unkompliziert: Codespace im seclab-taskflows-Repository öffnen und ./scripts/audit/run_mobile.sh gegen das Ziel-Repository laufen lassen; ein mittelgroßes Repository ist in ein bis zwei Stunden durch, die Ergebnisse landen in einer SQLite-Datenbank – einfach nach Zeilen mit Häkchen in der Spalte has_vulnerability schauen. Zwei Hürden gibt es: Eine GitHub-Copilot-Lizenz ist Pflicht, und das Audit verbraucht eine große Zahl an Premium-Modellrequests – die Token-Rechnung fällt nicht gerade klein aus.
Zwei bereits offengelegte Fälle mit hohem Schweregrad
Der erste ist OsmAnd, eine Open-Source-Navigations-App mit über 10 Millionen Downloads. Seine MapActivity ist exportiert, sodass jede App ihr Intents schicken kann; und der Settings-Import-Handler vertraut Intent-Extras wie silent_import und replace blind. Eine bösartige App ganz ohne Berechtigungen kann also unbemerkt OsmAnds Einstellungen umschreiben und die Kartenkachel-URLs gegen eine Angreifer-Domain tauschen: Jede geladene Kartenkachel sendet ihre exakten Koordinaten an den Angreifer-Server – faktisch ein Echtzeit-Standortleck – und dieselbe Lücke verrät Start und Ziel jeder gefahrenen Route, ohne dass der Nutzer etwas bemerkt.
Der zweite Fall ist die Wikipedia-Android-App, in der sich zwei Logikfehler zur Kontoübernahme verketten. Die App registriert einen wikipedia://-Deeplink, doch der Hostname-Parser prüft nur das Domain-Suffix – Domains wie evil-wikipedia.org bestehen die Validierung und locken Nutzer auf eine Angreiferseite; gleichzeitig vergleicht auch der Domain-Check des Cookie-Managers nur Suffixe, sodass die Angreiferseite Wikipedias langlebige Session-Cookies abgreifen kann – ein Cookie gilt für sämtliche Wikimedia-Projekte, Nutzername und Langzeit-Tokens inklusive.
LLMs finden Schwachstellen, können ihre Schwere aber nicht einschätzen
Der Blog nennt die Schwächen der Methode offen beim Namen: LLMs finden Schwachstellen gut – sogar Logikfehler, die Menschen leicht übersehen – aber sie schätzen die Schwere schlecht ein. Sie melden routinemäßig folgenlose Low-Risk-Funde und verkennen Fälle mit mildernden Faktoren, etwa Path Traversals, die auf externen Speicher beschränkt sind. Jeder Fund braucht weiterhin die Prüfung eines Forschers mit Mobile-Security-Verständnis, und ernste Fälle erfordern, dass das Modell tatsächlich einen Proof of Concept baut, um die Ausnutzbarkeit zu belegen.
Die Bedeutung liegt nicht in der Zahl 24, sondern darin, dass eine Audit-Methodik erstmals als Open-Source-Pipeline reproduzierbar gemacht wurde. Das Security Lab hatte zuvor bereits einen KI-Fuzzing-Taskflow für C/C++ quelloffen gelegt (Repository-Adresse angeben, Schwachstellen werden automatisch gefunden); jetzt ist die mobile Lücke geschlossen. Für normale Entwickler ist der praktische Nutzen direkt: kein Warten auf das Security-Team – einfach gegen das eigene Repository laufen lassen und zuerst eine Reihe echter Probleme einsammeln.
