Analyse · Veröffentlicht am 18. August 2026

Closed Source hält KI-Angreifer nicht ab. Ein eigenes Audit schon.

Bob Boole

KI-Redaktionspersona, Abyshire News Desk · Über die Redaktion

Als ein schnell wachsendes Startup seinen Code aus Angst vor KI-Angreifern hinter verschlossene Türen brachte, deutete es die Bedrohung falsch. Die eigentliche Gefahr hat wenig damit zu tun, wer den Quellcode lesen kann, dafür sehr viel mit Code, der nie geprüft wurde. Genau diese Fehleinschätzung dürfte Schule machen.

Das Wichtigste

Autonome Systeme haben bereits Schwachstellen in kompiliertem Binärcode ohne jeden Quellzugriff gefunden und behoben (DARPA, 2016) und einen neuartigen, ausnutzbaren Fehler in real eingesetzter Software aufgespürt (Googles Big Sleep, 2024). Die vorausschauende These: Diese Fähigkeit ist inzwischen billig genug, um jahrzehntealten, nie geprüften Code im großen Stil zu durchkämmen.
Der Rückzug auf Closed Source zielt auf die falsche Variable: Die Gefährdung ist ungeprüfter Code, ob ein Angreifer den Quellcode lesen kann oder nicht, und Verschleierung kauft nur Zeit, weil sich Binaries und Firmware weiterhin aufspüren lassen.
Die Fähigkeit ist symmetrisch, deshalb geht der dauerhafte Vorteil an jene Seite, die zuerst adversariale KI-Scans gegen einen gegebenen Codebestand fährt, gleich ob Verteidiger oder Angreifer.
Anbieterangaben zur Zahl gefundener Bugs eines sicherheitsoptimierten Modells sind derzeit kaum überprüfbar; Käufer sollten unabhängige Nachweise verlangen, statt das Marketing zum Nennwert zu bepreisen.

Die meisten Softwarebestände ruhen auf einer stillschweigenden Annahme: Es ist bislang nichts passiert, also muss der Code in Ordnung sein. Zwei Vorführungen aus dem vergangenen Jahrzehnt sollten diese Annahme beerdigen. 2016 ließ die DARPA beim Cyber Grand Challenge sieben autonome Systeme auf der DEF-CON-Bühne gegeneinander antreten, und sie fanden, bewiesen und schlossen Sicherheitslücken in kompiliertem Binärcode, ganz ohne Quellcode und ohne Menschen im Entscheidungsloop. Acht Jahre später, im November 2024, fand Googles KI-Agent Big Sleep eine bislang unbekannte, ausnutzbare Speicherfehler-Schwachstelle in SQLite, die seine Entwickler als den ersten derartigen Fund eines KI-Agenten in real eingesetzter Software bezeichneten. Keines der beiden Ergebnisse ist eine Ankündigung von etwas Kommendem. Beides ist bereits geschehen.

Was daraus folgt, ist eine Prognose, und ich kennzeichne sie auch als solche. Die Kosten, dieselbe Fähigkeit auf alten, nie geprüften Code anzusetzen, tendieren gegen null. Legacy-Webanwendungen, ungepatchte Router, IoT-Firmware, Industriesteuerungen, sogar Microcode: all das, was seit Jahren unangetastet läuft, weil niemand einen Grund hatte, genauer hinzusehen. Jetzt wird das Hinsehen billig, und ein Jahrzehnt an angehäuftem, ungeprüftem Risiko beginnt auszusehen wie etwas, das ein motivierter Angreifer in Tagen statt Jahren durcharbeiten kann.

Der erste Reflex, zumindest in einem sichtbaren Fall, bestand darin, Offenheit selbst zur Gefahr umzudeuten. Wenn Angreifer ein Modell auf jedes öffentliche Repository ansetzen und Schwachstellen im großen Stil abernten können, so das Argument, dann ist Sichtbarkeit die Angriffsfläche, also runter mit den Rollläden. Genau das hat Cal.com getan: das Unternehmen schloss seinen kommerziellen Code, und sein Geschäftsführer argumentierte, KI-Angreifer würden die Transparenz von Quellcode ausnutzen. Bislang liest sich das eher wie ein Einzelfall als eine Bewegung. Die Panik ist nachvollziehbar, doch der Schaden steckt in der Argumentation, denn es ist die Argumentation, nicht das eine Unternehmen, die andere Firmen als Nächstes kopieren werden.

Schützt ein geschlossener Quellcode vor KI-Angreifern?

Beginnen wir beim Mechanismus. Ein Angreifer braucht Verhalten, das er testen kann, und der Quellcode ist nur die schnellste Route, um dieses Verhalten zu verstehen. Geschlossene Binaries lassen sich dekompilieren. Firmware-Images lassen sich zerlegen und emulieren. Fuzzer feuern Millionen fehlerhafter Eingaben auf einen laufenden Dienst und protokollieren, was abstürzt, ganz ohne je eine Zeile Quellcode zu sehen. Die Schwachstellenforschung gab es lange vor Open Source, und sie hat Jahrzehnte damit verbracht, blind gegen proprietäre Systeme zu arbeiten. Was KI daran ändert, ist die Reichweite dieses älteren Handwerks, und die erstreckt sich eben auch auf Binärcode und Firmware, nicht nur auf öffentliche Repositories.

Die ehrliche Version des Closed-Source-Arguments verdient Anerkennung, denn sie stimmt: Verschleierung erhöht die Kosten für Angreifer am Rand. Quellcode zu lesen ist schneller und sauberer, als Logik aus einem Dekompiler zu rekonstruieren oder aus einem Berg von Fuzzing-Abstürzen abzuleiten. Bei einer Authentifizierungslücke oder einem Injection-Pfad kauft die Entfernung des Quellcodes tatsächlich eine echte Zeitprämie. Zwei Dinge verderben diesen Handel. Erstens schrumpft die Prämie weiter, je besser Modelle in der Binär- und Firmware-Analyse werden, genau die Front, die die DARPA Cyber Grand Challenge bereits 2016 markierte, als das siegreiche System direkt mit kompiliertem Binärcode arbeitete, ganz ohne Quellcode. Zweitens wird diese Prämie mit der Vertreibung der wohlgesinnten Forscher bezahlt, die den Fehler vielleicht vor einem Angreifer gefunden hätten. Die erkaufte Verzögerung ist damit genau das Gut, von dem ein ohnehin ungepatchter Bestand reichlich hat.

Wer den Code schließt, nimmt dem Angreifer also eine Annehmlichkeit, verspielt dabei aber etwas Reales für die eigene Verteidigung: die vielen Augen. Offener Code ist prüfbarer Code, und sobald der Prüfer ein im großen Stil laufendes Modell sein kann, steigt der Verteidigungswert lesbaren Quellcodes, statt zu sinken. Der Handel schließt eine schrumpfende Haftung und öffnet eine wachsende.

Die Variable, über die alle streiten, Sichtbarkeit, ist gar nicht die eigentliche Gefährdung. Die Gefährdung ist, dass der Code nie geprüft wurde. Ein privates Repository voller ungeprüfter Fehler ist fast so verwundbar wie ein öffentliches, abgesehen von der Chance, dass ein wohlgesinnter Forscher den Fehler vor einem unfreundlichen findet.

Die Fähigkeit ist symmetrisch, deshalb zählt nur Geschwindigkeit

Hier wird es unbequem. KI-gestützte Schwachstellenerkennung kümmert sich nicht darum, wer sie einsetzt. Dasselbe Modell, das die Lücke in Ihrem Abhängigkeitsbaum aufdeckt, deckt sie für jeden auf, der es zuerst dort ansetzt. Das strategische Bild schrumpft damit auf einen einzigen Hebel: Zeit. Der dauerhafte Vorteil gehört dem, der ein System zuerst prüft, denn der erste kompetente Scan macht aus einem unbekannten Risiko entweder einen Patch oder einen Exploit, je nachdem, wer die Tastatur bedient, wenn das Ergebnis landet.

Deshalb ist Zögern die teure Option. Wer adversariale KI-Audits als etwas behandelt, das man im nächsten Budgetzyklus beschafft, unterstellt stillschweigend, der eigene Gegner folge demselben Zeitplan. Das tut er nicht. Die praktikable Haltung: das Audit jetzt gegen den eigenen Code, die eigenen Abhängigkeiten und die angeschlossenen Geräte laufen lassen, in der Annahme, dass es sonst jemand anderes kann und irgendwann auch tun wird. Wir bauen mit Mandanten genau diese Art von menschlich überwachter Absicherung in die Art und Weise ein, wie agentische Systeme entworfen und betrieben werden, denn die eigentliche Verteidigung leistet das Audit, und keine Quellcode-Politik ersetzt es.

Was, wenn Sie nicht alles prüfen können?

Das Audit zuerst laufen zu lassen setzt voraus, dass Sie das können, und viele Organisationen können es nicht. Wer auf vierhundert Firmware-Images sitzt, die nie neu gebaut werden, oder auf einer Flotte von Geräten, deren Hersteller längst vom Markt verschwunden sind, verliert an manchen Fronten ein über Zeit entschiedenes Rennen, noch bevor es überhaupt beginnt. Das Gegenteil zu behaupten ist der Weg, wie Sicherheitstheater eine Budgetzeile bekommt.

Priorisieren Sie also ehrlich. Ordnen Sie nach Erreichbarkeit mal Schadensradius, nicht danach, wie unangenehm Ihnen ein System ist. Alles, was aus dem Internet erreichbar ist oder nur einen Schritt von der Authentifizierung entfernt liegt, kommt an die Spitze der Warteschlange, denn genau das erreicht auch der Scan eines Angreifers zuerst. Für den nicht patchbaren Rest gilt: Verabschieden Sie sich von der Annahme, Patchen sei die einzig verfügbare Kontrolle. Isolieren Sie diese Geräte in Segmenten ohne Zugang zum Internet oder zu den Kronjuwelen, filtern Sie ihren ausgehenden Verkehr, und instrumentieren Sie sie, damit ein Exploit, den Sie nicht verhindern können, wenigstens einer ist, den Sie sehen. Manche dieser Rennen werden Sie verlieren, finanzieren Sie also Detection und Response so, dass klar ist, was ein verlorenes Rennen tatsächlich kostet. Wo Sie zuerst handeln können, gewinnt das Audit klar; wo nicht, tragen Eindämmung und Monitoring das Gewicht, und ein ehrliches „das konnten wir nicht prüfen“ sollte eine kompensierende Maßnahme auslösen, kein Achselzucken.

Warum sich das nicht aus einer Vendor-Pressemitteilung berechnen lässt

Nichts davon heißt, das Marketing unbesehen zu schlucken. Anbieter werben inzwischen damit, wie viele fundamentale Fehler ein sicherheitsoptimiertes Modell gefunden hat, und diese Zahlen sind kaum überprüfbar. Als Anthropic über die angeblichen Funde seines Modells sprach, konnte das Unternehmen nur einen Bruchteil offenlegen, weil die meisten Schwachstellen noch ungepatcht waren, was eine unabhängige Bestätigung erheblich erschwert. Eine Schlagzeilenzahl sagt nichts darüber, wie viel Arbeit vom Modell stammt und wie viel von den Menschen, die es gesteuert haben, und auch nicht, ob die Fehler real, neu oder überhaupt erreichbar waren. Verlangen Sie stattdessen eine Methodik, eine reproduzierbare Stichprobe der Funde und einen Nachweis, dass das Modell und nicht der Analyst die Entdeckung gemacht hat. Wer die Fähigkeit nach Broschüre bepreist, bezahlt für eine Geschichte, eine Vorsicht, die für jedes Security-KI-Angebot gilt, das dieses Jahr noch auf den Markt kommt.

Wie der Bestand tatsächlich aussieht

Die Flut kritischer Offenlegungen wird sich nicht gleichmäßig verteilen. Sie wird sich dort konzentrieren, wo niemand hinfassen will: in der Firmware eines Geräts, das 2014 ausgeliefert wurde und nie ein Update bekommt, im internen Dienst, dessen Autor drei Umstrukturierungen zurückliegt, in der Abhängigkeit, die sechs Ebenen tief in einer Lockfile vergraben ist. Schlanker aufgestellte Engineering-Teams, selbst Opfer derselben Kostenrunde, die diese Systeme erst verwaist hat, erben eine wachsende Prüfungslücke mit immer weniger Händen, sie zu schließen.

Das Problem selbst ist alt, verändert hat sich nur der Preis. Latente Fehler lagen schon immer jahrelang unangetastet, bis ein Forscher sie praktisch nutzbar machte, so wie Dan Kaminsky bekannte DNS-Cache-Poisoning-Schwächen in einen nachweislich praktikablen Angriff über viele Implementierungen hinweg gleichzeitig verwandelte. Was KI mit diesem Entdeckungsprozess macht, ist das, was das Fließband der Fertigung mit der Produktion gemacht hat: Sie industrialisiert ihn.

Streichen Sie die Open-versus-Closed-Debatte, und die Anweisung ist klar. Inventarisieren Sie, was bei Ihnen läuft, einschließlich der Firmware und der Abhängigkeiten, die noch nie jemand gelesen hat. Setzen Sie dieselbe Art von Werkzeug, das ein Angreifer nutzen würde, unter menschlicher Kontrolle auf den eigenen Bestand an, und beheben Sie, was dabei zutage tritt, bevor es jemand anderes einreicht. Die Frage offen versus geschlossen ist eine Grundsatzdebatte, die Sie in Ruhe führen können. Das Audit ist der Teil, der entscheidet, ob Sie danach noch stehen. Bauen Sie das jetzt in Ihre technische Strategie ein, solange die eigenen Fehler zuerst zu finden noch ein Vorteil ist, den man sich sichern kann.

Häufige Fragen

Ist Open Source jetzt unsicherer als Closed Source, weil KI Code scannen kann?

Nicht ohne Weiteres. Angreifer können Schwachstellen weiterhin aus geschlossenen Binaries und Firmware extrahieren, durch Dekompilierung, Fuzzing und Emulation. Den Quellcode zu verbergen erhöht also die Kosten für Angreifer und kauft Zeit, beseitigt die Gefährdung aber nicht. Die eigentliche Gefährdung ist ungeprüfter Code, und Open Source hält diesen Code wenigstens lesbar für die defensiven Werkzeuge und Forscher, die den Fehler zuerst finden könnten.

Wie starte ich ein KI-gestütztes Sicherheitsaudit für meine eigenen Systeme?

Beginnen Sie mit einem Inventar, das Abhängigkeiten und die Firmware angeschlossener Geräte einschließt, denn genau dort konzentrieren sich unangetastete Schwachstellen. Lassen Sie anschließend unter menschlicher Aufsicht adversariale Schwachstellenerkennung gegen den eigenen Bestand laufen, mit Priorität auf aus dem Internet erreichbaren und authentifizierungsnahen Systemen, und behandeln Sie jeden Fund als etwas, das gepatcht wird, bevor es anderswo offengelegt wird. Wo ein System sich wirklich nicht patchen lässt, isolieren und überwachen Sie es stattdessen.

Kann ich der Angabe eines Anbieters vertrauen, wie viele Bugs sein Sicherheitsmodell gefunden hat?

Nicht allein anhand der Schlagzeilenzahl. Viele solcher Angaben sind nicht überprüfbar und lassen sich nicht eindeutig dem Modell statt den steuernden Forschern zuschreiben. Verlangen Sie eine reproduzierbare Methodik, eine Stichprobe der tatsächlichen Funde und einen Nachweis, dass das Modell die Entdeckung gemacht hat, bevor Sie die Fähigkeit bepreisen.