Files
clawsec/wiki/fr/exploitability-scoring.md
David Abutbul b37162a33d feat(i18n): add multilingual wiki scaffolding, language switcher, and… (#212)
* 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>
2026-04-29 09:00:31 +03:00

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ête lowL'exploitation limitée dans le contexte des agents, faible priorité unknown Inconnu 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 :**

  • lowmedium (exploitation disponible)
  • mediumhigh (exploitation disponible)
  • unknownmedium (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:

  1. Chemin canonique IC : exécutez le workflow NVD avec init/reset pour reconstruire les avis de NVD et signez les artefacts en pipeline.
  2. Chemin du développeur local : exécutez ./scripts/populate-local-feed.sh --force pour 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é:

  1. Rapport via GitHub Question: Utilisez le modèle de conseil pour signaler les CVE avec contexte d'exploitation
  2. Analyse automatisée: Le workflow community-advisory.yml obtient automatiquement des CVE déclarés par la communauté
  3. Examen manuel: Les responsables examinent et approuvent les évaluations de l'exploitabilité
  4. Mise à jour: Les avis approuvés sont ajoutés au flux avec des scores d'exploitation

Limites et travaux futurs

Limites actuelles

  1. Analyse statique: La notation est basée sur les métadonnées CVE et non sur l'analyse dynamique de l'exécution
  2. Pas de détection de version: Ne vérifie pas si des versions spécifiques sont vulnérables
  3. Classification des prix: Ne considère pas les atténuations partielles ou la défense en profondeur
  4. Contexte limité: Ne connaît pas la configuration exacte de l'agent ou les outils déployés

Améliorations futures

  1. ** Intégration EPSS**: Incorporer les cotes de probabilité EPSS (Exploit Prediction Score System)
  2. ** Correspondance de KEV** : référence croisée avec le catalogue CISA KEV (Vulnérabilités exploitées)
  3. Profilage d'agents: Considérer les capacités d'agents déployés et les API exposées
  4. Détection d'atténuation: Vérifiez les règles WAF, le bac à sable ou d'autres contrôles compensateurs
  5. Score basé sur le LM: Utiliser l'apprentissage automatique pour prédire l'exploitation à partir de données historiques

Références

Oui. Contribution

Pour améliorer la méthodologie de notation de l'exploitation :

  1. Soumettre les cas d'essai: Ajouter les cas d'essai à utils/analyze_exploitability.py
  2. Reporter de faux positifs/négatifs: Ouvrir les problèmes GitHub avec des exemples CVE
  3. Proposition d'ajustements de notation: Soumettre des PR avec justification et exemples
  4. 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