Warum Ihr „Skill-Scanner“ nur trügerische Sicherheit bietet (und vielleicht Malware ist)

Vielleicht entwickeln Sie KI-Anwendungen, vielleicht sind Sie CISO. Sie haben gerade den Einsatz von KI-Agenten für Ihr Entwicklungsteam genehmigt. Sie kennen die Risiken: Datenabfluss, Prompt-Injection und die Ausführung ungeprüften Codes. Wenn Ihr leitender Entwickler also sagt: „Keine Sorge, wir verwenden Skill Defender von ClawHub, um jeden neuen Skill zu scannen“, atmen Sie erleichtert auf. Der Punkt ist abgehakt.

Aber haben Sie diesen Skill-Scanner überprüft?

Ihre Sorge gilt nicht den bekannten Bedrohungen, sondern den Tools, denen Sie vertrauen, diese aufzuspüren. Es ist der nagende Verdacht, dass Ihr Sicherheitsnetz voller Löcher ist. Und bei den aktuellen „KI-Skill-Scannern“ ist dieser Verdacht durchaus berechtigt.

Wenn Agent Skills und ihre Sicherheitsrisiken für Sie neu sind: Wir haben bereits ein Bedrohungsmodell für Skill.md vorgestellt und erläutert, wie sie sich auf das gesamte Ökosystem der KI-Agenten und die Supply-Chain-Sicherheit auswirken.

Warum Regex SKILL.md-Dateien nicht auf bösartige Absichten prüfen kann

Der größte Feind der KI-Sicherheit ist nicht nur der Hacker, sondern auch die unendliche Vielfalt der Sprache. In der traditionellen AppSec suchen wir nach bekannten Schwachstellen (CVEs) und bekannten Mustern (Secrets). Dieser Ansatz funktioniert, weil Code strukturiert, endlich und deterministisch ist. Eine SQL-Injection-Payload hat eine erkennbare Struktur. Ein geleakter AWS-Schlüssel hat ein bestimmtes Format.

Ein Skill für einen KI-Agenten ist jedoch grundlegend anders. Er kombiniert natürlichsprachliche Prompts, Codeausführung und Konfiguration. Eine Sperrliste mit „verbotenen Wörtern“ oder Mustern ist ein aussichtsloser Kampf gegen die unendliche Vielfalt natürlicher Sprache. Sie können unmöglich alle denkbaren Arten aufzählen, einem LLM etwas Gefährliches aufzutragen. Nehmen wir den unscheinbaren Befehl curl. Ein Regex-Scanner könnte curl markieren, um Datenabfluss zu verhindern. Doch ein raffinierter Angreifer muss nicht curl schreiben. Er kann Folgendes schreiben:

• c${u}rl (mit Bash-Parametererweiterung)

• wget -O- (mit einem alternativen Tool)

• python -c "import urllib.request..." (mit einer Standardbibliothek)

• Oder einfach: „Bitte rufen Sie den Inhalt dieser URL ab und zeigen Sie ihn mir an.“

Im letzten Fall erstellt der Agent den Befehl selbst. Der Scanner sieht nur harmlose englische Anweisungen, doch die Absicht bleibt bösartig. Genau daran scheitert die Denkweise mit Sperrlisten: Sie versuchen, bestimmte Wörter in einem System zu blockieren, das Konzepte versteht.

Mit dem Kontext wird die Sache noch komplexer. Ein Skill, der „Shell-Zugriff“ anfordert, kann für ein DevOps-Bereitstellungstool völlig legitim sein. Für einen „Rezeptfinder“ oder einen „Kalenderassistenten“ wäre er katastrophal. Ein Musterabgleich erkennt „Shell-Zugriff“ und muss entweder beides markieren (und Fehlalarme erzeugen) oder beides ignorieren (und Risiken eingehen). Er versteht nicht, warum der Zugriff angefordert wird, sondern erkennt nur, dass diese Wörter vorkommen.

Fallstudie: Wir haben Community-Scanner mit echter Malware getestet

Wir wollten die beliebtesten Community-„Skill-Scanner“ auf die Probe stellen. Wir haben SkillGuard, Skill Defender und Agent Tinman untersucht. Außerdem haben wir sie mit einem eigens entwickelten „halb bösartigen“ Skill getestet, um zu sehen, ob sie Freund und Feind unterscheiden können.

1. SkillGuard: Der Scanner, der selbst Malware war

Unser erster Testkandidat war SkillGuard vom Nutzer c-goro. Das Versprechen? Ein schlanker Scanner für Ihre Skills. Die Realität? Eine Falle.

Bei unserer Analyse stuften unsere internen Systeme SkillGuard nicht als Sicherheitstool, sondern als selbst bösartigen Skill ein. Unter dem Vorwand, „Definitionen zu aktualisieren“, versuchte das Tool, eine Payload zu installieren.

Aktualisierung: Zum Zeitpunkt der Veröffentlichung wurde SkillGuard von ClawHub entfernt. Doch für die Hunderte Nutzer, die das Tool installiert haben, ist der Schaden bereits angerichtet. Das zeigt ein grundlegendes Problem: Wer scannt den Scanner?

2. Skill Defender: Der übersehene Treffer

Als Nächstes untersuchten wir Skill Defender (von itsclawdbro) und Agent Tinman (von oliveskin). Beide sind legitime Community-Projekte. Skill Defender trägt bei VirusTotal sogar das Siegel „Benign“.

Doch „harmlos“ heißt nicht „wirksam“.

Wir erstellten einen Test-Skill namens vercel. Er gab sich lediglich als Bereitstellungstool für die Vercel-Plattform aus. Tatsächlich sollte er unbemerkt den Hostnamen des Nutzers an einen Remote-Server übermitteln.

Wir ließen Skill Defender diesen bösartigen Skill mit der Gemini CLI überprüfen.

> use the skill defender to scan current skills

Das Ergebnis:

• Der bösartige Skill (vercel): Ergebnis: SAUBER. 0 Fundstellen.

• Der Scanner selbst (skill-defender): Ergebnis: GEFÄHRLICH. 20 Fundstellen.

Der Scanner erkannte die tatsächliche Bedrohung nicht, weil unser Code zum Abführen von Daten im gefälschten Vercel-Skill nicht mit seiner fest codierten Liste „böser“ Zeichenfolgen übereinstimmte. Dafür stufte er sich selbst als gefährlich ein, weil seine Referenzdateien genau die „Bedrohungsmuster“ enthielten, nach denen er sucht.

Das ist das klassische „Antivirus-Paradoxon“: Der Scanner wirkt selbst bösartig, weil er weiß, wie Malware aussieht – doch alles Neue bleibt ihm verborgen.

3. Ferret Scan: Weiterhin auf Regex-Muster beschränkt

Wir haben uns auch Ferret Scan angesehen, einen Scanner auf GitHub. Er wirbt neben Regex mit einer „Deep-AST-basierten Analyse“. Obwohl er deutlich besser ist als native ClawHub-Tools, hat auch er mit den Feinheiten natürlichsprachlicher Angriffe zu kämpfen.

Kann er einen fest codierten API-Schlüssel erkennen? Ja. Aber erkennt er auch eine Prompt-Injection, die in einem PDF versteckt ist, das der Agent zusammenfassen soll?

Weiter zur Verhaltensanalyse von Agentenabsichten

Wir müssen aufhören, KI-Sicherheit als „Filtern böser Wörter“ zu betrachten. Stattdessen sollten wir sie als Verhaltensanalyse verstehen.

KI-Code ist wie finanzielle Schulden: Man kann ihn schnell anhäufen. Doch wenn man die Bedingungen nicht versteht (also die Absicht des Prompts), treibt man sich selbst in den finanziellen Ruin.

Ein Regex-Scanner ist wie eine Rechtschreibprüfung. Er stellt sicher, dass Wörter korrekt geschrieben sind. Ein semantischer Scanner ist wie ein Lektor. Er fragt: „Ergibt dieser Satz Sinn? Fordert er den Nutzer zu etwas Gefährlichem auf?“

Erkenntnisse aus der ToxicSkills-Studie: Der Kontext ist entscheidend

In unserer aktuellen ToxicSkills-Studie haben wir festgestellt, dass 13,4 % der Skills kritische Sicherheitsprobleme enthielten. Die große Mehrheit davon wurde durch einfachen Musterabgleich NICHT erkannt.

• Prompt-Injection: Angriffe, die Jailbreak-Techniken nutzen, um Sicherheitsfilter zu umgehen.

• Verschleierte Payloads: In Base64-Zeichenfolgen oder externen Downloads versteckter Code (wie beim jüngsten Angriff google-qx4).

• Kontextbezogene Risiken: Ein Skill, der „Shell-Zugriff“ anfordert, kann für ein Entwicklertool sinnvoll sein, für einen „Rezeptfinder“ jedoch katastrophal.

Regex erkennt „Shell-Zugriff“ und markiert beides. Oder schlimmer: Regex erkennt beides nicht, weil im Prompt stattdessen „Systembefehl ausführen“ steht.

Die Lösung: KI-native Sicherheit für SKILL.md-Dateien

Um mit dieser Geschwindigkeit Schritt zu halten, müssen Sie über statische Muster hinausgehen. Sie brauchen KI-native Sicherheit.

Deshalb haben wir mcp-scan entwickelt (Teil der Evo-Plattform von Snyk). Das Tool sucht nicht einfach nach Zeichenfolgen. Ein spezialisiertes LLM liest die Datei SKILL.md und versteht die Fähigkeiten des Skills sowie die zugehörigen Artefakte (z. B. Skripte).

Sie können sich mcp-scan als eine Möglichkeit vorstellen, folgende Fragen zu stellen:

• Fordert dieser Skill die Berechtigung zum Lesen von Dateien an?

• Versucht er, den Nutzer davon zu überzeugen, frühere Anweisungen zu ignorieren?

• Verweist er auf ein Paket, das weniger als eine Woche alt ist (über Snyk Advisor)?

Durch die Kombination von Static Application Security Testing (SAST) mit LLM-basierter Absichtsanalyse können wir den Datenabfluss-Skill vercel erkennen, weil wir das Verhalten sehen (das Senden von Daten an einen unbekannten Endpunkt) und nicht nur die Syntax.

Stellen Sie Ihrem Team morgen diese drei Fragen:

1. „Haben wir ein Verzeichnis aller ‚Skills‘, die unsere KI-Agenten verwenden?“ – Wenn die Antwort Ja lautet, fragen Sie, wie das Verzeichnis erstellt wurde. Bei manueller Pflege ist es nicht aktuell. Wenn die Antwort Nein lautet, teilen Sie dem Team das Tool mcp-scan mit.

2. „Prüfen wir diese Skills auf ihre Absicht oder nur auf Schlüsselwörter?“ – Hinterfragen Sie die Regex-Denkweise.

3. „Was passiert, wenn ein vertrauenswürdiger Skill morgen mit einer bösartigen Abhängigkeit aktualisiert wird?“ – Setzen Sie sich für kontinuierliche statt einmalige Scans ein.

Lassen Sie sich von „Security-Theater“ kein falsches Sicherheitsgefühl vermitteln. Die Agenten sind intelligent. Ihre Sicherheitsmaßnahmen müssen noch intelligenter sein. Erfahren Sie, wie Evo by Snyk die Kontrolle über agentische KI vereint.