💻 Développement

vulnerability-analyzer

Analyse et évalue les vulnérabilités d'un système ou d'une application.

⚡ Installation & lancement en 1 commande

Copiez-collez dans votre terminal : le skill s'installe dans ~/.claude/skills et Claude Code se lance directement dessus.

macOS / Linux
curl -fsSL https://raw.githubusercontent.com/khalilbenaz/claude-skills-collection/main/install.sh | sh -s -- vulnerability-analyzer --launch
Windows (PowerShell)
iex "& { $(iwr -useb https://raw.githubusercontent.com/khalilbenaz/claude-skills-collection/main/install.ps1) } vulnerability-analyzer -Launch"

🚀 Déjà installé ?

claude "/vulnerability-analyzer"

Ou tapez /vulnerability-analyzer dans une session Claude Code, ou décrivez simplement votre besoin — le skill se déclenche automatiquement via le skill-router.

🔑 Déclencheurs automatiques

Le skill s'active automatiquement quand votre demande contient :

vulnérabilitéCVEfaillevulnerabilityrisque sécuritéscore CVSSpatch critique

📦 Installation manuelle

git clone https://github.com/khalilbenaz/claude-skills-collection.git cp -r claude-skills-collection/dev-skills/vulnerability-analyzer ~/.claude/skills/

Source : dev-skills/vulnerability-analyzer

📖 Manuel

Vulnerability Analyzer

Workflow

  1. Identification de la vulnérabilité
    • Collecter le CVE ID (ex : CVE-2024-12345) ou décrire la faille si non référencée
    • Identifier le composant affecté (bibliothèque, framework, OS, service) et les versions vulnérables
    • Consulter les sources officielles : NVD (nvd.nist.gov), CVE.org, bulletin du vendor
    • Vérifier si la vulnérabilité est confirmée (Published) ou en cours d'analyse (Awaiting Analysis)
    • Identifier les variantes et CVE liées dans la même famille de failles
  1. Évaluation CVSS v3.1
    • Vecteur d'attaque (AV) : Network / Adjacent / Local / Physical
    • Complexité d'attaque (AC) : Low / High (prérequis spéciaux nécessaires ?)
    • Privilèges requis (PR) : None / Low / High
    • Interaction utilisateur (UI) : None / Required
    • Impact Confidentialité / Intégrité / Disponibilité (CIA) : None / Low / High
    • Calculer le score final : 0.0-3.9 (Faible) / 4.0-6.9 (Moyen) / 7.0-8.9 (Élevé) / 9.0-10.0 (Critique)
    • Prendre en compte le score CVSS Temporel (exploit disponible, remédiation officielle)
  1. Analyse du contexte spécifique
    • Évaluer l'exposition réelle : le composant vulnérable est-il accessible depuis Internet ?
    • Identifier les mitigations existantes (WAF, segmentation réseau, configurations restrictives)
    • Déterminer la criticité métier du système affecté (production, données sensibles, compliance)
    • Analyser les dépendances : d'autres composants dépendent-ils du composant vulnérable ?
    • Vérifier si les conditions d'exploitation sont réunies dans l'environnement cible
  1. Recherche d'exploits connus
    • Vérifier la disponibilité de PoC publics (GitHub, Exploit-DB, Packet Storm)
    • Consulter le catalogue KEV de CISA (Known Exploited Vulnerabilities) pour exploitation active
    • Rechercher dans Metasploit, Nuclei templates, et PoC-in-GitHub
    • Évaluer la maturité de l'exploit : théorique / PoC / exploit fiable / utilisé massivement
    • Surveiller les indicateurs de compromission (IoC) associés à des campagnes actives
  1. Évaluation de l'impact business
    • Identifier les données à risque (données personnelles RGPD, données financières, secrets commerciaux)
    • Évaluer l'impact sur la compliance (PCI-DSS, ISO 27001, HDS, NIS2)
    • Estimer le coût potentiel : pénalités réglementaires, coût d'incident, atteinte à la réputation
    • Évaluer le risque SLA et de continuité de service (RTO/RPO impactés)
    • Quantifier l'exposition : nombre d'utilisateurs, volume de données, systèmes en aval
  1. Plan de remédiation
    • Patch officiel : appliquer le patch vendor dès disponibilité (lien direct vers le bulletin de sécurité)
    • Workaround temporaire : désactiver la fonctionnalité vulnérable, restreindre l'accès réseau
    • Durcissement de configuration : paramètres à modifier pour réduire la surface d'attaque
    • Règles WAF : signatures ModSecurity / AWS WAF / Cloudflare pour bloquer l'exploitation
    • Mise à jour de dépendances : commandes spécifiques (npm update <pkg>, pip install --upgrade <pkg>)
    • Fournir des exemples de code pour les remédiations applicatives (validation d'entrées, configuration sécurisée)
  1. Timeline de correction recommandée selon la sévérité
    • Critique (9.0-10.0) + exploitation active : patch dans les 24-48h, isolation immédiate si impossible
    • Critique (9.0-10.0) sans exploit actif : patch dans les 7 jours
    • Élevé (7.0-8.9) : patch dans les 30 jours, mitigation immédiate si exposition Internet
    • Moyen (4.0-6.9) : patch dans les 90 jours, intégrer au prochain cycle de maintenance
    • Faible (0.1-3.9) : patch dans les 180 jours ou au prochain cycle de mise à jour majeure
    • Ajuster selon le contexte : un Moyen sur un système critique peut devenir prioritaire
  1. Suivi post-remédiation et validation
    • Vérifier l'application du patch (version installée, hash du binaire, test de régression)
    • Effectuer un scan de validation ciblé (Nuclei, Nessus, OpenVAS) pour confirmer la correction
    • Mettre à jour le registre des vulnérabilités et les tickets de suivi (Jira, ServiceNow)
    • Documenter la remédiation avec date, actions réalisées et responsable
    • Évaluer si la même vulnérabilité peut être présente sur d'autres systèmes similaires

Règles