Sicherheitslücken in Software entstehen nicht nach Terminplan. Der Chief Security Officer der Deutschen Telekom hat sich zu diesem Thema geäußert und dabei verbreitete Vorstellungen über künstliche Intelligenz zurechtgerückt. Sein Kernpunkt: Code-Analyse mit KI-Modellen ist kein gelegentlicher Sonderlauf, sondern eine Aufgabe, die rund um die Uhr laufen muss. Ein besonderes Risiko sieht er bei Open Source.
Der Hintergrund ist für Betreiber von Webanwendungen und Content-Management-Systemen unmittelbar relevant. Zero-Day-Lücken sind Schwachstellen, für die zum Zeitpunkt ihrer Ausnutzung noch kein Patch existiert. Wer erst reagiert, wenn ein Hersteller ein Update veröffentlicht, arbeitet in diesem Fenster per Definition zu spät.
Warum Dauerbetrieb und nicht Stichprobe
Klassische Sicherheitsprüfungen folgen oft einem Projektrhythmus: ein Penetrationstest vor dem Launch, ein Audit vor dem Relaunch, dazwischen wenig. Dieses Muster passt nicht mehr zu Anwendungen, die kontinuierlich weiterentwickelt werden und deren Abhängigkeiten sich wöchentlich ändern.
Die Argumentation aus dem Telekom-Umfeld läuft darauf hinaus, Analysekapazität dauerhaft bereitzustellen statt punktuell. Praktisch heißt das: Prüfungen laufen bei jedem Commit, bei jedem Build und bei jeder Aktualisierung einer externen Bibliothek – nicht einmal pro Quartal.
Für mittelständische Organisationen ist das zunächst eine unangenehme Nachricht, weil es nach zusätzlichem Aufwand klingt. Tatsächlich verschiebt sich der Aufwand eher, als dass er wächst: weg von aufwendigen Einzelprüfungen, hin zu automatisierten Schritten in der Build-Kette, also in dem Prozess, der aus Quellcode ein lauffähiges System macht.
Open Source als besonderer Problembereich
Dass der Sicherheitsverantwortliche ausgerechnet Open Source hervorhebt, ist kein Argument gegen quelloffene Software. Es ist ein Hinweis auf eine strukturelle Eigenschaft moderner Projekte: Der Großteil des ausgelieferten Codes stammt meist nicht aus dem eigenen Haus, sondern aus Paketen, Frameworks und Bibliotheken Dritter.
In einem typischen Webprojekt sind das schnell hunderte Abhängigkeiten, von denen viele wiederum eigene Abhängigkeiten mitbringen. Diese transitive Tiefe ist der eigentliche Punkt: Ein Team kann den selbst geschriebenen Anteil sehr genau kennen und trotzdem nicht sagen, was drei Ebenen tiefer eingebunden ist.
Hinzu kommt die Beobachtbarkeit. Öffentlich einsehbarer Code ist für Verteidiger und Angreifer gleichermaßen lesbar. Wer automatisiert nach Mustern sucht, kann das über sehr viele Projekte gleichzeitig tun – was die Analyse auf beiden Seiten skalierbar macht.
Was KI-Modelle in der Code-Analyse leisten können
Statische Code-Analyse gibt es seit Jahrzehnten. Ihr bekanntes Problem sind Fehlalarme: Werkzeuge melden mehr Auffälligkeiten, als ein Team sinnvoll abarbeiten kann, und irgendwann werden die Meldungen ignoriert.
Der Mehrwert von Modellen liegt vor allem darin, Kontext einzubeziehen – etwa ob eine potenziell gefährliche Funktion überhaupt mit Nutzereingaben in Berührung kommt. Das verändert weniger die Erkennung als die Priorisierung. Entscheidend ist nicht, möglichst viele Befunde zu erzeugen, sondern die wenigen wirklich ausnutzbaren nach oben zu sortieren.
Gleichzeitig gilt die Einschränkung, die auch hinter dem Aufräumen mit KI-Mythen steht: Modelle ersetzen keine Sicherheitsarchitektur. Sie finden keine Fehler in Geschäftslogik, die nirgends als Regel hinterlegt ist, und sie entscheiden nicht, welches Risiko ein Unternehmen tragen will.
Übertragung auf CMS- und TYPO3-Projekte
Ein TYPO3-Projekt besteht aus dem Core, aus Extensions unterschiedlicher Herkunft und aus individuell entwickeltem Code. Genau diese Mischung macht die beschriebene Problemlage konkret: Die Angriffsfläche verändert sich mit jeder eingebundenen Erweiterung, auch ohne eigene Entwicklungsarbeit.
Sinnvolle Schritte lassen sich ohne großen Apparat umsetzen:
- Ein aktuelles Verzeichnis aller eingesetzten Komponenten samt Versionsstand führen, auch für transitive Abhängigkeiten.
- Abhängigkeitsprüfungen automatisiert in die Build-Kette einhängen, statt sie manuell anzustoßen.
- Vorab festlegen, wer Befunde bewertet und innerhalb welcher Frist kritische Meldungen behandelt werden.
- Updatefähigkeit als Projektziel behandeln: Wer Core oder Extensions stark überschreibt, verlängert seine Reaktionszeit bei jedem Patch.
- Extensions nach Pflegezustand auswählen – ein ungepflegtes Paket ist ein dauerhaftes Risiko, unabhängig von seinem Funktionsumfang.
Organisation schlägt Werkzeug
Der naheliegende Fehlschluss lautet, man müsse nur ein weiteres Analysewerkzeug einkaufen. Tatsächlich entsteht der Nutzen erst dort, wo Befunde verlässlich bearbeitet werden. Eine Meldung um drei Uhr nachts hilft wenig, wenn erst drei Wochen später jemand zuständig ist.
Deshalb gehören zur Rund-um-die-Uhr-Analyse zwingend Zuständigkeiten, Eskalationswege und eine realistische Einschätzung, wie schnell ein Update eingespielt werden kann. Dieser Teil lässt sich nicht automatisieren, prägt aber die tatsächliche Sicherheitslage stärker als die Wahl des Scanners.
Für Web- und Softwareprojekte heißt das: Sicherheit verschiebt sich endgültig vom Projektabschluss in den laufenden Betrieb und sollte im Budget entsprechend abgebildet sein. Wer Abhängigkeiten dokumentiert, Updatefähigkeit erhält und automatisierte Prüfungen mit klaren Zuständigkeiten verbindet, reduziert das Zeitfenster zwischen Bekanntwerden und Schließen einer Lücke spürbar. KI-gestützte Analyse hilft dabei vor allem bei der Priorisierung – die Entscheidung, wie schnell reagiert wird, bleibt eine organisatorische.
