Slopsquatting & Coding-Agenten: die KI-Software-Lieferkette absichern

In kurzer Zeit sind KI-Werkzeuge vom Experiment zur Grundausstattung der Softwareentwicklung geworden. Im Stack Overflow Developer Survey 2025 gaben 84 % der Befragten an, KI-Werkzeuge im Entwicklungsprozess zu nutzen oder dies zu planen (2024: 76 %). Tatsächlich im Einsatz waren sie bei 78,5 %, täglich bei 47,1 %. KI-Agenten nutzte 2025 erst knapp ein Drittel bei der Arbeit (etwa 31 %), 37,9 % hatten keine entsprechenden Pläne.

Ein Jahr später hat sich der Schwerpunkt verschoben. In der Umfrage 2026 (30.903 gültige Antworten aus 169 Ländern) sind Coding-Assistenten und -Agenten mit 66 % der wichtigste KI-Anwendungsfall, vor allgemeinen Chatbots (63 %). Stack Overflow fasst zusammen, die „überwältigende Mehrheit“ nutze Coding-Assistenten und -Agenten inzwischen täglich (73 %) – die Zahl beschreibt beide gemeinsam, nicht Agenten allein. GitHubs Octoverse 2025 zeigt dieselbe Richtung: mehr als 180 Mio. Entwicklerinnen und Entwickler, rund 36 Mio. davon neu, und fast 80 % der Neuen nutzen Copilot bereits in der ersten Woche. Eine Annahmequote für die Pull Requests des Coding Agent nennt GitHub nicht.

Assistenten schlagen vor, Agenten führen aus

Für die Sicherheit zählt weniger, wie viel Code ein Modell schreibt, als was es selbst tun darf. Ein Assistent macht einen Vorschlag, den ein Mensch liest, übernimmt oder verwirft. Ein Agent arbeitet im Terminal, führt npm install oder pip install aus, bindet MCP-Server (Model Context Protocol, die Schnittstelle zu externen Werkzeugen und Datenquellen) und Skills (wiederverwendbare Anweisungspakete für Agenten) ein und liest Repository-Inhalte, Issues und Dokumentation als Kontext. HiddenLayer weist darauf hin, dass Agenten typosquattete Pakete mit weniger menschlicher Prüfung übernehmen können und dass sich entfernte MCP-Server ändern können, ohne dass die Organisation es bemerkt (HiddenLayer, 16.07.2026).

Dass Agenten Installationsanweisungen ohne Eigentümerprüfung ausführen, ist beobachtet: Forschende fanden auf 6.214 Domains 8.265 llms.txt- bzw. llms-full.txt-Dateien; 120 davon verwiesen auf nicht registrierte Pakete oder Domains. Nachdem sie einige dieser Namen mit Beacon-Paketen belegt hatten, meldete sich ein Fortune-500-Unternehmen binnen einer Stunde; die Prozessketten deuteten auf Claude, OpenAI Codex und Nous Research Hermes (laut Schneier unter Berufung auf Ars Technica, 09/2026). Das ist keine Halluzination – die Namen stammten aus Herstellerdokumentation –, folgt aber derselben Logik: Wer einen freien Namen zuerst belegt, bestimmt, was der Agent installiert. Auch Versionen sind unsicher: In rund 37.000 analysierten KI-Upgrade-Empfehlungen halluzinierte GPT-5 laut Sonatype 27,8 % der Komponentenversionen.

Drei Ausgangsquellen und ihre Einordnung

Der Leitgedanke dieses Deep Dives: Die Software-Lieferkette beginnt heute im Prompt. Ein Paketname, den ein Modell vorschlägt oder ein Agent aus einer Skill-Datei übernimmt, ist das erste Glied einer Kette, die über Registrierung, Auflösung und Ausführung bis zu gestohlenen Tokens und zur Ausbreitung reicht. Wer nur das Modell bewertet, übersieht die Stufen, an denen sich ein Angriff tatsächlich unterbrechen lässt.

Beim Typosquatting registriert ein Angreifer einen Namen, der einem populären Paket zum Verwechseln ähnlich ist, und setzt auf Tippfehler, unaufmerksames Kopieren oder automatisierte Werkzeuge. Öffentliche Registries vergeben Namen an den, der zuerst kommt; ein neues Konto genügt. Die Muster sind überschaubar:

Vom Einzeltäter zur Fließbandarbeit

Weder Check Point noch Microsoft bringen diese Kampagnen mit KI in Verbindung; es geht um Typosquatting und Markenimitation. Bemerkenswert ist das Zielbild: Gesucht werden Build-Umgebungen, Cloud-Rollen und Publishing-Tokens – genau die Rechte, mit denen auch Coding-Agenten arbeiten. Sonatype nennt den Missbrauch von Vertrauen in bekannte Namen, Werkzeuge und Release-Workflows den erfolgreichsten Angriffsvektor im ersten Quartal 2026.

SANDWORM_MODE: Typosquatting zielt auf den Agenten

Den Übergang markiert eine von Socket am 20.02.2026 beschriebene Kampagne: Mindestens 19 typosquattete npm-Pakete, drei davon als Claude-Code-Imitate, stahlen npm-, GitHub-, CI- und Krypto-Zugangsdaten sowie LLM-API-Schlüssel von neun Anbietern. Zudem trugen sie einen eigenen MCP-Server in die Konfiguration von Claude Code, Claude Desktop, Cursor, VS Code Continue und Windsurf ein. Dessen Tools mit unauffälligen Namen wie index_project oder lint_check enthielten eine Prompt Injection: Der Assistent sollte SSH-Schlüssel, AWS-Zugangsdaten, .npmrc und .env lesen und diesen Schritt dem Nutzer verschweigen. Zur Weiterverbreitung nutzte die Schadsoftware gestohlene npm-Tokens, eingeschleuste pull_request_target-Workflows und SSH als Rückfallweg.

VamiSec-Einordnung: Das Paket ist hier nur der Türöffner. Die eigentliche Nutzlast ist eine dauerhafte Änderung an der Umgebung des Agenten, die in jeder künftigen Sitzung mit den Rechten der Entwicklerin oder des Entwicklers wirkt.

Was die Registries leisten – und wo es endet

• Typosquatting-Prüfung: PyPI erkennt und markiert nach eigener Aussage potenzielles Typosquatting automatisch beim Anlegen eines Projekts; Schwellenwerte oder Zahlen nennt PyPI nicht (Jahresrückblick 2025).
• Quarantäne: Administratoren können Projekte aus dem Index nehmen, ohne sie zu löschen. Seit August 2024 betraf das rund 140 Projekte, nur eines kam wieder frei (PyPI, 30.12.2024). Im März 2026 griff die Quarantäne über vertrauenswürdige Melder bereits automatisiert.
• Statusmarker: Über PEP 792 signalisieren die Index-APIs den Status „quarantined“; Installer sollen davor warnen.
• Reaktionszeit: 2025 bearbeitete PyPI über 2.000 Malware-Meldungen, 66 % innerhalb von vier und 92 % innerhalb von 24 Stunden.

Die Grenzen sind strukturell. Alle diese Maßnahmen setzen nach dem Upload an; das Zeitfenster bis zur Entfernung bleibt. Auch npm reagierte auf Shai-Hulud mit dem Blockieren von Uploads, die bekannte Indikatoren enthielten – ebenfalls reaktiv. Und eine Ähnlichkeitsprüfung erkennt nur, was einem bestehenden Namen ähnelt. Genau daran scheitert sie bei Namen, die ein Sprachmodell frei erfindet.

Der Begriff Slopsquatting wird Seth Larson (Python Software Foundation) zugeschrieben; verbreitet hat ihn Andrew Nesbitt am 08.04.2025. Gemeint ist: Ein Sprachmodell halluziniert einen nicht existierenden Paketnamen, ein Angreifer registriert ihn mit Schadcode. Die maßgebliche Messung stammt von Spracklen et al. (USENIX Security 2025, Distinguished Paper Award), die den Begriff selbst nicht verwenden.

Die Forschenden ließen 16 Code-Modelle 576.000 Code-Samples in Python und JavaScript erzeugen. Als halluziniert galt, was am 10.01.2024 nicht auf PyPI bzw. npm existierte – eine Untergrenze. Die 19,7 % beziehen sich auf Paketreferenzen, nicht auf Code-Samples.

Belege aus Forschung und Praxis, 2023 bis 2026

Bar Lanyado zeigte 2023 bei Vulcan Cyber, dass ChatGPT 3.5 bei über 40 von 201 Node.js- und über 80 von 227 Python-Fragen nicht veröffentlichte Pakete empfahl. Für seine 2024 bei Lasso Security veröffentlichte Folgestudie lud er unter dem wiederholt halluzinierten Namen huggingface-cli (echt: huggingface_hub[cli]) ein leeres Paket hoch – laut Lasso mit über 30.000 authentischen Downloads in drei Monaten. Alibaba nannte pip install huggingface-cli im ersten README-Commit seines Repositorys GraphTranslator (26.02.2024).

Bislang kein belegter Angriff

Stand 08.10.2026 ist kein öffentlich belegter Fall bekannt, in dem ein Angreifer einen nachweislich halluzinierten Namen bösartig registriert hat und Opfer ihn wegen eines KI-Vorschlags installierten. Dass etwa PhantomRaven (2025) Slopsquatting ausnutze, ist eine Einschätzung von Koi ohne veröffentlichten Beleg. Auch für die 53 Churilov-Namen sehen Socket und InfoWorld keine bösartigen Registrierungen.

VamiSec-Einordnung: Entwarnung ist das nicht. Die Voraussetzungen sind belegt: Halluzinationen wiederholen sich, eine kleine Schnittmenge ist modellübergreifend, und harmlose Platzhalter erhielten echte Installationen, zuletzt offenbar durch Agenten. Zugleich bleibt ein Treffer schwer erkennbar: Der Name wirkt meist nicht wie ein Tippfehler, und Seth Larson hält es für schwierig, wahrscheinlich unmöglich, versuchte Installationen halluzinierter Pakete zu beziffern (The Register, 12.04.2025). Das Fehlen belegter Fälle beweist deshalb kein geringes Risiko.

Zwischen Namensvorschlag und Schaden liegt die Ausführung. Paketmanager bieten dafür mehrere Zündpunkte, und nicht alle lassen sich mit einem Schalter abschalten. Der verbreitete Rat, Lifecycle-Skripte zu deaktivieren (ignore-scripts), ist richtig, aber unvollständig.

Sechs Vorfälle, ein Muster

1. 1
   KI-CLIs als Werkzeug des Angreiferss1ngularity/Nx – 26.08.2025

   Über einen pull_request_target-Workflow mit Shell-Injection erbeuteten Angreifer das npm-Token und veröffentlichten bösartige Nx-Versionen, rund vier Stunden lang. Die Nutzlast suchte lokal installierte KI-CLIs und startete sie laut Wiz mit --dangerously-skip-permissions, --yolo bzw. --trust-all-tools, um Geheimnisse zu inventarisieren. Laut GitGuardian gelang das nur auf 95 von 366 Zielsystemen (rund 26 %); insgesamt wurden 2.349 eindeutige Secrets öffentlich.

2. 2
   Phishing, Krypto-Clipperchalk/debug – 08.09.2025

   Ein Maintainer fiel auf eine Phishing-Mail von support@npmjs[.]help herein; die Domain war am 05.09.2025 registriert worden. Bösartige Versionen von 18 populären Paketen (Aikido; Socket zählt 19 Versionen) mit laut Aikido mehr als 2 Mrd. wöchentlichen Downloads tauschten im Browser Wallet-Adressen aus, indem sie fetch, XMLHttpRequest und window.ethereum abfingen.

3. 3
   Wurm über gestohlene TokensShai-Hulud – September 2025

   Ein selbstreplizierender Wurm injizierte post-install-Skripte, suchte mit TruffleHog, Umgebungsvariablen und Cloud-Metadaten nach Geheimnissen und veröffentlichte mit erbeuteten npm-Tokens weitere Pakete. GitHub entfernte mehr als 500 kompromittierte Pakete; Wiz führt die Kampagne auf Zugangsdaten aus s1ngularity zurück.

4. 4
   preinstall und Runner-BackdoorShai-Hulud 2.0 – ab 24.11.2025

   Die zweite Welle zündete schon in der preinstall-Phase, getarnt als Bun-Installer, registrierte befallene Hosts als selbst gehostete GitHub-Runner und legte laut Wiz mehr als 25.000 bösartige Repositories an. Konnte sie weder Zugangsdaten stehlen noch Daten ausleiten, versuchte sie laut Unit 42, das Home-Verzeichnis zu zerstören.

5. 5
   Kompromittierter Maintainer-Rechneraxios – 31.03.2026

   Nach Social Engineering und der Infektion seines Rechners mit einem RAT (Fernzugriffstrojaner) erschienen über das persönliche Konto des Lead-Maintainers axios 1.14.1 und 0.30.4 mit einer zusätzlichen Abhängigkeit, die mehrstufig weitere Schadsoftware samt RAT nachlud – rund drei Stunden lang. CISA empfahl in ihrer Warnung vom 20.04.2026 ausdrücklich ignore-scripts=true und min-release-age=7 (Tage) in der .npmrc sowie phishing-resistente MFA.

6. 6
   Gültige Provenance, Agent als PersistenzortTanStack / Mini Shai-Hulud – 11.05.2026

   Über einen pull_request_target-Workflow und vergifteten Actions-Cache lasen Angreifer das OIDC-Token für Trusted Publishing aus dem Runner-Speicher und veröffentlichten 84 bösartige Versionen von 42 @tanstack-Paketen – mit gültiger SLSA-Build-Level-3-Provenance (StepSecurity). Zur Persistenz schrieb die Malware einen SessionStart-Hook in .claude/settings.json, der bei jedem Start von Claude Code node .vscode/setup.mjs ausführt, dazu eine VS-Code-Task mit runOn: folderOpen.

Zwei Lehren

Erstens: Provenance – der signierte Nachweis, aus welchem Repository und Build ein Paket stammt – belegt die Herkunft, nicht die Unbedenklichkeit. Sinngemäß nach StepSecurity bestätigt SLSA-Provenance, welche Pipeline ein Artefakt erzeugt hat – nicht, ob sie sich wie vorgesehen verhielt. Im Red-Hat-Fall „Miasma“ trugen 32 manipulierte Pakete ebenfalls gültige Signaturen, weil die Angreifer den legitimen OIDC-Veröffentlichungsweg nutzten (Microsoft, 02.06.2026). Die npm-Dokumentation hält selbst fest, dass Provenance keinen schadcodefreien Inhalt garantiert.

Zweitens: Tokens sind die Währung der Ausbreitung. Die meisten dieser Nutzlasten suchten npm-, GitHub-, Cloud- oder LLM-API-Zugangsdaten und nutzten Veröffentlichungsrechte für die nächste Welle. VamiSec-Einordnung: Jede Agenten-Sitzung, in der Tokens im Klartext, Cloud-Profile oder schreibende Registry-Rechte erreichbar sind, ist ein möglicher Startpunkt einer solchen Welle. Mini Shai-Hulud zeigt zudem, dass die Konfiguration des Agenten selbst zum Persistenzort wird.

HiddenLayer stellt in seinem Rahmenwerk vom 28.07.2026 eine These in den Mittelpunkt: Die wesentliche Angriffsfläche eines Coding-Agenten ist nicht das Modell, sondern sein Harness – Prompts, Tools, Skills, MCP-Server und die Orchestrierungslogik um das Modell. Die Wurzel der Angriffe sieht HiddenLayer in fehlplatziertem Vertrauen. Bereits am 16.07.2026 hatte das Unternehmen jede Quelle, die ein Agent liest, als möglichen Einstiegspunkt für indirekte Prompt Injection eingestuft.

Angriffsklassen mit Belegen

Paket-Halluzinationen selbst ordnet OWASP unter LLM09 Misinformation ein („Unsafe Code Generation“), nicht unter LLM03 Supply Chain. In der Agentic-Liste deckt ASI05 den Fall ab, dass ungeprüft installierte Pakete bei Installation oder Import Schadcode ausführen; ASI04 empfiehlt unter anderem, auf Typosquats zu prüfen.

IDEsaster (Ari Marzouk) beschreibt für Copilot, Cursor, Windsurf, Claude Code und weitere KI-IDEs eine neue Kette: Prompt Injection → Tools → Basisfunktionen der IDE, etwa Remote-JSON-Schemas oder überschriebene Workspace-Einstellungen. Hinzu kommen Fehler in der Freigabe- und Sandbox-Logik der Agenten-CLIs, etwa ein umgehbarer Bestätigungsdialog in Claude Code (CVE-2025-54795, CVSS 4.0: 8,7) oder ein Sandbox-Ausbruch über ein vom Modell vorgegebenes Arbeitsverzeichnis in Codex CLI (CVE-2025-59532, CVSS 4.0: 8,6).

Leitgedanke: Sicherheit außerhalb des Modells

Die meisten Fälle teilen eine Struktur: Das Modell tat, was sein Kontext nahelegte. Wo Hersteller nachbesserten, geschah das nicht am Modell, sondern im Harness – durch erneute Freigabe geänderter MCP-Konfigurationen, den Vertrauensdialog vor jeder Ausführung, kanonische Pfadprüfung oder engere Allowlists. Entsprechend betitelt HiddenLayer seine Monitoring-Schicht: Sicherheit muss außerhalb des Modells existieren. VamiSec-Einordnung: Behandeln Sie Regeldateien, MCP-Konfigurationen, Hooks und Skills wie ausführbaren Code – mit Review, Versionierung und Freigabe – und jede vom Agenten gelesene Quelle als nicht vertrauenswürdige Eingabe.

Was HiddenLayer empfiehlt (Praxis)

HiddenLayer überschreibt die erste Schicht seines Rahmens vom 28.07.2026 mit „Understand Every Trust Relationship“ – jede Vertrauensbeziehung verstehen. Gemeint sind vier Gegenstände:

• Alle eingesetzten Agenten, Modelle, Harnesses, Tools, MCP-Server und Skills – ausdrücklich einschließlich Schatten-KI.
• Die Berechtigungen jedes Agenten und die Systeme, die er erreichen kann.
• Herkunft und Integrität von Tools, Skills und externen Diensten.
• Die Laufzeit-Interaktionen zwischen Agenten, Tools, Repositories und externen Systemen.

Herkunft und Integrität sind kein Formalismus: Remote-MCP-Server können sich ändern, ohne dass die Organisation es bemerkt (HiddenLayer, 16.07.2026). Ein Inventar, das nur Namen enthält, veraltet deshalb lautlos. Gegen Schatten-KI empfehlen BSI und ANSSI kontrollierte Firmenkonten statt privater Zugänge und klare Regeln, welche Werkzeuge mit welchen Daten genutzt werden dürfen. Die ENISA rät in ihrer rechtlich unverbindlichen Package-Manager-Empfehlung vom 10.03.2026 zudem zu Sichtbarkeit über alle Pakete, die KI-Werkzeuge auswählen.

Umsetzung: Agenten-Stückliste und SBOM (VamiSec-Empfehlung)

Wir empfehlen, das Inventar als Agenten-Stückliste (AI-BOM) zu führen: ein maschinenlesbares Verzeichnis, das je Agent Werkzeug und Version, Modell und Anbieter, Betriebsmodus, angebundene MCP-Server und Skills mit Version oder Hash, Regeldateien sowie die genutzte Identität festhält. Daneben steht die SBOM (Software Bill of Materials, Stückliste aller Softwarekomponenten) je Release. Beide beantworten im Ernstfall dieselbe Frage: Wo steckt die betroffene Komponente?

Bei der Tiefe der SBOM lohnt Genauigkeit. Der CRA verlangt in Anhang I Teil II Nr. 1 eine SBOM in einem gängigen, maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten abdeckt – anwendbar ab 11.12.2027; ein bestimmtes Format schreibt er derzeit nicht vor. Die BSI TR-03183-2 (Version 2.1.0) fordert dagegen für TR-konforme SBOMs eine rekursive Auflösung und nennt CycloneDX ab 1.6 oder SPDX ab 3.0.1. Schadcode kann über transitive Abhängigkeiten kommen: Die bösartige Version axios 1.14.1 fügte die Abhängigkeit plain-crypto-js hinzu, die weitere Schadstufen nachlud (CISA, 20.04.2026). Wir empfehlen die rekursive SBOM deshalb als Arbeitsstandard – als Best Practice, nicht als CRA-Pflicht. Laut ENISA (SBOM Adoption State of Play, Juni 2026) benötigen 24 % der Befragten eine volle Tiefenanalyse, nur 14 % erhalten sie.

Bezug zur Angriffskette

Sichtbarkeit ist keine Bruchstelle, aber die Voraussetzung für alle anderen. Sie erschwert Stufe 03 (Übernahme), weil neue Pakete, MCP-Server und Skills auffallen. Ohne Inventar lassen sich Freigabelisten, Isolation und Monitoring nicht flächendeckend durchsetzen. Nach einem Vorfall begrenzt sie Stufe 07 (Ausbreitung): Betroffene Repositories, Hosts und Tokens lassen sich sofort benennen, statt sie erst zu suchen.

Regelwerk-Anker: Finanzunternehmen im vollen DORA-Rahmenwerk müssen nach Art. 10 Abs. 2 lit. d der Delegierten Verordnung (EU) 2024/1774 (RTS zum IKT-Risikomanagement) nachverfolgen, welche Drittanbieter- und Open-Source-Bibliotheken IKT-Dienste für kritische oder wichtige Funktionen nutzen – samt Versionen und Updates. Grundschutz++ des BSI sieht als SOLLTE-Anforderung vor, Bestandteile vor dem Release per SBOM zu dokumentieren (DEV.4.3, mit Verweis auf die TR-03183-2).

Was HiddenLayer empfiehlt (Praxis)

Unter „Limit the Impact of Compromise“ nennt HiddenLayer fünf Maßnahmen: Least Privilege als Standard, menschliche Freigabe für folgenreiche Aktionen, Zugriff nur auf freigegebene Tools, MCP-Server und Skills, Begrenzung unnötiger ausgehender Netzverbindungen sowie die Prüfung von System-Prompts und Standardkonfigurationen vor dem Einsatz. Die OWASP Top 10 for Agentic Applications 2026 erweitern Least Privilege zu „Least Agency“: keine Autonomie, wo sie nicht gebraucht wird. Die Leitlinie von CISA, NSA und Partnerbehörden der Five Eyes vom 01.05.2026 rät ebenso, Agenten keinen breiten Zugriff auf sensible Daten und kritische Systeme zu geben.

Dass Standardwerte nicht automatisch sicher sind, zeigen dokumentierte Schwachstellen: Vor Version 1.0.4 enthielt Claude Code eine zu breite Liste „sicherer“ Befehle, über die Dateiinhalte ohne Rückfrage abfließen konnten (CVE-2025-55284, CVSS 4.0: 7,1). Bei GitHub Copilot (VS Code/Visual Studio) ließ sich die Bestätigungspflicht per Prompt Injection ganz abschalten (CVE-2025-53773, siehe Kapitel 5).

Umsetzung in sechs Schritten (VamiSec-Empfehlung)

1. 1
   AusführungsumgebungIsolieren

   Agenten mit Terminalzugriff und Builds laufen in Containern, Devcontainern oder VMs – ohne gemountete Host-Credentials, SSH-Agent oder Cloud-Profile. Läuft Schadcode, findet er möglichst wenig, was sich zu stehlen lohnt.

2. 2
   IdentitätEigene Identität vergeben

   Der Agent arbeitet nicht mit den persönlichen Tokens der Entwicklerin, sondern mit einer eigenen, eng geschnittenen Identität: nur die Repositories und Scopes, die die Aufgabe braucht, kein Publish-Recht.

3. 3
   TokensKurzlebige Zugangsdaten

   Eigene Pakete per Trusted Publishing (OIDC) veröffentlichen statt mit gespeicherten Tokens – bei npm allgemein verfügbar seit 31.07.2025, ab npm CLI 11.5.1. Wo Tokens bleiben, die kürzeste praktikable Laufzeit wählen.

4. 4
   Tools, MCP, SkillsFreigabelisten durchsetzen

   Nur freigegebene Tools, MCP-Server und Skills sind ladbar; Pakete kommen ausschließlich über den internen Proxy (siehe Abhängigkeits-Hygiene).

5. 5
   NetzwerkEgress begrenzen

   Ausgehender Verkehr nur zu freigegebenen Zielen. Auch harmlose Werkzeuge transportieren Daten: HiddenLayer zeigte 2025, wie ein SSH-Schlüssel über die Bild-URL eines Diagramms abfloss.

6. 6
   KonfigurationEinstellungen zentral vorgeben

   Auto-Approve aus; Freigabe für Installationen, Netzbefehle und Schreibzugriffe auf Agenten-Konfiguration. Flags wie --dangerously-skip-permissions, --yolo oder --trust-all-tools sperren – laut Wiz rief die s1ngularity-Schadsoftware lokale KI-CLIs genau damit auf. Wo das Werkzeug zentral verwaltete Richtlinien unterstützt, sollten diese Vorrang vor Einstellungen aus dem Repository haben.

Menschliche Freigabe wirkt nur, wenn die Person sieht, was sie freigibt. In der Tool-Poisoning-Demo von Invariant Labs zeigte der Bestätigungsdialog die vollständigen Eingaben nicht an. Das BSI empfiehlt ausdrücklich eine Bestätigung durch den Nutzer, bevor ein LLM Funktionen ausführt (Evasion Attacks on LLMs, 06.11.2025). Wir empfehlen Dialoge, die Befehl, Paketname und Ziel vollständig zeigen – und wenige, ernst genommene Freigaben statt Dauerbestätigungen.

Bezug zur Angriffskette

Diese Schicht liefert die meisten Bruchstellen: Isolation ohne Host-Geheimnisse unterbricht Stufe 06 (Zugriff), Egress-Kontrolle Stufe 07 (Ausbreitung), die Freigabeliste im Proxy Stufe 04 (Auflösung). Die menschliche Freigabe erschwert Stufe 03 (Übernahme). Kurzlebige, eng geschnittene Tokens begrenzen, wie weit gestohlene Zugangsdaten tragen.

Nachweise für Prüfer

• Zentrale Konfigurationsvorgabe je Agent (Auto-Approve, Freigabepflichten, gesperrte Flags) mit Änderungshistorie.
• Definition von Image oder Devcontainer ohne gemountete Credentials, dazu die Egress-Regeln.
• Token-Inventar mit Identität, Scope und Ablaufdatum; Trusted Publishing für eigene Pakete.
• Stichproben aus Freigabeprotokollen.

Regelwerk-Anker: Für besonders wichtige und wichtige Einrichtungen verlangen NIS2 Art. 21 Abs. 2 lit. e und § 30 Abs. 2 Satz 2 Nr. 5 BSIG Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung. Die DVO (EU) 2024/2690 fordert für die dort genannten Einrichtungsarten, etwa Cloud- und Managed-Service-Anbieter, Sicherheitsanforderungen an Entwicklungsumgebungen (Anhang Nr. 6.2). Finanzunternehmen im vollen DORA-Rahmenwerk müssen die Genehmigung von Änderungen von deren Beantragung und Umsetzung trennen (Art. 17 Abs. 1 RTS 2024/1774 zu Art. 9 Abs. 4 lit. e DORA) – ein Agent, der eigene Änderungen freigibt, ist damit kaum vereinbar (VamiSec-Einordnung).

Was HiddenLayer empfiehlt (Praxis)

• Agenten vor dem Einsatz mit adversarialen Eingaben testen (Red Teaming).
• Vorgeschlagene Aktionen vor der Ausführung prüfen.
• Tools und Skills von Drittanbietern prüfen – einschließlich versteckter Metadaten.
• Konkrete Versionen freigeben, statt dauerhaft „latest“ zu vertrauen.

Der letzte Punkt zielt auf den Rug Pull: Ein MCP-Server ändert seine Tool-Beschreibung, nachdem er freigegeben wurde (Invariant Labs, 01.04.2025). Dasselbe Muster zeigte MCPoison an der Konfiguration: Nach der ersten Freigabe genügte ein Commit, um den Befehl eines MCP-Eintrags ohne erneute Rückfrage auszutauschen (CVE-2025-54136, siehe Kapitel 5). Laut The Register lieferte das inoffizielle npm-Paket postmark-mcp 15 unauffällige Versionen, bevor Version 1.0.16 jede ausgehende E-Mail in Blindkopie an eine fremde Adresse schickte.

Versteckte Metadaten sind der zweite Schwerpunkt. Anweisungen in Tool-Beschreibungen sind für Nutzer unsichtbar, das Modell liest sie mit (Invariant Labs); Regeldateien können Anweisungen in unsichtbaren Unicode-Zeichen tragen (Pillar Security, 18.03.2025). Unter 3.984 von Snyk geprüften Agent Skills waren 76 nachweislich bösartig (05.02.2026, Details in Kapitel 5).

Umsetzung: Freigabe je Komponente (VamiSec-Empfehlung)

Für KI-Code gibt es keinen Sonderweg. BSI und ANSSI halten fest, dass KI-Coding-Assistenten erfahrene Entwickler nicht ersetzen und Produktivitätsgewinne durch mehr Qualitätssicherung ausgeglichen werden müssen (04.10.2024). Instruktionsdateien wie AGENTS.md helfen, sind aber keine Kontrolle. Der OpenSSF-Leitfaden für Code-Assistenten (01.08.2025) empfiehlt die Anweisung, keine Abhängigkeiten hinzuzufügen, die bösartig oder halluziniert sein könnten. Das kann das Risiko senken – doch das Modell kann die Regel übergehen, und harmlos klingende Skill-Anweisungen können Paket-Halluzinationen sogar verstärken (Hsu et al., angenommen für EMNLP 2026).

Red Teaming vor dem Rollout

1. 1
   Szenarien festlegen

   Aufgaben, die Paketvorschläge provozieren; präparierte READMEs, Issues und Tool-Beschreibungen mit versteckten Anweisungen; Versuche, Agenten-Einstellungen zu ändern oder Credential-Dateien zu lesen.

2. 2
   In der Zielkonfiguration ausführen

   Mit genau dem Modell, Harness, den MCP-Servern und Skills, die ausgerollt werden sollen – in isolierter Umgebung.

3. 3
   Messen

   Wie oft erfindet der Agent Pakete? Folgt er injizierten Anweisungen? Greifen Freigabe, Proxy und Isolation aus Schicht 2?

4. 4
   Wiederholen

   Bei jedem Wechsel von Modell, Werkzeugversion oder Integration und als Regressionstest nach Vorfällen.

Bezug zur Angriffskette: Validierung erschwert Stufe 01 (Erfindung) und 03 (Übernahme), weil erfundene Namen im Test und im Review auffallen. Die Versionsfreigabe verhindert, dass eine stillschweigend geänderte Komponente in Stufe 04 (Auflösung) nachgeladen wird. Nachweise für Prüfer: Red-Team-Bericht je Agenten-Konfiguration, Freigabeliste mit Versionen und Hashes, Review-Protokolle zu neuen Abhängigkeiten, Testnachweise für KI-generierten Code.

Regelwerk-Anker: Für Finanzunternehmen im vollen DORA-Rahmenwerk verlangt die RTS 2024/1774 in Art. 16 Quellcode-Reviews mit statischen und dynamischen Tests (Abs. 3), Sicherheitstests von Softwarepaketen spätestens in der Integrationsphase (Abs. 4) und – soweit machbar – Analyse und Tests von Open-Source-Quellcode vor dem Produktiveinsatz (Abs. 8). Der CRA verlangt von Herstellern ab 11.12.2027 wirksame und regelmäßige Sicherheitstests und -überprüfungen (Anhang I Teil II Nr. 3).

HiddenLayer begründet die vierte Schicht knapp: Sprachmodelle sind darauf ausgelegt, Anweisungen zu befolgen – nicht, Sicherheitsrichtlinien durchzusetzen (sinngemäß). Eine Kontrolle, die nur im Prompt steht, fällt mit der ersten erfolgreichen Prompt Injection. Überwachung setzt deshalb bei Betriebssystem, Netzwerk, Pipeline und Harness an. Die OWASP Top 10 for Agentic Applications nennen starke Beobachtbarkeit „nicht verhandelbar“.

Was HiddenLayer beobachten will (Praxis)

• Bewegungen sensibler Daten
• Tool-Nutzung und Dateioperationen
• Versuche der Rechteausweitung
• Aktivität von Schatten-KI
• API-Nutzung und auffälligen Rechenverbrauch

Erkennungsideen aus realen Vorfällen (VamiSec-Empfehlung)

Die Kampagnen der vergangenen Monate liefern konkrete Muster. Die Mini-Shai-Hulud-Welle um TanStack verankerte sich laut StepSecurity über einen SessionStart-Hook von Claude Code und eine VS-Code-Task (Details in Kapitel 4). SANDWORM_MODE trug laut Socket einen eigenen MCP-Server in die Konfiguration von Claude Code, Cursor und weiteren Werkzeugen ein. Miasma hielt laut Microsoft einen ruhenden Abflusskanal über api.anthropic.com bereit; die Exfiltrationsdomain der litellm-Releases war laut Snyk einen Tag zuvor registriert worden. Mehrere Wellen starteten Bun als Laufzeit – ein Weg an Node-zentriertem Monitoring vorbei.

Telemetrie über Agenten-Hooks

Mehrere Coding-Agenten bieten Hook-Schnittstellen, die bei Tool-Aufrufen eigene Programme starten. Wir empfehlen, darüber Tool-Aufrufe, Shell-Befehle und Dateizugriffe zentral zu protokollieren und riskante Aufrufe vor der Ausführung zu prüfen. Dieselbe Schnittstelle ist aber ein Persistenzweg, wie die TanStack-Welle zeigt; bei Claude Code liefen Hooks aus Projektdateien zeitweise ohne Zustimmung (Check Point, behoben am 26.08.2025). Hooks gehören deshalb in die zentral verwaltete Konfiguration – jede Änderung daran ist selbst ein Alarmsignal.

Bezug zur Angriffskette: Monitoring unterbricht keine Stufe verlässlich, verkürzt aber die Zeit, in der Stufe 05 (Ausführung), 06 (Zugriff) und 07 (Ausbreitung) unbemerkt bleiben. Wie kurz die Fenster sind, zeigen die Vorfälle: Die bösartigen TanStack-Versionen waren nach rund 1,7 Stunden als veraltet markiert, die axios-Versionen nach etwa drei Stunden entfernt. Daraus folgt für uns: Eigene Erkennung muss in Stunden reagieren, nicht in Tagen.

Regelwerk-Anker: Die DVO (EU) 2024/2690 verlangt für die dort genannten Einrichtungsarten Schutz vor bösartiger und nicht autorisierter Software einschließlich Erkennungsmaßnahmen (Anhang Nr. 6.9); anderen NIS2-Einrichtungen dient sie als Orientierung. Die Five-Eyes-Leitlinie zu agentischer KI (01.05.2026) nennt kontinuierliches Monitoring ausdrücklich.

Was HiddenLayer empfiehlt (Praxis)

Unter „Security Requires Ownership“ nennt HiddenLayer vier Punkte: eine verantwortliche Person (Owner) für jeden produktiv eingesetzten Agenten, die Aufnahme von Coding-Agenten in bestehende Threat Models und KI-Governance-Programme, Incident-Response-Verfahren speziell für agentische KI und die regelmäßige Überprüfung von Berechtigungen und vertrauenswürdigen Integrationen. Auch die Five-Eyes-Leitlinie vom 01.05.2026 empfiehlt, Risiken agentischer KI in bestehende Rahmenwerke zu integrieren und Threat Modeling zu betreiben.

Für NIS2-Einrichtungen ist das Leitungsaufgabe. Leitungsorgane müssen die Risikomanagementmaßnahmen billigen, ihre Umsetzung überwachen und können haftbar gemacht werden (NIS2 Art. 20 Abs. 1 und 2). In Deutschland verpflichtet § 38 BSIG die Geschäftsleitungen besonders wichtiger und wichtiger Einrichtungen zu Umsetzung, Überwachung und regelmäßigen Schulungen; die Haftung richtet sich nach Gesellschaftsrecht. Eine Richtlinie für KI-Coding-Werkzeuge sollte deshalb von der Leitung freigegeben sein.

Bausteine einer Richtlinie für KI-Coding-Werkzeuge (VamiSec-Empfehlung)

• Zugelassene Werkzeuge, Modelle und Betriebsmodi; Nutzung nur über Firmenkonten.
• Datenklassen: welche Informationen in welches Werkzeug dürfen.
• Autonomiestufen: was ein Agent selbst darf, was eine Freigabe braucht, was verboten ist.
• Paketregeln: Bezug nur über den internen Proxy, Cooldown, keine Install-Skripte ohne Freigabe.
• Freigabeprozess für MCP-Server, Skills und Regeldateien mit Bindung an Version oder Hash.
• Vier-Augen-Prinzip für Merges – auch bei Pull Requests von Agenten.
• Protokollierung, Ausnahmeverfahren und Rezertifizierung von Rechten und Integrationen, etwa halbjährlich.
• Schulung: Art. 4 KI-VO verlangt von Anbietern und Betreibern seit dem Digital Omnibus (VO (EU) 2026/1744, in Kraft seit 27.07.2026) Maßnahmen zur Unterstützung von KI-Kompetenz, aber kein garantiertes Niveau.

Im Threat Model erscheint der Agent als eigener Akteur mit Rechten; Regeldateien, Skills, MCP-Server und Paketquellen sind Vertrauensgrenzen. Der ENISA-Entwurf zur KI-gestützten Softwareentwicklung (v0.4, September 2026) beschreibt dafür STRIDE-Bedrohungen wie das Unterschieben bösartiger Pakete, Skills oder Instruktionsdateien.

Incident-Response-Playbook: bösartiges Paket installiert oder Agent kompromittiert

1. 1
   EindämmenIsolieren

   Betroffene Hosts, Container und Runner vom Netz nehmen, laufende Agenten-Sitzungen beenden, Pipelines mit dem Paket anhalten. Spuren sichern, bevor neu aufgesetzt wird.

2. 2
   EindämmenZugangsdaten rotieren

   Alle erreichbaren Geheimnisse: Registry-Tokens, Tokens der Git-Plattform, Cloud- und Vault-Zugänge, Modell-API-Schlüssel. CISA riet nach Shai-Hulud ausdrücklich zur Rotation. Ohne das Token-Inventar aus den Schichten 1 und 2 bleibt dieser Schritt lückenhaft.

3. 3
   BereinigenLockfiles und Caches prüfen

   Welche Repositories, Lockfiles, Paket- und CI-Caches enthalten die betroffenen Versionen? Bei TanStack lief der Angriff über einen vergifteten GitHub-Actions-Cache – Caches gehören zur Bereinigung.

4. 4
   BereinigenPersistenz in der Agenten-Konfiguration suchen

   Hooks und MCP-Einträge in Nutzer- und Projektkonfigurationen, VS-Code-Tasks mit runOn: folderOpen, neue Self-hosted-Runner und Workflows, .pth-Dateien. Im Zweifel neu aufsetzen statt reinigen.

5. 5
   MeldenMeldepflichten prüfen

   CRA-Hersteller melden seit 11.09.2026 aktiv ausgenutzte Schwachstellen ihrer Produkte über die Single Reporting Platform gleichzeitig an das koordinierende CSIRT und die ENISA: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Abhilfe. Relevant, wenn Schadcode in ein ausgeliefertes Produkt gelangt sein kann (VamiSec-Einordnung, im Einzelfall rechtlich prüfen). NIS2- und DORA-Einrichtungen prüfen parallel ihre eigenen Meldewege.

6. 6
   LernenNachbereiten

   Ursache, erreichte Stufe und fehlende Bruchstellen dokumentieren, Rechte und Integrationen rezertifizieren, Registry-Betreiber und Maintainer informieren.

Bezug zur Angriffskette: Governance erschwert Stufe 07 (Ausbreitung), weil vorab geklärt ist, wer welche Tokens rotiert, wer was sperrt und wer an wen meldet. Zugleich hält sie die übrigen Schichten aktuell – ohne Rezertifizierung wachsen Rechte und Integrationen schleichend.

Beim Paketbezug tragen der Cooldown – ein Mindestalter neuer Versionen vor der Installation – und die Sperre von Install-Skripten die Hauptlast. Achten Sie auf die Einheiten.

Zwei Grenzen gehören dazu. Erstens fängt ein Cooldown bösartige Versionen ab, die laut pnpm meist binnen einer Stunde entdeckt und entfernt werden – nicht aber einen halluzinierten Namen, den ein Angreifer früh besetzt und abwartet. Zweitens ist ignore-scripts unvollständig: Git-Abhängigkeiten können über eine eigene .npmrc Code ausführen (dagegen --allow-git=none ab npm 11.10.0), URL-Abhängigkeiten wie bei PhantomRaven brauchen --allow-remote=none (ab 11.15.0), Import-Code erfasst keine Skript-Sperre.

Konfiguration für Builds und Agenten (VamiSec-Empfehlung)

# CI-Builds und Agenten: nur über den internen Proxy (Platzhalter)
registry=https://registry.intern.example/
# keine Lifecycle-Skripte
ignore-scripts=true
# nur Versionen älter als 7 Tage (ab npm 11.10.0)
min-release-age=7

# pyproject.toml: nur Versionen älter als 7 Tage (ab uv 0.9.17)
[tool.uv]
exclude-newer = "7 days"
# Ausnahmen je Paket: exclude-newer-package

# pip ab 26.1: Dauer in Tagen, dazu Hash-Pflicht
pip install --require-hashes --uploaded-prior-to P7D -r requirements.txt

Sicherheitsupdates ausnehmen: Ein Cooldown darf Fixes nicht verzögern. Dependabot und Renovate umgehen ihn für Sicherheitsupdates standardmäßig, die Paketmanager kennen Ausnahmelisten (min-release-age-exclude, minimumReleaseAgeExclude, minimumReleaseAgeExcludes, exclude-newer-package). PyPI rät, Cooldowns mit Schwachstellen-Scans zu koppeln.

Lockfiles, Review, Proxy, Provenance

In CI und Agenten-Umgebungen nur reproduzierbar installieren: npm ci, pnpm install --frozen-lockfile, pip mit --require-hashes. Bei LiteLLM waren laut PyPI rund 40 bis 50 % der Installationen im Angriffsfenster ungepinnt. OWASP beschreibt den Fall, dass ein Agent ein Lockfile aus ungepinnten Angaben neu erzeugt und eine kompromittierte Minor-Version zieht – jede neue Abhängigkeit und Lockfile-Änderung braucht daher eine benannte Freigabe im Dependency-Review. Technisch setzt das ein interner Registry-Proxy mit Freigabeliste durch; BSI und ANSSI empfehlen Allowlisting erlaubter Pakete. Eine bloße Existenzprüfung genügt nicht: Der Angreifer kann den Namen vorher registriert haben (Spracklen et al.).

npm audit signatures prüft Registry-Signaturen und Provenance-Attestierungen (ab npm 9.5.0); PyPI unterstützt seit 14.11.2024 Attestierungen nach PEP 740, die pip und uv laut Trail of Bits nicht automatisch prüfen. Beides belegt die Herkunft, nicht die Unbedenklichkeit: Auch die bösartigen TanStack- und Miasma-Pakete trugen gültige Provenance bzw. Signaturen (siehe Kapitel 4). Als zusätzliche Prüfung ist das sinnvoll, als alleiniges Freigabekriterium ungeeignet.

Regelwerk-Anker: Die rechtlich unverbindliche ENISA-Empfehlung zu Paketmanagern (10.03.2026) rät zu offiziellen, verifizierbaren Registries, Lockfiles und Integritätsprüfungen in CI/CD. Grundschutz++ sieht als SOLLTE-Anforderungen vor, externe Artefakte aus unbekannten Quellen zu untersagen, ihre Integrität zu testen und auf Sicherheitsupdates zu prüfen (DEV.4.2, DEV.4.4, DEV.4.5); das Kompendium 2023 fordert vertrauenswürdige Quellen und die Prüfung unbekannter Komponenten (CON.8.A6, CON.8.A20). NIS2 Art. 21 Abs. 2 lit. d und § 30 Abs. 2 Satz 2 Nr. 4 BSIG verlangen Lieferkettensicherheit; CRA-Hersteller trifft ab 11.12.2027 die Sorgfaltspflicht für Drittkomponenten nach Art. 13 Abs. 5 – ausdrücklich auch für Open Source.

CRA, NIS2 und DORA setzen ähnlich an: Verantwortlich ist, wer die Komponente integriert oder das System betreibt (VamiSec-Einordnung). Für den Cyber Resilience Act (CRA) zeigt es Beispiel 34 der Kommissionsleitlinien C(2026) 5252 vom 27.07.2026: Ein Einzelentwickler, der eine freie Open-Source-Bibliothek in einem öffentlichen Paket-Repository veröffentlicht, und das Repository selbst haben keine CRA-Pflichten. Die Sorgfaltspflicht nach Art. 13 Abs. 5 trägt ab 11.12.2027 der integrierende Hersteller, risikobasiert nach Erwägungsgrund 34. Die Leitlinien sind unverbindlich. Ob Mensch oder Agent das Paket wählte, ändert daran nichts (VamiSec-Einordnung).

Cyber Resilience Act: Meldepflicht seit 2026, Sorgfaltspflicht ab 2027

• Pflicht seit 11.09.2026 (Art. 14 Abs. 1–2): aktiv ausgenutzte Schwachstellen über die Single Reporting Platform (SRP) an CSIRT und ENISA melden — Frühwarnung binnen 24 h, Meldung binnen 72 h, Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Abhilfe; auch für Bestandsprodukte.
• Pflicht ab 11.12.2027: Sorgfalt bei Drittkomponenten einschließlich freier Open-Source-Software (Art. 13 Abs. 5), Schwachstellen in Komponenten an deren Hersteller oder Maintainer melden (Abs. 6), keine bekannten ausnutzbaren Schwachstellen ausliefern (Anhang I Teil I Nr. 2 lit. a).
• SBOM: Anhang I Teil II Nr. 1 verlangt mindestens die Top-Level-Abhängigkeiten; eine rekursive Auflösung fordert erst die BSI TR-03183-2 v2.1.0 — gute Praxis, keine CRA-Pflicht. Ein Format wie CycloneDX oder SPDX schreibt der CRA nicht vor; einen Durchführungsrechtsakt dazu (Art. 13 Abs. 24, Kann-Vorschrift) listet die Kommission nicht (Stand 27.07.2026).
• Bußgelder (Art. 64 Abs. 2): bei Verstößen gegen Anhang I, Art. 13 oder 14 bis 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes, der höhere Betrag zählt.

NIS2 und BSIG: Lieferkette und Entwicklung als Mindestmaßnahmen

NIS2 verlangt Sicherheit der Lieferkette (Art. 21 Abs. 2 lit. d) sowie bei Erwerb, Entwicklung und Wartung (lit. e). Art. 21 Abs. 3, wonach Einrichtungen bei der Wahl der Lieferkettenmaßnahmen auch die sicheren Entwicklungsprozesse ihrer unmittelbaren Anbieter berücksichtigen, steht nicht wörtlich im BSIG; heranziehen lässt er sich über die richtlinienkonforme Auslegung. In Deutschland gilt seit 06.12.2025 § 30 Abs. 2 Satz 2 Nr. 4 und 5 BSIG; die Geschäftsleitung setzt um, überwacht und haftet bei schuldhafter Pflichtverletzung nach Gesellschaftsrecht (§ 38 BSIG, Art. 20 NIS2). Für fehlende oder nicht dokumentierte Maßnahmen sieht § 65 bis 10 Mio. EUR (besonders wichtige) bzw. 7 Mio. EUR (wichtige Einrichtungen) vor, bei über 500 Mio. EUR Gesamtumsatz bis 2 % bzw. 1,4 % des Gesamtumsatzes. Die DVO (EU) 2024/2690 ist nur für die in Art. 1 gelisteten Einrichtungsarten wie Cloud-, Rechenzentrums- und Managed-Service-Anbieter verbindlich, für alle anderen Orientierung.

DORA: Die präzisen Anker stehen in der RTS

DORA verlangt seit 17.01.2025, dass Änderungen an IKT-Systemen erfasst, getestet, bewertet, genehmigt, umgesetzt und verifiziert werden (Art. 9 Abs. 4 lit. e), und lässt Finanzunternehmen bei IKT-Dienstleistungen voll verantwortlich (Art. 28 Abs. 1). Für frei bezogene Bibliotheken ist die RTS 2024/1774 präziser (volles Rahmenwerk, Titel II): Bibliotheken für kritische oder wichtige Funktionen nachverfolgen (Art. 10 Abs. 2 lit. d), Code-Reviews mit statischen und dynamischen Tests (Art. 16 Abs. 3), Softwarepakete spätestens bei der Integration testen (Abs. 4), Quellcode-Integrität schützen (Abs. 7), Open-Source-Code vor dem Produktiveinsatz prüfen, soweit machbar (Abs. 8), Genehmigung und Umsetzung von Änderungen trennen (Art. 17 Abs. 1). Ein Agent, der eigene Pull Requests mergt, passt dazu nicht (VamiSec-Einordnung).

AI Act und Produkthaftung

Ein Coding-Assistent ist nach dem AI Act typischerweise kein Hochrisiko-System, denn Softwareentwicklung steht nicht in Anhang III. Für einsetzende Unternehmen bleibt Art. 4: Seit dem Digital Omnibus (VO (EU) 2026/1744, in Kraft seit 27.07.2026) müssen sie Maßnahmen zur Unterstützung der KI-Kompetenz ergreifen, ohne ein Niveau zu garantieren. GPAI-Pflichten treffen die Modellanbieter, nicht die Nutzer. Nach der Produkthaftungsrichtlinie (EU) 2024/2853 ist Software ein Produkt; für Produkte, die nach dem 09.12.2026 in Verkehr gebracht werden, haftet der Hersteller gegenüber natürlichen Personen auch für fehlerhafte Komponenten, die unter seiner Kontrolle integriert wurden, und fehlende Sicherheitsupdates entlasten ihn nicht. Die Richtlinie wirkt über nationales Recht; der deutsche Regierungsentwurf (BT-Drs. 21/4297) ist zum 08.10.2026 nicht als verkündet verifiziert.

Leitfäden: unverbindliche Orientierung

• ENISA, Secure Use of Package Managers (10.03.2026): nennt Slopsquatting ausdrücklich und empfiehlt, KI-gewählte Pakete sichtbar zu machen und in CI/CD automatisiert zu prüfen.
• ENISA, AI-assisted software development (Entwurf v0.4, September 2026): halluzinierte Pakete, untergeschobene Skills und Instruktionsdateien — noch nicht final.
• BSI und ANSSI, AI Coding Assistants (04.10.2024): Paket-Halluzinationen als Weg zu „package confusion“; Plausibilitätsprüfung, Allowlisting, Sandboxing.
• BSI Grundschutz++ DEV.4.2 bis DEV.4.5 (SOLLTE-Anforderungen): Artefakte aus unzuverlässigen oder unbekannten Quellen untersagen, auch Packages und Modelle; SBOM, Integritätstests. Kompendium 2023: CON.8.A6, CON.8.A20.

Der Plan ist eine VamiSec-Empfehlung und folgt der Angriffskette: Zuerst schaffen Sie Sichtbarkeit und schließen offensichtliche Lücken, dann ziehen Sie Bruchstellen an den Stufen 04 Auflösung und 05 Ausführung ein, zuletzt machen Sie die Regeln verbindlich und messbar. Ausgangspunkt ist eine ehrliche Bestandsaufnahme, etwa mit dem Self-Assessment auf dieser Seite. Regulierte Unternehmen beginnen mit dem, was schon gilt: CRA-Meldepflichten seit 11.09.2026, BSIG-Maßnahmen seit 06.12.2025, DORA seit 17.01.2025.

Zehn Kennzahlen mit Zielwerten

Messen Sie, was die Kette tatsächlich unterbricht, nicht die Zahl der Schulungen. Die Zielwerte sind VamiSec-Empfehlungen, keine regulatorischen Schwellen; die meisten lassen sich automatisch aus Proxy-Logs, CI-Konfiguration und zentraler Agenten-Konfiguration erheben. Wie riskant Modi ohne Bestätigung sind, zeigt s1ngularity: Die Schadsoftware rief laut Wiz lokal installierte KI-CLIs mit Flags wie --dangerously-skip-permissions und --yolo auf, um Geheimnisse zu inventarisieren. Berichten Sie quartalsweise an die Geschäftsleitung; in NIS2-Einrichtungen muss sie die Umsetzung der Maßnahmen nach § 38 BSIG ohnehin überwachen.

Nachweise für Prüfer

• Inventar der KI-Coding-Werkzeuge, Agenten, MCP-Server und Skills mit Owner, Version und Rechten (AI-BOM)
• Richtlinie für KI-Coding-Werkzeuge, von der Geschäftsleitung gebilligt (Art. 20 Abs. 1 NIS2; Umsetzung und Überwachung nach § 38 BSIG)
• Versionierte Konfiguration von Proxy, Paketmanagern, Update-Bots und Egress-Regeln — § 30 Abs. 1 BSIG verlangt, die Einhaltung der Maßnahmen zu dokumentieren
• Freigabeprotokolle für neue Abhängigkeiten und Agenten-Erweiterungen aus der Pull-Request-Historie, mit menschlicher Freigabe von Agenten-Änderungen (für DORA-Finanzunternehmen: Funktionstrennung nach Art. 17 Abs. 1 RTS 2024/1774)
• SBOM je Release: mindestens Top-Level-Abhängigkeiten (CRA Anhang I Teil II Nr. 1, ab 11.12.2027), besser rekursiv nach BSI TR-03183-2 v2.1.0
• Testnachweise für Softwarepakete spätestens in der Integrationsphase (Art. 16 Abs. 4 RTS 2024/1774) und Red-Teaming-Bericht der Agenten
• Incident-Playbook mit Token-Rotationsliste und Meldewegen nach Art. 14 CRA (24 h / 72 h / 14 Tage) samt Übungsprotokoll
• Quartalsweiser KPI-Bericht an die Geschäftsleitung