Was fast 10.000 Entwicklerumgebungen über Risiken der agentischen Entwicklung verraten

Wichtigste Erkenntnisse

• KI-Coding-Tools sind weit verbreitet: 43 % der Entwickler nutzen zwei oder mehr KI-Coding-Umgebungen.

• MCP ist bereits weit verbreitet: 50,8 % der Entwickler haben mindestens einen MCP-Server installiert.

• MCP-Risiken treten bereits auf: 1 von 7 Entwicklern mit MCP-Servern hatte mindestens einen Sicherheitsbefund.

• Agent-Skills schaffen eine weitere Risikodimension: 22,8 % der Entwickler hatten mindestens einen Skill installiert.

• Prompt-Injection ist in aktiv genutzten Tools präsent: Snyk fand 392 bestätigte Prompt-Injection-Befunde in Tool-Beschreibungen.

Jahrelang haben sich Application-Security-Teams auf vertraute Fragen konzentriert: Ist der Code sicher? Sind Abhängigkeiten anfällig? Ist die Build-Pipeline geschützt? Werden Probleme erkannt, bevor sie in die Produktion gelangen?

Agentische Entwicklung wirft eine neue Frage auf: Welche Systeme, Tools, Anweisungen und Berechtigungen haben zur Erstellung dieses Codes beigetragen?

KI-Coding-Agenten schlagen längst nicht mehr nur Code-Schnipsel vor oder vervollständigen Codezeilen. Sie sind zunehmend mit MCP-Servern, Skills, Integrationen und weiteren Komponenten der Softwareentwicklungsumgebung verbunden. Sie können Kontext abrufen, externe Dienste aufrufen, Aktionen ausführen und Code generieren – auf eine Weise, die bestehende Sicherheitsprozesse nicht erfassen oder steuern können.

Damit wird die Entwicklerumgebung selbst zu einem Teil der Software-Supply-Chain, den Teams verstehen und steuern müssen. Laut neuen Snyk-Forschungsergebnissen ist dieser Wandel bereits in realen Entwicklerumgebungen sichtbar.

Snyk analysierte fast 10.000 Entwicklerumgebungen sowie Umgebungen früher ADS-Anwender und stellte messbare Risiken bei KI-Coding-Tools, MCP-Servern und Agent-Skills fest. Die Daten weisen auf einen Wandel hin, den AppSec-Teams nicht länger als theoretisch abtun können: Agentische Entwicklung schafft eine neue Ebene der Software-Supply-Chain, die sich mit den meisten Sicherheitsprogrammen weder erkennen noch steuern lässt.

KI-Coding-Tools werden zu vernetzten Entwicklungsumgebungen

KI-Coding-Tools gehören heute zum Entwicklungsalltag. In vielen Unternehmen beschränkt sich ihre Nutzung jedoch nicht auf ein einziges genehmigtes Tool oder eine standardisierte Umgebung. Entwickler können mehrere KI-Coding-Umgebungen parallel nutzen, darunter Claude, Cursor, Windsurf, Gemini, Copilot, Kiro und VS-Code-Erweiterungen. Jedes Tool kann über eine eigene Konfiguration, eigene Integrationen, Kontextquellen und Berechtigungen verfügen. Für AppSec-Teams entsteht dadurch eine Herausforderung bei der Transparenz.

Die Verbreitung verschiedener KI-Tools wird zum Sicherheitsproblem, wenn jede Umgebung eine Verbindung zu externen Systemen herstellen, Anweisungen verarbeiten und beeinflussen kann, wie Code entsteht. Je mehr Tools im Einsatz sind, desto schwieriger lassen sich grundlegende Governance-Fragen beantworten:

• Welche KI-Coding-Umgebungen sind installiert?

• Womit sind sie verbunden?

• Über welche Berechtigungen verfügen sie?

• Welche Anweisungen beeinflussen ihr Verhalten?

• Arbeiten sie innerhalb oder außerhalb der genehmigten Sicherheitskontrollen?

Bei traditioneller AppSec können Teams oft beim Repository, bei der Build-Pipeline oder beim bereitgestellten Artefakt ansetzen. Bei agentischer Entwicklung kann das Risiko schon früher entstehen – in der Entwicklerumgebung, noch bevor Code eingecheckt wird.

MCP-Server werden zu einer neuen Ebene der Supply-Chain

MCP, das Model Context Protocol, ermöglicht KI-Agenten die Verbindung zu externen Tools und Datenquellen. Dazu können Code-Repositories, Browser-Automatisierung, Dokumentation, lokale Dateien, Issue-Tracker, Design-Tools und weitere Dienste im gesamten Softwareentwicklungszyklus gehören. MCP-Server sind also mehr als eine Komfortfunktion: Sie bestimmen mit, worauf Agenten zugreifen und welche Aktionen sie ausführen können.

Dabei handelt es sich um aktive Konfigurationen, über die Agenten direkt von Entwicklerrechnern aus mit externen Tools und Diensten interagieren können.

In der traditionellen Softwareentwicklung wird die Supply-Chain häufig anhand von Paketen, Abhängigkeiten, Containern und Artefakten betrachtet. Diese Komponenten lassen sich mit etablierten Prozessen scannen, inventarisieren, steuern und überwachen.

MCP-Server funktionieren jedoch anders und sind Teil der Zugriffsebene: Sie bestimmen, was Agenten sehen und tun können. Häufig werden sie lokal installiert oder außerhalb zentraler Prüfprozesse konfiguriert. Sie können Agenten zudem Zugriff auf sensible Systeme gewähren, bevor Code ein Repository, eine CI-Pipeline oder ein übliches Sicherheits-Gate erreicht. In agentischen Entwicklungsumgebungen zeigen sich bereits erste Risikosignale.

In der Praxis sieht dieses Risiko möglicherweise nicht wie ein anfälliges Paket aus, das in eine Anwendung eingebunden wurde. Stattdessen kann es sich um einen MCP-Server oder eine Agentenkonfiguration handeln, die beeinflusst, was ein Agent tut, welche Systeme er erreichen kann oder welchen Anweisungen er folgt.

So können beispielsweise Prompt-Injection-Risiken an Stellen auftreten, die beim herkömmlichen Scannen möglicherweise nicht geprüft werden. Snyk fand 392 bestätigte Prompt-Injection-Befunde in Tool-Beschreibungen und 98 bestätigte bösartige Code-Muster in Agent-Skill-Dateien – und zwar in Umgebungen, die zum Zeitpunkt des Scans bereits aktiv genutzt wurden.

Tool-Konfigurationen können unerwartete Zugriffswege schaffen. Anweisungen außerhalb von Code-Repositories können das Verhalten von Agenten beeinflussen. In Workflows mit hoher Autonomie kann ein Agent handeln, bevor ein Mensch das Ergebnis geprüft hat. Unternehmen müssen daher die Umgebungen absichern, in denen diese Tools eingesetzt werden.

Agent-Skills schaffen eine weitere Risikodimension

Eine separate Analyse von Umgebungen bei Design-Partnern aus Unternehmen untersuchte eine zweite Ebene der Supply-Chain: Agent-Skills. Skills sind Anweisungsdateien, die das Verhalten, die Standardeinstellungen, Personas, Workflows und wiederverwendbaren Fähigkeiten eines Agenten prägen. Sie können Teams dabei helfen, das Verhalten von Agenten zu standardisieren. Gleichzeitig schaffen sie eine weitere Ebene der Supply-Chain: Anweisungen, die geteilt, verändert, aus Ökosystemen Dritter bezogen oder außerhalb üblicher Code-Reviews ausgeführt werden können.

Skills können auf verschiedene Weise Risiken mit sich bringen:

• Anweisungen aus externen Quellen abrufen

• Agenten nicht kontrollierten Inhalten Dritter aussetzen

• Geheimnisse unsachgemäß handhaben

• Versteckte Anweisungen enthalten, die das Verhalten von Agenten manipulieren

Da Skills häufig geteilt oder aus Ökosystemen Dritter bezogen werden, können sie wie eine Supply-Chain-Komponente funktionieren – auch wenn sie nicht wie eine herkömmliche Abhängigkeit aussehen.

Separate Snyk-Forschung zum öffentlichen Ökosystem für Agent-Skills zeigt, wie sich dieses Risiko in der Praxis äußern kann. In der ToxicSkills-Studie analysierten Snyk-Forschende 3.984 Skills von ClawHub und skills.sh. Dabei enthielten 13,4 % mindestens ein Sicherheitsproblem mit kritischem Schweregrad, während 36,82 % mindestens eine Sicherheitslücke aufwiesen. Die Validierung durch Menschen bestätigte außerdem bösartige Payloads, die auf den Diebstahl von Zugangsdaten, die Installation von Hintertüren und die Exfiltration von Daten ausgelegt waren.

Wenn externe Anweisungen das Verhalten von Agenten beeinflussen können, reicht es nicht aus, nur den generierten Code abzusichern. Unternehmen müssen auch die Anweisungsebene verstehen, die beeinflusst, wie der Agent arbeitet.

Warum herkömmliche AppSec-Kontrollen erweitert werden müssen

Herkömmliche AppSec wurde für Code, Repositories, Pipelines und Artefakte entwickelt. Agentische Entwicklung bringt Risiken früher ins Spiel – innerhalb der Tools, Anweisungen und Konfigurationen, die den Code bereits vor seiner Entstehung prägen.

KI-Coding-Agenten können Risiken verursachen, bevor Code eingecheckt wird. MCP-Server können beispielsweise auf Entwicklerrechnern installiert sein, ohne im zentralen Inventar erfasst zu werden. Skills können das Verhalten beeinflussen, ohne wie Quellcode geprüft zu werden. Agenten können sich mit Tools verbinden und Aktionen ausführen, während sie außerhalb der herkömmlichen Grenzen von SAST, SCA, CI/CD oder Repository-basierten Kontrollen arbeiten.

Das macht bestehende AppSec-Ansätze nicht überflüssig. SAST, SCA, IaC-Scanning, Container-Sicherheit und Pipeline-Kontrollen bleiben unverzichtbar, reichen allein aber möglicherweise nicht mehr aus. Um mit der Weiterentwicklung der Softwareentwicklung Schritt zu halten, müssen Sicherheitsteams ihre Programme über die Absicherung von Code-Artefakten hinaus erweitern und auch die Systeme absichern, die diese erzeugen.

Dazu gehören Agenten, Tools, Integrationen, Anweisungen und Konfigurationen, die an der KI-gestützten Entwicklung beteiligt sind. Entscheidend ist die Transparenz: Wenn Sicherheitsteams nicht sehen können, welche Agenten eingesetzt werden, womit sie verbunden sind und welche Anweisungen sie verarbeiten, können sie die Risiken nicht wirksam steuern.

5 Maßnahmen, die Sicherheitsteams jetzt ergreifen sollten

Agentische Entwicklung verändert sich rasant. Die Lösung besteht jedoch nicht darin, die Einführung von KI zu blockieren oder Entwickler auszubremsen. Sicherheitsteams müssen Transparenz und Governance in die bereits genutzten Workflows integrieren – mit fünf konkreten Maßnahmen.

1. Finden Sie heraus, was Entwickler und Agenten nutzen: Erfassen Sie KI-Coding-Umgebungen, MCP-Server, Skills und Integrationen in allen Entwicklerumgebungen. Was Teams nicht sehen, können sie auch nicht steuern.

2. Betrachten Sie Agentenkonfigurationen als Teil der Software-Supply-Chain: Sicherheitsprüfungen sollten sich nicht nur auf Code und Abhängigkeiten erstrecken, sondern auch auf die Tools, Anweisungen und externen Komponenten, auf die Agenten angewiesen sind.

3. Erweitern Sie Richtlinien auf MCP-Server und Skills: Unternehmen brauchen eine Möglichkeit festzulegen, was zulässig ist, eingeschränkt wird, eine Genehmigung erfordert oder aufgrund des Risikos blockiert werden sollte.

4. Prüfen Sie Schutzmaßnahmen für Agentenaktionen: Mit wachsender Autonomie der Agenten müssen Sicherheitskontrollen näher am Zeitpunkt einer Aktion greifen – nicht erst, nachdem der Code erstellt wurde.

5. Integrieren Sie die Sicherheit agentischer Entwicklung in bestehende AppSec-Programme: Daraus sollte kein isolierter Governance-Bereich entstehen. Vielmehr sollte AppSec so erweitert werden, dass es der heutigen Softwareentwicklung Rechnung trägt.

Auf diesen Funktionen baut der Ansatz von Snyk für Agentic Development Security auf – von der Erkennung und Steuerung von MCP-Servern und Skills, bevor sie in Agenten-Workflows gelangen, über Schutzmaßnahmen innerhalb der Agentenausführung bis hin zur Validierung von KI-generiertem Code während seiner Erstellung.

Die Systeme absichern, die Software entwickeln

Die Absicherung von KI-generiertem Code ist notwendig, reicht allein aber nicht mehr aus. Da Agenten immer stärker in die Softwareentwicklung eingebunden werden, müssen Sicherheitsteams nicht nur den von Agenten erzeugten Code verstehen, sondern auch die Tools, Anweisungen, Integrationen und Berechtigungen, die das Ergebnis prägen. Zur Software-Supply-Chain gehören auch die agentischen Systeme, die überhaupt erst beim Entwickeln von Software helfen.

Der vollständige Bericht enthält alle Erkenntnisse: die am häufigsten installierten MCP-Server und ihre zugehörigen Risikoprofile, eine Aufschlüsselung der Arten von Skill-Befunden in Unternehmensumgebungen, die vollständigen Daten zu Prompt-Injection- und bösartigen Code-Mustern sowie einen detaillierten Maßnahmenkatalog für Sicherheitsteams. Laden Sie den Bericht herunter und erfahren Sie noch heute mehr.