Fehler zu finden ist billig: Bank of Americas 1.000 Externe zeigen, wer zahlt
KI im Stil von Mythos macht die Suche nach Schwachstellen reichlich verfügbar. Die eigentliche Rechnung ist die menschliche Arbeit der Behebung, und Banken bekommen sie zuerst.
Foto: Unknown author Unknown author / Wikimedia Commons (CC BY-SA 2.5)
Was, wenn der teuerste Teil eines KI-Durchbruchs in der Cybersicherheit gar nicht die KI ist? Die Antwort der Bank of America, auf denkbar unglamouröse Weise geliefert: 1.000 zusätzliche Menschen mit Laptops.
Die Mythos-Rechnung einer Bank wird in Personal bezahlt, nicht in Lizenzen
Konzernchef Brian Moynihan sagte gegenüber CNBC, die Bank habe 1.000 externe Kräfte angeheuert, um Softwarefehler zu beheben, die Anthropics Mythos aufgedeckt hat. Laut Finextra arbeiten sie neben 3.000 internen Mitarbeitenden. Die Überschrift von TechRadar spricht von Kosten in Höhe von mehreren Hundert Millionen; wir würden diese Zahl mit Vorsicht behandeln, bis die Bank sie aufschlüsselt.
Das ist ein seltener Einblick, was die Mythos-Ära eine reale Institution kostet, und es ist keine Lizenzgebühr für ein Modell.
Das Finden wurde billig, das Reparieren nicht
Anthropic zufolge hat Mythos Tausende bislang unbekannter Schwachstellen gefunden und laut der Zusammenfassung von ArmorCode in über 83 % der Fälle auf Anhieb funktionierende Exploits erzeugt. Beeindruckend. Aber ein Fehlerbericht ist keine Lösung. Jemand muss den Code verstehen, ändern, testen, einplanen und vermeiden, dass an einem Dienstag ein Zahlungssystem ausfällt.
Das ist der Teil, den niemand mit einer Pressemitteilung skalieren kann. Unsere Einschätzung: Der Engpass hat sich vom Finden zur Arbeitskraft für die Behebung verschoben, und die zusätzliche Belegschaft der Bank of America ist das erste harte Preisschild für diese Verschiebung. Die Sicherheitsbranche hatte schon lange mehr Funde als Fixes. Mythos hat diesen Rückstau nicht erzeugt; wie Mitiga es formuliert, hat es offengelegt, wie untragbar er schon war. Wir halten das für zutreffend.
Es gibt noch einen leiseren Punkt. Wie CNBC berichtete, sagen Forscher, vieles von dem, was Mythos fand, lasse sich mit vorhandenen öffentlichen Modellen reproduzieren, wenn man sie geschickt orchestriert. Wenn das stimmt, hängt das Angebot an Funden nicht an einem einzelnen, nur eingeschränkt zugänglichen Modell. Es wird aus vielen Werkzeugen weiter kommen, zu jedem Unternehmen mit Code.
Banken spüren es zuerst, weil sie die Warteschlange nicht überspringen können
Banken betreiben alte Kernsysteme, Integrationen von Drittanbietern und strenge Änderungskontrollen, also genau dort, wo Korrekturen am langsamsten sind. Ein Bankenkommentator argumentierte, Kernbankanbieter stellten oft die größte Angriffsfläche einer Bank dar. Das ist eine Meinung, passt aber zur Form des Problems: Den Code eines Anbieters kann man nicht patchen, indem man Externe einstellt.
Auch Aufsichtsbehörden bewerten keine Absichten. Derselbe Kommentar merkt an, dass nach einem Vorfall geprüft wird, ob das Institut die Kontrolle in der Geschwindigkeit hatte, die die Bedrohung verlangte. Eine Bank mit Rückstau hat also ein Governance-Problem, nicht nur ein IT-Problem. 1.000 Leute darauf anzusetzen, ist die rationale Reaktion eines Instituts, das sich nicht leisten kann, das langsame zu sein.
Beachtenswert ist, wer gewinnt. Nicht die Verteidiger, zumindest noch nicht. Wir vermuten, dass die bisherigen Gewinner die Anbieter von Behebungsleistungen sind: Dienstleister, Automatisierungsanbieter und Hersteller von Werkzeugen für Ausgleichsmaßnahmen. Anbieter wie Moderne bewerben genau das und behaupten, die Behebung einer Schwachstelle in 2.000 Repositories dürfe nicht das 2.000-Fache kosten. Das ist Marketing und hier unbewiesen, zeigt aber, wohin das Geld fließen könnte.
Mehr Personal ist eine Notlösung, keine Strategie
Das Einstellen von Externen skaliert linear; die Funde möglicherweise nicht. Wenn, wie das Team von Anthropic Berichten zufolge schätzt, vergleichbare Fähigkeiten innerhalb von sechs bis achtzehn Monaten bei anderen Labors auftauchen, werden bald viele große Unternehmen solche Werkzeuge auf ihren eigenen proprietären Code richten. Der Rückstau, so ArmorCode, könnte um Größenordnungen wachsen. Daraus stellt sich niemand heraus.
Was also sollten Leser oder CISOs tun? Drei Dinge, unserer Meinung nach. Gnadenlos nach tatsächlicher Gefährdung priorisieren, nicht nach reiner Schwere. Gegenmaßnahmen wie Isolierung vorab freigeben, damit sie nicht auf das nächste Änderungsfenster warten. Und für das Beheben budgetieren, nicht für das Finden: Wenn der Posten für KI-Scans größer ist als der für die Behebung, hat man das Problem wahrscheinlich falsch eingeschätzt.
Das Fazit
Für normale Kunden, die fragen, ob ihr Geld sicher ist: Nichts von dem, was wir gelesen haben, besagt, dass die Bank of America gehackt wurde. Es ist die Geschichte einer Bank, die viel Geld ausgibt, um Schwachstellen zuvorzukommen, was besser ist, als sie zu ignorieren. Die Lehre lautet nicht, dass KI das Bankwesen kaputtgemacht hat. Sie lautet, dass die Rechnung für Entdeckung in KI-Tempo bei der Reparatur in menschlichem Tempo landet, und 1.000 Externe sind schlicht die erste Rechnung, die wir sehen.
Noch keine Themen: Eröffne das erste.
Weitere Artikel
Der Backup-Anbieter ist die neue Eingangstür, und KI hat sie eingetreten
Der Angriff auf ConnectWise Cloud Backup zeigt: Eine einzige Anbieter-Zugangsdatei plus ein agentisches KI-Tool genügt, um Hunderte Tenants zu erreichen. Backup- und MSP-Tools gehören in Tier 0.
Der PHP-Notfall zeigt: Patchen im menschlichen Tempo reicht nicht mehr aus
Zwei von KI entdeckte PHP-Lücken legten Behörden und große Websites lahm. Die Lehre: Das Finden ist schneller als das Patchen, und in dieser Lücke verlieren Verteidiger.
Das Vertrauen im Browser ist noch immer zu fragil für stilles Versagen
Der eMudhra-Vorfall zeigt, dass HTTPS außerhalb des Browsers angreifbar bleiben kann – bei uneinheitlichem Widerruf, veralteten Truststores und kaum sichtbaren Unterschieden für Nutzer.
GitLabs CVSS-10-Schwachstelle macht CI/CD zur Produktionsinfrastruktur
Eine kritische GitLab-Schwachstelle erinnert daran, dass Entwicklerinfrastruktur zu einem Angriffspfad in der Software-Lieferkette werden kann – und nicht lediglich ein Kollaborationstool ist, das man später patcht.



