Pentest vs scan de vulnérabilités : que choisir ?

"On fait un pentest ou un scan ?", la question revient à chaque comité de sécurité. La réponse n'est pas l'un ou l'autre, mais la bonne combinaison au bon moment. Trop d'organisations commandent un pentest annuel à 15 000 € et pensent que leur sécurité est couverte. Elle ne l'est pas. Mais un scan automatisé seul ne suffit pas non plus.

Le pentest : l'attaquant simulé

Un test d'intrusion est réalisé par un ou plusieurs pentesteurs humains qui simulent une attaque réelle sur votre système. Ils utilisent les mêmes outils et techniques que les attaquants.

Ce que le pentest apporte

• Créativité humaine : le pentesteur enchaîne des vulnérabilités mineures pour obtenir un impact majeur. Une mauvaise config CORS + une XSS stockée + un cookie sans flag HttpOnly = exfiltration de sessions admin. Un scan ne fait pas cette chaîne.

• Contexte métier : le testeur comprend que l'accès aux données patients est plus critique que l'accès à la page "À propos". Il priorise par impact réel.

• Preuve d'exploitation : pas juste "cette vulnérabilité existe" mais "voici ce qu'un attaquant en fait concrètement". Ça change la conversation avec la direction.

• Tests logiques : élévation de privilèges horizontale (accéder aux données d'un autre utilisateur), contournement de workflows métier. Aucun scanner ne teste ça.

Les limites du pentest

• Coût élevé : 5 000 à 30 000 € selon le périmètre (application web simple vs infrastructure complète). Un pentest Red Team peut atteindre 50 000 à 100 000 €.

• Ponctuel : une photo à un instant T. Le lendemain du pentest, un déploiement peut introduire une nouvelle vulnérabilité.

• Couverture limitée : en 5 jours, le pentesteur ne teste pas 100 % de votre surface. Il se concentre sur les vecteurs les plus prometteurs.

• Dépendance au testeur : la qualité varie énormément d'un prestataire à l'autre. Un pentest médiocre donne un faux sentiment de sécurité.

• Fréquence : la plupart des organisations font un pentest par an. 365 jours sans visibilité entre deux tests.

Le scan de vulnérabilités : le filet continu

Le scan de vulnérabilités est un processus automatisé qui identifie les failles connues sur vos systèmes en les comparant aux bases de CVE (NVD, VulnDB).

Ce que le scan apporte

• Exhaustivité : le scanner teste chaque port, chaque service, chaque version de package. Là où le pentesteur se concentre, le scanner balaye tout.

• Fréquence : quotidien ou hebdomadaire. Vous détectez une nouvelle CVE sur votre stack Apache dans les 24h après sa publication, pas 11 mois après au prochain pentest.

• Coût marginal faible : une fois configuré, le scan additionnel ne coûte rien. Scanner 10 serveurs ou 1 000 demande le même effort humain.

• Scoring standardisé : CVSS pour la sévérité technique, EPSS pour la probabilité d'exploitation réelle. EPSS est devenu indispensable : une CVE avec un CVSS de 9.8 mais un EPSS de 0.1 % est moins urgente qu'une CVE à CVSS 7.5 avec un EPSS de 85 %.

• Historique et tendances : suivi de la dette de vulnérabilités dans le temps, métriques MTTR (Mean Time To Remediate).

Les limites du scan

• Pas de créativité : le scan identifie des vulnérabilités individuelles, pas des chaînes d'exploitation. Il ne teste pas la logique métier.

• Faux positifs : les scanners génèrent 20-30 % de faux positifs selon les environnements. Sans priorisation intelligente, c'est du bruit.

• Vulnérabilités connues uniquement : si la CVE n'est pas dans la base, le scanner ne la trouve pas. Zero-days, misconfigurations custom, failles logiques : invisibles.

• Pas de contexte d'impact : une vulnérabilité sur un serveur de dev interne n'a pas le même impact qu'une vulnérabilité identique sur le serveur de production exposé.

CVSS vs EPSS : changer de paradigme

Le scoring CVSS (Common Vulnerability Scoring System) évalue la sévérité technique d'une vulnérabilité. Le scoring EPSS (Exploit Prediction Scoring System) évalue la probabilité qu'elle soit exploitée dans les 30 prochains jours.

En 2026, prioriser par CVSS seul est obsolète. Exemple concret :

• CVE-2024-XXXX : CVSS 9.8 (critique), EPSS 0.04 % → pas d'exploit connu, complexité d'exploitation élevée. Priorité basse.

• CVE-2024-YYYY : CVSS 7.2 (haute), EPSS 92 % → exploit public, activement exploité dans la nature. Priorité immédiate.

ThreatClaw combine CVSS et EPSS pour prioriser les remédiations. Vous corrigez d'abord ce que les attaquants exploitent réellement, pas ce qui a le plus gros score théorique.

Quand choisir quoi ?

Voici mon guide de décision :

• Scan continu (obligatoire) : pour toute organisation, quelle que soit la taille. C'est votre filet de sécurité permanent. Aucune excuse en 2026 pour ne pas scanner son infrastructure au moins hebdomadairement.

• Pentest annuel (recommandé) : pour les organisations avec des applications web, des API, ou des environnements complexes. Le pentest valide ce que le scan ne peut pas tester.

• Pentest semestriel : si vous êtes dans un secteur régulé (finance, santé) ou si votre surface d'attaque change fréquemment (déploiements continus).

• Red Team : si votre maturité est suffisante (SOC opérationnel, détection en place). Le Red Team teste la détection et la réponse, pas seulement les vulnérabilités. Inutile si votre monitoring est inexistant.

ThreatClaw pour le scan continu

Les skills ThreatClaw couvrent le scan continu sous tous les angles :

• Nmap : découverte d'actifs et scan de ports avec scripts NSE de détection de vulnérabilités

• Trivy/Grype : scan des images Docker, des dépendances applicatives et des filesystems

• OWASP ZAP : scan DAST des applications web exposées

• Nuclei : 8 000+ templates communautaires pour la détection de vulnérabilités web et infrastructure

• Lynis : audit de hardening Linux avec scoring

Chaque finding est scoré (CVSS + EPSS), contextualisé (production vs dev, exposé vs interne) et priorisé. Le résultat : un flux de vulnérabilités traitables, pas un rapport de 500 pages qu'on imprime et qu'on range. Commencez le scan continu.

Le modèle combiné optimal

Pour une PME/ETI, la combinaison la plus efficace :

• Continu : ThreatClaw pour le scan de vulnérabilités (infra + web + containers), automatisé, quotidien

• Annuel : pentest applicatif par un prestataire externe (focus logique métier, chaînes d'exploitation)

• À chaque changement majeur : scan ciblé après un déploiement important, une migration cloud, un changement d'architecture

L'audit continu comble le vide entre les pentests. Le pentest valide ce que l'automatisation ne peut pas tester. Les deux se renforcent mutuellement.

FAQ

Un scan de vulnérabilités peut-il remplacer un pentest ?

Non. Le scan identifie des vulnérabilités individuelles connues. Le pentest teste l'exploitation réelle, les chaînes d'attaque et la logique métier. Un scan peut trouver qu'Apache est en version vulnérable. Seul un pentesteur trouvera que cette vuln combinée avec une mauvaise config réseau permet d'accéder à la base de production. Les deux sont nécessaires.

Quel budget prévoir pour un pentest ?

Fourchettes courantes en France (2026) : application web simple (5 000-10 000 €), application web complexe + API (10 000-20 000 €), infrastructure réseau (8 000-25 000 €), Red Team complet (30 000-100 000 €). Méfiez-vous des offres à moins de 3 000 € : à ce prix, vous aurez un scan automatisé déguisé en pentest.

À quelle fréquence scanner mes vulnérabilités ?

Minimum hebdomadaire pour l'infrastructure, à chaque build/déploiement pour les applications. Les environnements exposés sur Internet méritent un scan quotidien. Avec ThreatClaw, la fréquence est configurable par skill et par périmètre, sans surcoût lié au volume.

EPSS est-il plus fiable que CVSS ?

Ce sont deux métriques complémentaires qui mesurent des choses différentes. CVSS mesure la sévérité technique intrinsèque. EPSS mesure la probabilité d'exploitation dans les 30 jours. Pour la priorisation des patchs, EPSS est plus actionnable car il reflète le risque réel. Pour le reporting de conformité, CVSS reste la référence. Utilisez les deux ensemble.