2026-04-12•Yevhen Kim

techaisecurity

Im Zeitalter von AI muss Sicherheit über den gesamten Weg von der Idee bis zum Release eingebaut werden

Noch vor Kurzem bedeutete AI in der Entwicklung vor allem eines: Geschwindigkeit. Eine Funktion schneller schreiben. Eine Testversion schneller bauen. Eine Aufgabe schneller abschließen.

Das reicht nicht mehr.

Was heute zählt, ist eine andere Frage: Wie sicher ist das, was dabei entsteht — und wie gut geschützt ist der gesamte Weg, den Code, Bibliotheken und externe Komponenten nehmen, bevor sie im Produkt landen.

Das Problem ist längst nicht mehr theoretisch

Das Risiko ist real.

Veracode hat Codebeispiele getestet, die mit AI-Hilfe entstanden sind, und festgestellt: 45 % bestanden die Sicherheitsprüfungen nicht und enthielten gefährliche Schwachstellen. Noch beunruhigender: Neuere und größere Modelle verbesserten diese Zahl nicht. (veracode.com)

Das stellt die Frage anders.

Code, der mit AI-Hilfe entstand, lässt sich nicht mehr nur nach zwei Kriterien beurteilen: Funktioniert er — und wie schnell wurde er geschrieben? Es gibt ein drittes:

Bringt er ein Risiko ins System, das das Team zu spät erkennt.

Warum „bessere AI” das nicht löst

Die Versuchung ist verständlich: Die nächste Modellgeneration wird klüger sein und automatisch sicherer schreiben. In der Praxis funktioniert das nicht so.

AI beurteilt Systeme nicht wie ein erfahrener Ingenieur. Sie trägt keine Verantwortung für das Produkt, spürt nicht, was ein Fehler im Betrieb kostet, und haftet nicht für die Folgen. Sie liefert die statistisch wahrscheinlichste Variante — nicht die vorsichtigste.

Bessere Modelle bedeuten also noch keine höhere Sicherheit. Die Daten von Veracode belegen das direkt. (veracode.com)

AI kann das Schreiben von Code beschleunigen. Sie hebt aber nicht die Notwendigkeit von Skepsis, Prüfung und Sicherheitsdisziplin auf.

Warum die Sicherheitsfrage über den Code hinausgeht

In einem echten Produkt besteht eine Änderung fast nie nur aus neuem Code. Mit ihr kommen Bibliotheken, externe Abhängigkeiten, Skripte, Build-Werkzeuge, automatisierte Prüfungen, Container, Fremddienste — alles, was der Code passiert, bevor er in Produktion geht.

Die Frage ist also nicht nur, ob der Code sicher ist. Sondern ob der gesamte Auslieferungsweg es ist.

OWASP macht das explizit: Software durchläuft eine ganze Kette aus Erstellung, Build, Test und Auslieferung, und Fehler können überall auf diesem Weg entstehen, nicht nur im Code selbst. (owasp.org) (owasp.org)

Für AI macht das drei Dinge besonders relevant.

1. AI bringt Änderungen schneller ins Projekt

Wer schneller schreibt, holt Bibliotheken und Fremdkomponenten schneller ins Projekt. Und alles, was darin steckt. Wer dabei nicht mitbekommt, was da wirklich landet, verliert schnell den Überblick.

2. Sieht fertig aus. Ist es nicht.

Ein schneller Blick auf den Code sagt kaum etwas. Die Datenverarbeitung kann schlampig sein, Berechtigungen zu weit gefasst, die Validierungslogik nur für den Normalfall ausgelegt. Das fällt im Diff nicht auf. Wird genehmigt.

3. Auch die AI-Schicht selbst gehört zur Risikozone

Sobald ein Team AI in die Entwicklung einbaut, weitet sich die Risikozone über den Code hinaus aus. Dazu gehören Modelle, Plugins, Agenten, automatisierte Prüfungen, externe Integrationen — der gesamte Prozess, über den AI beeinflusst, was ausgeliefert wird.

Das Risiko liegt nicht nur darin, was AI geschrieben hat. Sondern darin, wie AI in den Weg von der Idee zum Release eingebaut ist.

Ein „kluger Kommentar” reicht nicht

2025 hat GitHub explizit geschrieben, dass Copilot Code Review jetzt LLM-Analyse, externe Tool-Aufrufe und regelbasierte Prüfungen über ESLint und CodeQL kombiniert. (github.blog)

Das ist kein Zufall. Einer der wichtigsten Akteure in diesem Bereich setzt nicht darauf, dass AI den Code liest und das reicht.

Das heißt: statische Analyse, Abhängigkeitsprüfungen und jemand, der den Diff vor der Genehmigung wirklich liest.

Ein AI-Kommentar reicht nicht aus, auch wenn er überzeugend klingt.

Was das für Websites und Webanwendungen bedeutet

Jedes Ergebnis, das AI geliefert hat, muss denselben vollständigen Sicherheitsweg durchlaufen wie Code, den ein Mensch geschrieben hat.

Nicht vereinfacht. Nicht „das ist ja nur ein Entwurf”. Nicht „das prüfen wir später”. Denselben Weg.

Das bedeutet mindestens Folgendes.

Sicherheit muss von Anfang an eingebaut sein

Sicherheit, die erst am Ende dazukommt, ist keine Sicherheit — sie ist eine Prüfung, die regelmäßig übersprungen wird. OWASP ist klar: Sicherheit muss durch den gesamten Entwicklungsprozess laufen, von Design bis Release. (owasp.org)

Für AI-Code ist das direkt: Wenn Sicherheit nicht im Prozess steckt, bringt die Geschwindigkeit von AI Risiken nur schneller in Produktion.

Automatische Prüfungen sind keine Option

Statische Analyse, Linter, Abhängigkeitsprüfungen und technische Filter sind keine Extras — sie sind der Mindeststandard. Deshalb baut GitHub Code Review um Werkzeuge wie CodeQL und ESLint, statt auf AI allein zu setzen. (github.blog)

Externe Komponenten müssen geprüft werden

Abhängigkeiten sind eine der wichtigsten Angriffsflächen bei Webanwendungen. OWASP empfiehlt: Komponentenverzeichnis pflegen, Regeln für Abhängigkeiten setzen, Herkunft von Artefakten prüfen, Build-Prozess kontrollieren. (owasp.org)

Menschliche Prüfung bleibt notwendig

AI kann auffällige Stellen markieren. Aber die fachliche Einschätzung kann nicht an eine Maschine abgegeben werden — besonders nicht bei Zugriffsrechten, Eingabeverarbeitung, externen Integrationen, Nutzerdaten oder Verhalten in Ausnahmesituationen.

Der gefährlichste Fehler: Sicherheit als etwas behandeln, das später dazukommt

In 2026 ist das keine Naivität mehr. Es ist eine schlechte Wette.

DORA beschreibt AI in seinem Bericht als Verstärker: Sie stärkt starke Systeme und macht die Schwachstellen schwacher sichtbarer. Die Teams, die wirklich profitieren, sind nicht die, die AI am schnellsten eingeführt haben — sondern die, die sie in ein Engineering-System mit Prüfungen, Tests und Verantwortlichkeit eingebettet haben. (dora.dev)

AI senkt die Anforderungen an Sicherheit nicht. Sie erhöht den Preis dafür, sie zu ignorieren.

Was Reife in 2026 bedeutet

Code, der mit AI-Hilfe entstand, gilt nicht standardmäßig als sicher. Er bekommt dieselbe kritische Prüfung wie jeder andere Code — vielleicht mehr.

Kein AI-Ergebnis umgeht die üblichen Prüfschritte: Sicherheit im Prozess, automatische Analyse, Abhängigkeitsprüfungen, Tests, menschliche Prüfung.

Risiken werden breit betrachtet — nicht nur im Code, sondern auch in Bibliotheken, Werkzeugen, Automatisierung, externen Integrationen und der AI-Schicht selbst.

Geschwindigkeit und Sicherheit werden getrennt bewertet. Wenn AI eine Änderung beschleunigt hat, heißt das nicht, dass sie sicherer geworden ist.

Sicherheit ist Teil des Auslieferungssystems, keine Abschlusskontrolle kurz vor dem Release.

Fazit

AI hat nicht nur die Produktivität beschleunigt — sie hat auch die Rate beschleunigt, mit der schwache Entscheidungen, gefährliche Muster und riskante Abhängigkeiten ins Produkt gelangen. Codesicherheit und Supply-Chain-Sicherheit können deshalb nicht am Rand des Entwicklungsprozesses bleiben.

In 2026 das als Problem anderer zu behandeln — des Security-Teams, der nächsten Modellgeneration, des nächsten Sprints — ist nur eine andere Form, es nicht anzugehen.

Es ist eine Grundbedingung, um auf diesem Niveau zu arbeiten.

Quellen

Geschrieben vonYevhen Kim

Weiterlesen

Alle Journal-Einträge ansehen

Wenn dieser Artikel hilfreich war, gibt es im Journal weitere Notizen zu Architektur, AI-Workflows, Delivery und Engineering-Praxis.

2026-04-16•pinned