SkillSpector ist ein Apache-2.0 Sicherheitsscanner von NVIDIA für KI-Agent-Fähigkeiten: Anweisungspakete, die Markdown, Skripte, Abhängigkeiten, Tooldefinitionen und Aktivierungsregeln enthalten können. Es akzeptiert ein lokales Verzeichnis, eine einzelne Datei, ein Zip-Archiv, ein Git-Repository oder eine URL und erzeugt Terminal-, JSON-, Markdown- oder SARIF-Ergebnisse mit einer Risikobewertung von 0–100.
Sein Wert ist das Bedrohungsmodell. Eine Fertigkeit ist nicht nur eine Dokumentation. Sobald ein Agent ihm folgt, können Anweisungen Dateizugriff, Shell-Ausführung, Verwendung von Anmeldeinformationen, Netzwerkübertragung oder dauerhafte Konfigurationsänderungen verursachen. SkillSpector prüft sowohl herkömmliche Softwarerisiken als auch agentenspezifische Probleme wie Prompt-Injection, übermäßige Agentur, Memory Poisoning, Triggermissbrauch und Tool-Description-Poisoning. Ein sauberer Bericht ist ein Beweis aus einer Analyseschicht vor der Installation – keine Garantie dafür, dass das Laufzeitverhalten sicher ist.
Wo SkillSpector in die Vertrauenspipeline passt
Quellidentität + Commit-Pin
|
v
Auspacken in isoliertem Arbeitsbereich
|
.-------+--------.
v v
Statische Regelabhängigkeit / OSV
AST + Taint-Signaturen + Metadaten
'-------+--------'
v
optionale semantische LLM-Überprüfung
|
menschliche Disposition
akzeptieren / beheben / mit Begründung unterdrücken / ablehnen
|
Sandbox + geringste Privilegien + Laufzeitüberwachung
Diese Reihenfolge ist wichtig. Das heutige Scannen einer nicht angehefteten URL beweist nicht, dass der Download von morgen identisch ist. Das Ausführen eines LLM über feindliche Anweisungen, ohne seine Anmeldeinformationen zu isolieren, führt zu einer weiteren Gefährdung. Das Hochladen einer SARIF-Datei ohne Blockierungsrichtlinie schafft Sichtbarkeit, aber keine Kontrolle. Behandeln Sie den Scanner als einen Schritt in einem reproduzierbaren Zulassungsprozess.
Was der zweistufige Analysator macht
| Bühne | Mechanismus | Stärke | Erwartete Schwäche |
|---|---|---|---|
| Statische Muster | Regex- und Regelabgleich über Skill-Dateien hinweg | Schnell, deterministisch und erklärbar | Gutartige Beispiele können übereinstimmen; neuartige Formulierungen können ausweichen |
| Verhaltens-AST | Erkennt Python Ausführungsprimitive und gefährliche Aufrufketten | Findet Codeverhalten über Schlüsselwörter hinaus | Führt keinen Code aus; Die Sprach- und Indirektionsabdeckung ist endlich |
| Verschmutzungsverfolgung | Sucht nach Flüssen von Eingaben/Geheimnissen/Dateien zur Ausführung oder zu Netzwerksenken | Verbindet Quelle und Senke auf einem sinnvollen Weg | Dynamischer Versand und komplexe Frameworks können den statischen Fluss zunichte machen |
| OSV-Suche | Fragt OSV.dev nach deklarierten Abhängigkeitsschwachstellen ab | Aktuelle Schwachstelleninformationen im Internet | Der Offline-Modus verwendet einen kleineren Fallback; Nicht deklarierter/verkaufter Code kann übersehen werden |
| YARA Signaturen | Entspricht bekannten Malware-, Webshell-, Miner- und Exploit-Mustern | Nützlich für bekannte Familien | Unbekannte, verpackte oder veränderte Nutzlasten können ausweichen |
| Optionale LLM-Überprüfung | Bewertet Absicht und Kontext und erklärt Ergebnisse | Kann offensichtliche statische Fehlalarme reduzieren | Wahrscheinlichkeitsbasiert, anbieterabhängig und anfällig für kontroverse Inhalte |
Das Projekt beschreibt die statische Analyse als „High-Recall“ mit mäßiger Präzision und sagt, dass eine optionale semantische Überprüfung die Präzision verbessert. Kopieren Sie keine Schlagzeilen-Präzisionszahl in die Richtlinie, ohne sie in Ihrem eigenen Korpus zu reproduzieren. Ein Sicherheitsteam kümmert sich um falsch-negative Ergebnisse pro Kategorie und nicht nur um eine Gesamtzahl.
Die 16 Risikokategorien in betrieblicher Hinsicht
| Risikogruppe | Beispiele behandelt | Was ein Prüfer überprüfen sollte |
|---|---|---|
| Befehlskontrolle | Schnelle Injektion, versteckte Anweisungen, systembedingte Leckage | Sind Anweisungen sichtbar, umfangreich und den Host-Richtlinien untergeordnet? |
| Datenzugriff | Umgebungserfassung, Dateisystemaufzählung, Kontextexfiltration | Welche genauen Datenklassen können in welche Domänen fließen? |
| Autorität | Eskalation von Privilegien, übermäßige Entscheidungsfreiheit, Missbrauch von Tools | Fordert der Skill nur die minimalen umkehrbaren Berechtigungen an? |
| Beharrlichkeit | Speichervergiftung, Selbstmodifikation, Startup oder Cron-Persistenz | Kann der Skill zukünftige Sitzungen oder seine eigene Durchsetzung ändern? |
| Software-Lieferkette | Nicht angeheftete Pakete, Remote-Skripte, CVEs, Tippfehler, Verschleierung | Sind Hashes, Commits und Abhängigkeitsherkunft reproduzierbar? |
| MCP Grenze | Wildcard-Berechtigungen, nicht deklarierte Funktionen, Tool-Poisoning | Stimmen die deklarierten Metadaten mit Code und Laufzeitverkehr überein? |
| Codeverhalten | exec/eval, Unterprozess, dynamische Importe, fehlerhafte Ausführung | Ist gefährliches Verhalten unerlässlich, eingeschränkt und sicher parametrisiert? |
| Ausgabe und Trigger | Unbereinigte Ausgabe, umfassende Aktivierung, Schattenbefehle | Kann gewöhnlicher Text unerwartet eine Vertrauensgrenze aktivieren oder überschreiten? |
SkillSpector dokumentiert derzeit 64 Muster in diesen 16 Kategorien. Die Zahl ist für die Versionierungsabdeckung nützlich, nicht als Sicherheitsbewertung allein. Zehn Varianten einer bekannten Regex schützen nicht unbedingt vor einer neuen Angriffskette, während eine einzige hochwertige Taint-Regel ein kritisches Leck verhindern kann.
Den Risiko-Score verstehen
Das dokumentierte Modell addiert 50 Punkte für einen kritischen Befund, 25 für hoch, 10 für mittel und 5 für niedrig, wendet einen 1,3-fachen Multiplikator an, wenn ausführbare Skripte vorhanden sind, und begrenzt das Ergebnis auf 100. Veröffentlichte Bänder beschriften 0–20 niedrig, 21–50 mittel, 51–80 hoch und 81–100 kritisch.
| Partitur/Band | Standardempfehlung | Was es nicht bedeutet |
|---|---|---|
| 0–20 / Niedrig | Setzen Sie die manuelle Überprüfung und den Sandbox-Test fort | Nicht „sicher“; Blinde Flecken können unbeobachtetes Verhalten beinhalten |
| 21–50 / Mittel | Erfordern eine Verfügung und Sanierung durch den Eigentümer | Nicht automatisch bösartig; Die legitime Netzwerk- oder Shell-Nutzung kann punkten |
| 51–80 / Hoch | Blockieren Sie die Installation, es sei denn, die Sicherheit gewährt eine Ausnahme | Die Bewertung allein stellt keine Absicht dar |
| 81–100 / Kritisch | Ablehnen und Quelle/Herkunft untersuchen | Mehrere Befunde können eine Grundursache beschreiben; Deduplizierung während der Triage |
Ein Score komprimiert heterogene Beweise. Behalten Sie Regel-IDs, Dateispeicherorte, Snippets, Konfidenz, Analyseversion und Quell-Commit bei. Zwei Fähigkeiten mit einem Wert von 50 können völlig unterschiedliche Risiken aufweisen: ein kritischer Codeausführungspfad im Vergleich zu zehn Hygienebefunden mit geringem Schweregrad.
Nur statisches Scannen versus LLM-unterstütztes Scannen
| Modus | Verwenden Sie wann | Datengrenze | Implikationen für die Politik |
|---|---|---|---|
--nein-llm | Schnelle CI, nicht vertrauenswürdige Eingaben, Air-Gap-Überprüfung oder deterministische Baselines | Es wird keine semantische Nutzlast an einen Modellanbieter gesendet | Erwarten Sie mehr Fehlalarme und verpasste Absichten |
| Verwalteter OpenAI/Anthropic/NVIDIA-Endpunkt | Eine kontextbezogene Triage ist eine externe Bearbeitung wert | Fertigkeitsinhalte können die Umgebung verlassen | Überprüfen Sie die Anbieterbedingungen, die Aufbewahrung, die Region und die Anmeldeinformationen |
| Lokaler OpenAI-kompatibler Endpunkt | Sensible Fähigkeiten oder reproduzierbare interne Bewertung | Kann lokal bleiben, wenn das Netzwerk kontrolliert wird | Die Qualität des Modells und die Robustheit der sofortigen Injektion liegen in Ihrer Verantwortung |
Geben Sie dem semantischen Modell des Scanners niemals mehr Autorität, als es benötigt. Das Modell sollte Text analysieren und keine Produktionsgeheimnisse oder Installationsberechtigungen besitzen. Behandeln Sie alle Fertigkeitsinhalte als gegnerische Eingabe und protokollieren Sie den genauen Anbieter/das genaue Modell, da sich die semantischen Dispositionen zwischen den Versionen ändern können.
Bekannte blinde Flecken
NVIDIA führt ausdrücklich wichtige Einschränkungen auf: Nicht-englischsprachige Angriffe können übersehen werden; In Bildern versteckter Text wird nicht analysiert. kompilierter, verschlüsselter oder binärer Code liegt außerhalb der statischen Sichtbarkeit; und Laufzeitverhalten wird nicht ausgeführt. OSV Die Abdeckung wird reduziert, wenn das Netzwerk nicht verfügbar ist. Die statische Analyse kann auch Probleme mit generiertem Code, Reflektion, Downloads der zweiten Stufe, umgebungsbedingtem Verhalten und Missbrauch haben, der erst auftritt, nachdem ein Remote-Server seine Antwort geändert hat.
| Blinder Fleck | Kompensierende Kontrolle |
|---|---|
| Bild- oder Dokumentanweisungen | Extrahieren Sie OCR/Metadaten und überprüfen Sie Medien in einer separaten Sandbox |
| Binäres oder verschlüsseltes Artefakt | Lehnen Sie undurchsichtige Payloads ab oder fordern Sie reproduzierbare Quellen und Malware-Sandboxing |
| Nur-Laufzeit-Verhalten | In einem instrumentierten Container mit standardmäßig verweigertem Netzwerk/Dateisystem ausführen |
| Nicht-englische oder verschleierte Eingabeaufforderung | Nutzen Sie sprachbewusste Überprüfung, Unicode-Normalisierung und kontradiktorische Testfälle |
| Remote-Abhängigkeitsänderungen | Pin-Commit/Hash, Spiegelabhängigkeiten und Überprüfung von Signaturen/SBOM |
| Scannerumgehung oder Defekt | Nutzen Sie tiefgreifende Verteidigungstests, unabhängige Überprüfungen und Scanner-Regressionstests |
Eine CI-Zulassungsrichtlinie, die Teams durchsetzen können
- Unveränderliche Eingaben auflösen. Zeichnen Sie das Repository auf, schreiben Sie SHA fest, archivieren Sie Hash, Autor und Lizenz vor dem Scannen.
- Auspacken ohne Ausführung. Deaktivieren Sie Hooks, Vorlagen und Paketinstallationen, während Sie jede Datei inventarisieren.
- Zuerst statisch ausführen. Speichern Sie JSON und SARIF mit der Version SkillSpector und ob OSV erreichbar war.
- Wenden Sie explizite Gates an. Blockieren Sie alle nicht unterdrückten kritischen/hohen Ergebnisse, Anmeldeinformationen-zu-Netzwerk-Fehler, versteckten Anweisungen oder undurchsichtigen ausführbaren Dateien.
- Führen Sie die semantische Überprüfung separat durch. Senden Sie nur genehmigte Inhalte an einen isolierten Anbieter und erlauben Sie dem Model niemals, den Skill zu installieren.
- Erfordern eine menschliche Disposition. Jede Unterdrückung benötigt einen Eigentümer, einen Grund, einen Umfang und ein Ablaufdatum.
- Testen Sie Laufzeitgrenzen. Beginnen Sie ohne Geheimnisse, mit schreibgeschützten Komponenten, einer Domänen-Zulassungsliste und einem verfügbaren Konto.
- Updates erneut scannen. Auslöser bei Quelländerungen, Änderungen der Abhängigkeitssperre, Regelpaketveröffentlichungen und neu veröffentlichten CVEs.
| Finden | Vorgeschlagenes Tor | Ausnahmebeweis |
|---|---|---|
| Kritischer/hoher Taint oder Ausführungskette | Harter Block | Sicherheitsüberprüfung plus Codekorrektur; Vermeiden Sie dauerhafte Unterdrückung |
| Externes Netzwerkziel | Blockieren, sofern nicht auf der Zulassungsliste | Geschäftszweck, Datenklassifizierung, Domänen- und Nutzdatennachweis |
| Nicht angeheftete Abhängigkeit | Blockfreigabe | Lockfile/Hash und kontrollierter Update-Prozess |
| Breite Trigger- oder Wildcard-Berechtigung | Erfordern eine Verengung | Nachgewiesene Bedarfs- und Laufzeitgenehmigungskontrolle |
| Hygieneproblem geringer Schwere | Mit Frist warnen | Eigentümer und Sanierungsticket |
So bewerten Sie die Erkennungsqualität
Erstellen Sie einen beschrifteten Korpus, der den Fähigkeiten ähnelt, die Ihre Organisation installiert. Dazu gehören saubere Fähigkeiten, die rechtmäßig Unterprozesse oder Netzwerk-APIs verwenden, absichtlich angreifbare Vorrichtungen für jede relevante Regelfamilie, mehrsprachige Anweisungen, codierter Text, umbenannte Tools und verkettete Verhaltensweisen. Teilen Sie den Korpus auf, damit Tuning-Beispiele nicht zum einzigen Testsatz werden.
| Metrisch | Frage beantwortet | Warum es wichtig ist |
|---|---|---|
| Rückruf nach Schweregrad/Kategorie | Wie viele bekannte gefährliche Fälle wurden gefunden? | Eine hohe Gesamtrate kann darüber hinwegtäuschen, dass es keine Abdeckung für die Ausschleusung von Anmeldedaten gibt |
| Präzision | Wie viele Warnungen waren umsetzbar? | Geringe Präzision trainiert Entwickler, das Tor zu umgehen |
| Zeit zur Disposition | Wie lange dauert die menschliche Triage? | Misst die tatsächlichen Betriebskosten |
| Inkrementelle Scanzeit | Kann die Prüfung bei jeder Änderung durchgeführt werden? | Langsame Gates führen zu seltenen Audits |
| Semantische Stabilität | Stimmen wiederholte Läufe/Modellversionsläufe überein? | Legt nichtdeterministische politische Ergebnisse offen |
| Fluchtrate | Welches riskante Verhalten trat zur Laufzeit nach dem Bestehen auf? | Testet das gesamte Einlasssystem, nicht nur den Scanner |
SARIF und Berichterstattung
Die Ausgabe von SARIF kann zum GitHub-Code-Scanning hochgeladen werden, sodass die Ergebnisse an den Quellorten angezeigt werden und am normalen Sicherheitsworkflow des Repositorys teilnehmen. JSON eignet sich besser für Richtlinien-Engines und Längsschnittmetriken; Markdown unterstützt ein menschliches Überprüfungspaket; Die Terminalausgabe erfolgt bequem vor Ort. Bestätigen Sie das Verhalten des Exit-Codes in Ihrer angehefteten Version und implementieren Sie das Gate explizit, anstatt davon auszugehen, dass beim Erstellen eines Berichts ein Build fehlschlägt.
Berichte können selbst sensible Snippets, interne Pfade und verdächtige Anweisungen enthalten. Beschränken Sie die Aufbewahrung und den Zugriff auf Artefakte. Veröffentlichen Sie kein vollständiges Ergebnis, das einen Token oder eine Exploit-Nutzlast enthält, in einer öffentlichen Pull-Anfrage.
Alternativen und ergänzende Kontrollen
| Option | Beste Verwendung | Beziehung zu SkillSpector |
|---|---|---|
| Cisco AI Defense-Skill-Scanner | Ein weiterer auf Agentenfähigkeiten ausgerichteter Multi-Engine-Scanner | Vergleichen Sie Abdeckung und Fehlalarme. Unabhängige Engines können die Erkennung diversifizieren |
| Semgrep/CodeQL | Umfassende sprachspezifische statische Analyse und benutzerdefinierte Organisationsregeln | Ergänzen Sie Agentenanweisungen und MCP-spezifische Prüfungen |
| OSV-Scanner/Dependabot | Abhängigkeitsschwachstelle und Update-Workflows | Umfassendere Abhängigkeitsoperationen als eine eingebettete Suche |
| YARA/Antimalware-Sandbox | Bekannte Malware und dynamisches Verhalten | Nützlich für Nutzlasten außerhalb der Markdown-orientierten Analyse |
| Manuelle Zulassungsliste + signierter Katalog | Umgebungen mit hoher Kontrolle und wenigen anerkannten Fähigkeiten | Reduziert die Variabilität der Lieferkette; Scannen Sie weiterhin jede signierte Version |
| Laufzeit-Sandbox/Richtlinien-Engine | Durchsetzung von Datei-, Netzwerk-, Geheim- und Genehmigungsgrenzen | Wesentlicher Ausgleich, da das Scannen vor der Installation nicht alles überwachen kann |
FAQ
Bedeutet eine niedrige Punktzahl, dass eine Fertigkeit sicher ist?
Nein. Das bedeutet, dass die angeheftete Scannerversion nicht viele erkannte Ergebnisse gesammelt hat. Blinde Flecken, Laufzeitverhalten und Supply-Chain-Substitution bleiben möglich.
Führt SkillSpector den Skill aus?
Nein. Die dokumentierte Einschränkung liegt eher in der statischen Analyse als in der dynamischen Ausführung. Verwenden Sie für Laufzeittests eine separate instrumentierte Sandbox.
Kann es ein Remote-Git-Repository scannen?
Ja, zusammen mit URLs, Zip-Archiven, Verzeichnissen und einzelnen Dateien. Scannen Sie zur Reproduzierbarkeit einen unveränderlichen Commit oder Hash anstelle einer veränderlichen Zweig-URL.
Ist eine LLM-Analyse erforderlich?
Nein. --nein-llm Läuft nur statisch. Die semantische Analyse ist optional und kann verwaltete Anbieter oder einen lokalen OpenAI-kompatiblen Endpunkt verwenden.
Was passiert ohne OSV Netzwerkzugriff?
Der Scanner greift auf eine kleine integrierte Liste zurück, sodass die Abdeckung von Abhängigkeitsschwachstellen weniger aktuell und umfassend ist. Notieren Sie diesen verschlechterten Zustand im Bericht.
Wer sollte die endgültige Entscheidung treffen?
Ein ausgewiesener Sicherheits- oder Plattformprüfer mit Input vom funktionalen Eigentümer des Skills. Der Scanner liefert Befunde; es sollte keine Installationsberechtigung erteilen.
Quellen und Überprüfung
- Offizielles SkillSpector-Repository und README
- Offizielle Sicherheitsrichtlinie
- Technischer NVIDIA-Artikel zu verifizierten Fähigkeiten und SkillSpector
- Von NVIDIA geprüfter Agenten-Skills-Katalog
- OSV API Dokumentation
- GitHub SARIF Dokumentation hochladen
- OWASP-Leitfaden für LLM-Anwendungsrisiken
- MITRE ATLAS Wissensdatenbank zu gegnerischen Bedrohungen
- Vergleich der Skill-Scanner von Cisco AI Defense
Zuletzt überprüft am 26. Juli 2026. Musteranzahl, Anbieter, Standardmodelle und CLI-Verhalten können sich ändern. Fixieren Sie die Scannerversion und überprüfen Sie das aktuelle Repository, bevor Sie ein Gate übernehmen.
