SkillSpector im Test: Wie sicher sind unsere Claude Code Skills?

Skills sind kleine Anleitungspakete, die Agenten wie Claude Code, Codex CLI oder Gemini CLI beibringen, wie ein bestimmter Arbeitsschritt abläuft. Wer einen Skill installiert, gibt ihm damit weitreichenden Einfluss: Der Agent liest die Anweisungen und führt sie mit denselben Rechten aus, mit denen er auch auf das Dateisystem und das Netzwerk zugreift. Eine Prüfinstanz dazwischen gibt es bisher kaum.

Hier setzt SkillSpector an, ein Open-Source-Scanner von NVIDIA. Die Zahlen aus der zugehörigen Untersuchung klingen alarmierend: Von 42.447 analysierten Skills enthielten 26,1 Prozent Schwachstellen, bei 5,2 Prozent deutet das Muster auf bösartige Absicht hin. Wir wollten wissen, was solche Zahlen in der Praxis bedeuten, und haben den Scanner auf unser eigenes Setup losgelassen: 76 installierte Skills aus unserem Arbeitsalltag. Was als schneller Test begann, wurde eine kleine Detektivgeschichte mit überraschendem Täter.

Skills laufen mit vollem Vertrauen

Ein Skill ist im Kern eine Markdown-Datei mit Anweisungen, oft ergänzt um Skripte, die der Agent bei Bedarf ausführt. Anders als bei Browser-Extensions oder App-Stores existiert dafür kein Review-Prozess. Wer einen Skill aus einem GitHub-Repository oder einem Marktplatz installiert, verlässt sich darauf, dass der Autor nichts Schädliches hineingeschrieben hat.

Das Angriffsmodell unterscheidet sich dabei von klassischer Malware. Ein bösartiger Skill braucht keinen Exploit. Es reicht, dem Agenten in normaler Sprache Anweisungen zu geben, etwa Umgebungsvariablen auszulesen und an einen fremden Server zu schicken. Der Agent führt das aus, weil Anweisungen auszuführen seine Aufgabe ist. Wie schnell aus zu viel Vertrauen in Werkzeuge ein reales Risiko wird, haben wir schon im Beitrag über Vibe Coding und eine CVSS-10-Schwachstelle beschrieben.

Was SkillSpector macht

SkillSpector beantwortet die Frage, ob ein Skill vor der Installation auffällige Muster enthält. Der Scanner arbeitet zweistufig: Zuerst läuft eine schnelle statische Analyse mit 68 Erkennungsmustern in 17 Kategorien, darunter Prompt Injection, Datenabfluss, Rechteausweitung und Lieferketten-Risiken. Optional folgt eine zweite Stufe, in der ein Sprachmodell die Funde semantisch bewertet. Für Abhängigkeiten fragt das Tool live die Schwachstellendatenbank OSV.dev ab.

Am Ende steht ein Risiko-Score von 0 bis 100 mit einer Empfehlung. Ausgeben lässt sich das Ergebnis im Terminal oder als JSON, Markdown und SARIF, womit sich der Scanner auch in CI-Pipelines einbinden lässt. Das Projekt steht unter Apache-2.0-Lizenz und hat seit dem Start im März 2026 rund 14.000 Sterne auf GitHub gesammelt.

Unser Testaufbau: 76 Skills aus dem echten Setup

Statt Beispiel-Skills zu scannen, haben wir das komplette Claude-Code-Setup unserer Testumgebung geprüft: 30 direkt installierte Skills, darunter unsere SEO-Toolchain und ein selbst geschriebener Shopify-Crawler-Skill, plus 46 Skills aus installierten Plugins. Diese Umgebung macht den Test gerade praxisnah: Hier probieren wir Skills aus, ohne die Update-Routinen, mit denen wir unsere Produktivumgebung aktuell halten. Ihr Zustand entspricht damit ziemlich gut einem typischen Nutzer-Rechner, auf dem Skills einmal installiert und dann vergessen werden. Gescannt wurde rein statisch, also ohne die optionale LLM-Bewertung. Das entspricht dem Modus, den die meisten Nutzer als schnellen Vorab-Check fahren würden.

Erste Runde: vier Mal CRITICAL

Die nackten Zahlen wirken zunächst beunruhigend:

• 46 von 76 Skills blieben komplett unauffällig, Score 0.

• Vier Skills erreichten die Einstufung CRITICAL, mit Scores zwischen 89 und 100.

• Unser eigener Shopify-Crawler-Skill landete mit Score 59 bei HIGH.

• Insgesamt meldete der Scanner über 100 Einzelfunde, von Prompt Injection bis zu verwundbaren Abhängigkeiten.

Hätten wir an dieser Stelle aufgehört, wäre die Schlagzeile fertig gewesen: Mehr als jeder dritte Skill auffällig, vier davon kritisch. Genau so entstehen viele der Zahlen, die derzeit durch Fachartikel geistern. Der interessante Teil beginnt aber erst nach dem Scan.

Drei der vier Alarme lösen sich auf

Wir haben jeden CRITICAL-Fund manuell im Quelltext nachgeprüft. Bei einem Brainstorming-Skill meldete der Scanner versteckte Anweisungen in einer Serverdatei. An der bemängelten Stelle steht: ein HTML-Template mit CSS-Regeln für ein Logo. Die Mustererkennung hatte Formulierungen im Stylesheet als verdeckte Instruktionen gelesen.

Bei einem Figma-Plugin lagen fast alle zwölf Funde in einer einzigen Datei: einer TypeScript-Definitionsdatei mit über 10.000 Zeilen API-Dokumentation. Wo ein Kommentar beschreibt, was eine Funktion nicht tun darf, erkannte der Scanner ein Anti-Refusal-Statement. Dasselbe Muster bei einem dritten Skill: Die angebliche Weigerungs-Umgehung lautet im Original sinngemäß, dass Messwerte im Report niemals versteckt werden dürfen. Eine Stilregel für die Ausgabe, keine Manipulation.

Der dritte CRITICAL-Fall zeigt eine Grauzone. Ein Komprimierungs-Skill, der Konfigurationsdateien im Agenten-Verzeichnis liest und umschreibt, bekam die Kategorie Agent Snooping zugewiesen. Der Befund stimmt technisch, nur ist dieses Verhalten der dokumentierte Zweck des Skills. Der Scanner kann Absicht nicht von Missbrauch unterscheiden, und das sagt er in seiner Dokumentation auch selbst.

Der vierte Fund schrumpft beim Nachfassen

Blieb der Spitzenreiter: unsere SEO-Toolchain, ein umfangreiches Skill-Paket mit eigenen Python-Skripten, Score 100, 48 Einzelfunde. Den Großteil davon konnten wir schnell einordnen. Ein SEO-Werkzeug, das API-Schlüssel aus Umgebungsvariablen liest und damit Anfragen an Google, Moz oder DataForSEO* (Werbung) stellt, sieht für eine statische Analyse zwangsläufig wie Datenabfluss aus. Das ist seine Funktionsweise. Übrig blieben die Lieferketten-Funde: sechs Python-Abhängigkeiten, für die OSV.dev bekannte Schwachstellen listet.

Auch dieser Fund schrumpfte beim zweiten Blick. Die requirements.txt des Pakets arbeitet mit Mindestversionen, nicht mit festen Pins, der Scanner las die Untergrenzen aber als installierte Stände. Der Abgleich mit den tatsächlich installierten Paketen ergab: Zwei waren wirklich veraltet und brauchten ein Update, der Rest lief längst in gefixten Versionen. Ärgerlich war einer der beiden echten Treffer trotzdem, eine Pillow-Version mit dreizehn offenen Advisories, darunter eine Command Injection, die ausgerechnet Windows betrifft. Unsere Arbeitsplattform.

Die eigentliche Schwachstelle: unsere Installation war fünf Monate alt

Beim Vorbereiten des Dependency-Updates kam der eigentliche Befund ans Licht. Das Open-Source-Projekt hinter der Toolchain hatte seine Versionsuntergrenzen anderthalb Wochen vor unserem Test bereits angehoben und eine der verwundbaren Abhängigkeiten komplett entfernt. Upstream war sauber. Veraltet war die Kopie in unserer Testumgebung, Stand Februar, fünf Monate alt. Unsere Produktivsysteme durchlaufen eine Update-Pflege und waren nicht betroffen; die Testumgebung durchläuft sie bewusst nicht. Sie zeigt dadurch ungeschönt, was sich auf einem Rechner ansammelt, der keine solche Routine hat.

Das ist die unbequeme Eigenheit des Skill-Ökosystems: Skills werden bei der Installation kopiert, danach existiert kein Update-Kanal. Kein Paketmanager meldet neue Versionen, kein Dependabot schlägt Alarm, nichts signalisiert, dass Upstream längst Fixes veröffentlicht hat. Die Kopie altert still vor sich hin. Nach dem Neu-Installieren über den offiziellen Installer waren fast alle Lieferketten-Funde erledigt. Übrig blieb eine einzige veraltete Versionsuntergrenze im Upstream-Projekt, die haben wir als Pull Request eingereicht.

Der Gegen-Scan: alles sauber, trotzdem CRITICAL

Nach dem Update haben wir den Scan wiederholt und erwartet, dass der Score deutlich fällt. Das Gegenteil passierte: weiterhin CRITICAL, jetzt mit 300 Einzelfunden statt 48. Die Erklärung steckt in der neuen Version der Toolchain. Sie bündelt eine eigene Python-Umgebung und einen Playwright-Browser direkt im Skill-Ordner, und der Scanner prüft diese Fremddateien mit. 229 der 300 Funde lagen in gebündelten Browser-Dateien, die mit dem Skill-Code nichts zu tun haben.

Mein Lieblingsfund aus dieser Runde: Die Datei url_safety.py wurde als SSRF-Risiko geflaggt, Kategorie Cloud Metadata Access. Dieses Modul ist die SSRF-Schutzfunktion der Toolchain. Es blockt Anfragen an Cloud-Metadata-Adressen, und weil diese Adressen dafür im Code stehen müssen, meldet der Scanner den Wachhund als Einbrecher.

Für solche Fälle bringt SkillSpector das passende Werkzeug übrigens selbst mit: Über eine Baseline lassen sich geprüfte Funde unterdrücken, sodass künftige Scans nur neue Auffälligkeiten melden. Ohne diese Pflege bleibt der Score dauerhaft rot, und ein dauerhaft roter Score ist so nützlich wie eine Alarmanlage, die immer klingelt.

Weshalb regelmäßige Scans wichtig sind

Der Test zeigt noch etwas Grundsätzliches: Ein Scan ist eine Momentaufnahme. Schwachstellendatenbanken bewegen sich täglich weiter, und eine Abhängigkeit, die heute sauber durchläuft, kann morgen eine CVE-Meldung tragen, ohne dass sich am Code eine Zeile geändert hat. Ein Teil der Advisories zu unserem Pillow-Fund ist jünger als die Kopie, auf der wir sie fanden. Wer nur beim Installieren prüft, sieht solche Meldungen nie.

Dazu wächst der Bestand schleichend. Wer regelmäßig neue Skills ausprobiert, hat nach ein paar Monaten Dutzende Anleitungspakete mit Ausführungsrechten auf dem Rechner, von denen viele nie einen Erstcheck gesehen haben. Unsere Testumgebung ist dafür das beste Beispiel. Ein wiederkehrender Scan, etwa monatlich oder als SARIF-Report in der CI, fängt beides ab: neu gemeldete Schwachstellen im alten Bestand und neu dazugekommene Skills. Mit gepflegter Baseline bleibt das bekannte Rauschen dabei draußen.

Damit das nicht bei guten Vorsätzen bleibt, hier die Routine, die wir dafür eingerichtet haben. Sie aktualisiert die Skills, legt beim ersten Lauf eine Baseline an und meldet danach nur noch neue Funde. Einmal im Monat per Cron oder Windows-Taskplaner angestoßen reicht für ein privates Setup aus.

Ein Hinweis aus der Praxis: In Version 2.5.1 funktioniert die Baseline nicht zusammen mit dem rekursiven Modus, deshalb scannt die Routine den Bestand als Ganzes. Bei uns unterdrückt die Baseline 348 geprüfte Funde, der Lauf meldet null neue, und die Einstufung fällt von CRITICAL auf LOW. So sieht ein Alarm aus, dem man wieder glauben kann.

Was die 26 Prozent aus der Studie bedeuten

Unser Test verschiebt den Blick auf die Studienzahlen. Wenn 26,1 Prozent von 42.447 Skills Schwachstellen enthalten, steckt in dieser Menge vermutlich ein erheblicher Anteil an Funden wie unseren: legitime Werkzeuge, deren Verhalten für statische Muster verdächtig aussieht, dazu reale, aber unspektakuläre Versäumnisse wie veraltete Abhängigkeiten und alternde Installationskopien. Die 5,2 Prozent mit mutmaßlich bösartiger Absicht sind die eigentlich beunruhigende Zahl, denn dort geht es um Skills, die gezielt Schaden anrichten sollen.

Beide Lesarten führen zur selben Konsequenz. Skills aus fremden Quellen verdienen vor der Installation denselben Blick, den ein npm-Paket oder eine Browser-Extension bekommen sollte. Der Unterschied: Bei Skills gab es dafür bislang schlicht kein etabliertes Werkzeug.

So setzen wir SkillSpector künftig ein

Nach dem Test bleibt SkillSpector bei uns im Werkzeugkasten, mit klar umrissener Rolle. Vor der Installation eines fremden Skills läuft ein statischer Scan als Erstfilter. Schlägt er an, entscheidet nicht der Score, sondern die manuelle Prüfung der gemeldeten Stellen. Für die eigenen Skill-Bestände kommt ein zweiter Handgriff dazu, den uns dieser Test gelehrt hat: installierte Kopien regelmäßig gegen Upstream abgleichen, denn dort lag unser einziges reales Problem.

Wer tiefer einsteigen will, kann die zweite Analysestufe mit LLM-Bewertung zuschalten. Sie kostet API-Tokens, dürfte aber einen Großteil der Fehlalarme aussortieren, die uns im statischen Modus begegnet sind. Bei der Gelegenheit lohnt sich auch ein Blick darauf, was solche Scans an Kontext verbrauchen: Warum wir Terminal-Ausgaben in Claude Code generell filtern, steht im Beitrag über RTK, den Rust Token Killer.

Fazit

SkillSpector schließt eine Lücke: Erstmals gibt es einen ernstzunehmenden, offenen Scanner für die Sicherheitsprüfung von AI-Agent-Skills. Unser Praxistest zeigt zugleich, wie viel Interpretationsarbeit zwischen Score und Wahrheit liegt. Von vier CRITICAL-Einstufungen war eine substanziell, und selbst die zeigte am Ende nicht auf den Skill, sondern auf die alternde Installationskopie unserer Testumgebung. Der Scanner hat uns trotzdem zu einem realen Fix geführt, nur eben anders als gedacht. Wer die Scores als Startpunkt für eine eigene Bewertung nutzt, bekommt ein brauchbares Werkzeug. Wer sie als Urteil liest, sortiert harmlose Skills aus und wiegt sich bei ungescannten in falscher Sicherheit.

Wenn du wissen willst, wie es um die Sicherheit deines eigenen Agent-Setups oder deines Shops steht, sprich uns an. Wir prüfen Setups mit demselben Ansatz wie in diesem Test: Werkzeuge liefern Kandidaten, Menschen treffen die Bewertung.