KI hat Sicherheit zur obersten Priorität für Softwareeigentümer gemacht

KI-Modelle können inzwischen Sicherheitslücken im Quellcode finden und dabei helfen, funktionierende Exploits dafür zu schreiben. Angreifer nutzen sie dafür, und die Eigentümer des Codes können das ebenso. Für jeden, der Software besitzt oder entwickelt, ist Sicherheit an die Spitze der Liste gerückt.

Über KI-gestützte Angriffe haben wir Anfang des Monats geschrieben, und wir kommen bewusst auf das Thema zurück. In unserer eigenen Arbeit sehen wir immer wieder, wie leicht es geworden ist, Sicherheitsprobleme im Code zu finden, für uns und für jeden, der ihn angreifen will.

Was sich für Angreifer geändert hat

Im November 2025 berichtete Anthropic über eine Spionagekampagne, bei der Angreifer das Tool Claude Code gegen rund dreißig Organisationen weltweit einsetzten. Anthropic schätzt, dass die KI 80 bis 90 % der Arbeit erledigte und Menschen nur gelegentlich eingriffen. Die KI schickte Tausende von Anfragen, oft mehrere pro Sekunde.

Im Mai 2026 beschrieb die Google Threat Intelligence Group den ersten Zero-Day-Exploit, der ihrer Einschätzung nach mit KI-Hilfe gebaut wurde. Kriminelle Gruppen planten, ihn für die massenhafte Ausnutzung eines verbreiteten Open-Source-Administrationswerkzeugs einzusetzen und dessen Zwei-Faktor-Authentifizierung zu umgehen. Der Fehler lag in der Anwendungslogik: Der Entwickler hatte eine Vertrauensannahme fest im Code verankert.

Angreifer sind zudem schneller als Patches. Der Bericht M-Trends 2026 von Mandiant beziffert die mittlere Zeit bis zur Ausnutzung einer Schwachstelle auf minus sieben Tage, das heißt, die Ausnutzung beginnt oft, bevor ein Fix veröffentlicht ist. Exploits waren im sechsten Jahr in Folge der häufigste Weg in eine Organisation, mit 32 % der von Mandiant untersuchten Einbrüche.

Was sich für Softwareeigentümer geändert hat

Dieselben Modelle finden Schwachstellen auch für die Eigentümer des Codes. Im Januar 2026 behob OpenSSL, die Verschlüsselungsbibliothek hinter einem großen Teil der sicheren Verbindungen im Internet, 12 Schwachstellen. Das Sicherheitsunternehmen AISLE fand alle 12 mit seinem autonomen KI-Analysewerkzeug. Einige der Fehler steckten seit 1998 im Code, in einer Bibliothek, die Sicherheitsspezialisten seit Jahrzehnten untersuchen.

Wir sehen das in unserer eigenen Arbeit. Mitigate entwickelt seit 2011 individuelle Software, und mit aktuellen KI-Modellen finden wir in unserem eigenen Code, ältere Systeme eingeschlossen, Sicherheitsprobleme, deren Aufdeckung früher viel Spezialistenzeit gekostet hätte. Für ein Softwareunternehmen ist das unangenehm auszusprechen. Wir sagen es, weil wir dasselbe bei den meisten Systemen erwarten, die vor diesen Werkzeugen geschrieben wurden, egal von wem. KI macht außerdem einen ersten Prüfdurchlauf so günstig, dass er sich wiederholen lässt, und damit gibt es weniger Gründe zu warten.

Behandeln Sie es als Priorität Nr. 1

Rund um KI gibt es viel Lärm, und es ist verlockend, alles auszublenden. Beim Thema Sicherheit sollten Sie weiter hinhören. Sobald KI den Großteil der Arbeit übernehmen kann, eine Schwachstelle zu finden und auszunutzen, sagt ein System, das zehn Jahre ohne Vorfall gelaufen ist, wenig über seine Sicherheit aus. Es wurde möglicherweise schlicht nie mit den Werkzeugen untersucht, die Angreifer heute einsetzen.

Wir ermutigen jeden Softwareeigentümer und jedes Entwicklungsteam, die Entwicklungen im Bereich Sicherheit zu verfolgen und danach zu handeln:

• Setzen Sie Sicherheit im Plan jedes Systems, das Ihnen gehört, an die erste Stelle, besonders bei älteren Systemen, die über mehrere Teams und Integrationen hinweg gewachsen sind.
• Gehen Sie davon aus, dass es Schwachstellen gibt, die Sie noch nicht gefunden haben, und prüfen Sie diese Annahme mit einer KI-gestützten Prüfung des Quellcodes.
• Lassen Sie erfahrene Entwickler für das Ergebnis verantwortlich bleiben. KI übersieht echte Schwachstellen und meldet welche, die es nicht gibt. Deshalb muss jemand jeden Befund bestätigen, beheben und die Korrektur testen. Eine leere Befundliste beweist nicht, dass ein System sicher ist.
• Entwicklungsteams können dieselbe Prüfung bei neuem Code vor der Auslieferung durchführen, damit weniger Fehler in die Produktion gelangen.
• Orientieren Sie die Prüfung an einem anerkannten Standard, etwa Version 5.0 des OWASP Application Security Verification Standard für Webanwendungen.
• Vereinbaren Sie, wie mit dem Quellcode umgegangen wird, bevor ein Werkzeug Zugriff erhält, und halten Sie Produktivzugangsdaten und Kundendaten aus der Prüfung heraus.

Wenn ein System, auf das Sie angewiesen sind, im letzten Jahr keine Sicherheitsprüfung durchlaufen hat, nehmen Sie eine in diesem Quartal heute in den Plan auf.