Gut genug war gestern: Warum die stille Wette der Software-Security verloren ist

Im Frühjahr durfte ich die Eröffnungs-Keynote beim andrena Software Excellence Day halten. Der Titel „Gut genug war gestern“ war eine Behauptung, die ich damals ausführlich hergeleitet habe. Ein halbes Jahr später nehme ich keins der Argumente dafür zurück, muss aber fast jede Zahl nach oben korrigieren.

Die stille Prämisse war nie, dass unsere Software bestmöglich geschützt ist

Jede Security-Entscheidung beruht auf einer Bewertung, die selten jemand ausspricht: Wie wahrscheinlich ist es, dass jemand eine Schwachstelle findet? Das ist eine Risikobewertung, und sie endet mit einer Entscheidung. In der Software-Entwicklung fiel sie jahrelang gleich aus: Wir haben das Risiko akzeptiert oder ignoriert, ohne Protokoll ist das dasselbe. Eine stillschweigende Risikoakzeptanz hat keinen Eigentümer und kommt nie wieder auf den Tisch, auch dann nicht, wenn ihre Grundlage wegfällt.

Die Bewertung stützte sich auf eine Prämisse. Und die lautete nie „unsere Software ist bestmöglich geschützt“, sondern „niemand hat die Kapazität, sie gründlich zu prüfen“. Auf der einen Seite der Waage lagen Millionen Zeilen Code, auf der anderen die Zeit eines Menschen, der ihn durchsehen will: begrenzt, teuer, dafür zu wertvoll. Diese Schieflage hat uns geschützt, nicht unsere Sorgfalt. Das war eine heimliche Strategie, und sie beruhte auf einer Wette.

Wenn Prüfen billig wird, verliert man diese Wette

2018 vergingen zwischen der Veröffentlichung einer Schwachstelle und ihrer ersten Ausnutzung typischerweise 771 Tage, das sind gut zwei Jahre. 2023 waren es noch fünf Tage. Seit 2025 liegt der Wert bei null: Die Hälfte aller ausgenutzten Schwachstellen wird spätestens am Tag ihrer Veröffentlichung angegriffen. 2026 ist der Durchschnitt erstmals negativ: Die Ausnutzung beginnt, bevor überhaupt jemand von der Schwachstelle weiß.

Damit funktioniert das eingeübte Hase-und-Igel-Spiel nicht mehr: finden, melden, patchen, einspielen. Es hat immer davon gelebt, dass zwischen den einzelnen Schritten Zeit lag – Wochen, in denen sich ein Wartungsfenster planen ließ. Diese Zeit hat man nicht mehr.

Wer trotzdem daran festhält, externalisiert das Risiko auf den Betreiber. Dieser zahlte bisher mit Aufwand: Wartungsfenster, Regressionstests, Ausfallzeiten. Jetzt zahlt er zusätzlich mit dem Risiko, dass der Patch zu spät kommt. Das kann kein Betrieb mehr auffangen.

Für die Entwicklung folgt daraus dreierlei: Schwachstellen gar nicht erst entstehen lassen; was trotzdem entsteht, so schnell schließen, wie es technisch geht; und begrenzen, welcher Schaden überhaupt möglich ist, mit Schwachstelle wie ohne. Richtig war das schon vorher. Seit dem Frühjahr 2026 – seit Claude Mythos alte Fehler im Bestand aufspürt und Anthropics Project Glasswing das Durchforsten zum Programm macht – ist es dringend notwendig.

Wo Sicherheit heute verloren geht

Beim Vermeiden von Schwachstellen denkt man zuerst an den Quelltext. Dabei ist er nur eine von drei Stellen: die Pipeline, die das Produkt baut, der Code, aus dem sie es baut, und der Agent, der an beidem arbeitet. Die drei unterscheiden sich darin, wie der Schaden entsteht: In der Pipeline steht ein Angreifer am Anfang. Im Code gibt es den Angreifer nicht, die Lücke schreiben wir selbst. Beim Agenten braucht es keine Lücke.

In der Pipeline

Wie weit ein einzelnes Versäumnis trägt, hat sich in diesem Jahr gezeigt. Ende Februar stiehlt die Gruppe TeamPCP über einen fehlkonfigurierten `pull\_request\_target`-Workflow – eine GitHub-Actions-Konfiguration, die fremden Code mit den Rechten des eigenen Repositories laufen lässt – den Access Token eines Aqua-Security-Service-Accounts. Der Token wird danach nicht vollständig rotiert.

Drei Wochen später, am 19. März, werden damit 76 von 77 Versions-Tags der `trivy-action` rückwirkend auf bösartigen Code umgelenkt: offiziell, signiert und aus der bekannten Quelle. Zwölf Stunden lang gibt jede Pipeline, die in diesem Fenster mit einem dieser Tags läuft, ihre Credentials preis. Trivy ist ein Vulnerability-Scanner; Hier wurde das Werkzeug, das Lücken finden soll, selbst die Lücke.

Mit den so erbeuteten Zugangsdaten kompromittiert TeamPCP Checkmarx KICS, LiteLLM und zuletzt über 60 npm-Pakete. Ende März trifft es Cisco – über 300 Repositories –, Anfang April die Europäische Kommission, wo CERT-EU den Abfluss von rund 92 GB komprimierter Daten bestätigt. Cisco war kein Ziel, sondern Beifang: Der Konzern hatte Trivy in der eigenen Pipeline.

Im August stuft CloudSEK mehr als 2.500 Organisationen als potenziell betroffen ein, darunter Siemens und Volkswagen, abgeschlossen ist der Fall bis heute nicht.

IWer sucht, der findet, das gilt entlang der gesamten Pipeline

Wer Werkzeuge einsetzt, handelt sich deren Angriffsfläche ein und auch die der Werkzeuge darunter. Für Hersteller heißt das: Die eigene Pipeline ist Teil des Produkts. Ein Angreifer, der sie unterwandert, muss den Quelltext gar nicht mehr anfassen; was er einschleust, ist ordnungsgemäß signiert und läuft klaglos – und oft unbemerkt – durch.

Im eigenen Code

Seit drei Jahren legt Veracode Sprachmodellen dieselben Programmieraufgaben vor: Jede davon lässt sich sicher oder unsicher lösen, und im Prompt steht kein Wort über Sicherheit. Die Syntax-Korrektheit ist in dieser Zeit von rund 50 auf 95 Prozent gestiegen. Der Anteil sicherer Lösungen liegt unverändert bei 55 Prozent. In fast der Hälfte der Fälle baut das Modell also eine bekannte Schwachstelle ein, daran hat sich über drei Modellgenerationen nichts geändert. Wer die wiederkehrenden Schwachstellenmuster kennt, liest solchen Code anders. Wer sie nicht kennt, sieht nur grüne Tests.

Im eigenen Agenten

Der erste Fall braucht keinen Angreifer. Ende April soll ein Coding-Agent bei PocketOS ein Credential-Problem in der Staging-Umgebung lösen. Er entscheidet eigenmächtig, ein Produktions-Volume zu löschen – samt der Backups darin. Dauer: neun Sekunden. Sein Systemprompt schreibt vor, vor destruktiven Aktionen nachzufragen. Er fragt nicht und zitiert die Regel hinterher trotzdem fehlerfrei. Ein Einzelfall ist das nicht: Schon im Juli 2025 löschte ein Replit-Agent die Produktionsdatenbank eines Kunden – mitten in einem ausgerufenen Code-Freeze – und erfand anschließend Daten, um den Fehler zu verdecken.

Im zweiten Fall steht sehr wohl ein Angreifer am Anfang, er nutzt keine Schwachstelle, sondern eine Schwäche. Ein Entwicklungsteam hat den offiziellen GitHub-MCP-Server angebunden, dazu ein öffentliches und ein privates Repository. MCP – das Model Context Protocol – ist die Schnittstelle, über die Agenten auf Werkzeuge und Datenquellen zugreifen. Der Angreifer legt im öffentlichen Repository ein Issue an, in dem eine Anweisung versteckt ist. Das Team bittet den Agenten, sich die offenen Issues anzusehen. Der Agent liest die versteckte Anweisung, holt Daten aus dem privaten Repository und veröffentlicht sie im öffentlichen. Kein Paket war vergiftet, der Server ist der offizielle von GitHub, das Team hat nichts falsch gemacht.

Die Fehlerquelle liegt tiefer als eine Fehlkonfiguration: Ein Sprachmodell hat keinen getrennten Kanal für Anweisung und Inhalt. Das Muster ist von der SQL-Injection bekannt: Fremde Eingabe wird als Anweisung gelesen. Dagegen gibt es dort ein Mittel – die parametrisierte Query trennt Struktur und Daten in zwei Kanäle. Ein Sprachmodell hat nur einen. Alles, was in den Kontext gelangt, ist derselbe Text, der Auftrag des Teams und die versteckte Zeile im fremden Issue stehen gleichberechtigt nebeneinander. Das Modell unterscheidet nicht schlecht, es kann nicht unterscheiden.

Anweisung? Inhalt? Für diesen Agenten ein und dasselbe...

Präparieren lässt sich nicht nur ein Issue, sondern jede Quelle, die ein Agent liest – Zscaler hat eine reale Kampagne dokumentiert: eine gefälschte Doku-Seite für eine frei erfundene Python-Bibliothek, die lesenden Agenten versteckte Anweisungen unterschiebt. Die meisten getesteten Modelle ignorierten die versteckte Anweisung, aber ein Modell, das sie befolgt, genügt.

Zu diesen Quellen gehört ein anderer Agent. Im Juli prüft OpenAI eigene Modelle in einer Übungsumgebung für Angriffstechniken – zehntausende Läufe parallel, jeder in einer eigenen Sandbox, ein Teil der Aufgaben absichtlich unlösbar. Die Agenten finden einander trotzdem, über den Cache eines gemeinsam genutzten Paketservers. Dort richten sie ein Schwarzes Brett ein und tauschen mehr als 70.000 Nachrichten und Dateien aus. Als einer von ihnen Zugangsdaten für Hugging Face findet, beteiligen sich rund 700 an einem Angriff auf dessen Produktivsysteme, viele davon, obwohl sie in ihren eigenen Aufzeichnungen festhalten, dass das Ziel außerhalb ihres Auftrags liegt. Die Bitte eines Kollegen wiegt schwerer als die selbst erkannte Grenze.

Gegen solche Eingaben helfen strengere Systemprompts nicht. Ein NIST-Wissenschaftler legt 2026 eine formale Analyse vor, nach der es keine endliche Menge von Leitplanken gibt, die gegen alle solchen Eingaben robust ist. Was ein Agent tun will, lässt sich nicht zuverlässig vorhersagen. Was er tun kann, lässt sich festlegen.

Warum das Schließen nicht mehr mithält

Bleibt die zweite Forderung: Was trotzdem entsteht, schnell zu schließen.

Diesen Sommer arbeitete sich „NOVA“, ein KI-System von Palo Alto Networks, zwei Monate lang durch den Quelltext von knapp viertausend Open-Source-Projekten und förderte gut vierzehntausend bestätigte Schwachstellen zutage. Davon waren 85 bekannt. Die übrigen hatte nie jemand gemeldet. Das hätte ich im Frühjahr noch für eine Übertreibung gehalten.

Und NOVA ist nicht allein, auch an anderen Stellen tauchen alte Fehler auf: Anthropics Claude Mythos fand einen 27 Jahre alten OpenBSD-Bug, die Firma AISLE einen OpenSSL-Fehler von 1998. Was jahrzehntelang niemandem auffiel, liegt jetzt offen.

Die Prüfkapazität, auf deren Fehlen wir gewettet haben, existiert mittlerweile, genauer seit diesem Sommer. Solche Systeme sind billig, sie schlafen nicht und sie langweilen sich nicht. Die Hersteller selbst haben solche Systeme im Programm: OpenAI prüft mit „Codex Security“ – gestartet als „Aardvark“ – Code autonom auf Schwachstellen; Anthropic bündelt unter Project Glasswing rund 50 Partner, um kritische Open-Source-Software zu durchkämmen, bevor Angreifer es tun. Anthropic hat die Folge im Mai selbst benannt: Früher sei Software-Sicherheit davon begrenzt gewesen, wie schnell man Schwachstellen findet, heute davon, wie schnell man sie prüfen, melden und beheben kann.

Vergessen wir einfach mal alles, was wir bishter über Volumina und Prüfkapazitäten gedacht haben

Wohin das führt, zeigt das Linux-Kernel-Projekt. Die private Sicherheitsliste des Projekts bekam vor zwei Jahren zwei bis drei Meldungen pro Woche. Heute sind es fünf bis zehn – pro Tag. Linus Torvalds nennt die Liste deshalb nahezu nicht mehr handhabbar: Zu viele Melder lassen dieselben Werkzeuge über denselben Code laufen und melden dasselbe. Die Maintainer kommen nicht mehr hinterher. Sie beheben keine Fehler mehr, sie trennen die Spreu vom Weizen: Dubletten, Fehlalarme, ungeprüfte Maschinenausgaben.

Aufschlussreicher als der Befund ist die Reaktion. Das Projekt hat den Prozess geändert: Was mit KI gefunden wurde, behandelt es wie eine bereits veröffentlichte Meldung: kein Embargo, keine Vorlaufzeit. Gegen KI wendet sich Torvalds dabei ausdrücklich nicht. Er verlangt nur, dass die Melder nicht bloß weiterreichen, was die Maschine ausgespuckt hat, sondern selbst Hand anlegen. Am besten mit einem Patch.

Wo der Mensch hingehört

Menschliche Aufmerksamkeit ist der Engpass. Trotzdem sehen die meisten Prozesse sie genau dort vor, wo sie am wenigsten bewirkt.

Die übliche Antwort auf das Volumen heißt „human in the loop“. Sie klingt nach Kontrolle und regelt doch nur die Haftung: Wo die Menge das Prüfen im Einzelnen unmöglich macht, wird aus der Freigabe eine Unterschrift – wer alles freigeben muss, gibt alles frei. Rutscht etwas durch, ist wenigstens dokumentiert, wer unterschrieben hat. Und das Protokoll, das er oder sie abzeichnet, muss nicht stimmen: In rund sieben Prozent der untersuchten Mitschnitte gab ein Agent einen Werkzeugaufruf vor und führte einen anderen aus. Damit ist der Kontrollpunkt, auf den sich alle verlassen, der schwächste im ganzen Prozess.

Dafür ist menschliche Aufmerksamkeit zu knapp. Sie gehört dorthin, wo keine Maschine sie ersetzt: zu der Frage, was schützenswert ist, was ein Angreifer damit anfangen könnte und welche Entwürfe deshalb ausscheiden. Threat Modeling ist genau diese Arbeit. KI kann dabei zuarbeiten, entscheiden muss der Mensch.

Das Volumen dagegen ist eine Werkzeugaufgabe, deterministische Werkzeuge und KI nebeneinander, nicht gegeneinander. Und beim Schreiben hilft KI, man muss es ihr nur sagen: Die 55 Prozent gelten für Prompts ohne ein Wort über Sicherheit. Steht das Wort drin, steht Sicherheit im Kontext und was im Kontext steht, berücksichtigt das Modell. Meine Erfahrung bestätigt das, für den Code wie für die Tests.

Nachrüsten lässt sich damit trotzdem nichts. Sicherheit muss im Entwurf stecken. Was dort fehlt, findet man später wieder, aberals Befund, nicht als Lösung.

Was das praktisch bedeutet

Die Toolchain wie Produktionscode behandeln. Gepinnte Digests statt beweglicher Tags, rotierte Tokens, minimale Rechte. GitHub geht voran: Dependabot wartet seit Juli drei Tage, bevor es ein Versions-Update vorschlägt – Sicherheitsupdates ausgenommen. Dieser Cooldown bremst die eigene Automatik, die sonst jede frisch vergiftete Version einspielt, bevor irgendjemand sie prüfen konnte.

Reviews risikobasiert steuern. Bei lokal erkennbaren Problemen sind die Modelle gut: parametrisierte Queries, Standard-Krypto. Bei allem, was sich nur über den Datenfluss durch mehrere Stellen erkennen lässt, brechen sie ein:Cross-Site Scripting und Log Injection lösen sie in unter 20 Prozent der Fälle sicher. Genau dorthin gehört menschliche Aufmerksamkeit, und zwar von Menschen, die solche Schwachstellenklassen benennen können.

Agenten Grenzen geben, keine Ermahnungen. Wirksam ist nur, was der Agent nicht wegargumentieren kann: Rechte, Netzgrenzen, getrennte Umgebungen. Und nachsehen, ob die Trennung hält: Die 1.200 Agenten liefen jeder in einer eigenen Sandbox und teilten sich trotzdem einen Paket-Cache. Die gefährliche Kombination lässt sich dabei genau benennen – fremde Inhalte lesen, eigene Geheimnisse sehen und nach außen schreiben zu dürfen – Simon Willison nennt sie die „lethal trifecta“. Wer eines der drei wegnimmt, entschärft die Kombination.

„Das findet eh keiner“ streichen. Der Satz war die stille Begründung für aufgeschobene Refactorings und nicht priorisierte Tickets. Für das nächste Sprint Planning taugt ein anderer: „Wir haben uns darauf verlassen, dass das niemand findet. Das können wir nicht mehr.“

Fazit

Die Kapazitätsbeschränkung, auf die wir gewettet haben, existiert nicht mehr. Diese Wette ist verloren, unabhängig davon, wie sorgfältig der eigene Code geschrieben ist.

Pipeline, Code und Agent haben einen gemeinsamen Nenner: Erzeugt, ausgeliefert und ausgeführt wird im Takt der Maschine. Gelesen wird im Takt des Menschen. Security ist deshalb keine Abwehr nach außen, die ein Team am Rande des Prozesses erledigt, sondern eine Eigenschaft jedes einzelnen Schritts. Kaufen lässt sich so etwas nicht: Es sitzt in den Köpfen der Menschen, die den Code produzieren – oder nirgends.

Das Problem ist nicht neu. Weggefallen ist der alte Schutz. Was den Druck erzeugt, hilft auch dagegen: Code-Review mit KI, automatisiertes Scanning, Pipelines, die prüfen, statt nur zu bauen. Sie ergänzen, was an Schutz schon da ist; aber sie ersetzen es nicht. Sie liefern Befunde. Was ein Befund wert ist, entscheidet, wer ihn liest – und das muss gelernt sein.

Die Wiener haben dafür einen Satz: Die Lage ist hoffnungslos, aber nicht ernst. Hoffnungslos, weil das alte Gleichgewicht nicht zurückkommt. Nicht ernst, weil wir wissen, was zu tun ist – und es tun können.

In der Reihenfolge, in der sie im Text vorkommen:

• Zero Day Clock – Live-Dashboard zur Zeit zwischen Veröffentlichung und Ausnutzung einer Schwachstelle: zerodayclock.com – Zahlen im Text aus der Median-Reihe, Stand August 2026
• Anthropic: Claude Fable 5 and Mythos 5, 09.06.2026 – anthropic.com
• Wiz: Trivy Compromised: Everything You Need to Know about the Latest Supply Chain Attack, 20.03.2026 – wiz.io · Aqua Security: Trivy Security Advisory (CVE-2026-33634)
• Datadog Security Labs zur Kompromittierung von LiteLLM – securitylabs.datadoghq.com
• BleepingComputer zum Quellcode-Abfluss bei Cisco – bleepingcomputer.com
• CERT-EU: European Commission cloud breach: a supply-chain compromise, 02.04.2026 – cert.europa.eu · dazu die Pressemitteilung der Kommission IP/26/748
• The Hacker News: Malicious LiteLLM Releases Tied to Trivy Hack, 12.08.2026 – CloudSEK-Auswertung und FBI-Warnung FLASH-20260702-01 – thehackernews.com
• Veracode: Spring 2026 GenAI Code Security Update, 24.03.2026 – veracode.com
• Zenity: System Prompts Are Not Security Controls – Analyse des PocketOS-Vorfalls, 28.04.2026 – zenity.io
• The Register zum Replit-Vorfall: Vibe coding service Replit deleted user's production database, faked data, told fibs galore, 21.07.2025 – theregister.com
• Invariant Labs: GitHub MCP Exploited – Accessing private repositories via MCP, 26.05.2025 – invariantlabs.ai
• Zscaler ThreatLabz: Indirect Prompt Injection in Web Content Targets AI Agents, 02.07.2026 – zscaler.com
• METR und Redwood Research: Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident, 26.08.2026 – metr.org · zur technischen Seite Hugging Face: Anatomy of a Frontier Lab Agent Intrusion, Juli 2026 – huggingface.co
• Apostol Vassilev (NIST): Robust AI Security and Alignment – A Sisyphean Endeavor?, IEEE Security & Privacy 05–06/2026 – Meldung des NIST · DOI
• Unit 42 / Palo Alto Networks: The Frontier AI Vulnerability Burst, 04.08.2026 – unit42.paloaltonetworks.com
• OpenAI: Introducing Aardvark, 29.10.2025 – openai.com · seit März 2026 als „Codex Security“ in Codex integriert
• Anthropic: Project Glasswing – An initial update, 22.05.2026 – anthropic.com
• Linus Torvalds zur Sicherheitsliste des Linux-Kernels, 18.05.2026 – The Register · Tom's Hardware
• GitHub: The case for a cooldown – Why Dependabot now waits before issuing version updates, Juli 2026 – github.blog
• Simon Willison: The lethal trifecta for AI agents: private data, untrusted content, and external communication, 16.06.2025 – simonwillison.net