Validation des Vulnérabilités

Validez les résultats de sécurité en évaluant s'ils sont réellement exploitables dans le contexte de cette base de code. Cette skill filtre les faux positifs, confirme les vraies vulnérabilités et génère des exploits de preuve de concept.

Quand utiliser cette skill

• Après commit-security-scan - Validez les résultats avant de créer des issues ou de bloquer les PR
• Résultats HIGH/CRITICAL - Priorisez la validation des résultats graves
• Avant la correction - Confirmez que la vulnérabilité est réelle avant d'investir dans des correctifs
• Revue de sécurité - Validation approfondie de résultats spécifiques

Prérequis

• .factory/threat-model.md doit exister (depuis la skill threat-model-generation)
• security-findings.json doit exister (depuis la skill commit-security-scan)

Entrées

Instructions

Suivez ces étapes pour chaque résultat à valider :

Étape 1 : Charger le contexte

1. Lisez security-findings.json depuis commit-security-scan
2. Lisez .factory/threat-model.md pour le contexte du système
3. Identifiez les résultats à valider en fonction des entrées

Étape 2 : Analyse de réachabilité

Pour chaque résultat, déterminez si le code vulnérable est accessible :

1. Tracez les points d'entrée

   • Les utilisateurs externes peuvent-ils atteindre ce chemin de code ?
   • Quels endpoints HTTP, commandes CLI ou gestionnaires d'événements y mènent ?
   • Une authentification est-elle requise pour atteindre ce code ?

2. Cartographiez la chaîne d'appels

   • À partir du point d'entrée, tracez le chemin jusqu'au code vulnérable
   • Documentez chaque appel de fonction dans la chaîne
   • Notez les conditions de branchement qui doivent être satisfaites

3. Classifiez la réachabilité

   • EXTERNAL - Accessible depuis une entrée externe non authentifiée
   • AUTHENTICATED - Nécessite une session utilisateur valide
   • INTERNAL - Accessible uniquement depuis les services internes
   • UNREACHABLE - Code mort ou bloqué par des conditions

Étape 3 : Analyse du flux de contrôle

Déterminez si un attaquant peut contrôler l'entrée vulnérable :

1. Identifiez la source

   • D'où proviennent les données contaminées ?
   • Paramètre HTTP, téléchargement de fichier, requête de base de données, variable d'environnement ?

2. Tracez le flux de données

   • Suivez les données de la source vers le puits (fonction vulnérable)
   • Documentez chaque transformation ou étape de validation
   • Notez toute sanitisation, encodage ou conversion de type

3. Évaluez le contrôle par l'attaquant

   • L'attaquant peut-il contrôler pleinement l'entrée ?
   • Y a-t-il des limites de longueur, des restrictions de caractères ou une validation de format ?
   • Les données passent-elles par une sanitisation ?

Étape 4 : Évaluation des mesures d'atténuation

Vérifiez si les contrôles de sécurité existants préviennent l'exploitation :

1. Validation d'entrée

   • L'entrée est-elle validée avant d'atteindre le code vulnérable ?
   • Quelles règles de validation sont appliquées ?

2. Protections du framework

   • Le framework fournit-il une protection automatique ? (par ex. paramétrisation ORM, échappement XSS React)
   • La protection est-elle activée et correctement configurée ?

3. Intergiciel de sécurité

   • Y a-t-il des règles WAF, rate limiting ou autres contrôles ?
   • Les en-têtes CSP ou autres protections du navigateur s'appliquent-ils ?

4. Référencez le modèle de menace

   • Vérifiez la section « Existing Mitigations » pour ce type de menace
   • Confirmez que les mesures d'atténuation sont réellement en place

Étape 5 : Évaluation de l'exploitabilité

Déterminez la difficulté d'exploitation :

Considérez :

• Complexité de l'attaque
• Privilèges requis
• Interaction utilisateur nécessaire
• Étendue de l'impact

Étape 6 : Générer une preuve de concept

Pour les vulnérabilités confirmées, créez une preuve de concept :

1. Composez le payload d'exploit

   • Créez un payload minimal qui démontre la vulnérabilité
   • Utilisez des payloads bénins (sans dommages réels)

2. Documentez la requête

   • Méthode HTTP, URL, en-têtes, corps
   • Ou commande CLI, entrée de fichier, etc.

3. Décrivez le comportement attendu par rapport au comportement réel

   • Ce qui devrait se passer (comportement sécurisé)
   • Ce qui se passe réellement (comportement vulnérable)

Exemple de structure PoC :

{
  "payload": "' OR '1'='1",
  "request": "GET /api/users?search=' OR '1'='1",
  "expected_behavior": "Retourne les utilisateurs correspondant au terme de recherche",
  "actual_behavior": "Retourne tous les utilisateurs en raison d'une injection SQL"
}

Étape 7 : Calculer le score CVSS

Attribuez un score CVSS 3.1 basé sur :

Exemple : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N = 9,1 (Critique)

Étape 8 : Classer le résultat

En fonction de l'analyse, classifiez chaque résultat :

Étape 9 : Générer la sortie

Créez validated-findings.json :

{
  "validation_id": "val-<timestamp>",
  "validation_date": "<ISO timestamp>",
  "scan_id": "<from security-findings.json>",
  "threat_model_version": "<from threat-model.md>",
  "validated_findings": [
    {
      "id": "VULN-001",
      "status": "CONFIRMED",
      "original_severity": "HIGH",
      "validated_severity": "HIGH",
      "exploitability": "EASY",
      "reachability": "EXTERNAL",
      "existing_mitigations": [],
      "exploitation_path": [
        "L'utilisateur soumet une requête de recherche via GET /api/users?search=<payload>",
        "Le routeur Express transmet la requête au gestionnaire searchUsers()",
        "Le gestionnaire transmet l'entrée non-sanitisée au template SQL",
        "PostgreSQL exécute le SQL malveillant"
      ],
      "proof_of_concept": {
        "payload": "' OR '1'='1",
        "request": "GET /api/users?search=' OR '1'='1",
        "expected_behavior": "Retourne les utilisateurs correspondant au terme de recherche",
        "actual_behavior": "Retourne tous les utilisateurs en raison d'une injection SQL"
      },
      "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "cvss_score": 9.1,
      "validation_notes": "Confirmé par traçage de code. Pas de validation d'entrée ou de paramétrisation."
    }
  ],
  "false_positives": [
    {
      "id": "VULN-003",
      "original_severity": "MEDIUM",
      "reason": "L'entrée est validée par le schéma Joi dans l'intergiciel avant d'atteindre ce code. Le schéma applique un format UUID qui prévient l'injection.",
      "evidence": "Voir src/middleware/validation.js:45 - Joi.string().uuid()"
    }
  ],
  "needs_manual_review": [
    {
      "id": "VULN-005",
      "original_severity": "HIGH",
      "reason": "Flux de données complexe via file d'attente de messages. Impossible de tracer complètement si la sanitisation se produit dans le service consommateur."
    }
  ],
  "summary": {
    "total_analyzed": 10,
    "confirmed": 5,
    "likely": 2,
    "false_positives": 2,
    "needs_manual_review": 1,
    "by_severity": {
      "CRITICAL": 1,
      "HIGH": 3,
      "MEDIUM": 1,
      "LOW": 0
    }
  }
}

Critères de succès

La skill est complète quand :

• [ ] Tous les résultats spécifiés ont été analysés
• [ ] Chaque résultat a un statut (CONFIRMED, LIKELY, FALSE_POSITIVE, NEEDS_MANUAL_REVIEW)
• [ ] Les résultats confirmés ont des chemins d'exploitation documentés
• [ ] Les résultats confirmés ont des exploits de preuve de concept
• [ ] Les faux positifs ont un raisonnement clair
• [ ] validated-findings.json est un JSON valide
• [ ] Les scores CVSS sont calculés pour les résultats confirmés

Vérification

Exécutez ces vérifications avant de terminer :

# Vérifiez que la sortie existe et est un JSON valide
cat validated-findings.json | jq . > /dev/null && echo "✓ JSON valide"

# Vérifiez que tous les résultats ont un statut
jq '.validated_findings | all(.status)' validated-findings.json

# Vérifiez que les résultats confirmés ont un PoC
jq '.validated_findings | map(select(.status == "CONFIRMED")) | all(.proof_of_concept)' validated-findings.json

# Vérifiez que les faux positifs ont un raisonnement
jq '.false_positives | all(.reason)' validated-findings.json

Exemples d'invocation

Valider tous les résultats :

Validez les résultats de sécurité du dernier scan.

Valider des résultats spécifiques :

Validez les résultats VULN-001 et VULN-002 depuis security-findings.json.

Valider uniquement HIGH/CRITICAL :

Validez tous les résultats de sévérité HIGH et CRITICAL du scan de sécurité.

Valider avec des fichiers spécifiques :

Validez les résultats dans security-findings.json en utilisant le modèle de menace à .factory/threat-model.md.

Références

• Calculatrice CVSS 3.1 : https://www.first.org/cvss/calculator/3.1
• OWASP Testing Guide : https://owasp.org/www-project-web-security-testing-guide/
• Exemples : validation-examples.md (dans le répertoire de cette skill)
• Skill précédente : commit-security-scan