Scan de Sécurité des Commits

Analysez les changements de code (commits, PR, diffs) en utilisant le raisonnement basé sur les LLM pour détecter les vulnérabilités de sécurité. Cette skill lit le code directement et applique les patterns du modèle de menaces du repository pour identifier les problèmes dans toutes les catégories STRIDE.

Quand Utiliser Cette Skill

• Révision PR - Scan de sécurité automatisé sur les pull requests
• Vérification pré-commit - Analyser les changements en staging avant de commiter
• Comparaison de branches - Examiner la sécurité des changements d'une branche feature
• Assistance à la revue de code - Aider les reviewers à repérer les problèmes de sécurité

Prérequis

Cette skill nécessite :

1. Modèle de menaces - .factory/threat-model.md doit exister
2. Configuration de sécurité - .factory/security-config.json pour les seuils de sévérité

IMPORTANT : Si ces fichiers n'existent pas, tu DOIS les générer d'abord avant de procéder au scan de sécurité.

Pour générer les prérequis :

1. Informe l'utilisateur : « Le modèle de menaces n'existe pas encore. Je vais le générer d'abord avant de scanner. »
2. Exécute la skill threat-model-generation pour créer les deux fichiers
3. Une fois terminé, continue avec le scan de sécurité

Ne demande PAS à l'utilisateur d'exécuter la skill manuellement - fais-le automatiquement dans le cadre de ce workflow.

Entrées

La skill détermine ce qu'il faut scanner à partir de la demande de l'utilisateur :

Si aucune portée n'est spécifiée, demande une clarification à l'utilisateur.

Instructions

Suis ces étapes dans l'ordre :

Étape 1 : Vérifier les Prérequis (Auto-Générer s'ils Manquent)

Essaye de lire ces fichiers :

• .factory/threat-model.md
• .factory/security-config.json

Si l'un de ces fichiers manque ou ne peut pas être lu :

1. Informe l'utilisateur : « Le modèle de menaces de sécurité n'existe pas encore. Je vais le générer d'abord - cela peut prendre une minute. »
2. Invoque la skill threat-model-generation pour analyser le repository et créer les deux fichiers
3. Une fois la génération terminée, continue à l'étape 2

Cela garantit que le scan de sécurité dispose toujours du contexte du modèle de menaces pour une analyse précise.

Étape 2 : Récupérer les Fichiers Modifiés

En fonction de la demande de l'utilisateur, récupère la liste des fichiers modifiés et leurs diffs avec git :

• Pour les PR : utilise gh pr diff
• Pour les commits/plages : utilise git diff ou git show
• Pour les changements en staging : utilise git diff --cached

Lis le contenu complet de chaque fichier modifié pour le contexte.

Étape 3 : Charger le Modèle de Menaces

Lis .factory/threat-model.md et .factory/security-config.json pour comprendre :

• L'architecture du système et les limites de confiance
• Les patterns de vulnérabilités connus pour ce codebase
• Les seuils de sévérité pour les résultats

Étape 4 : Analyser les Vulnérabilités

Pour chaque fichier modifié, vérifie systématiquement les menaces STRIDE :

S - Usurpation d'Identité

• Contrôles d'authentification manquants ou faibles
• Vulnérabilités de gestion de session
• Exposition de tokens/credentials dans le code
• Paramètres de cookie non sécurisés

T - Falsification de Données

• Injection SQL : Concaténation/interpolation de strings dans les requêtes SQL
• Injection de Commandes : Input utilisateur dans les commandes shell, eval(), exec()
• XSS : Input utilisateur non échappé en HTML/templates
• Mass Assignment : Assignation aveugle de la requête au modèle
• Path Traversal : Input utilisateur dans les chemins de fichiers sans validation

R - Répudiation

• Logs d'audit manquants pour les opérations sensibles
• Logging d'erreur insuffisant
• Vulnérabilités d'injection de logs

I - Divulgation d'Informations

• IDOR : Accès direct aux objets sans vérification de propriété
• Messages d'erreur verbeux exposant les internals
• Secrets, clés API, credentials codés en dur
• Données sensibles dans les logs ou les réponses
• Endpoints de debug exposés

D - Déni de Service

• Rate limiting manquant sur les endpoints
• Consommation de ressources non bornée (uploads de fichiers, requêtes)
• Attaques de complexité algorithmique (regex, tri)
• Pagination manquante sur les endpoints de liste

E - Escalade de Privilèges

• Contrôles d'autorisation manquants sur les endpoints
• Opportunités de contournement de rôle/permission
• Escalade de privilèges via manipulation de paramètres

Étape 5 : Évaluer Chaque Résultat

Pour chaque vulnérabilité potentielle :

1. Tracer le flux de données : Suis l'input utilisateur de la source au point de destination

   • D'où vient l'input ? (params de requête, body, headers, fichiers)
   • Passe-t-il par une validation/sanitization ?
   • Où aboutit-il ? (database, shell, réponse, système de fichiers)

2. Vérifier les mitigations existantes :

   • Y a-t-il une validation ailleurs dans le codebase ?
   • Y a-t-il des middleware/décorateurs qui protègent ce code ?
   • Le framework offre-t-il une protection automatique ?

3. Déterminer la sévérité :

   • CRITIQUE : Exécution de code à distance, contournement d'authentification, fuite de données
   • HAUTE : Injection SQL, XSS, IDOR, escalade de privilèges
   • MOYENNE : Divulgation d'informations, headers de sécurité manquants
   • BASSE : Violations de bonnes pratiques, problèmes mineurs

4. Évaluer la confiance :

   • HAUTE : Pattern vulnérable clair, flux de données direct, pas de mitigations
   • MOYENNE : Vulnérabilité possible, incertitude sur le contexte
   • BASSE : Pattern suspect, probablement des mitigations qu'on ne voit pas

Étape 6 : Générer le Rapport

Crée security-findings.json avec cette structure :

{
  "scan_id": "scan-YYYY-MM-DD-XXX",
  "scan_date": "<ISO 8601 timestamp>",
  "scan_type": "pr|commit|range|staged|working",
  "commit_range": "<base>..<head>",
  "pr_number": null,
  "threat_model_version": "<from security-config.json>",
  "findings": [
    {
      "id": "VULN-001",
      "severity": "HIGH",
      "stride_category": "Tampering",
      "vulnerability_type": "SQL Injection",
      "cwe": "CWE-89",
      "file": "src/api/users.py",
      "line_range": "45-49",
      "code_context": "<vulnerable code snippet>",
      "analysis": "<explanation of why this is vulnerable>",
      "exploit_scenario": "<how an attacker could exploit this>",
      "threat_model_reference": "Section 5.2 - SQL Injection",
      "existing_mitigations": [],
      "recommended_fix": "<how to fix the vulnerability>",
      "confidence": "HIGH",
      "reasoning": "<why this confidence level>"
    }
  ],
  "summary": {
    "total_findings": 0,
    "by_severity": { "CRITICAL": 0, "HIGH": 0, "MEDIUM": 0, "LOW": 0 },
    "by_stride": {
      "Spoofing": 0,
      "Tampering": 0,
      "Repudiation": 0,
      "InfoDisclosure": 0,
      "DoS": 0,
      "ElevationOfPrivilege": 0
    },
    "files_analyzed": 0
  }
}

Étape 7 : Rapporter les Résultats

1. Enregistre les résultats dans security-findings.json
2. Rapporte le résumé à l'utilisateur (nombre de résultats par sévérité, seuils déclenchés)
3. Vérifie les seuils de sévérité depuis security-config.json et note s'il y en a de déclenchés

Référence CWE

Mappings CWE communs pour les résultats :

Exemples d'Invocation

Scanner une PR :

Scan PR #123 for security vulnerabilities

Scanner les changements en staging avant de commiter :

Scan my staged changes for security issues

Scanner une branche feature :

Scan changes from main to feature/user-auth for vulnerabilities

Scanner les commits récents :

Scan the last 5 commits for security issues

Références

• Exemples d'analyse : analysis-examples.md (dans le répertoire de cette skill)
• Modèle de menaces : .factory/threat-model.md
• Configuration de sécurité : .factory/security-config.json
• OWASP Top 10
• CWE Top 25