Vulnerability Analyzer

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.

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 :

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

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)