KI und Code
KI-generierter Code: die Sicherheitsrisiken und wie Sie ihn prüfen
Sicherheit von KI-generiertem Code heißt, Code von Assistenten und Coding-Agenten so zu behandeln wie Code von jemandem, den Sie nie getroffen haben: jede hinzugefügte Abhängigkeit prüfen, den Code auf Secrets und Injection-Lücken scannen und ihn von einer Person prüfen lassen, bevor er gemergt wird. Neu durch KI sind Pakete, die veraltet oder schädlich sind oder gar nicht existieren.
Free-Tarif, keine Kreditkarte erforderlich.
Welche Sicherheitsrisiken hat KI-generierter Code?
Coding-Assistenten und -Agenten schreiben Code, indem sie auf Basis von bestehendem Code vorhersagen, was üblicherweise als Nächstes kommt. Das macht sie schnell, und es bedeutet auch, dass sie wiederholen, was in diesem Code verbreitet war, einschließlich alter Bibliotheksversionen, veralteter APIs und unsicherer Gewohnheiten. Ein Modell weiß nicht, welches Release eines Pakets im letzten Monat gepatcht wurde, sofern es das nicht nachschlägt, und ein Agent, der Befehle ausführen darf, installiert womöglich, was er vorschlägt, bevor jemand die Änderung gelesen hat.
Keines dieser Risiken ist für sich genommen neu. Was sich ändert, sind Menge und Tempo: mehr Code, mehr neue Abhängigkeiten und weniger Menschen, die jede Zeile lesen. Die Antwort besteht darin, die Prüfungen, die Sie bei jedem externen Beitrag anwenden würden, automatisch auszuführen, damit sie bei einem großen Diff nicht übersprungen werden.
- Veraltete oder bekanntermaßen verwundbare Abhängigkeitsversionen, die das Modell aus seinen Trainingsdaten vorschlägt.
- Paketnamen, die es nicht gibt oder die ein Angreifer registriert hat, weil Modelle dazu neigen, sie zu erfinden.
- Neu veröffentlichte schädliche Pakete, auch mit Namen, die beliebten Bibliotheken zum Verwechseln ähnlich sind.
- In Code oder Konfiguration eingefügte Secrets: API-Schlüssel, Tokens, Verbindungszeichenfolgen.
- Unsichere Muster wie aus Strings zusammengesetzte SQL-Abfragen oder Shell-Befehle, deaktivierte Zertifikatsprüfungen oder schwache Kryptografie.
- Agenten mit weitreichenden Berechtigungen, die ohne Review Pakete installieren, Skripte ausführen oder Änderungen pushen.
Was ist Slopsquatting?
„Slopsquatting“ bezeichnet das Registrieren eines Pakets unter einem Namen, den KI-Modelle gern erfinden, sodass jeder, der den erfundenen Namen installiert, den Code des Angreifers erhält. Das Wort verbindet „Slop“, Slang für minderwertige maschinell erzeugte Inhalte, mit Typosquatting, bei dem Angreifer Tippfehler-Varianten beliebter Pakete registrieren. Es funktioniert, weil öffentliche Registries wie npm und PyPI jedem erlauben, unter einem noch nicht vergebenen Namen zu veröffentlichen.
Eine begutachtete Studie, vorgestellt auf der USENIX Security 2025, testete 16 codegenerierende Modelle und erzeugte 576.000 Codebeispiele. Die Autoren berichten, dass der durchschnittliche Anteil halluzinierter Pakete bei kommerziellen Modellen mindestens 5,2 % und bei Open-Source-Modellen 21,7 % betrug, und sie sammelten 205.474 eindeutige erfundene Paketnamen. Wurde derselbe Prompt zehnmal wiederholt, tauchte ein erfundener Name in 58 % der Fälle mehr als einmal auf; genau das macht solche Namen vorhersehbar genug, um sie zu registrieren.
Das Projekt OpenSSF Malicious Packages veröffentlicht Meldungen zu schädlichen Paketen aus Open-Source-Registries im OSV-Format, mit Kennungen, die mit MAL- beginnen. Ein Abgleich der Abhängigkeiten damit erkennt Pakete, die bereits gemeldet wurden. Ein gestern registriertes Paket, das noch niemand analysiert hat, erkennt er nicht; er ergänzt also die Prüfung, ob ein Paket existiert, wer es veröffentlicht und wie lange es schon verfügbar ist. Diese Prüfung in dem Moment, in dem ein Agent ein Paket vorschlägt, steht auf der Roadmap von KROMSE.
Wie Sie KI-geschriebenen Code vor dem Merge prüfen
Ziel ist eine Routine, die gleich abläuft, ob nun eine Person oder ein Agent die Änderung geschrieben hat. Das meiste davon kann in der Pipeline laufen, die bereits Ihre Tests ausführt; der menschliche Teil besteht darin, den Diff mit der Skepsis zu lesen, die Sie dem Pull Request eines Fremden entgegenbringen würden. Die OpenSSF veröffentlicht einen Leitfaden für sicherheitsorientierte Anweisungen an Code-Assistenten, ein nützlicher Ausgangspunkt für die Prompts selbst.
- Lockfiles committen und in der CI daraus installieren, damit die geprüften Versionen auch die ausgelieferten sind.
- Für neue Abhängigkeiten exakte Versionen festlegen und jede Änderung am Lockfile prüfen, nicht nur am Manifest.
- Bestätigen, dass jedes neue Paket existiert, das gemeinte ist und einen Herausgeber und eine Historie hat, die Sie überprüfen können.
- Eine Allowlist freigegebener Pakete führen oder über einen internen Registry-Proxy installieren, der alles andere blockiert.
- Quellcodeanalyse, Secret-Scans und Abhängigkeitsprüfungen bei jeder Änderung ausführen und Merges bei neuen kritischen Befunden blockieren.
- Für KI-geschriebene Änderungen eine namentlich benannte prüfende Person verlangen und Agenten nicht eigenständig mergen oder deployen lassen.
Ändert KI-geschriebener Code Ihre Pflichten aus dem Cyber Resilience Act?
Die Cyberresilienz-Verordnung (Cyber Resilience Act, CRA) legt ihre Pflichten dem Hersteller eines Produkts mit digitalen Elementen auf. Ihr Erwägungsgrund 34 stellt klar, dass die Pflichten zur Behandlung von Schwachstellen für das Produkt als Ganzes gelten, einschließlich aller integrierten Komponenten. Artikel 13 Absatz 5 verlangt die gebotene Sorgfalt bei der Integration von Komponenten Dritter, auch quelloffener, und Anhang I Teil II verlangt von Herstellern, Komponenten zu ermitteln und zu dokumentieren, unter anderem mit einer Software-Stückliste (SBOM), und die Sicherheit des Produkts wirksam und regelmäßig zu testen und zu überprüfen.
In der Praxis ist eine Abhängigkeit, die ein Agent hinzugefügt hat, eine Komponente Dritter wie jede andere, und eine Schwachstelle, die sie mitbringt, müssen Sie während des Unterstützungszeitraums behandeln. Die Meldepflichten nach Artikel 14 gelten seit dem 11. September 2026; die meisten übrigen Pflichten gelten ab dem 11. Dezember 2027.
Was automatisierte Prüfungen finden und was ihnen entgeht
Schwachstellendatenbanken kennen Schwachstellen, die gemeldet wurden, und eine Datenbank für schädliche Pakete kennt Pakete, die jemand analysiert hat. Quellcodeanalyse findet bekannte riskante Muster, etwa eine aus Benutzereingaben zusammengesetzte Abfrage, aber keine fehlerhafte Geschäftsregel und keine fehlende Berechtigungsprüfung, die wie gewöhnlicher Code aussieht. Ein Secret-Scan des aktuellen Codes sieht keinen Schlüssel, der committet und später gelöscht wurde, denn er bleibt in der Git-Historie.
Deshalb kombiniert eine Review-Routine mehrere Prüfungen mit einer Person, die die Änderung liest. Wenn ein Tool nichts meldet, halten Sie fest, was es nicht sehen konnte, damit „keine Befunde“ nicht als „kein Risiko“ gelesen wird. Bei KI-geschriebenem Code sind die größten Lücken Pakete, die zu neu sind, um in irgendeiner Datenbank zu stehen, und Namen, die es nicht gab, bis ein Modell sie vorgeschlagen hat.
Heute in KROMSE verfügbar
KROMSE prüft den Code und die Abhängigkeiten, die Ihr Team und seine KI-Assistenten erzeugen; es meldet Befunde und ändert keinen Code.
- Prüft Lockfiles und Manifeste mit OSV-Scanner gegen OSV.dev, für npm, Yarn v1, pnpm, Poetry, uv, pip, Go-Module, Cargo, Maven, Gradle, Composer, Bundler und .NET-Projekte.
- Markiert Abhängigkeiten, die in der Datenbank OpenSSF Malicious Packages stehen, als kritisch; einzige Abhilfe ist das Entfernen.
- Findet mit Gitleaks eingecheckte Zugangsdaten im Code des gescannten Commits; die Secret-Werte werden geschwärzt und nie gespeichert. Die Git-Historie wird nicht gescannt.
- Quellcodeanalyse für 11 Sprachen: C, C++, C#, Go, Java, JavaScript, TypeScript, Kotlin, Python, Scala und Swift.
- Eine verständliche Erklärung zu jedem Befund und eine KI-Einschätzung pro Befund im Rahmen des Nutzungskontingents Ihres Tarifs.
Als Nächstes geplant
Auf der Roadmap, noch nicht verfügbar. Die Termine sind Zielmarken, keine Zusagen; diese Seite wird an dem Tag aktualisiert, an dem eine Funktion live geht.
- Geplant · Q4 2026 (November)Plug-in für Coding-Agenten. Ein Plug-in für KI-Coding-Agenten wird jedes Paket prüfen, das der Agent vorschlägt, bevor es in den Code gelangt – auch Pakete, die es gar nicht gibt oder die erst vor wenigen Tagen veröffentlicht wurden.
- Geplant · Q4 2026 (November)KI-Korrekturvorschläge, von Menschen freigegeben. KROMSE wird Korrekturen für Befunde vorschlagen, mit KI formuliert und erst angewendet, nachdem eine Person in Ihrem Team sie freigegeben hat.
- Geplant · Q1 2027Sicherheit von KI-Agenten und -Modellen. KROMSE wird eine KI-Stückliste (AI Bill of Materials) erstellen, prüfen, welche Tools und Berechtigungen Ihre Agenten nutzen können, und unsichere Modelldateien erkennen.
Häufige Fragen
Ist KI-generierter Code unsicherer als Code von Menschen?
Das hängt vom Modell, vom Prompt und vom Review ab. KI-generierter Code wiederholt tendenziell, was in bestehendem Code verbreitet war, einschließlich veralteter Versionen und unsicherer Muster, und er kommt in größeren Mengen. Prüfen Sie ihn wie Code von jemandem, den Sie nicht kennen: dieselben Tests, dieselben Scans und eine menschliche Freigabe vor dem Merge.
Was ist Slopsquatting?
Slopsquatting ist das Registrieren eines Pakets unter einem Namen, den KI-Modelle gern erfinden, sodass jeder, der den erfundenen Namen installiert, den Code des Angreifers erhält. Es ist eine Variante des Typosquatting. Zur Abwehr prüfen Sie, dass jede neue Abhängigkeit existiert und die gemeinte ist, legen Versionen in einem committeten Lockfile fest und gleichen Pakete mit Datenbanken für schädliche Pakete ab.
Wie verhindere ich, dass ein KI-Agent schädliche Pakete installiert?
Begrenzen Sie, was der Agent darf: keine Installationen außerhalb einer Sandbox, Installationen nur aus einer freigegebenen Liste oder über einen internen Registry-Proxy und kein Merge ohne menschliches Review. Prüfen Sie neue Abhängigkeiten in der CI gegen Daten zu Schwachstellen und schädlichen Paketen, und legen Sie Versionen in einem committeten Lockfile fest.
Kann KROMSE mir sagen, ob ein von einer KI vorgeschlagenes Paket gar nicht existiert?
Heute nicht. KROMSE prüft die Abhängigkeiten in Ihren Lockfiles und Manifesten gegen OSV.dev, einschließlich der Meldungen von OpenSSF Malicious Packages, sodass ein bereits gemeldetes schädliches Paket als kritisch markiert wird. Erfundene Paketnamen und erst vor wenigen Tagen veröffentlichte Pakete zu erkennen, steht auf der Roadmap, über ein Plug-in für Coding-Agenten.
Behebt KROMSE KI-generierten Code?
Nein. KROMSE meldet Befunde, erklärt sie verständlich und kann im Rahmen des Nutzungskontingents Ihres Tarifs eine KI-Einschätzung pro Befund liefern. Es bearbeitet keinen Code und öffnet keine Pull Requests, und seine GitHub App hat nur Lesezugriff. KI-Korrekturvorschläge, die eine Person freigibt, stehen auf der Roadmap.
Tauchen Secrets in KI-generiertem Code in einem KROMSE-Scan auf?
KROMSE führt Gitleaks auf dem Code des gescannten Commits aus und meldet eingecheckte Zugangsdaten; die Secret-Werte werden geschwärzt und nie gespeichert. Die Git-Historie scannt es nicht, ein Schlüssel, der committet und später gelöscht wurde, wird also nicht gefunden. Rotieren Sie jeden offengelegten Schlüssel, ob er noch im Code steht oder nicht.
Verwandte Leitfäden
Quellen
- Spracklen et al., „We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs“, USENIX Security 2025
- OpenSSF Best Practices Working Group: Security-Focused Guide for AI Code Assistant Instructions
- OpenSSF Malicious Packages: Repository
- OpenSSF: Schädliche Pakete mit der OSV-API erkennen
- Verordnung (EU) 2024/2847 (Cyberresilienz-Verordnung)