KI-Sicherheitsscanner wecken unsere technischen Schulden

Im Jahr 2024 landete ein Bug-Report im Tracker des PHP-Projekts. Er beschrieb eine Out-of-Memory-Situation, also die Sorte Problem, die einen Prozess zum Absturz bringt. Das ist nervig, in der informellen Hierarchie der Bugs aber praktisch ein Achselzucken. Er lag einfach herum. Dann, während eines unabhängigen, von OpenAI gesponserten Audits von PHP, verwandelte ein Forscher der Sicherheitsfirma Calif, der mit KI-Sicherheitsscannern und seiner eigenen tiefen Expertise arbeitete, diesen lästigen Absturz innerhalb von etwa zwei Wochen in Remote Code Execution. Jeder Server mit einem verwundbaren PHP-Build konnte dazu gebracht werden, fremden Code auszuführen oder sensible Daten herauszugeben. Zum Wirkungsbereich gehörten NASA, Wikipedia und das Weiße Haus, denn WordPress und Drupal laufen auf PHP, und PHP läuft auf einem erstaunlich großen Teil des Webs.

Der Patch wurde ausgeliefert, bevor jemand mit böser Absicht zugreifen konnte, die Geschichte endete also gut. Aber die beteiligten Forscher sagen immer wieder dasselbe: Das ist der Anfang, nicht das Ende. Vier Jahrzehnte von Menschen geschriebenem Code enthalten einen Ozean an Bugs, die wir gemeinsam unter „Absturz, wird nicht behoben“ abgelegt haben, und KI-Werkzeuge haben die Kosten gesenkt, herauszufinden, welche dieser Abstürze in Wahrheit geladene Waffen sind. Ich habe in den letzten Wochen mit Leuten gesprochen, die die Sicherheit echter Systeme verantworten, darüber, was sich dadurch in der Praxis ändert. Was folgt, ist keine Umfrage, sondern eine Sammlung von Fehlern, die ich Teams bereits habe machen sehen, und davon, was die Leute, die es richtig gemacht haben, stattdessen getan haben.

Fehler eins: Absturz-Bugs als „lästig, aber harmlos“ abtun

Der PHP-Bug im Zentrum dieser Geschichte war nicht versteckt. Er wurde gemeldet, bestätigt und herabpriorisiert, weil er „nur“ einen Out-of-Memory-Fehler verursachte. Das ist der häufigste Triage-Fehler in ausgereiften Softwareorganisationen, und KI-gestützte Exploit-Entwicklung hat ihn gerade teuer gemacht. Die Columbia-Professorin Suman Jana, die genau in dieser Forschungsklasse arbeitet, hat die Dynamik in Interviews rund um die Veröffentlichung treffend beschrieben: Zu jedem Zeitpunkt hat jedes große Projekt einen Stapel Absturzberichte, die niemand ernst nimmt, weil die Umwandlung eines Absturzes in einen Exploit lange Ketten zähen, hochspezifischen Denkens erfordert. Menschen scheuen diese Arbeit. Modelle langweilen sich nicht.

Hier die mechanische Version, warum die Unterscheidung wichtig ist. Ein Speicherfehler, der den Heap mit unkontrollierten Daten beschädigt, bringt meist nur den Prozess zum Absturz: Der Allokator bemerkt etwas Inkonsistentes und bricht ab, oder der Prozess dereferenziert Müll und löst einen Segmentation Fault aus. Derselbe Bug wird aber, mit sorgfältig dimensionierter und geformter Eingabe gefüttert, zu einem Schreib-Primitiv:

void handle_request(const char *input, size_t len) {
char *buf = malloc(64);
memcpy(buf, input, len);   /* len never validated */
/* len = 65:            heap metadata trashed -> likely abort, filed as 'crash' */
/* len = attacker-tuned: adjacent object's function pointer overwritten */
process(buf);             /* calls through the corrupted pointer -> their code runs */
free(buf);
}

Die Grenze zwischen diesen beiden Ergebnissen ist nicht der Bug, sondern die Eingabe. Herauszufinden, welche Bits in welcher Reihenfolge überschrieben werden müssen, damit die Ausführung an einer gewählten Adresse landet, ist mühsam, aber mechanisch. Und „mühsam, aber mechanisch“ ist genau der Kern dessen, wobei Sprachmodelle gut helfen können. Die Abhilfe für diesen Fehler ist zuerst konzeptionell, dann technisch: Hör auf, „es stürzt nur ab“ als Schweregrad-Signal für speichersicheren Code zu verwenden. Ein Absturz in C oder C++ (oder im C-Kern eines Interpreters wie PHP) ist ein Exploit, der noch nicht entwickelt wurde. Die neue Triage-Frage lautet nicht „stürzt es ab?“, sondern „wird die Korruption von einem Angreifer beeinflusst?“ Wenn nicht vertrauenswürdige Eingaben Größe, Offset oder Inhalt eines fehlerhaften Schreibzugriffs steuern, geh von Ausnutzbarkeit aus und priorisiere entsprechend, auch dann, wenn noch niemand einen funktionierenden Exploit demonstriert hat. Gerade dann, denn demonstrierte Exploits brauchen heute Wochen, nicht Jahre.

Fehler zwei: Scanner-Ergebnisse wie ein Backlog behandeln

Der zweite Fehlermodus tritt genau dann auf, wenn ein Team moderne KI-gestützte Scanner über einen Bestand laufen lässt, der Code mit zwanzig Jahren Alter enthält. Das Tool liefert hunderte Befunde, das Dashboard wird rot, und das Team tut, was Backlogs einem antrainieren: nach Schweregrad sortieren und oben anfangen. Sechs Monate später haben sie vierzig Dinge behoben, die Zahl ist gestiegen, und die Stimmung ist ruiniert. Die Ingenieure, mit denen ich gesprochen habe und die damit gut umgehen, sagten alle sinngemäß dasselbe: Die Ausgabe eines KI-Scanners ist kein Backlog, sondern Rohinformation. Sie braucht einen Triage-Durchgang durch einen Analysten, bevor auch nur ein einziges Ticket angelegt wird.

Effektive Triage fragt in diesem Regime nach Exploit-Pfaden, nicht nach Schweregrad-Werten:

• Ist der verwundbare Code von nicht vertrauenswürdigen Eingaben erreichbar? Ein Heap-Overflow in einer Funktion, die nur eine lokale Konfigurationsdatei verarbeitet, ist ein völlig anderes Tier als derselbe Overflow in der Request-Verarbeitung.
• Ist er heute aus dem Internet erreichbar? Nicht „sollte er sein“, sondern ist er es. Prüfe Load-Balancer-Konfigurationen und DNS, nicht das Architekturdiagramm.
• Kontrolliert die Eingabe die Korruption? Größe, Offset oder Inhalt des fehlerhaften Zugriffs. Das ist die Grenze zwischen Absturz und Exploit aus dem vorherigen Abschnitt.
• Was bringt ein Exploit dem Angreifer? Ein Absturz in einem gesandboxten Worker, der sich neu startet, ist etwas anderes als einer in dem Prozess, der die Datenbank-Zugangsdaten hält.
• Gibt es einen Exploit in freier Wildbahn oder eine öffentliche Beschreibung? Das bringt alles unabhängig vom Score an die Spitze der Warteschlange.

Dieser letzte Punkt verdient Betonung. Scores wie CVSS wurden für eine Welt entworfen, in der Menschen Bugs in menschlicher Geschwindigkeit fanden, und sie gewichten theoretischen Schweregrad systematisch höher als Erreichbarkeit. Wenn ein Scanner theoretischen Schweregrad in industriellem Maßstab erzeugen kann, ertrinkst du. Die Teams, die damit am besten zurechtkommen, haben die Pipeline umgedreht: erst Erreichbarkeit und Exposition, dann Schweregrad. Alles, was per Konstruktion unerreichbar ist, wird dokumentiert und geschlossen statt behoben, denn ein ausgelieferter Fix trägt sein eigenes Regressionsrisiko, und dieses Risikobudget brauchst du für die Befunde, die wirklich zählen. Hier zeigen sich auch KI-gestützte Code-Verständnisprüfungen auf der defensiven Seite: Dieselben Werkzeuge, die den Bug finden, können oft in Minuten beantworten, „zeig mir jeden Aufrufpfad von der Netzwerkgrenze zu dieser Funktion“. Eine Frage, die früher einen Senior-Ingenieur einen Tag pro Befund kostete.

Fehler drei: Annehmen, dass Patches mit der Geschwindigkeit der Funde mithalten können

Hier ist eine Asymmetrie, die auf einem Poster in jedem Sicherheitsteam-Raum hängen sollte. Den Exploit-Pfad des PHP-Bugs zu finden, dauerte einen fähigen Forscher mit KI-Unterstützung etwa zwei Wochen. Den Patch zu entwickeln, brauchte vier Ingenieure zwei Monate. Finden ist ein Suchproblem: Du brauchst genau einen Weg hindurch. Beheben ist ein beweisartiges Problem: Du musst jeden Pfad schließen und dafür sorgen, dass die Milliarden Installationen, die nicht angegriffen werden, genau so weiterlaufen wie zuvor. Die Aufgabe der Verteidiger ist strikt schwerer als die der Angreifer, und KI verkürzt die Angreiferseite dieser Lücke weit schneller als die Verteidigerseite.

Teams, die diese Asymmetrie ignorieren, gehen eine von zwei schlechten Wetten ein. Entweder hetzen sie Patches heraus, um dem Veröffentlichungsdruck gerecht zu werden, und liefern Regressionen aus. Der PHP-Patch fasste Interna des Interpreters an, die auf rund drei Vierteln der Websites laufen, die ihren Stack offenlegen, der Wirkungsradius eines schlechten Fixes ist also gesamtgesellschaftlich. Oder sie verzweifeln und tun nichts, während sie auf einen perfekten Fix warten. Die Praktiker, die dieses Fenster gut gemeistert haben, taten etwas weniger Heroisches und Wirksameres: Sie haben „jetzt abmildern“ von „richtig beheben“ getrennt. Abmilderungen sind günstig, schnell und umkehrbar. Dazu gehört, den betroffenen Endpunkt am Reverse Proxy einzuschränken, eine WAF-Regel auszurollen, die die Eingabeform des Exploits blockiert, den verwundbaren Codepfad hinter einem Feature-Flag abzuschalten oder den Kreis derer zu verkleinern, die den Dienst erreichen können, während der echte Patch reift. Ich habe schon früher geschrieben, dass die Entscheidung zwischen Patchen und Abmildern ein echter Zielkonflikt ist und kein moralisches Versagen. Dieser Vorfall ist genau diese Lektion im planetaren Maßstab.

Die Folgerung, die niemand hören will: Deine mittlere Zeit bis zur Abmilderung ist jetzt die Metrik, die zählt, denn das Zeitfenster zwischen „von White Hats gefunden“ und „von jemandem Schlimmeren gefunden“ schrumpft. Im PHP-Fall blieb das Fenster nur offen, weil die Forscher verantwortungsvoll handelten und die Stiftung schnell reagierte. Die Brotli-Kompressionsbibliothek erzählte im selben Zeitraum eine weniger schmeichelhafte Geschichte: Ein vergleichbarer Bug lag acht Jahre im Code, wurde in Git behoben, aber acht Monate lang nicht veröffentlicht, und wurde von mindestens vier Forschern unabhängig wiederentdeckt. Wenn Entdeckung günstig und parallel ist, wird „irgendwer findet es schon irgendwann“ nicht mehr zu einem beruhigenden Gedanken, sondern zu einer Terminplanungsgarantie.

Fehler vier: Dem Fix vertrauen, weil ein LLM ihn geschrieben hat

Das optimistische Gegenargument zu all dem lautet: Schön, KI findet Bugs heute schneller, als wir sie beheben können, aber KI wird sie auch beheben. Anthropic hat im Oktober Werkzeuge in genau diese Richtung veröffentlicht. Ein LLM erzeugt einen Patch, dann erzeugt ein zweites Modell einen maschinenprüfbaren Beweis, dass der Patch das beabsichtigte Verhalten erhält, und ein kleiner, schlichter, vertrauenswürdiger Beweisprüfer validiert den Beweis. Der Prüfer ist die einzige Komponente, die korrekt sein muss, und das kann sie sein, weil sie fast nichts tut. Jana ist von dieser Richtung wirklich begeistert, und ich verstehe warum: Es ist der erste glaubwürdige Weg, das Beheben beinahe so automatisierbar zu machen wie das Finden.

Aber ich habe inzwischen zwei Teams dabei beobachtet, wie sie Workflows für „KI-generierte Sicherheitspatches“ eingeführt haben, und beide haben denselben Fehler gemacht: Sie behandelten den Patch des Modells als Lösung statt als Kandidaten. Im einen Fall schloss der Patch den gemeldeten Heap-Overflow durch eine Längenprüfung, verschob den Overflow aber auf einen zweiten Allokationspfad sechs Zeilen weiter, den das Modell nicht berücksichtigt hatte. Der Fix bestand das Review, weil er offensichtlich korrekt aussah, und genau darin liegt der Fehlermodus: LLM-Patches sind auf eine Weise flüssig, wie menschliche Patches es nicht sind, und Flüssigkeit unterdrückt Skepsis. Die Teams, die aus generierten Patches Nutzen gezogen haben, haben drei Gates in dieser Reihenfolge eingebaut:

1. Eine Regressionssuite, die die Exploit-Eingabe enthält. Der Proof-of-Concept, der den Befund ausgelöst hat, wird zu einem dauerhaften Test. Wenn der Scanner dir eine abstürzende Eingabe geliefert hat, ist das dein erster neuer Testfall, kostenlos.
2. Eine Varianten-Suche. Bevor gemergt wird, beantwortet jemand (oder etwas): Wo kommt dasselbe Muster sonst noch vor? Eine einzelne Instanz eines systemischen Musters zu beheben, ist der Weg zu CVE-Fortsetzungen.
3. Unabhängige Prüfung der Invariante, nicht des Diffs. Formuliere, was jetzt gelten muss, etwa „kein Pfad aus der Request-Verarbeitung erreicht memcpy mit ungeprüfter Länge“, und prüfe das mit Tests, statischer Analyse oder formalen Werkzeugen. Das Diff allein zu reviewen heißt nur, die Hausaufgaben des Modells noch einmal zu lesen.

Formale Verifikation wird hier helfen, sobald sie reift. Beachte aber die Arbeitsteilung, die sie vertrauenswürdig macht: Die kreativen Teile dürfen halluzinieren, weil die letzte Instanz mechanisch und klein ist. Das ist das Designprinzip, das du unabhängig von deinen Werkzeugen übernehmen solltest. Alles, was ein LLM produziert, also Befund, Patch oder Beweis, sollte in etwas münden, das nicht dieselben Fehlermodi teilt. Wenn dein Verifikationsschritt ein weiterer Prompt ist, hast du nichts verifiziert.

Fehler fünf: Annehmen, dass jemand anderes den Code geprüft hat

Unter jeder technischen Lektion hier liegt eine wirtschaftliche. PHP ist Infrastruktur im Maßstab einer öffentlichen Versorgung: Es betreibt WordPress, Drupal und einen langen Schwanz des Webs, zu dem Raumfahrtagenturen und Regierungswebsites gehören. Seine Sicherheit ruht auf der PHP Foundation, einem kleinen, finanzierten Gremium, plus Freiwilligen. Der bequeme Mythos von Open Source lautete immer: „Mit genug Augenpaaren sind alle Bugs oberflächlich.“ Was in dreißig Jahren tatsächlich passierte, war, dass alle annahmen, die Augenpaare gehörten jemand anderem. KI liefert diese Augenpaare nun wahllos an Angreifer und Verteidiger gleichermaßen. Damit wird der Mythos endlich wahr, nur feindselig und unter Termindruck.

Die PHP2Shell-Veröffentlichung funktionierte wegen einer ungewöhnlichen Konstellation: OpenAI sponserte ein externes Audit, eine gut ausgestattete Firma erledigte die Arbeit, und Wiz half, die Befunde zu bestätigen und zu erweitern. Das ist Wohltätigkeit, kein System, und es skaliert nicht auf die Tausenden kritischen, aber unfinanzierten Projekte in deinem Abhängigkeitsbaum. Wenn die Produktion deiner Organisation von einem Open-Source-Interpreter, Framework oder einer Bibliothek abhängt, und das tut sie, sind die wichtigen Maßnahmen langweilig: die Stiftungen finanzieren, Audits sponsern, Ingenieursstunden beisteuern. Und wenn du eigene Scanner laufen lässt und etwas in einer Abhängigkeit findest, melde es upstream, statt deinen Fork zu patchen und weiterzuziehen. Die Alternative ist die Welt, die Matthew Green von der Johns Hopkins University vorhersagt: Strukturell ändert sich nichts, bis ein Vorfall groß genug ist, um normale Menschen aufzuschrecken. Sein Rat bis dahin ist unspektakulär und richtig: Wenn das Update-Fenster erscheint, installiere es jetzt, nicht nächste Woche. Dieselbe Lektion haben wir im letzten großen PHP-Veröffentlichungszyklus auf die harte Tour gelernt, als den Stecker zu ziehen den cleveren Fixes überlegen war für Teams, die nicht schnell genug patchen konnten.

Die Augenpaare sind gekommen. Sie sind nur nicht wählerisch, auf welcher Seite sie stehen.

Das Montagmorgen-Playbook für KI-aufgedeckte Schwachstellen

Alles oben Genannte lässt sich auf eine kurze Liste der Dinge verdichten, die ich dieses Quartal tatsächlich tun würde, wenn ich eine Engineering-Organisation mit Altcode in Produktion leiten würde. Und wenn du das liest, hast du Altcode in Produktion:

• Patche konsequent und miss, wie lange es dauert. Deine Update-Latenz ist jetzt eine Sicherheitskontrolle mit einer schrumpfenden sicheren Schwelle. Kenne deine Zahl, bevor du sie brauchst.
• Triagiere deinen bestehenden Absturz-Bug-Backlog neu, mit der Frage nach Ausnutzbarkeit statt dem Schweregrad-Score: Kontrolliert nicht vertrauenswürdige Eingabe die Korruption? Alles Speicherunsichere und Erreichbare wird hochgestuft.
• Betreibe KI-gestütztes Scannen selbst, zuerst auf deinem ältesten Code. Die Grenzkosten der Wiederentdeckung liegen jetzt nahe null, also solltest du annehmen, dass alles in deiner Angriffsfläche, was findbar ist, auch gefunden wird. Finde es zuerst.
• Trenne Abmilderung von Behebung in deinem Incident-Prozess. Bereite das Playbook im Voraus vor: Proxy-Regeln, Feature-Flags, Zugriffsbeschränkungen. Zeit zu kaufen ist eine legitime Strategie; so zu tun, als bräuchtest du keine Zeit, ist es nicht.
• Mache generierte Patches abhängig von Exploit-Eingabe-Tests und Varianten-Suchen, niemals davon, wie sauber der Diff aussieht.
• Investiere Geld oder Stunden in die Upstream-Projekte, von denen du abhängst. Gesponserte Audits haben diesen hier gefunden. Das ist kein Zufall; es ist das Modell in Aktion, und es muss aufhören, außergewöhnlich zu sein.

Man kann fair darüber streiten, ob diese Ära „technische Schulden abbauen“ ist oder uns für immer auf ein Laufband aus funktionsneutraler Fix-Arbeit schickt. Wahrscheinlich beides: Jeder nicht triviale Patch trägt das Risiko des nächsten subtilen Bugs, und kein System ist je fertig. Aber ich lebe lieber in einer Welt, in der die Schulden von Auditoren und White Hats eingefordert werden, als in einer, in der wir so tun, als sei der Treibsand Fels, weil uns bisher nichts verschluckt hat. PHP2Shell endete mit einem Patch und einem Seufzer der Erleichterung. Der nächste liegt bereits in jemandes Absturz-Warteschlange, abgelegt als harmlos. Schau dir deine an.