Ein KI-Agent meldet: Sicherheitslücke behoben, Tests bestanden. Bevor die Änderung in den gemeinsamen Code übernommen wird, braucht es dennoch eine eigene Prüfung. Zeigt der Test tatsächlich den ursprünglichen Fehler? Schließt die Änderung alle relevanten Wege zur Schwachstelle? Und funktioniert die Software für erlaubte Eingaben noch?
Ein guter Prüfweg beginnt mit der konkreten Schwachstelle, vergleicht das Verhalten vor und nach der Änderung und verfolgt anschließend den Code über die geänderten Zeilen hinaus. Erst wenn die Ergebnisse nachvollziehbar sind, lässt sich über den Merge entscheiden: das Zusammenführen der Änderung mit dem gemeinsamen Entwicklungsstand.
Erst verstehen, was geschützt werden soll
Lesen Sie zunächst die Fehlermeldung und beschreiben Sie in einem Satz, was ein Angreifer erreichen kann und unter welchen Bedingungen. Geht es etwa darum, dass jemand ein fremdes Dokument öffnen kann? Dann reicht die Aussage „Zugriff geprüft“ nicht. Entscheidend ist, welches Konto auf welches Dokument zugreifen darf und an welcher Stelle die Anwendung diese Berechtigung kontrolliert.
Ein Patch ist der Änderungsvorschlag im Quellcode. Die Änderungsansicht, oft Diff genannt, zeigt hinzugefügte und entfernte Zeilen. Prüfen Sie nicht nur, ob die neuen Zeilen plausibel aussehen: Verfolgen Sie auch, woher Daten kommen, welche Funktion sie verarbeitet und welche anderen Wege dorthin führen. Die OWASP-Anleitung zur Codeprüfung empfiehlt, automatisierte Werkzeuge durch menschliche Analyse zu ergänzen. Gerade Berechtigungen und Geschäftslogik hängen vom Zusammenhang der Anwendung ab.
Bei unserem gedachten Dokumentenbeispiel könnte eine neue Prüfung im Webformular sitzen, während eine andere Schnittstelle dieselbe Datei ohne diese Prüfung ausliefert. Der sichtbare Fehler wäre an einer Stelle behoben, der unerlaubte Zugriff über den zweiten Weg aber weiter möglich.
Den Fehler vor und nach der Änderung nachstellen
Nutzen Sie eine geeignete Testumgebung und möglichst einen vorhandenen reproduzierbaren Fall. Ein aussagekräftiger Sicherheitstest zeigt zunächst am ungeänderten Stand das fehlerhafte Verhalten und nach der Korrektur das erwartete sichere Ergebnis. So lässt sich erkennen, ob der Test die Schwachstelle überhaupt erreicht und ob die Änderung für das unterschiedliche Ergebnis verantwortlich ist.
Ein einzelner Testfall ist ein Anfang. Variieren Sie relevante Eingaben und prüfen Sie weitere erreichbare Pfade. Beim Dokumentenbeispiel wären das etwa verschiedene Benutzerrollen, fremde und eigene Dokumente sowie alternative Schnittstellen. Welche Varianten sinnvoll sind, ergibt sich aus der konkreten Ursache; eine universelle Liste kann sie nicht ersetzen.
Für Sicherheitslücken in Abhängigkeiten empfiehlt OWASP, einen verfügbaren Reproduktionsfall als Regressionstest zu nutzen und auch alternative Eingaben und erreichbare Pfade zu prüfen. Ein Regressionstest soll verhindern, dass ein bereits behobener Fehler bei einer späteren Änderung zurückkehrt. Die Empfehlung lässt sich als Denkweise auch auf eigenen Anwendungscode übertragen.
Erlaubte Nutzung muss erhalten bleiben
Eine Korrektur kann einen Angriff verhindern, indem sie gleich jede Anfrage zurückweist. Sicher nutzbar ist die Funktion dann trotzdem nicht. Prüfen Sie deshalb neben unerlaubten Eingaben auch die erlaubten: Im Beispiel muss der Eigentümer sein Dokument weiterhin öffnen können, während fremde Konten abgewiesen werden.
Führen Sie vorhandene passende Modul-, Integrations- und Funktionstests aus. Modultests betrachten kleine Teile, Integrationstests deren Zusammenspiel. Achten Sie auf fehlgeschlagene Tests und darauf, ob die KI einen Test gelöscht, abgeschwächt oder nur an das neue Verhalten angepasst hat. Ein grünes Ergebnis ist nur so aussagekräftig wie die geprüften Fälle.
Dass beide Seiten wichtig sind, zeigt auch der Prüfstand CWE-bench: Dort werden Sicherheitskorrekturen anhand von Angriffstests und regulärem Verhalten bewertet. Der Prüfstand ist ein Beispiel für diesen Gedanken, keine Freigabe für eine konkrete Änderung im eigenen Projekt. Unser Artikel über CWE-bench erklärt, wie die Aufgaben aufgebaut sind.
Was hat die KI außerdem verändert?
Gehen Sie den gesamten Diff durch. Hat der Agent nur die betreffende Prüfung ergänzt oder zugleich Berechtigungen gelockert, Abhängigkeiten geändert und Fehlerbehandlung entfernt? Prüfen Sie solche Änderungen gesondert. Ein kleiner Patch ist leichter zu verstehen, aber auch wenige Zeilen können große Folgen haben.
Kontrollieren Sie auch neue Paketversionen und Konfigurationsänderungen. Eine aktualisierte Bibliothek kann die Schwachstelle schließen, zugleich aber andere Schnittstellen verändern. Im Zweifel helfen die Hinweise des jeweiligen Projekts und Tests der tatsächlich genutzten Funktionen. Geheimnisse wie Zugangsschlüssel gehören nicht in den Änderungsvorschlag oder in öffentlich geteilte Testausgaben.
Die OWASP-Hinweise zu KI beim Programmieren raten davon ab, generierten Code oder generierte Tests allein aufgrund ihrer Herkunft als sicher zu behandeln. Lassen Sie eine sachkundige Person die Änderung unabhängig prüfen, besonders wenn sie Zugriffsrechte, vertrauliche Daten oder andere kritische Bereiche betrifft.
Wann ist der Patch bereit?
Halten Sie vor dem Merge fest, welche Ursache behoben werden sollte, welche Wege Sie untersucht haben und welche Tests vor und nach der Änderung ergeben haben. Dokumentieren Sie ebenso offene Fragen. Ein Prüfprotokoll muss nicht lang sein; es muss einem anderen Menschen erlauben, die Entscheidung nachzuvollziehen.
Wenn sich der Fehler nicht reproduzieren lässt, ein relevanter Pfad ungeprüft bleibt oder die Änderung nicht verstanden wird, ist Zurückstellen eine begründete Entscheidung. Ein erfahrener Reviewer kann helfen, den fehlenden Kontext zu klären. Bestehende Tests und Werkzeuge reduzieren Aufwand, ersetzen aber nicht die Frage, ob sie genau die behauptete Korrektur und das gewünschte Verhalten abdecken.
Quellen
- OWASP: Secure Coding with AI
- OWASP: Secure Code Review
- OWASP: Vulnerable Dependency Management
- Collinear AI: CWE-bench v2
Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde redaktionell geprüft.
