* feat(i18n): add multilingual wiki scaffolding, language switcher, and translation QA pipeline * docs(readme): adopt picoclaw-style multilingual link bar * fix(i18n): repair localized index links and tighten partial-pair QA * ci(i18n): fail on broken markdown links in README/wiki * ci(i18n): add changed-files mode for markdown link checks * i18n(de): use local Argos MT to fill untranslated German sections * i18n(es,fr): fill untranslated sections via local Argos workflow * i18n(ja): fill untranslated sections with scoped local Argos pass * i18n(ko): fill untranslated sections with scoped local Argos pass * fix(i18n): address review feedback --------- Co-authored-by: David Abutbul <David.a@prompt.security>
16 KiB
Méthode de notation de l'exploitation
Aperçu
Le système de notation d'exploitabilité de ClawSec fournit une évaluation de vulnérabilité contextuelle spécialement conçue pour les déploiements d'agents d'IA (OpenClaw/NanoClaw). Contrairement aux scores CVSS génériques qui traitent tous les environnements de façon égale, notre notation tient compte de la surface d'attaque unique et des modèles d'utilisation des agents d'IA pour réduire la fatigue alerte et prioriser les menaces actionnables.
Niveau de notation
Niveau de gravité Signification
- Oui.
high=Critical/High=Exploitable dans les déploiements d'agents typiques, attention immédiate requise=medium= Moyenne Peut être exploitable selon la configuration, justifie enquêtelowL'exploitation limitée dans le contexte des agents, faible prioritéunknownInconnu Données insuffisantes pour évaluer l'exploitabilité
Facteurs de cotation
- Oui. 1. Score de base du CVSS (base)
L'analyse commence par le score de base du CVSS comme fondement :
-
CVSS ≥ 9.0: Gravité critique → score initial
high -
CVSS 7.0-8,9: Haute sévérité → score initial
high -
CVSS 4.0-6.9: sévérité moyenne → score initial
medium -
CVSS 1.0-3.9: Faible sévérité → score initial
low -
Pas de CVSS: → score initial
unknown -
Oui. 2. Analyse vectorielle d ' attaque (Métrique CVSS)
L'analyseur analyse les vecteurs CVSS v2, v3.0 et v3.1 pour évaluer:
Accessibilité du réseau
- AV:N (Réseau): Téléexploitable sur réseau
- AV:A (Adjoint): Nécessite un accès au réseau local
- AV:L (local): Nécessite un accès au système local
- AV:P (Physique): Nécessite un accès physique
Impact sur les agents: Les vulnérabilités accessibles au réseau sont élevées parce que les agents fonctionnent généralement comme des services de réseau ou font des appels d'API externes.
Exigences en matière d'authentification
- PR:N / Au:NONE: Aucune authentification requise → élève le score
- PR:L / Au:SINGLE: Faibles privilèges requis
- PR:H / Au:MULTIPLE: Les privilèges élevés requis → réduit le score
Impact sur les agents: Les exploits non authentifiés sont essentiels pour les API d'agents publics.
L'interaction utilisateur
- UI:N: Aucune interaction utilisateur requise → élève le score
- UI:R: Nécessite une interaction utilisateur → réduit le score
Impact sur les agents: Les agents fonctionnent souvent de manière autonome, de sorte que les vulnérabilités nécessitant une interaction utilisateur sont moins critiques.
Complexe d'attaque
- AC:L: Faible complexité → élève le score
- AC:M / AC:H: complexité moyenne/haute → neutre ou réduit le score
Impact sur les agents: Les exploits à faible complexité sont plus susceptibles d'être automatisés et utilisés dans les attaques de masse.
- Oui. 3. Type de vulnérabilité (contexte du détachement)
ClawSec ajuste les scores en fonction de la façon dont les types de vulnérabilité affectent les déploiements d'agents d'IA :
Types à risque élevé dans le contexte de l'agent
*Exécution de code à distance (RCE) *
Score: Always HIGH
Rationale: RCE is critical in agent deployments
Les agents d'IA exécutent le code arbitraire dans le cadre de leur fonction. Les vulnérabilités RCE permettent aux attaquants de détourner le flux d'exécution des agents, d'exfiltrer les identifiants ou de pivoter vers d'autres systèmes.
*Forgerie de demande à l'aide d'un serveur *
Score: Elevated to HIGH if CVSS ≥ 6.0
Rationale: SSRF affects agents making external requests
Les agents appellent souvent des API externes, accèdent aux services internes et récupèrent des ressources à distance. SSRF permet aux attaquants :
- Accès aux services de métadonnées cloud internes (AWS IMDSv1, métadonnées GCP)
- Pivot vers les réseaux internes
- Exfiltrer les données par tunnel DNS
*Path Traversal / Directory Traversal *
Score: Elevated to HIGH if CVSS ≥ 6.0
Rationale: Path traversal affects agents with file access
Les agents lisent les fichiers, exécutent des scripts et gèrent les bases de code. Le parcours permet :
- Lecture de fichiers de configuration sensibles (.env, identifiants)
- Accès aux clés SSH, jetons API
- Suppression des fichiers système critiques
Injection de commande
Score: Always HIGH
Rationale: Command injection is critical in agent deployments
Comme RCE, les agents exécutent souvent des commandes shell pour interagir avec les systèmes. L'injection de commande permet un compromis complet du système.
Types à risque moyen
*Prototype Pollution (Node.js) *
Score: Elevated from LOW to MEDIUM
Rationale: Prototype pollution can escalate in Node.js agents
De nombreux cadres d'agents fonctionnent sur Node.js. La pollution par prototype peut conduire à:
- Dépassement des contrôles d'authentification
- L'escalade des privilèges
- Refus de service
Injection SQL / Injection NoSQL
Score: Elevated to HIGH if network-accessible and unauthenticated
Rationale: Injection affects agents with database access
Les agents qui stockent l'historique de conversation, les données utilisateur ou les résultats d'outils dans les bases de données sont vulnérables aux attaques par injection.
Types de risques inférieurs
** Scénario du site (XSS)* *
Score: Reduced to MEDIUM if not network-accessible
Rationale: XSS has limited impact in headless agents
Les agents ne rendent généralement pas HTML dans les navigateurs, réduisant l'impact XSS. Cependant, XSS dans les interfaces de gestion d'agents ou de chat reste une préoccupation.
- Oui. 4. Exploiter la disponibilité
Lorsque --check-exploits est activé, l'analyseur vérifie les URL de référence pour les exploits publics:
** Indicateurs d'exploitation :**
- exploit-db.com / exploit-database.com
- packetstormsecurity.com
- github.com/exploitation, github.com/poc
- modules-cadres métasploit
- URL contenant "/exploiter", "/poc", "/proof-of-concept"
** Augmentation de la note :**
low→medium(exploitation disponible)medium→high(exploitation disponible)unknown→medium(exploitation disponible + CVSS > 0)
Rationale: Le public exploite moins la barrière des compétences pour les attaquants et augmente la probabilité d'exploitation automatisée.
L'algorithme de notation
L ' analyseur suit cet arbre de décision:
1. Parse CVSS score → set baseline (high/medium/low/unknown)
2. Parse CVSS vector → analyze attack characteristics
3. Adjust for attack vector:
- Network-accessible + no auth + no UI → elevate to HIGH
- Local-only access → reduce HIGH to MEDIUM
4. Adjust for vulnerability type:
- Check against agent-specific risk categories
- Elevate or reduce score based on deployment context
5. Check for public exploits (if enabled):
- Elevate score if exploits detected
6. Generate rationale explaining the final score
Exemples
Exemple 1 : risque critique (haute exploitation)
{
"cve_id": "CVE-2024-12345",
"cvss_score": 9.8,
"cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "remote_code_execution",
"description": "Unauthenticated RCE in Express.js framework"
}
Produit d'analyse:
{
"exploitability_score": "high",
"exploitability_rationale": "Critical CVSS score (9.8); remotely exploitable without authentication; RCE is critical in agent deployments"
}
Pourquoi HAUT: CVSS critique + accès réseau + pas d'auth + type RCE.
Exemple 2 : SSRF dans l'API d'agent (haute exploitation)
{
"cve_id": "CVE-2024-23456",
"cvss_score": 7.3,
"cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "server_side_request_forgery",
"description": "SSRF in webhook handler allows internal network access"
}
Produit d'analyse:
{
"exploitability_score": "high",
"exploitability_rationale": "High CVSS score (7.3); remotely exploitable without authentication; SSRF affects agents making external requests"
}
Pourquoi HAUT: SSRF est critique pour les agents qui font des appels API (la plupart font). Accès réseau sans authentification élève le risque.
Exemple 3 : Chemin transversal avec exploitation publique (haute exploitation)
{
"cve_id": "CVE-2024-34567",
"cvss_score": 6.5,
"cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "path_traversal",
"references": [
"https://exploit-db.com/exploits/51234",
"https://nvd.nist.gov/vuln/detail/CVE-2024-34567"
]
}
Produit d'analyse (avec --check-exploits):
{
"exploitability_score": "high",
"exploitability_rationale": "Medium CVSS score (6.5); network accessible; path traversal affects agents with file access; public exploit available (1 source)"
}
Pourquoi HIGH: L'accès au fichier de transit + agent + l'exploitation publique élève le CVSS moyen à une grande exploitabilité.
Exemple 4 : XSS dans l'assurance-chômage des agents (Exploitation moyenne)
{
"cve_id": "CVE-2024-45678",
"cvss_score": 7.1,
"cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L",
"type": "cross_site_scripting",
"description": "Stored XSS in agent management dashboard"
}
Produit d'analyse:
{
"exploitability_score": "medium",
"exploitability_rationale": "High CVSS score (7.1); network accessible; XSS has limited impact in headless agents"
}
Pourquoi MEDIUM : Malgré un CVSS élevé, XSS est moins critique dans les déploiements d'agents (opération sans tête). Nécessite une interaction utilisateur.
Exemple 5 : Escalation des privilèges locaux (Exploitation moyenne)
{
"cve_id": "CVE-2024-56789",
"cvss_score": 8.8,
"cvss_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "privilege_escalation",
"description": "Local privilege escalation via symbolic link attack"
}
Produit d'analyse:
{
"exploitability_score": "medium",
"exploitability_rationale": "High CVSS score (8.8); requires local access"
}
Pourquoi MEDIUM: Malgré un CVSS élevé, nécessite un accès local. Les agents fonctionnent généralement dans des environnements containerizzato/sandbox où l'escalade locale a un impact limité.
Exemple 6 : Prototype de pollution par exploitation (haute exploitation)
{
"cve_id": "CVE-2024-67890",
"cvss_score": 5.3,
"cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "prototype_pollution",
"description": "Prototype pollution in lodash merge function",
"references": [
"https://github.com/exploit/prototype-pollution-poc",
"https://snyk.io/vuln/SNYK-JS-LODASH-1234567"
]
}
Produit d'analyse (avec --check-exploits):
{
"exploitability_score": "high",
"exploitability_rationale": "Medium CVSS score (5.3); remotely exploitable without authentication; prototype pollution can escalate in Node.js agents; public exploit available (1 source)"
}
Pourquoi HAUT : Prototype pollution dans les agents Node.js + exploitation publique + accès réseau sans auth = risque élevé malgré un CVSS modéré.
Utilisation dans les flux de travail ClawSec
Note automatique (Feed NVD)
Le workflow poll-nvd-cves.yml marque automatiquement de nouveaux CVE :
# Workflow step
python utils/analyze_exploitability.py --json --check-exploits < cve-data.json
Les avis en advisories/feed.json peuvent inclure:
{
"id": "CVE-2024-12345",
"severity": "high",
"exploitability_score": "high",
"exploitability_rationale": "Critical CVSS score (9.8); remotely exploitable without authentication; RCE is critical in agent deployments",
"attack_vector_analysis": {
"is_network_accessible": true,
"requires_authentication": false,
"requires_user_interaction": false,
"complexity": "low"
}
}
Analyse manuelle
Les chercheurs en sécurité peuvent analyser manuellement les CVE :
# Basic analysis
echo '{"cve_id":"CVE-2024-12345","cvss_score":7.3,"type":"ssrf"}' | \
python utils/analyze_exploitability.py --json
# With exploit detection
echo '{"cve_id":"CVE-2024-12345","cvss_score":7.3,"references":["https://exploit-db.com/exploits/51234"]}' | \
python utils/analyze_exploitability.py --json --check-exploits
Filtrage par Exploitation
Les utilisateurs peuvent filtrer les avis par un score d'exploitation :
# Get only high-exploitability advisories
curl -s https://clawsec.prompt.security/feed.json | \
jq '.advisories[] | select(.exploitability_score == "high")'
# Prioritize by exploitability and severity
curl -s https://clawsec.prompt.security/feed.json | \
jq '[.advisories[] | select(.exploitability_score == "high" and .severity == "critical")] | sort_by(.cvss_score) | reverse'
Remplissage des avis existants (entretien historique)
scripts/backfill-exploitability.sh est conservé comme utilitaire de maintenance historique pour la maintenance unique du dépôt.
Ce n'est pas la voie principale pour la génération de conseils normaux.
Voies préférées:
- Chemin canonique IC : exécutez le workflow NVD avec init/reset pour reconstruire les avis de NVD et signez les artefacts en pipeline.
- Chemin du développeur local : exécutez
./scripts/populate-local-feed.sh --forcepour repeupler les flux locaux avec un contexte d'exploitation.
N'utilisez le remblayage que lorsqu'il répare explicitement le contenu de flux qui existe déjà en repo.
Contributions communautaires
Les membres de la communauté peuvent soumettre des évaluations de l'exploitabilité:
- Rapport via GitHub Question: Utilisez le modèle de conseil pour signaler les CVE avec contexte d'exploitation
- Analyse automatisée: Le workflow
community-advisory.ymlobtient automatiquement des CVE déclarés par la communauté - Examen manuel: Les responsables examinent et approuvent les évaluations de l'exploitabilité
- Mise à jour: Les avis approuvés sont ajoutés au flux avec des scores d'exploitation
Limites et travaux futurs
Limites actuelles
- Analyse statique: La notation est basée sur les métadonnées CVE et non sur l'analyse dynamique de l'exécution
- Pas de détection de version: Ne vérifie pas si des versions spécifiques sont vulnérables
- Classification des prix: Ne considère pas les atténuations partielles ou la défense en profondeur
- Contexte limité: Ne connaît pas la configuration exacte de l'agent ou les outils déployés
Améliorations futures
- ** Intégration EPSS**: Incorporer les cotes de probabilité EPSS (Exploit Prediction Score System)
- ** Correspondance de KEV** : référence croisée avec le catalogue CISA KEV (Vulnérabilités exploitées)
- Profilage d'agents: Considérer les capacités d'agents déployés et les API exposées
- Détection d'atténuation: Vérifiez les règles WAF, le bac à sable ou d'autres contrôles compensateurs
- Score basé sur le LM: Utiliser l'apprentissage automatique pour prédire l'exploitation à partir de données historiques
Références
- CVSS v3.1 Spécification: https://www.first.org/cvss/v3.1/specification-document
- CVSS v2 Guide: https://www.first.org/cvss/v2/guide
- EPSS: https://www.first.org/epss/
- CISA KEV: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- ** API NVD**: https://nvd.nist.gov/developers/vulnerabilities
Oui. Contribution
Pour améliorer la méthodologie de notation de l'exploitation :
- Soumettre les cas d'essai: Ajouter les cas d'essai à
utils/analyze_exploitability.py - Reporter de faux positifs/négatifs: Ouvrir les problèmes GitHub avec des exemples CVE
- Proposition d'ajustements de notation: Soumettre des PR avec justification et exemples
- Contexte de l'agent de partage: Contribuer les profils de vulnérabilité propres à l'agent
See CONTRIBUTING.md for detailed contribution guidelines.
Entretenu par: Prompt Security License: AGPL-3,0-ou plus tard Dernière mise à jour: 2026-03-01