dev-vulnerability-analyzer

name	dev-vulnerability-analyzer
description	Analyse et évalue les vulnérabilités d'un système ou d'une application. À utiliser pour comprendre et prioriser les vulnérabilités, construire un plan de remédiation et valider la correction. Se déclenche avec "vulnérabilité", "CVE", "faille", "vulnerability", "risque sécurité", "score CVSS", "patch critique". Also triggers on "analyze a vulnerability", "CVE impact", "is this CVE exploitable".

Vulnerability Analyzer

Workflow

1. Collecte des informations

Commencer par poser ces questions si l'utilisateur ne les a pas fournies :

• CVE ID ou description de la faille ?
• Composant/version affecté ? Stack technique (language, runtime, OS) ?
• Environnement : exposition Internet ? cloud / on-premise / conteneur ?
• Système en production avec données sensibles ?

Sources officielles à consulter systématiquement :

https://nvd.nist.gov/vuln/detail/CVE-XXXX-YYYY   # NVD — score CVSS officiel
https://www.cve.org/CVERecord?id=CVE-XXXX-YYYY    # CVE.org — description brute
https://www.cisa.gov/known-exploited-vulnerabilities-catalog  # KEV — exploitation active
https://github.com/advisories                      # GitHub Advisory Database

2. Évaluation CVSS v4.0 (2026)

CVSS v4.0 remplace v3.1 comme référence depuis 2024. Vérifier la version du score fourni.

Métrique	Valeurs	Poids sur le score
Attack Vector (AV)	Network > Adjacent > Local > Physical	Fort
Attack Complexity (AC)	Low > High	Moyen
Privileges Required (PR)	None > Low > High	Moyen
User Interaction (UI)	None > Passive > Active	Faible
Impact CIA	High > Low > None (×3)	Fort

Score final : 0.0–3.9 Faible / 4.0–6.9 Moyen / 7.0–8.9 Élevé / 9.0–10.0 Critique

Attention : le score NVD est calculé dans le contexte générique. Toujours recalculer avec le contexte réel (score Environmentale/Temporel).

Calculateur CVSS officiel : https://www.first.org/cvss/calculator/4-0

3. Vérification de l'exposition réelle

Questions de décision avant de prioriser :

[ ] Le composant est-il joignable depuis Internet (direct ou indirect) ?
[ ] Des données sensibles (PII, financières, secrets) transitent-elles par ce composant ?
[ ] L'exploitation nécessite-t-elle des privilèges déjà présents dans l'environnement ?
[ ] Des mitigations compensatoires existent-elles (WAF, network policy, auth forte) ?
[ ] Le service est-il critique pour la continuité métier ?

Une faille CVSS 7.5 sur un service interne sans données sensibles est moins urgente qu'un CVSS 6.5 sur une API publique d'authentification.

4. Recherche d'exploits actifs

# Vérifier si dans le catalogue KEV CISA (exploitation confirmée en production)
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" \
  | jq '.vulnerabilities[] | select(.cveID == "CVE-XXXX-YYYY")'

# Rechercher des PoC publics
gh search repos "CVE-XXXX-YYYY" --limit 10

# Vérifier Nuclei templates disponibles
nuclei -list -tags cve -filter-severity critical,high | grep XXXX-YYYY

# Exploit-DB
searchsploit CVE-XXXX-YYYY

Maturité d'exploit (du moins grave au plus grave) :

1. Théorique — aucun code public
2. PoC — démonstration en labo, difficile à adapter
3. Exploit fonctionnel — code public adapté à des cibles réelles
4. Weaponized — intégré dans des frameworks (Metasploit, ransomware kits)
5. Exploitation active ITW (In The Wild) — confirmée CISA KEV ou threat feeds

5. Scan de détection dans l'environnement

# Trivy — dépendances et images Docker
trivy image myapp:latest --severity HIGH,CRITICAL
trivy fs . --severity HIGH,CRITICAL --format json > trivy-report.json

# Grype — alternative rapide
grype dir:. -o json | jq '.matches[] | select(.vulnerability.severity == "Critical")'

# Snyk — dépendances applicatives
snyk test --severity-threshold=high --json

# OWASP Dependency-Check (Java/Maven)
dependency-check.sh --project myapp --scan ./target --format HTML

# npm audit
npm audit --audit-level=high --json

# pip-audit (Python)
pip-audit --format json --severity high

6. Plan de remédiation par priorité

Décision rapide :

Situation	Action
KEV CISA + exposition Internet	Isolation immédiate → patch sous 24h
Critique sans exploit public + exposition Internet	Workaround immédiat + patch sous 7j
Élevé + exposition Internet	Patch sous 30j, mitigation réseau
Critique sur système interne isolé	Patch sous 30j, surveillance accrue
Moyen/Faible système non critique	Intégrer au prochain cycle maintenance

Commandes de mise à jour de dépendances :

# npm / Node.js
npm update <package>                        # patch seul
npm install <package>@latest                # dernière version stable
npm audit fix --force                       # forcer les corrections (tester avant !)

# Python
pip install --upgrade <package>
pip install "<package>>=X.Y.Z"

# Java / Maven
mvn versions:update-properties              # mise à jour des propriétés
mvn dependency:tree | grep <package>        # identifier l'arbre de dépendances

# Go
go get <module>@vX.Y.Z
go mod tidy

# Docker — reconstruire l'image sur base patchée
docker build --no-cache -t myapp:patched .

Workarounds fréquents :

# Désactiver un endpoint vulnérable (nginx)
location /vulnerable-path { return 403; }

# Restreindre l'accès réseau (iptables)
iptables -A INPUT -p tcp --dport 8080 -s 0.0.0.0/0 -j DROP
iptables -A INPUT -p tcp --dport 8080 -s 10.0.0.0/8 -j ACCEPT

# Règle Cloudflare WAF (expression)
(http.request.uri.path contains "/vulnerable-endpoint") → Block

# Désactiver un header ou feature dangereuse (Spring Boot)
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.XXX=false

Remédiation applicative — exemples :

# Validation d'entrée stricte (Python) — contre injection / path traversal
import re, os

def safe_file_read(user_input: str, base_dir: str) -> str:
    # Normaliser et valider
    safe_name = re.sub(r'[^a-zA-Z0-9_\-\.]', '', user_input)
    full_path = os.path.realpath(os.path.join(base_dir, safe_name))
    if not full_path.startswith(os.path.realpath(base_dir)):
        raise ValueError("Path traversal détecté")
    return open(full_path).read()

// Désérialisation sécurisée (Java) — contre RCE par désérialisation
ObjectInputStream ois = new ObjectInputStream(inputStream) {
    @Override
    protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {
        if (!ALLOWED_CLASSES.contains(desc.getName())) {
            throw new InvalidClassException("Classe non autorisée : " + desc.getName());
        }
        return super.resolveClass(desc);
    }
};

7. Timeline de correction

Sévérité + contexte	Délai max	Action immédiate
Critique + KEV CISA	24–48h	Isoler le service
Critique sans exploit	7 jours	Activer WAF / bloquer IP
Élevé + exposition Internet	30 jours	Mitigation réseau
Élevé + interne	60 jours	Surveillance logs
Moyen	90 jours	Planifier maintenance
Faible	180 jours	Prochain cycle majeur

Ajuster si : système PCI-DSS / HDS / NIS2 (délais souvent contractuels), données personnelles (RGPD notif 72h si brèche).

8. Validation post-remédiation

# Vérifier la version installée
dpkg -l <package> | grep '^ii'            # Debian/Ubuntu
rpm -q <package>                           # RHEL/CentOS

# Scan de confirmation ciblé avec Nuclei
nuclei -u https://target.example.com -tags cve -id CVE-XXXX-YYYY

# Vérifier l'image Docker mise à jour
trivy image myapp:patched --exit-code 1 --severity CRITICAL

# Audit npm après correction
npm audit --audit-level=critical

Checklist de clôture :

[ ] Version patchée déployée en production
[ ] Scan de validation passé (0 finding sur la CVE)
[ ] Ticket de suivi fermé avec date + responsable
[ ] Même vulnérabilité vérifiée sur les systèmes similaires
[ ] Monitoring/alerting mis en place si applicable
[ ] Retour d'expérience documenté (cause, délai, action)

Anti-patterns et pièges fréquents

• Ne pas confondre score NVD et risque réel : un CVSS 9.8 sur un composant interne non exposé est moins urgent qu'un 7.0 sur une API publique authentifiée.
• npm audit fix --force sans test : peut casser des dépendances transitives — toujours tester en staging.
• Patcher sans valider : vérifier que la version installée correspond bien au bulletin (les packages managers mentent parfois sur la version effective).
• Ignorer les dépendances transitives : la faille peut venir d'une dépendance de dépendance — utiliser npm ls <package> ou mvn dependency:tree pour localiser la source.
• Fermer le ticket sans scan de confirmation : sans scan post-patch, impossible de garantir que la correction est effective.
• Traiter les workarounds comme définitifs : les blocages WAF ou network peuvent être contournés ; le patch reste la seule correction durable.
• Négliger les systèmes similaires : si une faille touche un service, chercher systématiquement si le même composant est présent ailleurs.

Sources de référence (2026)

Source	Usage
nvd.nist.gov	Score CVSS officiel, description technique
cisa.gov/kev	Exploitations actives confirmées
github.com/advisories	Dépendances open-source
security.snyk.io	Dépendances + remediation guidée
exploit-db.com	PoC et exploits publics
vulncheck.com	Intelligence threat + KEV enrichi
first.org/cvss	Calculateur CVSS v4.0

Communication Rules — MANDATORY

• Ultra-concise. No filler, no preamble, no pleasantries.
• Never say "happy to help", "sure!", "great question", "let me", or similar.
• Tool first, talk second. Act before explaining.
• Result first. Lead with outcome, not process.
• Stop when done. No summary, no recap, no trailing commentary.
• No politeness wrappers. Direct and blunt.
• Minimum words. If one word works, do not use ten.
• No unsolicited explanations.
• No emoji unless asked.