Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Haben Sie schon einmal ein LLM gebeten, Code zu generieren, und sich dabei gefragt, ob dieser tatsächlich sicher ist? Da Unternehmen „KI-Einhörner“ einstellen und Tools wie Claude oder Copilot zum Standard werden, ist es leicht, sich Hals über Kopf darauf einzulassen. Doch in diesen Code-Blöcken verbergen sich unbemerkt Schwachstellen. Wenn die Code-Review-Praxis nachlässt, entwickeln sich diese Schwachstellen zu einer Gefahr.
Ich habe beobachtet, wie sich das bei KI-generierten Dockerfiles abspielt: Man fordert eine Standardvorlage an, erhält ein veraltetes Basis-Image und setzt es ein. Wenn man das bei einem Dutzend Diensten so macht, hat man am Ende ein Sicherheitsteam, das in „KI-generierten technischen Schulden“ versinkt, an deren Entstehung sich niemand mehr erinnern kann. Wie ich noch erläutern werde, wurde SecureChain entwickelt, um die daraus resultierenden Probleme bei der Abhängigkeitsverwaltung zu bewältigen.
Der Mythos „KI rettet die Lage“
LLMs gelten als die beste Lösung für einfache Aufgaben wie das Erstellen einer Dockerfile. Für Frontend-Entwickler, die sich bisher kaum mit DevOps beschäftigt haben, ist ein KI-Assistent wie ein Lebensretter, der Container-Konfigurationen in Sekundenschnelle aus dem Ärmel schüttelt. Das dachte ich zumindest, als ich eine Dockerfile brauchte und noch nie zuvor eine geschrieben hatte.
Aber es gibt da ein Problem. Diese helfende Hand rächt sich oft, wenn der neue, glänzende Code, den sie generiert hat, plötzlich Fehler macht, Fehlermeldungen ausgibt oder – noch schlimmer – mit bekannten Sicherheitslücken in die Produktion gelangt.
Stell dir KI-generierten Code wie eine Pizza vor, die du gar nicht bestellt hast. Du hast zwar immer noch Hunger, aber bevor du sie essen kannst, musst du sicherstellen, dass keine Sardellen drauf sind … es sei denn, du stehst auf Sardellen. In diesem Szenario kannst du diese lästigen winzigen Fische mit betroffenen Node-Versionen vergleichen, die du NICHT einbinden möchtest. Überprüfe, was drauf ist, bevor du einen Bissen nimmst.
Die Anatomie eines KI-Fehlers
Hier werden zwei Probleme in einen Topf geworfen. KI kann einerseits direkt unsicheren Code schreiben, andererseits kann sie veraltete Abhängigkeiten empfehlen, deren Verwendung zwar nie falsch war, deren weitere Nutzung jedoch falsch ist. In diesem Artikel geht es hauptsächlich um den zweiten Punkt, da dieser leichter übersehen wird.
Es kann so kurz aussehen: node:18-alpine. Eine Zeile, gültige Syntax, lässt sich ohne Fehler kompilieren. Dahinter verbergen sich jedoch drei systemische Fehler:
- Veraltete Bilder: Der Assistent schlägt eine Basisbildversion vor, die zu einem bestimmten Zeitpunkt in den Trainingsdaten eine sinnvolle Standardeinstellung war. Möglicherweise stützt er sich auf dieses veraltete Bild oder auf unvollständige Informationen darüber, was Ihr Projekt tatsächlich unterstützt.
- Eingebaute Sicherheitslücken: Eine EOL-Laufzeitumgebung macht alte Sicherheitslücken dauerhaft, da keine Korrekturen mehr vom Upstream-Entwickler bereitgestellt werden. Node.js 18 hat am 30. April 2025 das Ende der Lebensdauer (EOL) erreicht.und Docker Hub zeigt an
18-alpinewurde zuletzt vor über einem Jahr veröffentlicht. Was auch immer in dieser endgültigen Version enthalten war, das bekommst du. - Blindes Vertrauen: Entwickler gehen davon aus, dass „die KI darin gut sein sollte“, und verzichten auf eine Überprüfung, da das Ergebnis vertraut wirkt und der Build erfolgreich ist.
Nichts zerstört die Illusion. docker pull node:18-alpine funktioniert genau wie im Jahr 2024. Der Container wird gestartet. Niemand aus dem Upstream-Bereich bringt Patches ein.
Die Forschungsergebnisse weisen in dieselbe Richtung. Der „2026 GenAI Code Security Report“ von Veracode beziffert die durchschnittliche Sicherheitserfolgsquote bei mehr als 100 Modellen über einen Zeitraum von vier Jahren auf 56 % – ein Wert, der unverändert blieb, obwohl die Syntaxkorrektheit auf über 95 % stieg. Dabei handelt es sich um 80 Programmieraufgaben ohne Sicherheitsvorgaben in der Eingabeaufforderung; es ist also eine Basislinie für ungeleitete Ergebnisse und keine Fehlerquote für alle ausgelieferten Produkte.
KI-Tools sind großartig, verstehen Sie mich nicht falsch. Sie sind zweifellos schnell, aber sie sind nicht perfekt und erfordern nach wie vor den Einsatz von Menschen und geeigneten Werkzeugen, um Probleme zu erkennen, bevor sie die Codebasis beeinträchtigen.
Warum die Disziplin bei Prüfungen zusammenbricht
Das Generieren von Code ist mittlerweile so einfach, dass wir ihn oft gar nicht mehr als „zu überprüfenden Code“ betrachten. Das Ergebnis wirkt wie Wegwerfware: abfragen, einfügen, ausführen, weitermachen. Je schneller dieser Kreislauf wird, desto leichter wird die Überprüfung zu dem langsamen Schritt, den jeder stillschweigend umgeht.
In der Praxis sieht der Verlust der Disziplin in der Regel folgendermaßen aus:
- Bedingungsloses Vertrauen in die KI bei Routineaufgaben
- Verwendung von Laufzeitversionen wie Node 18, deren Lebensdauer bereits abgelaufen ist
- Die AI-Ausgabe nicht mit Sicherheitstools wie Docker Scout oder Snyk abgleichen
- Ignorieren von IDE-Warnungen, die auf Schwachstellen oder riskante Abhängigkeiten im generierten Code hinweisen
- Infrastrukturdateien bei der Überprüfung nur flüchtig überfliegen, weil es sich dabei nicht um „echten“ Anwendungscode handelt
- Vorrang für die Geschwindigkeit nach dem Motto „KI rettet den Tag“ vor produktionsreifer Sicherheit
Den fünften Punkt unterschätzt man leicht. Man ist schnell versucht, jede Zeile einer React-Komponente durchzulesen und dabei an der darunter liegenden neunzeiligen Dockerfile-Datei vorbeizuscrollen. Diese Datei ist keine Konfiguration. Sie ist das Fundament.
Es ist von entscheidender Bedeutung, die verschiedenen Arten von Fehlern zu verstehen, die hinter KI-generiertem Code stehen:
Von „Hallucinated Hygiene“ spricht man, wenn eine KI eine Konfiguration vorschlägt, die zwar standardmäßig aussieht, aber aus einer veralteten oder nicht mehr unterstützten Quelle stammt. Die Formatierung entspricht dem Lehrbuch. Die Versionsnummer ist veraltet.
„Severity-Blindheit“ tritt auf, wenn Entwickler KI-generierten Code als „gelöstes“ Problem betrachten, anstatt ihn als Komponenten zu betrachten, die noch auf Schwachstellen überprüft werden müssen. Ein grüner Build ist noch lange kein fehlerfreier Build.
Kontext: Ein Fehler bedeutet, dass die KI möglicherweise nicht weiß, welche Versionen das Ende ihrer Lebensdauer erreicht haben, welche aktive CVEs aufweisen oder wie Ihre Versionsrichtlinie lautet, es sei denn, Sie teilen ihr dies mit.
Code ist niemals sicher, nur weil er von einem LLM geschrieben wurde. Behandeln Sie ihn wie Code aus einer nicht vertrauenswürdigen Quelle: Überprüfen Sie ihn, scannen Sie ihn auf Schadcode und bekannte Schwachstellen und vergleichen Sie die Abhängigkeiten mit den aktuellen Upstream-Informationen.
So sieht eine durch KI generierte Code-Sicherheitslücke aus
Wenn Sie eine KI-generierte Dockerfile-Datei in Visual Studio Code öffnen, in dem eine Scan-Erweiterung installiert ist – beispielsweise Docker DX (das Docker-Scout-Ergebnisse direkt im Text anzeigt) oder Snyk –, wird möglicherweise sofort eine Warnung angezeigt. Das LLM hat Ihnen eine veraltete Node-Version zugewiesen, ohne dass Sie diese jemals ausgewählt haben. Der Wortlaut variiert je nach Tool, aber so sieht die Warnung in einer typischen Next.js-Konfiguration aus:
# Use the official Node.js runtime as the base image
FROM node:18-alpine AS builder
# Illustrative scanner warning:
# Image references an End-of-Life Node.js runtime (18.x, EOL 2025-04-30)
# and may include known vulnerabilities.
# Move to a supported LTS line, then rebuild, rescan, and test.Übersetzung: Die KI hat Ihnen „node:18“ zugewiesen, das nicht nur veraltet ist. Das Node.js-Projekt stellt für diese Version keine Sicherheitsupdates mehr bereit, und das veröffentlichte Image wurde seit über einem Jahr nicht mehr neu erstellt. Ihr Build funktioniert zwar einwandfrei, doch die zugrunde liegende Basis wird nicht mehr unterstützt. Das ist das Risiko in der Software-Lieferkette, das durchrutscht, wenn „es lässt sich kompilieren“ zum Ziel wird.
AI Dockerfile generation
|-- Base image suggestion (node:18-alpine)
|-- EOL runtime, no upstream security releases
|-- Image last rebuilt over a year agoDie menschliche Note in Ihren Begutachtungsprozess zurückbringen
Sie können die Nutzung von KI natürlich einfach einstellen, wenn Sie möchten, aber soweit ich das beurteilen kann, nimmt die Nutzung von Tag zu Tag zu. Sie können jedoch Ihren Überprüfungsprozess anpassen, damit die Geschwindigkeit nicht unbemerkt an die Stelle der Überprüfung tritt.
Option 1: Manuelle Überprüfung und Korrekturen
Die „Quick Fix“-Funktionen in modernen IDEs können oft einen veralteten Vorschlag durch einen unterstützten ersetzen. Bevor Sie KI-Code committen:
- Schauen Sie sich den Veröffentlichungsplan des Upstream-Projekts an und nicht nur die Registry, die Ihnen gerne ein Tag bereitstellt, das die Betreuer nicht mehr unterstützen.
- Lesen Sie die Änderungsprotokolle oder Migrationshinweise zwischen dem Vorschlag der KI und Ihrer Zielversion.
- Führen Sie nach der Änderung einen Neuaufbau und einen erneuten Scan durch, da das Austauschen des Tags allein noch nicht beweist, dass das Image sauber ist.
- Teste den Build zunächst in einem neuen Branch, NIEMALS direkt im Main-Branch.
- Machen Sie sich bewusst, dass „schnell vorankommen“ nicht bedeutet, dass Sie die Überprüfung überspringen können.
Option 2. Aktualisieren der Eingabeaufforderung oder der Konfiguration
Geben Sie dem Modell weniger Spielraum zum Raten. Wenn Ihr Team über eine festgelegte Laufzeitrichtlinie verfügt, fügen Sie diese in die Eingabeaufforderung oder in die Anweisungen Ihres Repositorys ein, damit sie jedes Mal angewendet wird, anstatt denselben Vorschlag immer wieder korrigieren zu müssen:
# Use a supported Node.js LTS base image
FROM node:24-alpine AS baseEs ist entscheidend, in welche Linie Sie wechseln. Node 24 ist die aktive LTS-Linie, die am 20. Oktober 2026 in den Wartungsmodus übergeht und am 30. April 2028 das EOL erreicht. Node 22 befindet sich bereits im LTS-Wartungsmodus; das EOL-Datum ist mit dem 30. April 2027 angegeben. Knoten 20 hat im April 2026 das EOL erreicht. Ein Mitarbeiter kann alle drei Optionen mit derselben Überzeugung empfehlen – überprüfen Sie den Zeitplan daher bitte selbst.
Machen Sie deutlich, was node:24-alpine Das ist allerdings der Haken. Es handelt sich um eine dynamische Hauptversionsangabe, nicht um eine feste Festlegung. Docker Hub zeigt „Node 24 Alpine“-Images an, die im letzten Monat aktualisiert wurden – genau das, was man für die Übernahme von Patches benötigt, aber nicht für reproduzierbare Builds. Wenn Reproduzierbarkeit wichtig ist, sollten Sie die Kombination aus vollständiger Version und Alpine festlegen oder auf einen unveränderlichen Digest verweisen und selbst dafür sorgen, dass diese Festlegung regelmäßig aktualisiert wird.
Ein sauberer Neuaufbau zeigt Ihnen, dass die Ersetzungs-Builds erstellt wurden und die Warnung verschwunden ist. Er sagt Ihnen jedoch nicht, dass das Image frei von Sicherheitslücken ist oder dass die App weiterhin einwandfrei funktioniert. Es folgen weiterhin Scans und Tests. KI ist großartig, was die Geschwindigkeit angeht, aber Sie brauchen immer noch den menschlichen Touch, um diese „heimtückischen“ Dinge aufzuspüren.
Wo Sie den Aufwand investieren, ist eine Ermessensentscheidung. Standardcode für ein internes Tool erfordert eine Überprüfung der Tags und einen Scan. Alles, was mit dem Produktionsdatenverkehr, der Authentifizierung, geheimen Daten oder Ihrem Abhängigkeitsbaum zu tun hat, wird in einem isolierten Zweig einer vollständigen Überprüfung unterzogen.
Überprüfen Sie stets das Ergebnis. Betrachten Sie KI-Vorschläge als Entwürfe und nicht als endgültige Pläne. Das Unterdrücken der Warnmeldungen von Sicherheitstools beseitigt nicht die zugrunde liegenden technischen Schulden.
Sicherheit skalieren mit SecureChain
Die Bewältigung von Abhängigkeitsrisiken bei Dutzenden von Diensten kann jedes Sicherheitsteam überfordern, insbesondere wenn KI schneller Optionen generiert, als diese manuell überprüft werden können. Hier fungiert SecureChain als „Schutzschild“ für Ihren Abhängigkeitsbaum.
Basisbilder sind nur eine Oberfläche. Derselbe Assistent, der ausgewählt hat node:18-alpine hast du auch ausgefüllt package.json, aus demselben veralteten Bild. SecureChain deckt diese zweite Ebene ab und ersetzt das öffentliche Register als Quelle, aus der Ihre Builds bezogen werden. Dieser Schutz wirkt sich an zwei Stellen aus:
- Schutz vor dem Ende des Lebenszyklus (Pre-EOL): Jedes Paket wird in abgesicherten, isolierten Umgebungen aus dem Quellcode neu kompiliert und auf bekannte Malware, verdächtige Codemuster sowie Risiken in der Lieferkette überprüft. Anschließend wird es im Rahmen des SLA gepatcht, sobald CVEs bekannt werden – einschließlich transitiver Abhängigkeiten.
- Schutz nach Ablauf der EOL: Wenn die Wartung durch den Hersteller endet, sorgt der „Endless Lifecycle Support“ (ELS) weiterhin für Fehlerbehebungen, die genau auf die von Ihnen bereits verwendeten Versionen zurückportiert werden. Keine erzwungenen Upgrades, keine Neuprogrammierung.
Richten Sie Ihren Repository-Manager oder direkt Ihren Paketmanager auf SecureChain aus und arbeiten Sie einfach weiter. Gleiche Pakete, gleiche APIs, gleicher Arbeitsablauf. Jedes Paket enthält eine Herkunftsangabe nach SLSA Level 3, eine SBOM sowie VEX-Daten – nützliche Nachweise, wenn jemand fragt, woher eine von der KI vorgeschlagene Abhängigkeit stammt.
Nichts davon ersetzt die Code-Review. Das bedeutet, dass die Sicherheit der Abhängigkeiten nicht davon abhängt, dass ein Assistent bei jeder Versionsauswahl die richtige Entscheidung trifft.
Das Fazit
Geraten Sie nicht in Panik, wenn das LLM Code schneller schreiben kann, als Sie ihn überprüfen können. Passen Sie einfach den Prozess an. Vorschläge sollten auch genau als das betrachtet werden: als Vorschläge. Nutzen Sie Ihren Code-Editor oder Ihre IDE, Ihre Scanner und die anderen Ihnen zur Verfügung stehenden Tools, um Schwachstellen aufzuspüren, bevor sie überhaupt in der Produktion auftauchen.
Die Veröffentlichungstermine verschieben sich ständig, unabhängig davon, ob das Modell dies bemerkt oder nicht, und genau in dieser Lücke lauern die Schwachstellen des KI-generierten Codes. Stellen Sie stets sicher, dass ein Mensch involviert ist, um eine sichere und reibungslose Markteinführung zu gewährleisten.
