SkillSpector est un scanner de sécurité Apache-2.0 de NVIDIA pour les compétences d'agent IA : packages d'instructions pouvant contenir du Markdown, des scripts, des dépendances, des définitions d'outils et des règles d'activation. Il accepte un répertoire local, un fichier individuel, une archive zip, un référentiel Git ou une URL et produit des résultats de terminal, JSON, Markdown ou SARIF avec un score de risque de 0 à 100.
Sa valeur est le modèle de menace. Une compétence n’est pas simplement une documentation. Une fois qu'un agent les suit, les instructions peuvent entraîner l'accès aux fichiers, l'exécution du shell, l'utilisation des informations d'identification, la transmission réseau ou des modifications de configuration persistantes. SkillSpector vérifie à la fois les risques logiciels conventionnels et les problèmes spécifiques aux agents tels que l'injection rapide, l'agence excessive, l'empoisonnement de la mémoire, l'abus des déclencheurs et l'empoisonnement de la description de l'outil MCP. Un rapport propre est la preuve d'une couche d'analyse pré-installée, et non une garantie que le comportement d'exécution est sûr.
Où SkillSpector s'inscrit dans le pipeline de confiance
identité de la source + code PIN de validation
|
v
déballer dans un espace de travail isolé
|
.-------+--------.
v v
dépendance aux règles statiques / OSV
AST + signatures de contamination + métadonnées
'-------+--------'
v
révision sémantique LLM facultative
|
disposition humaine
accepter/réparer/supprimer avec raison/rejeter
|
sandbox + moindre privilège + surveillance de l'exécution
Cet ordre compte. Scanner aujourd’hui une URL non épinglée ne prouve pas que le téléchargement de demain sera identique. L’exécution d’un LLM sur des instructions hostiles sans isoler ses informations d’identification crée une autre exposition. Le téléchargement d'un fichier SARIF sans politique de blocage crée une visibilité mais aucun contrôle. Considérez le scanner comme une étape dans un processus d’admission reproductible.
Que fait l'analyseur en deux étapes
| Scène | Mécanisme | Force | Faiblesse attendue |
|---|---|---|---|
| Modèles statiques | Regex et correspondance de règles dans les fichiers de compétences | Rapide, déterministe et explicable | Des exemples bénins peuvent correspondre ; une formulation nouvelle peut échapper |
| AST comportementale | Détecte les primitives d'exécution Python et les chaînes d'appels dangereuses | Recherche le comportement du code au-delà des mots-clés | N'exécute pas de code ; la couverture du langage et de l'indirection est limitée |
| Suivi des souillures | Recherche les flux depuis les entrées/secrets/fichiers vers l'exécution ou les récepteurs réseau | Connecte la source et le puits dans un chemin significatif | La répartition dynamique et les cadres complexes peuvent vaincre le flux statique |
| Recherche OSV | Interroge OSV.dev pour les vulnérabilités de dépendance déclarées | Intelligence actuelle sur les vulnérabilités en ligne | Le mode hors ligne utilise une solution de repli plus petite ; le code non déclaré/vendu peut être manqué |
| YARA signatures | Correspond aux modèles connus de logiciels malveillants, de webshell, de mineurs et d'exploits | Utile pour les familles connues | Des charges utiles inconnues, emballées ou modifiées peuvent échapper |
| Examen LLM facultatif | Évalue l'intention et le contexte, explique les résultats | Peut réduire les faux positifs statiques évidents | Probabiliste, dépendant du fournisseur et exposé au contenu contradictoire |
Le projet décrit l'analyse statique comme étant à rappel élevé avec une précision modérée et affirme que la révision sémantique facultative améliore la précision. Ne copiez pas un chiffre de précision dans une politique sans le reproduire sur votre propre corpus. Une équipe de sécurité se soucie des faux négatifs par catégorie, et non d’un seul nombre global.
Les 16 catégories de risques en termes opérationnels
| Groupe à risque | Exemples couverts | Ce qu'un évaluateur doit vérifier |
|---|---|---|
| Contrôle des instructions | Injection rapide, directives cachées, fuite d'invite du système | Les instructions sont-elles visibles, étendues et subordonnées à la politique de l'hôte ? |
| Accès aux données | Récolte d'environnement, énumération du système de fichiers, exfiltration de contexte | Quelles classes de données exactes peuvent être acheminées vers quels domaines ? |
| Autorité | Élévation de privilèges, agence excessive, mauvaise utilisation des outils | La compétence demande-t-elle uniquement les autorisations réversibles minimales ? |
| Persistance | Empoisonnement de la mémoire, auto-modification, persistance au démarrage ou cron | La compétence peut-elle modifier les sessions futures ou sa propre application ? |
| Chaîne d'approvisionnement en logiciels | Packages non épinglés, scripts distants, CVE, typosquatting, obfuscation | Les hachages, les commits et la provenance des dépendances sont-ils reproductibles ? |
| Limite MCP | Autorisations génériques, capacités non déclarées, empoisonnement des outils | Les métadonnées déclarées correspondent-elles au code et au trafic d’exécution ? |
| Comportement du code | exec/eval, sous-processus, importations dynamiques, exécution entachée | Les comportements dangereux sont-ils essentiels, contraints et paramétrés en toute sécurité ? |
| Sortie et déclencheurs | Sortie non nettoyée, activation large, commandes fantômes | Un texte ordinaire peut-il activer ou franchir de manière inattendue une limite de confiance ? |
SkillSpector documente actuellement 64 modèles dans ces 16 catégories. Le numéro est utile pour la couverture des versions, et non comme score de sécurité en soi. Dix variantes d'une expression régulière connue ne protègent pas nécessairement contre une nouvelle chaîne d'attaque, tandis qu'une seule règle de contamination de haute qualité peut empêcher une fuite critique.
Comprendre le score de risque
Le modèle documenté ajoute 50 points pour un résultat critique, 25 pour élevé, 10 pour moyen et 5 pour faible, applique un multiplicateur de 1,3 × lorsque des scripts exécutables sont présents et plafonne le résultat à 100. Les bandes publiées étiquettent 0 à 20 faible, 21 à 50 moyen, 51 à 80 élevé et 81 à 100 critique.
| Partition/groupe | Recommandation par défaut | Ce que ça ne veut pas dire |
|---|---|---|
| 0–20 / Faible | Poursuivre l'examen manuel et le test sandbox | Pas « sûr » ; les angles morts peuvent contenir un comportement inobservé |
| 21-50 / Moyen | Exiger une disposition et des mesures correctives du propriétaire | Pas automatiquement malveillant ; l'utilisation légitime d'un réseau ou d'un shell peut avoir un impact |
| 51-80 / Élevé | Bloquer l'installation sauf si la sécurité accorde une exception | Le score à lui seul n’établit pas l’intention |
| 81-100 / Critique | Rejeter et rechercher la source/provenance | Plusieurs résultats peuvent décrire une cause fondamentale ; dédupliquer pendant le tri |
Un score comprime des preuves hétérogènes. Préservez les ID de règles, les emplacements de fichiers, les extraits de code, la confiance, la version de l'analyseur et la validation de la source. Deux compétences avec un score de 50 peuvent présenter des risques radicalement différents : un chemin d'exécution de code critique contre dix résultats d'hygiène de faible gravité.
Numérisation statique uniquement ou numérisation assistée par LLM
| Mode | Utiliser quand | Limite des données | Implication politique |
|---|---|---|---|
--non-llm | CI rapide, entrées non fiables, examen isolé ou lignes de base déterministes | Aucune charge utile sémantique envoyée à un fournisseur de modèles | Attendez-vous à davantage de faux positifs et d'intentions manquées |
| Point de terminaison OpenAI/Anthropic/NVIDIA géré | Le tri contextuel mérite un traitement externe | Le contenu des compétences peut quitter l'environnement | Examiner les conditions, la rétention, la région et les informations d'identification du fournisseur |
| Point de terminaison local compatible OpenAI | Compétences sensibles ou évaluation interne reproductible | Peut rester local si le réseau est contrôlé | La qualité des modèles et la robustesse de l’injection rapide deviennent votre responsabilité |
Ne donnez jamais au modèle sémantique du scanner plus d’autorité qu’il n’en a besoin. Le modèle doit analyser le texte et ne pas posséder de secrets de production ou d'autorisations d'installation. Traitez tout contenu de compétence comme une entrée contradictoire et enregistrez le fournisseur/modèle exact, car les dispositions sémantiques peuvent changer d'une version à l'autre.
Angles morts connus
NVIDIA répertorie explicitement des limitations importantes : les attaques non anglaises peuvent passer inaperçues ; le texte caché dans les images n'est pas analysé ; le code compilé, chiffré ou binaire échappe à la visibilité statique ; et le comportement d'exécution n'est pas exécuté. La couverture OSV est réduite lorsque le réseau est indisponible. L'analyse statique peut également rencontrer des difficultés avec le code généré, la réflexion, les téléchargements de deuxième étape, les comportements conditionnés par l'environnement et les abus qui n'apparaissent qu'après qu'un serveur distant modifie sa réponse.
| Angle mort | Contrôle compensatoire |
|---|---|
| Instructions relatives à l'image ou au document | Extrayez l'OCR/les métadonnées et examinez les médias dans un bac à sable séparé |
| Artefact binaire ou chiffré | Rejetez les charges utiles opaques ou exigez un sandboxing reproductible des sources et des logiciels malveillants. |
| Comportement d'exécution uniquement | Exécuter dans un conteneur instrumenté avec un réseau/système de fichiers refusé par défaut |
| Invite non anglaise ou obscurcie | Utilisez la révision basée sur le langage, la normalisation Unicode et les cas de tests contradictoires |
| Modifications des dépendances à distance | Épinglez le commit/hachage, mettez en miroir les dépendances et vérifiez les signatures/SBOM |
| Évasion ou défaut du scanner | Utiliser la défense en profondeur, les examens indépendants et les tests de régression par scanner |
Une politique d'admission CI que les équipes peuvent appliquer
- Résolvez l’entrée immuable. Enregistrez le référentiel, validez SHA, archivez le hachage, l'auteur et la licence avant l'analyse.
- Déballez sans exécution. Désactivez les hooks, les modèles et l’installation de packages lors de l’inventaire de chaque fichier.
- Exécutez d'abord en mode statique uniquement. Enregistrez JSON et SARIF avec la version SkillSpector et si OSV était joignable.
- Appliquez des portes explicites. Bloquez tout résultat critique/élevé non supprimé, toute contamination des informations d'identification du réseau, toute instruction cachée ou tout exécutable opaque.
- Effectuez une révision sémantique séparément. Envoyez uniquement le contenu approuvé à un fournisseur isolé et n’autorisez jamais le modèle à installer la compétence.
- Exiger une disposition humaine. Chaque suppression nécessite un propriétaire, une justification, une portée et une date d'expiration.
- Testez les limites d’exécution. Commencez sans secrets, avec des appareils en lecture seule, une liste d'autorisation de domaine et un compte jetable.
- Analysez à nouveau les mises à jour. Déclenchez les modifications de source, les modifications de verrouillage de dépendance, les versions de packs de règles et les CVE nouvellement divulgués.
| Trouver | Porte suggérée | Preuve d'exception |
|---|---|---|
| Entachement critique/élevé ou chaîne d'exécution | Blocage dur | Examen de sécurité et correction du code ; éviter la suppression permanente |
| Destination réseau externe | Bloquer sauf si inscrit sur la liste autorisée | Objectif commercial, classification des données, preuve de domaine et de charge utile |
| Dépendance non épinglée | Libération de bloc | Fichier de verrouillage/hachage et processus de mise à jour contrôlé |
| Déclencheur large ou autorisation générique | Exiger un rétrécissement | Besoin démontré et contrôle de l'approbation de l'exécution |
| Problème d'hygiène de faible gravité | Avertir avec délai | Propriétaire et ticket de remédiation |
Comment évaluer la qualité de la détection
Créez un corpus étiqueté qui ressemble aux compétences installées par votre organisation. Incluez des compétences propres qui utilisent légitimement des sous-processus ou des API de réseau, des éléments intentionnellement vulnérables pour chaque famille de règles pertinente, des instructions multilingues, du texte codé, des outils renommés et des comportements enchaînés. Divisez le corpus afin que les exemples de réglage ne deviennent pas le seul ensemble de tests.
| Métrique | Réponse à la question | Pourquoi c'est important |
|---|---|---|
| Rappel par gravité/catégorie | Combien de cas dangereux connus ont été découverts ? | Un taux global élevé peut cacher une couverture nulle pour l’exfiltration des informations d’identification |
| Précision | Combien d’alertes étaient exploitables ? | La faible précision entraîne les développeurs à contourner la porte |
| Temps de disposition | Combien de temps dure le triage humain ? | Mesure le coût opérationnel réel |
| Temps d'analyse incrémentiel | Le contrôle peut-il être exécuté à chaque modification ? | Les portes lentes migrent vers des audits peu fréquents |
| Stabilité sémantique | Les exécutions répétées/versions de modèle conviennent-elles ? | Expose des résultats politiques non déterministes |
| Taux d'évasion | Quel comportement à risque est apparu lors de l'exécution après le passage ? | Teste l'ensemble du système d'admission, pas seulement le scanner |
SARIF et reporting
La sortie SARIF peut être téléchargée vers l'analyse de code GitHub afin que les résultats apparaissent aux emplacements sources et participent au flux de travail de sécurité normal du référentiel. JSON est meilleur pour les moteurs de politiques et les mesures longitudinales ; Markdown prend en charge un paquet de révision humaine ; la sortie du terminal est pratique localement. Confirmez le comportement du code de sortie dans votre version épinglée et implémentez la porte explicitement plutôt que de supposer que la création d'un rapport échoue lors d'une build.
Les rapports peuvent eux-mêmes contenir des extraits sensibles, des chemins internes et des instructions suspectes. Limitez la conservation et l’accès aux artefacts. Ne publiez pas un résultat complet contenant un jeton ou une charge utile d’exploitation dans une demande d’extraction publique.
Contrôles alternatifs et complémentaires
| Options | Meilleure utilisation | Relation avec SkillSpector |
|---|---|---|
| Scanner de compétences Cisco AI Defense | Un autre scanner multimoteur axé sur les compétences des agents | Comparez la couverture et les faux positifs ; des moteurs indépendants peuvent diversifier la détection |
| Semgrep/CodeQL | Analyse statique approfondie spécifique au langage et règles d'organisation personnalisées | Compléter les instructions de l'agent et les contrôles spécifiques à MCP |
| OSV-Scanner/Dépendabot | Vulnérabilité de dépendance et workflows de mise à jour | Opérations de dépendance plus larges qu'une seule recherche intégrée |
| YARA/bac à sable antimalware | Malwares connus et comportement dynamique | Utile pour les charges utiles en dehors de l'analyse orientée Markdown |
| Liste d'autorisation manuelle + catalogue signé | Environnements à haut contrôle avec peu de compétences approuvées | Réduit la variabilité de la chaîne d’approvisionnement ; scannez toujours chaque version signée |
| Sandbox d'exécution/moteur de stratégie | Faire respecter les limites des fichiers, du réseau, des secrets et des approbations | Compensation essentielle car l’analyse pré-installation ne peut pas tout observer |
FAQ
Un score faible signifie-t-il qu’une compétence est sûre ?
Non. Cela signifie que la version du scanner épinglée n’a pas accumulé beaucoup de résultats reconnus. Les angles morts, le comportement d’exécution et la substitution de la chaîne d’approvisionnement restent possibles.
SkillSpector exécute-t-il la compétence ?
Non. Sa limite documentée est l’analyse statique plutôt que l’exécution dynamique. Utilisez un bac à sable instrumenté distinct pour les tests d’exécution.
Peut-il analyser un référentiel Git distant ?
Oui, ainsi que les URL, les archives zip, les répertoires et les fichiers individuels. Pour des raisons de reproductibilité, analysez un commit ou un hachage immuable plutôt qu'une URL de branche mutable.
Une analyse LLM est-elle requise ?
Non. --non-llm fonctionne uniquement en statique. L'analyse sémantique est facultative et peut utiliser des fournisseurs gérés ou un point de terminaison local compatible OpenAI.
Que se passe-t-il sans accès au réseau OSV ?
Le scanner s'appuie sur une petite liste intégrée, de sorte que la couverture des dépendances et des vulnérabilités est moins actuelle et moins complète. Enregistrez cet état dégradé dans le rapport.
À qui revient la décision finale ?
Un réviseur de sécurité ou de plateforme désigné, avec la contribution du propriétaire fonctionnel de la compétence. Le scanner fournit des résultats ; il ne doit pas accorder d'autorité d'installation.
Sources et vérification
- Dépôt officiel SkillSpector et README
- Politique de sécurité officielle
- Article technique NVIDIA sur les compétences vérifiées et SkillSpector
- Catalogue de compétences d'agent vérifié par NVIDIA
- OSV API documentation
- GitHub SARIF télécharger la documentation
- Conseils OWASP pour les risques liés aux applications LLM
- MITRE ATLAS base de connaissances sur les menaces adverses
- Comparaison des scanners de compétences Cisco AI Defense
Dernière révision le 26 juillet 2026. Le nombre de modèles, les fournisseurs, les modèles par défaut et le comportement de l'interface CLI peuvent changer. Épinglez la version du scanner et vérifiez le référentiel actuel avant d'adopter une porte.
