Ein Großinstitut lässt seine Codebasis von KI-Modellen prüfen – und steht danach vor einer Liste, die das eigene Team nicht abarbeiten kann. Übereinstimmend berichten mehrere Fachmedien, dass die Bank of America rund 1.000 externe Auftragnehmer engagiert hat, um Sicherheitslücken zu schließen, die zuvor mit KI-Unterstützung gefunden wurden. Genannt wird dabei unter anderem das Modell Mythos, das einer der Berichte Anthropic zuordnet.

Die Zahl ist in diesem Zusammenhang das eigentliche Signal. Nicht die Analyse war der Engpass, sondern die Umsetzung. Das Finden von Schwachstellen hat sich durch KI massiv beschleunigt, das Beheben nicht im gleichen Maß.

Analyse skaliert, Remediation nicht

Statische Codeanalyse gibt es seit Jahrzehnten. Neu ist, dass Sprachmodelle Zusammenhänge über Dateigrenzen hinweg erfassen, Fachlogik mitlesen und auch Muster melden, die klassische Regelwerke übersehen. Entsprechend länger werden die Befundlisten.

Das Patchen dagegen bleibt klassische Entwicklungsarbeit: verstehen, ändern, testen, ausrollen, dokumentieren. Jeder Eingriff in gewachsenen Code trägt ein Regressionsrisiko, also die Gefahr, dass eine Korrektur an anderer Stelle Funktionen bricht. Genau dieser Teil lässt sich nicht einfach durch mehr Rechenleistung verkürzen.

Dass ein Unternehmen dieser Größe externe Kapazität in vierstelliger Höhe zukauft, legt nahe: Die Befundmenge überstieg deutlich, was interne Teams neben dem laufenden Betrieb leisten konnten.

Der Business Case liegt hinter dem Aufwand

Einer der Berichte verweist darauf, dass die Bank nach Abschluss der Patcharbeiten erhebliches Einsparpotenzial erwartet. Details dazu sind nicht belastbar öffentlich, deshalb lohnt sich der Blick auf die Logik dahinter statt auf Zahlen.

Wer Schwachstellen kennt, muss sie behandeln – auch haftungsrechtlich. Unbekannte Risiken sind bequem, aber teuer, wenn sie ausgenutzt werden. Eine einmalige Bereinigungswelle ist ein Investitionsblock; der dauerhafte Nutzen entsteht erst, wenn danach ein Prozess existiert, der neue Befunde laufend und in kleinen Mengen abarbeitet.

Was das für mittelständische Web- und CMS-Systeme heißt

Die meisten Unternehmen haben keine 1.000 externen Entwickler zur Verfügung. Sie haben aber dieselbe Ausgangslage: eine über Jahre gewachsene Plattform, Erweiterungen unterschiedlicher Herkunft, Abhängigkeiten, die niemand mehr vollständig überblickt.

Wer in dieser Situation ein KI-gestütztes Code-Review startet, sollte vorher wissen, wie mit dem Ergebnis umgegangen wird. Sonst entsteht ein Dokument, das Handlungsdruck erzeugt, ohne Handlungsfähigkeit zu schaffen.

Priorisierung ist der entscheidende Schritt

Nicht jeder Befund ist ein Risiko. Entscheidend ist, ob eine Schwachstelle im konkreten System überhaupt erreichbar ist – von außen, ohne Anmeldung, in einem produktiven Pfad. Bewährt hat sich eine einfache Reihenfolge:

  • Erreichbarkeit: Ist der betroffene Code über das offene Internet ansprechbar oder nur in internen Tools aktiv?
  • Datenbezug: Sind personenbezogene Daten, Zahlungsdaten oder Zugangsdaten betroffen?
  • Ausnutzbarkeit: Braucht es eine Kette ungewöhnlicher Vorbedingungen oder genügt ein manipulierter Request?
  • Aufwand der Korrektur: Punktueller Fix, Abhängigkeits-Update oder Umbau eines Moduls?

Erst aus der Kombination dieser Punkte entsteht eine Reihenfolge, die sich gegenüber Geschäftsführung und Budgetverantwortung begründen lässt.

Falschmeldungen einkalkulieren

KI-gestützte Analyse liefert auch Hinweise, die sich bei genauer Prüfung als unkritisch erweisen. Das ist kein Argument gegen das Verfahren, aber ein Argument für einen Zwischenschritt: Jeder Befund braucht eine fachliche Bewertung durch Menschen, bevor er in die Umsetzungsliste wandert.

Ohne diesen Filter passiert zweierlei. Teams verlieren Zeit mit Korrekturen ohne Sicherheitsgewinn, und das Vertrauen in künftige Reports sinkt. Beides ist teurer als die Bewertung selbst.

Ein belastbarer Ablauf für die Praxis

Für gewachsene Web- und CMS-Landschaften hat sich ein abgestuftes Vorgehen bewährt:

  1. Bestandsaufnahme: Welche Systeme, Erweiterungen und Bibliotheken sind im Einsatz, in welchen Versionen?
  2. Analyse: Automatisierte Prüfung, ergänzt um KI-gestütztes Review der eigenen Individualentwicklung.
  3. Triage: Bewertung jedes Befunds nach Erreichbarkeit, Datenbezug und Aufwand.
  4. Sofortmaßnahmen: Was ohne Release-Zyklus abgesichert werden kann, etwa über Zugriffsbeschränkungen oder Konfiguration.
  5. Abarbeitung in Wellen: Feste Kapazität pro Sprint statt eines einmaligen Kraftakts.
  6. Absicherung: Automatisierte Tests und wiederkehrende Prüfläufe, damit Befunde nicht zurückkehren.

Der sechste Punkt wird am häufigsten gestrichen und ist der wichtigste. Eine einmalige Bereinigung hält nur, wenn sie in der Pipeline verankert wird – also in den automatisierten Schritten zwischen Commit und Deployment.

Externe Kapazität sinnvoll einsetzen

Der Zukauf externer Entwicklungsleistung ist im Fall der Bank of America eine Reaktion auf Mengendruck. Für kleinere Organisationen gilt das Prinzip in abgewandelter Form: Externe Unterstützung lohnt sich dort, wo wiederkehrende, klar beschreibbare Arbeit anfällt – Abhängigkeits-Updates, Anpassung veralteter Schnittstellen, Nachziehen von Sicherheitskonfigurationen.

Kontext- und fachlogikintensive Eingriffe gehören dagegen zu den Menschen, die das System kennen. Diese Trennung entscheidet darüber, ob zusätzliche Kapazität entlastet oder zusätzliche Abstimmung erzeugt.

Einordnung

Für Web- und Softwareprojekte verschiebt sich der Engpass: KI-gestützte Prüfung ist verfügbar und günstig, die Behebung bleibt Handarbeit mit Budget- und Zeitbedarf. Wer ein Code-Review beauftragt, sollte die Umsetzungskapazität für die Befunde gleich mitplanen, sonst entsteht ein dokumentiertes Risiko ohne Lösung. Sinnvoll ist deshalb, Analyse, Priorisierung und feste Abarbeitungskapazität von Anfang an als ein Vorhaben zu betrachten – und die Ergebnisse dauerhaft in den Entwicklungsprozess zu integrieren statt in eine einmalige Aktion.

Quellen