Nuclei à l'échelle : scan de vulnérabilités et réponse rapide KEV

Un RSSI à temps partagé n'a ni pentester dédié ni budget pour un audit trimestriel sur chaque actif. Ce qu'il lui faut, c'est un moyen de répondre à deux questions simples en continu : "est-ce que mon parc entier est vulnérable à ce qui vient de sortir" et "combien de temps me sépare d'une exploitation active". Nuclei répond aux deux, à condition d'être utilisé comme un moteur de scan de vulnérabilités à l'échelle, pas comme un outil de test ponctuel sur une poignée de cibles.

Cet article couvre la méthode complète : le modèle de template, la manière de scanner un parc sans le mettre à genoux, la réponse rapide à un bulletin KEV, et pourquoi la maintenance du jeu de templates est le vrai sujet, pas l'installation du moteur.

Le modèle de template Nuclei, brique de base du scan à l'échelle

Un template Nuclei est un fichier YAML qui décrit une requête et la condition qui prouve la présence d'une faille. Deux commandes suffisent pour comprendre l'usage à l'échelle :

# Une seule cible, un tag précis
nuclei -u https://app.exemple.fr -tags cve,kev
 
# Un parc entier, décrit dans un fichier
nuclei -l cibles.txt -tags cve,kev -severity critical,high

Le fichier cibles.txt contient une URL ou un hôte par ligne : c'est la brique qui transforme Nuclei d'un outil "je teste une appli" en un outil "je couvre mon parc". Les tags filtrent le jeu de templates chargé : cve cible les signatures liées à des CVE publiées, kev (quand le pack les qualifie ainsi) cible celles qui correspondent à une exploitation active documentée. Le moteur applique ensuite chaque template selon deux mécanismes :

• Les matchers décident si la réponse prouve la vulnérabilité (code de statut, mot-clé dans le corps, expression régulière, callback réseau via interactsh pour les failles aveugles).
• Les extractors récupèrent une donnée utile dans la réponse (un numéro de version, un jeton, un chemin) sans se prononcer sur la vulnérabilité : utile pour du fingerprint technologique en amont d'un matcher.

Cette séparation matchers/extractors est ce qui permet d'écrire des templates précis plutôt que des règles qui disent juste "le chemin existe".

Scanner un parc sans le saturer

La première fois qu'on lance Nuclei sur un parc de plusieurs centaines d'actifs sans réglage, deux choses se produisent : le pare-feu applicatif commence à bloquer l'IP source, et certains services sous-dimensionnés tombent sous la charge. Le scan à l'échelle n'est pas qu'une question de couverture, c'est une question de débit maîtrisé.

Avant (scan qui casse des choses) :

nuclei -l cibles.txt -t nuclei-templates/

Sans limite de débit ni de concurrence, Nuclei ouvre autant de connexions que le système le permet, sur toutes les cibles en parallèle, avec l'intégralité du jeu de templates communautaire. Sur un parc PME avec des applications legacy ou des équipements réseau modestes, c'est le service qui plante avant la fin du scan.

Après (scan maîtrisé) :

nuclei -l cibles.txt \
  -tags cve,kev \
  -severity critical,high,medium \
  -rl 150 \
  -c 25 \
  -timeout 8 \
  -retries 1

• -rl (rate-limit) plafonne le nombre de requêtes par seconde envoyées globalement : c'est le réglage qui protège les équipements réseau et les applications fragiles.
• -c (concurrency) limite le nombre de cibles traitées en parallèle, indépendamment du débit par cible.
• -timeout évite qu'une cible qui ne répond pas bloque le pool de workers.
• La résolution DNS doit être vérifiée en amont (un domaine qui pointe vers une IP tierce ou expirée fait perdre du temps et peut générer un scan hors périmètre) : un fichier de résolveurs dédiés ou une liste d'IP validées en entrée évite ce piège.

Un scan qui termine proprement sur l'ensemble du parc, sans incident collatéral, vaut plus qu'un scan agressif qui remonte trois vulnérabilités avant de faire tomber un service.

Réponse KEV et 0-day : du bulletin CISA au template déployé en heures

C'est le second usage, et celui qui justifie vraiment Nuclei pour un RSSI sans équipe offensive dédiée. Un bulletin CISA KEV tombe : la faille est confirmée comme activement exploitée, pas seulement théorique. Le compte à rebours commence, et il se compte en heures, pas en semaines.

Le principe de priorisation est simple à appliquer :

• KEV (Known Exploited Vulnerabilities) : la faille est déjà exploitée dans la nature. C'est une urgence opérationnelle, pas une hypothèse à évaluer.
• EPSS (Exploit Prediction Scoring System) : une probabilité d'exploitation à 30 jours. Utile pour arbitrer entre deux CVE qui ne sont pas encore dans KEV.

Croiser "cette CVE est dans KEV" avec "elle touche un actif exposé de mon parc" donne une liste courte et actionnable. Sur cette liste, la chaîne devient : lire le bulletin, identifier le comportement observable qui prouve la faille (un chemin, une réponse caractéristique, un en-tête), écrire ou récupérer le template, le valider sur une version vulnérable connue, puis lancer :

nuclei -l cibles.txt -tags kev -severity critical -json -o resultats-kev.json

Le résultat en JSON s'ingère directement dans un pipeline de remédiation ou un ticket. L'objectif n'est pas la perfection du template au premier jet, c'est la réduction du délai entre "le bulletin existe" et "je sais qui, dans mon parc, est concerné".

Versionner et maintenir le jeu de templates

Un jeu de templates n'est pas un artefact statique : il se met à jour comme n'importe quelle base de signatures.

nuclei -update-templates

Cette commande synchronise le dépôt de templates local avec la dernière version publiée. Mais la mise à jour brute pose un problème en environnement de production : un template modifié ou retiré entre deux scans change silencieusement la surface couverte. Deux réflexes limitent ce risque :

• Le pinning : figer une version connue du jeu de templates (par un tag de commit ou un identifiant de release) pour les scans de référence, et ne faire évoluer cette version qu'après vérification.
• Le diff : comparer le jeu de templates avant et après mise à jour pour savoir ce qui a été ajouté, modifié ou supprimé, avant de relancer un scan de parc complet avec ce nouveau jeu.

Sans cette discipline, un scan "à jour" peut en réalité couvrir moins de surface qu'un mois auparavant, sans que personne ne s'en aperçoive avant l'incident.

Réduire les faux positifs : la discipline qui change tout

Un scan de vulnérabilités qui remonte cent alertes dont soixante sont du bruit finit ignoré. La réduction des faux positifs repose sur trois pratiques, pas sur un réglage miracle :

• Des matchers stricts. Un code de statut seul ne prouve rien ; une bannière de version peut être masquée ou héritée d'un correctif partiel. Le matcher doit porter sur le comportement observable de la faille (une donnée précise dans la réponse, une combinaison de conditions avec matchers-condition: and), pas sur un indice indirect.
• Le fingerprint technologique en amont. Identifier la techno et sa version exacte avant d'appliquer un template ciblé évite de tester une signature Apache sur un serveur Nginx, ou une version de CMS sur une instance qui ne l'exécute pas.
• Les negative matchers. Exclure explicitement les réponses qui ressemblent à un faux positif connu (une page d'erreur générique qui contient par coïncidence le mot-clé recherché) réduit le bruit sans perdre en couverture.

La preuve, ici encore, est empirique : un template qui reste silencieux sur un corpus de cibles bénignes ou déjà corrigées, et qui ne se déclenche que sur la cible réellement vulnérable, est le seul critère qui compte. "Valide syntaxiquement" et "fiable en production" sont deux choses différentes.

Pourquoi un abonnement de templates maintenu bat un clone GitHub figé

Cloner le dépôt communautaire de templates un jour donné coûte une commande. Le maintenir ensuite coûte du temps, tous les jours. Deux mois plus tard, sans mise à jour, ce clone souffre de trois problèmes simultanés : les nouvelles CVE ne sont pas couvertes, les templates existants n'ont pas suivi les correctifs de faux positifs remontés par la communauté, et rien ne signale qu'une faille désormais en KEV n'a toujours pas de détection associée dans le jeu figé.

Un jeu de templates maintenu résout ce triple problème en continu : priorisation systématique par KEV et EPSS, validation de chaque signature sur un moteur réel avant publication, et mise à jour régulière qui ferme la fenêtre d'exposition au lieu de la laisser s'élargir mois après mois.

C'est exactement ce que livre le pack Nuclei ThreatClaw : un jeu de templates entretenu, priorisé KEV et EPSS, prêt à scanner un parc entier sans le saturer, pour réagir en heures et non en semaines au prochain bulletin critique.