# Vulnerability Analyzer

> 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".

- Skill: `khalilbenaz/vulnerability-analyzer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add khalilbenaz/vulnerability-analyzer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/khalilbenaz/vulnerability-analyzer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: khalilbenaz (https://skillmd.com/u/khalilbenaz)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/khalilbenaz/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.

| 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

```bash
# 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

```bash
# 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 :**

```bash
# 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 :**

```bash
# 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 :**

```python
# 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()
```

```java
// 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

```bash
# 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 |