In den letzten Jahren hatte die Anwendungssicherheit eine klare Grenze: das Repository und die pipelineDort befanden sich die Kontrollzentren, dort wurden die Scans durchgeführt, dort entschieden die Teams, ob etwas in die Produktion ging. All das basierte auf einer Annahme: Ein Entwickler wählte explizit aus, welcher Code und welche Abhängigkeiten in das System gelangten.
Diese Annahme trifft nicht mehr zu. Ein wachsender Anteil des heutigen Codes wird von einem KI-System geschrieben, vorgeschlagen oder installiert, oft ohne dass jemand den Namen der eingebundenen Software überprüft.cisJe nachdem, was in den Code gelangt, bewegt sich auch der Angriff. Er rückt an den Anfang des Prozesses vor: in dem Moment, in dem der Code erstellt wird, im Assistenten selbst und in den Dateien, die ihn konfigurieren.
Dies ist Ihre Angriffsfläche für KI-Systeme: Jedes Modell, jeder Agent, jeder MCP-Server, jede Fähigkeit und jede von der KI vorgeschlagene Abhängigkeit kann nun ein Risiko darstellen, noch bevor ein Mensch sie überprüft. Dieselbe KI, der Ihre Entwickler vertrauen, ist nun Teil dieses Risikos. Dies ist kein zukünftiges Risiko. Es handelt sich um einen Wandel, der bereits stattgefunden hat, und so sieht er in der Praxis aus.
Eine Angriffswelle, kein Einzelfall
Keine der folgenden Aufgaben ist eine Laborübung.cise oder ein hypothetisches Szenario. Es handelt sich um öffentlich dokumentierte Vorfälle, fast alle aus dem letzten Jahr, und jeder einzelne rückt den KI-Agenten selbst ein Stück näher:
- August 2025, s1ngularity: Angreifer stahlen ein Publishing-Token von Nx, einem der am weitesten verbreiteten Build-Systeme, und veröffentlichten bösartige Versionen auf npm. Dabei nutzten sie KI-Tools, um auf den Rechnern der Entwickler nach Geheimnissen zu suchen.
- September 2025, chalk/debug: Einer der größten Sicherheitsvorfälle bei npm war der Diebstahl von 18 Paketen mit mehr als zwei Milliarden wöchentlichen Downloads durch die Übernahme des Accounts eines einzelnen Maintainers.
- September 2025, Shai-Hulud: Einer der ersten dokumentierten Würmer, der sich über npm selbst verbreiten konnte. Seine zweite Welle im November war aggressiver und mit Geheimnissen verknüpft, die in mehr als 25,000 Repositories offengelegt wurden.
- Oktober 2025, nicht verwendete Importe: Teil der PhantomRaven-Kampagne, bei der KI-Halluzinationen durch eine Slopsquatting-Technik echte Malware in npm einschleusten.
- Dieses Jahr bei ClawHub: ein manipuliertes KI-Fähigkeitenregister, in dem fünf der sieben am häufigsten heruntergeladenen Fähigkeiten Schadsoftware waren.
Die Branche kommt zunehmend zu demselben Schluss. Die OWASP Top 10 für LLM-Anwendungen stuft die sofortige Einschleusung als größtes Risiko ein. Die OWASP MCP Top 10 (derzeit in der Beta-Phase) konzentriert sich auf das Protokoll, das Agenten zur Kommunikation mit Tools verwenden. Die OWASP Agentic Skills Top 10, ein neues Projekt im Inkubator-Stadium, nennt bösartige Fähigkeiten als größtes Risiko. OWASP agiert üblicherweise vorsichtig; die gleichzeitige Eröffnung von drei Fronten, von denen eine dringend ist, verdeutlicht die rasante Entwicklung.
Alle drei Ansätze laufen auf dieselbe Idee hinaus: Die Anweisungen, Werkzeuge und Konfigurationen eines Modells sind nun Teil der Angriffsfläche für KI und befinden sich üblicherweise im eigenen Repository. Daraus ergibt sich die erste Frage, die Sie Ihren Teams stellen sollten: Wer überprüft die Regeldateien, Fähigkeiten und MCP-Konfigurationen in Ihrem Repository?
Vektor 1: die vergiftete Fertigkeit
Eine Fähigkeit ist eine Datei mit Anweisungen und Fähigkeiten, die einem KI-Agenten beibringt, wie er eine Aufgabe ausführt. Es ist nicht die einzige Möglichkeit, das Verhalten eines Agenten zu formen (Regeldateien, hooks, und MCP-Konfigurationen tun dasselbe), aber sie alle haben eine Gemeinsamkeit: Sie werden innerhalb des Repositorys zusammen mit dem Code übertragen.
In einer diesjährigen Studie wurden 4,000 dieser Fähigkeiten untersucht:
- 36 % wiesen mindestens eine Sicherheitslücke auf.
- 13.4 % waren kritisch.
- Fast 100 davon enthielten direkt schädliche Nutzdaten.
Der entscheidende Unterschied: Der Angreifer zielt nicht mehr auf Ihren Code ab. Er zielt auf den Agenten, der Ihren Code schreibt, und platziert versteckte Anweisungen (manchmal mithilfe unsichtbarer Zeichen), die das Modell liest und als aktiv interpretiert. Ein menschlicher Prüfer gibt diese Anweisungen frei. pull request in gutem Glauben, weil die Datei in ihren Augen sauber aussieht. Das Modell interpretiert Anweisungen, die der Prüfer nie gesehen hat.
Dies ist keine theoretische Schwachstelle. CVE-2025-59536 (CVSS 8.7) ermöglichte das Starten von Claude Code aus einem nicht vertrauenswürdigen Repository, wodurch eine manipulierte Konfiguration Befehle ausführen konnte, bevor der Benutzer dem Vertrauensdialog zustimmte. Eine zweite Schwachstelle, CVE-2026-21852, ermöglichte das Auslesen eines API-Schlüssels über projektgesteuerte Konfigurationen, ohne dass der Benutzer etwas genehmigte.
H2: Vektor 2: Slopsquatting
Der Name ist eine Mischung aus „Slop“ (dem von KI manchmal generierten Datenmüll) und dem klassischen Typosquatting. Typosquatting basiert auf menschlichen Fehlern: Ein Angreifer registriert einen Paketnamen, der einem gängigen Namen ähnelt, und wartet auf einen Tippfehler. Es ist ein Zufallsprodukt.
Slopsquatting wartet nicht auf einen Fehler. In der Studie, auf die in dieser Sitzung Bezug genommen wurde, 19.7 % der von KI-Modellen generierten Paketverweise wiesen auf nicht existierende Pakete. Modelle neigen dazu, immer wieder dieselben Namen zu erfinden. Ein Angreifer beobachtet daher, welche Namen die KI erfindet, registriert diese Namen mit bösartigem Code und wartet auf die nächste von der KI vorgeschlagene Installation, um sie in Ihre Anwendung einzubinden.
Der Maßstab ist nicht klein: Im Jahr 2025 wurden mehr als 450,000 neue Schadsoftwarepakete identifiziert. Zwei Beispiele verdeutlichen dies:
- Ein Forscher platzierte ein harmloses Testpaket namens Huggingface-cli Um dies zu beweisen. Es wurde protokolliert. mehr als 30,000 Downloads in drei Monaten.
- ungenutzte ImporteWie aus der obigen Zeitleiste hervorgeht, handelte es sich bei der bestätigten Malware, die in einem öffentlichen Register aktiv war und genau diese Technik anwandte. Das war kein Test.
Die Frage ist nicht, ob dies Ihrem Team passieren kann. Vielmehr geht es darum, wie viele KI-vorgeschlagene Pakete heute in Ihren Code gelangen, ohne dass sie jemand überprüft.
Die Antwort: standards holen auf
Zwei Kräfte wirken parallel. Während die Angriffe zunehmen, standardDie Körper reagieren:
- NIST SP 800-218A erweitert das Framework für sichere Softwareentwicklung um Praktiken, die speziell für KI-Modelle gelten, einschließlich des Nachweises von Integrität und Herkunft.
- In Mai 2026, CISA und seine internationalen G7-Partner veröffentlichte Leitlinien zu einer Software-Stückliste für KI, in denen definiert wird, was in dieses Inventar gehört: Modelle, Datensätze, Komponenten, Anbieter und Abhängigkeiten.
Die Richtung ist klar: die SBOM expandiert zu einer KI-BOM. Was man nicht inventarisieren kann, kann man weder zertifizieren noch bestätigen. Und heutzutage können die meisten Organisationen das nicht:
- 43% Sie können die KI-Tools, die sie bereits verwenden, weder prüfen noch inventarisieren.
- 79% Sie haben keinen Einblick in die KI-Agenten und MCP-Systeme, die in ihrer eigenen Umgebung laufen.
In regulierten Umgebungen entwickelt sich die Bestandsaufnahme von einer bewährten Praxis zu einer vertraglichen Erwartung oder Compliance-Pflicht. Eine Bestandsaufnahme zeigt jedoch nur den vorhandenen Bestand an. Allein kann sie einen Angriff nicht verhindern.
Die Lücke: ein EDR für AppSec
SAST und SCA Tools sind darauf ausgelegt, Code und Abhängigkeiten zu analysieren, nicht das Verhalten eines Agenten oder dessen Konfiguration. EDR Es erkennt zwar Prozesse und Netzwerkverbindungen, aber es fehlt ihm typischerweise der Kontext der Anwendungssicherheit, um eine Abhängigkeit oder eine Agentenkonfiguration zu interpretieren. Zwischen diesen beiden Werkzeugkategorien klafft eine Lücke – genau dort, wo heute Code generiert wird und wo sich die Angriffsfläche für KI-Systeme befindet.
Diese Lücke weist drei blinde Flecken auf:
- KI-Ressourcen. Modelle, Agenten und MCP-Server werden nicht auf Ihrem angezeigt SASToder SCADas ist wie ein Radar. Man kann nicht inventarisieren, was man nicht sieht.
- Konfigurationsdateien. Fähigkeiten, Regeln und MCP-Konfigurationen prägen das Verhalten von Agenten, werden aber typischerweise so überprüft, als wären sie harmloser Klartext.
- Paketinstallationen. A Eine schädliche Abhängigkeit kann ausgeführt werden, bevor ihre Schädlichkeit bekannt ist.und dann Geheimnisse und Tokens zu exfiltrieren, ohne dass irgendjemand dies genehmigt.
Wie Xygeni es schließt
Was ein EDR für Endpunkte leistet, Xygeni Shield leistet für den KI-gestützten Entwicklungszyklus Folgendes: Es schützt den Ort, an dem Code erstellt wird, und berücksichtigt dabei den Kontext der Anwendungssicherheit.
- Sichtbarkeit, wo SAST und SCA nicht erreichen. Xygeni kennzeichnet schädliche Skills und Regeldateien, analysiert MCP-Konfigurationen und erstellt eine revisionssichere Umgebung. KI-BOM, abgebildet auf die OWASP LLM, MCP und Agentic Skills Top 10s.
- Intelligenz, nicht nur Unterschriften. MEW (Malware Early Warning) analysiert das Verhalten und das Risiko eines Pakets, um es zu blockieren, bevor eine CVE-Meldung, eine Sicherheitswarnung oder eine öffentliche Signatur vorliegt. Aktuelle Netzwerkinformationen unterbrechen Verbindungen zu bekanntermaßen schädlicher Infrastruktur.
- Ein einziger Kontrollpunkt, vom Code bis zum Endpunkt. Ein einzelner Agent, der ohne Umstrukturierung der Umgebung eingesetzt wird und über integrierte Nachweise zur europäischen Datensouveränität und Compliance verfügt.
In einer Live-Demonstration verhinderte diese Richtliniendurchsetzung den Versuch eines KI-Agenten, ein Schadprogramm über drei verschiedene Installationspfade (virtuelle Umgebung, Paketmanager und direkter Download) zu installieren, bevor die Installation abgeschlossen werden konnte. Alle Vorgänge wurden in Echtzeit protokolliert und konnten an ein Security Operations Center (SOC) exportiert werden. Die Einrichtung eines ersten Projekts dauert in der Regel etwa eine Stunde; die Ausweitung des Schutzes auf eine gesamte Organisation dauert je nach Struktur üblicherweise ein bis zwei Wochen.
FAQ
Was ist die Angriffsfläche einer KI in einem Absatz?
Die Angriffsfläche einer KI umfasst alle Modelle, Agenten, MCP-Server, Fähigkeiten, Regeldateien und KI-generierten Abhängigkeiten, über die Risiken in eine Anwendung gelangen können, oft bevor diese von einem Menschen geprüft wird. Sie geht über herkömmlichen Code und Abhängigkeiten hinaus und schließt auch Konfigurationsdateien und Anweisungen ein, die das Verhalten eines KI-Agenten bestimmen.
Wie kann ich feststellen, ob ein von meinem KI-Assistenten vorgeschlagener Paketname eine Halluzination oder einfach nur legitim, aber ungewohnt ist?
Vor der Installation prüfen: Überprüfen Sie die Registry und analysieren Sie den tatsächlichen Inhalt und Zweck des Pakets, anstatt sich allein auf den Namen zu verlassen. Xygeni automatisiert diese Prüfung in Echtzeit während der Codegenerierung, sodass eine Installation vor der Ausführung genehmigt oder blockiert wird, unabhängig davon, ob Sie das Paket kennen oder nicht.
Betrifft Slopsquatting alle KI-Modelle gleichermaßen?
Die Untersuchung, die dem Wert von 19.7 % zugrunde liegt, umfasste mehrere Modelle und stellte fest, dass das Problem weit verbreitet ist und nur geringe Unterschiede zwischen den Modellen aufweist. Es handelt sich um ein Muster, das sich auf die KI-gestützte Entwicklung im Allgemeinen bezieht und nicht um einen Fehler, der spezifisch für einen einzelnen Assistenten ist.
Können wir nachträglich überprüfen, ob wir bereits ein fehlerhaftes oder schädliches Paket installiert haben?
Ja. Die Plattform von Xygeni bietet Kunden Zugriff auf eine gepflegte Datenbank erkannter Schadsoftwarepakete, die mit Ihrem bestehenden Komponentenbestand abgeglichen werden kann, sodass Sie mit wenigen Klicks überprüfen können, ob bereits installierte Komponenten eine bekannte Bedrohung darstellen.
Wie lange dauert die Implementierung in einem mittelständischen Unternehmen mit mehreren Teams?
Die Einführung eines ersten Projekts dauert in der Regel etwa eine Stunde. Die Skalierung auf eine gesamte Organisation dauert üblicherweise ein bis zwei Wochen, abhängig von der Teamstruktur und den Arbeitsweisen.
Erstellen Sie kostenlos eine Karte Ihrer KI-Angriffsfläche.
Ermitteln Sie kostenlos den KI-Fußabdruck Ihrer Anwendung: Erstellen Sie ein Konto und Führen Sie in wenigen Minuten einen ersten Scan durch.Beginnen Sie mit einer einzelnen Anwendung, prüfen Sie, welche KI darin enthalten ist, und ermitteln Sie, welcher Teil Ihrer KI-Angriffsfläche gefährlich ist.
*Einige der oben genannten Funktionen werden durch Xygeni Shield und die ASPM/KI-Sicherheitsmodule; die Verfügbarkeit kann je nach Tarif variieren. Siehe xygeni.io Für aktuelle Produktdetails.
