“Nous gérons déjà nos vulnérabilités, nous faisons des scans de sécurité réguliers”.
Si vous êtes DSI ou RSSI, vous avez peut-être déjà prononcé cette phrase. Et elle est légitime : vos outils sont probablement en place, vos cycles d’analyse sont planifiés, vos tableaux de bord se remplissent. En apparence, tout est sous contrôle.
Le problème, c’est qu’entre deux scans, votre surface d’attaque continue d’évoluer. Et vos actifs considérés comme sécurisés ne le sont peut-être plus.
L’enjeu n’est donc plus seulement de détecter vos failles à intervalles réguliers mais de piloter votre exposition en temps réel, en fonction des menaces, de votre contexte et de votre capacité réelle de remédiation.
C’est exactement la promesse du CTEM (Continuous Threat Exposure Management) : passer d’une logique de contrôle périodique à une gestion continue et structurée du risque.
Dans cet article, nous allons décrypter cette approche devenue incontournable, comprendre en quoi elle redéfinit la gestion des vulnérabilités, et comment Cyberwatch vous permet de l’intégrer concrètement à vos pratiques.
CTEM : une nouvelle approche face aux limites de la gestion classique des vulnérabilités
Pendant des années, la gestion des vulnérabilités (VM) et de la sécurité des systèmes d’information s’est appuyée sur des audits périodiques : un scan mensuel, un pentest trimestriel, un audit de conformité annuel.
Mais cette approche n’est plus en phase avec la réalité des SI modernes. Et ce, pour plusieurs raisons :
1) Des infrastructures de plus en plus dynamiques et éphémères
Le modèle traditionnel de gestion des vulnérabilités repose sur un principe simple : photographier l’état de sécurité du SI à un instant T, analyser les résultats, puis corriger les problèmes identifiés.
Seulement voilà : à l’heure du cloud et des déploiements continus, cette photo vieillit dès la seconde où elle est prise.
Imaginez un cycle de scan mensuel qui s’exécute le 1er du mois. Le 3, votre équipe DevOps déploie un microservice avec une dépendance vulnérable. Le 7, une CVE critique est publiée sur un composant présent dans 30% de votre infrastructure. Le 15, un stagiaire lance une instance EC2 pour tester un POC et oublie de la désactiver.
Votre prochain scan découvrira ces problèmes avec 2 à 4 semaines de retard, dans le meilleur des cas.
Ce scénario n’est pas hypothétique. Dans les architectures modernes, avec des environnements multi-cloud hybrides, des milliers de microservices, des conteneurs orchestrés par Kubernetes, des fonctions serverless, ou encore des API exposées publiquement, votre surface d’attaque est en effet démultipliée et les changements dans votre infrastructure sont permanents.
La conséquence est immédiate : la cartographie des actifs sur laquelle repose votre analyse devient rapidement obsolète, et certains actifs échappent à votre supervision.
2) Un volume de vulnérabilités qui explose
Au-delà de ces angles morts dans la supervision des actifs, le volume de vulnérabilités à traiter augmente à un rythme sans précédent.
Selon les chiffres du FIRST (Forum of Incident Response and Security Teams), près de 50 000 CVE ont été recensées en 2025. Soit une hausse d’environ 21% sur un an, après une hausse déjà estimée à +39% entre 2023 et 2024.
À cette avalanche de vulnérabilités s’ajoute une accélération des délais d’exploitation : les attaquants industrialisent en effet désormais l’exploitation des failles critiques, et pour les vulnérabilités les plus médiatisées (comme Log4Shell il y a quelques années) le délai entre publication et premières attaques tombe parfois à moins de 24 heures.
Résultat : la fenêtre de remédiation se réduit drastiquement, accentuant encore le décalage avec des cycles d’analyse périodiques.
3) Une priorisation encore trop déconnectée du risque réel
Dans ce contexte, vous ne pouvez plus tout traiter : il faut savoir quoi corriger en priorité, et dans quels délais.
Or, dans les approches traditionnelles, la priorisation repose encore largement sur des scores techniques génériques (CVSS), sans tenir compte :
- De l’exposition réelle de l’actif,
- De sa criticité métier,
- De l’existence d’exploits actifs,
- Ni de votre capacité opérationnelle de remédiation.
Résultat : vos équipes accumulent des milliers de vulnérabilités, sans pouvoir identifier clairement celles qui doivent être traitées en premier.
Plusieurs semaines (parfois plusieurs mois) peuvent donc s’écouler entre la détection d’une faille critique et sa remédiation effective.
Ce décalage est d’autant plus problématique que la pression réglementaire s’intensifie. La directive NIS2 (applicable depuis octobre 2024) impose des obligations renforcées de gestion des risques cyber, avec des sanctions pouvant aller jusqu’à 2% du chiffre d’affaires mondial.
Pour répondre à tous ces enjeux, il ne suffit plus d’améliorer les scans : il faut changer d’approche. C’est tout l’objet du CTEM.
Le CTEM à la loupe : définition et principes clés du Continuous Threat Exposure Management
Un concept popularisé par Gartner
Le terme CTEM (Continuous Threat Exposure Management) a été introduit par l’entreprise de recherche et de conseil Gartner en 2022, dans ses travaux sur l’”exposure management”.
Gartner le définit comme un ensemble de processus et de capacités organisés en cinq phases (que nous allons détailler juste après), permettant d’évaluer de manière continue l’accessibilité, l’exposition et l’exploitabilité des actifs numériques et physiques.
Deux éléments sont essentiels dans cette définition :
- D’abord, le CTEM n’est pas un simple outil. C’est un cadre méthodologique global, qui structure la façon dont l’organisation mesure son exposition réelle, priorise ses actions de sécurité et réduit concrètement le risque de compromission.
- Ensuite, l’approche est résolument orientée sur l’exploitabilité et l’impact métier, et non plus uniquement sur la détection de vulnérabilités. On ne cherche plus seulement à savoir combien de failles existent dans le système d’information, mais lesquelles peuvent réellement être exploitées, sur quels actifs critiques, et avec quelles conséquences pour l’organisation.
L’objectif est clair : réduire de manière systématique et mesurable l’exposition aux menaces grâce à un cycle continu.
Les 5 phases du framework CTEM
Le framework CTEM s’articule autour de cinq phases :
Ces cinq phases forment une boucle continue, et c’est précisément ce qui les distingue d’un enchaînement classique d’actions de sécurité.
- Discovery : tout commence par une vision fiable et à jour de la surface d’attaque. Cette phase consiste à identifier les actifs, les services exposés, les identités et les ressources cloud, y compris ceux qui échappent aux inventaires traditionnels.
- Scoping : une fois cette visibilité obtenue, l’enjeu est de définir le périmètre réellement prioritaire. L’analyse se concentre sur les actifs critiques et les scénarios de compromission ayant un impact métier fort, plutôt que de traiter l’ensemble du SI de manière uniforme.
- Prioritization : dans un contexte où tout ne peut pas être corrigé immédiatement, cette étape permet de classer les vulnérabilités selon le risque réel. Contrairement aux approches traditionnelles fondées sur le seul score CVSS, la priorisation intègre ici des critères contextuels : l’existence d’exploits actifs, la probabilité d’exploitation (via des scores comme l’EPSS), ou encore le niveau d’exposition réseau de l’actif concerné.
- Validation : avant de mobiliser les équipes, il s’agit de confirmer que le risque est concret. L’analyse des chemins d’attaque ou les simulations permettent d’identifier les failles réellement exploitables et d’écarter celles qui ne constituent pas une menace immédiate.
- Mobilization : la dernière phase transforme la priorisation en actions de remédiation planifiées et pilotées dans le temps, en tenant compte des contraintes opérationnelles et de la capacité réelle des équipes à corriger.
Reste alors une question clé : comment industrialiser ce cycle et l’intégrer réellement dans vos opérations de sécurité ?
C’est là qu’intervient Cyberwatch, notre plateforme de gestion des vulnérabilités et de gestion de la conformité : non pas comme une brique supplémentaire dans votre stack de sécurité, mais comme la plateforme qui opérationnalise chaque étape du cycle CTEM.
Mettre en œuvre le CTEM avec Cyberwatch, étape par étape
1) Discovery : construire un inventaire fiable et vivant de vos actifs
Sans inventaire exhaustif et à jour, pas de CTEM possible.
C’est pourquoi Cyberwatch s’appuie sur un large éventail de mécanismes de découverte pour identifier automatiquement les actifs de votre infrastructure, qu’ils soient locaux, cloud, conteneurisés ou externes.
Les principaux mécanismes de découverte :
- Infrastructure locale : scans réseau et découvertes ciblées pour détecter les machines non enregistrées, puis intégration (possible en mode sans agent), organisation par groupes et suivi dans le temps via des exécutions récurrentes.
- Cloud (AWS, Azure, GCP, OpenStack…) : interrogation des APIs pour cartographier VMs et ressources associées (ex. Microsoft Entra ID), avec couverture multi-projets / multi-régions et mises à jour récurrentes.
- Docker & Kubernetes (EKS/AKS/OpenShift…) : inventaire des images (registries et/ou images réellement déployées) avec ajout automatique pour analyse.
- Exposition externe (IP / DNS / WHOIS / Certificate Transparency) : scan de plages IP et inventaire de domaines, détection de domaines liés (marques, filiales, domaines oubliés) et identification de sous-domaines via les journaux publics de certificats TLS (Certificate Transparency), y compris ceux qui échappent aux approches DNS classiques.
Au final, chaque nouvel actif détecté est intégré automatiquement, et les actifs décommissionnés sortent de l’inventaire : vous disposez en continu d’une vision fiable de votre surface d’exposition.
2) Scoping : définir un périmètre aligné sur vos enjeux métier
Une fois l’inventaire fiabilisé par la phase de discovery, l’enjeu n’est plus de tout analyser de la même manière, mais d’adapter le niveau d’exigence au niveau de risque.
Un actif critique comme un serveur ERP exposé sur Internet doit par exemple faire l’objet d’un suivi prioritaire, tandis qu’un actif faiblement exposé, comme un environnement de développement isolé, relève d’une priorité plus basse.
Le scoping consiste précisément à organiser votre surface d’attaque en périmètres cohérents pour éviter le bruit et concentrer vos efforts là où l’impact métier est réel.
Avec Cyberwatch, cette logique se matérialise par l’organisation des actifs en projets ou en groupes correspondant à vos environnements (Production, DMZ, serveurs web, tests…).
Chaque périmètre peut alors disposer de ses propres règles : fréquence de scan, seuils d’alerte, critères de priorisation ou droits d’accès.
Par exemple :
Projet « Production »
├─ Fréquence de scan : quotidienne
├─ Seuil d’alerte : CVSS ≥ 9.0 (notification immédiate)
└─ Accès : DSI + RSSI
Il est également possible de définir précisément les plages IP à surveiller et de distinguer les actifs exposés des systèmes internes.
Cette segmentation évite de surévaluer des risques peu réalistes tout en appliquant un niveau d’exigence plus élevé sur les ressources critiques.
3) Prioritization : passer du volume de CVE au risque réellement critique
Une fois l’inventaire maîtrisé et le périmètre défini, l’enjeu devient clair : définir ce qui doit être corrigé en priorité.
Concrètement, il s’agit de transformer une liste de milliers de vulnérabilités en une file d’attente courte, contextualisée, et alignée sur vos enjeux métiers.
Dans Cyberwatch, cette priorisation repose d’abord sur la définition d’une politique de criticité pour chaque actif. Chaque périmètre se voit attribuer des exigences de Confidentialité, Intégrité et Disponibilité (CIA) qui permettent de recalculer un score CVSS contextuel : le CVSS-BTE.
Ce score tient compte de votre réalité technique : par exemple, un serveur totalement isolé du réseau peut être défini comme accessible uniquement en local. Les vulnérabilités exploitables à distance voient alors leur criticité automatiquement revue à la baisse. À l’inverse, une faille affectant un système exposé en production conservera un niveau de priorité élevé.
À cette contextualisation s’ajoute une lecture orientée menace. Les vulnérabilités remontées comme prioritaires sont celles qui combinent :
- Un seuil CVSS à partir duquel une faille doit être traitée,
- Le score EPSS, qui reflète la probabilité d’exploitation dans le monde réel,
La présence dans des catalogues de référence comme le CERT-FR ALE, le CISA KEV ou les listes maintenues par Cyberwatch.
On ne raisonne plus en sévérité théorique globale, mais en risque réel pour un actif donné.
La priorisation devient ainsi directement exploitable par les équipes : les efforts se concentrent sur les vulnérabilités critiques, exposées et susceptibles d’être exploitées, plutôt que sur un backlog de CVE sans hiérarchisation.
4) Validation : vérifier l’exploitabilité et mesurer l’efficacité des correctifs
Après avoir défini les vulnérabilités à traiter en priorité, la phase de validation consiste à mesurer l’efficacité des décisions prises en répondant à deux questions clés :
- La menace est-elle bien réelle dans votre contexte ?
- Les actions de remédiation ont-elles effectivement supprimé le risque ?
L’objectif est de passer d’une décision théorique à une réduction mesurable de l’exposition.
Dans Cyberwatch, cette validation commence par la mise en contexte de chaque CVE : l’encyclopédie de vulnérabilités centralise, pour une même faille, la sévérité technique (CVSS et CVSS-BTE), les correctifs disponibles et surtout l’existence d’exploits publics ou d’outils d’attaque connus.
Croisée avec le score EPSS et l’appartenance à des catalogues de référence (CERT-FR, CISA KEV…), cette information permet d’identifier immédiatement les vulnérabilités activement exploitées, faciles à industrialiser dans des campagnes d’attaque, et reconnues comme critiques par les autorités de référence.
À l’inverse, une vulnérabilité sévère mais sans exploit connu et à faible probabilité d’exploitation peut être objectivement reclassée.
La validation porte également sur l’efficacité des corrections. Après le déploiement d’un patch, un changement de configuration ou la suppression d’un service, Cyberwatch relance automatiquement les analyses sur les actifs concernés. La disparition effective de la CVE est vérifiée, les dates de détection et de correction sont historisées, et le temps d’exposition est calculé.
Vous ne vous contentez plus de déclarer un correctif déployé : vous démontrez que le risque a été supprimé, vous détectez les échecs de remédiation et vous identifiez les éventuelles régressions.
Ces indicateurs alimentent directement le pilotage CTEM en apportant une mesure factuelle de l’efficacité des actions menées.
5) Mobilization : orchestrer la remédiation et piloter la réduction du risque
Une fois les vulnérabilités validées, l’enjeu est de passer à l’exécution : corriger, suivre l’avancement et démontrer que le risque diminue réellement. C’est le rôle de la phase de mobilisation, où Cyberwatch devient le point de convergence entre les équipes sécurité, les opérations IT et le pilotage.
Elle repose concrètement sur trois dimensions :
Orchestrer la remédiation technique avec le patch management
La vue gestion des correctifs fait le lien direct entre une vulnérabilité prioritaire et l’action à mener. Pour chaque actif, elle centralise les CVE, les correctifs associés et les opérations possibles.
Les patchs peuvent être déployés automatiquement sur les environnements Windows et Linux, avec gestion des dépendances et intégration aux outils existants comme WSUS ou Red Hat Satellite. Lorsqu’un logiciel est lui-même à l’origine du risque, sa désinstallation peut être déclenchée depuis la plateforme.
Cyberwatch ne se limite plus à identifier les failles : il fournit un plan d’action technique traçable, vulnérabilité par vulnérabilité.
S’intégrer aux workflows IT via l’ITSM
Mobiliser, c’est aussi s’aligner sur les processus des équipes en charge de la remédiation.
Les intégrations ITSM (ServiceNow, Microsoft Teams, GLPI, Jira…) permettent de transformer automatiquement une vulnérabilité validée en ticket pré-rempli avec l’ensemble du contexte : actif concerné, niveau de criticité, correctif recommandé.
Les équipes sécurité pilotent dans Cyberwatch, les équipes IT travaillent dans leur outil habituel, mais la chaîne reste continue et synchronisée.
Piloter la remédiation dans le temps
La mobilisation n’est durable que si elle est mesurable. Cyberwatch historise les dates de détection et de correction de chaque vulnérabilité et calcule les temps de traitement.
Ces données alimentent les tableaux de bord : vulnérabilités critiques par périmètre, temps moyen de remédiation, respect des SLA, couverture des scans.
Le module d’alertes déclenche automatiquement des notifications ou des intégrations lorsqu’un seuil est atteint : nouvelle CVE critique, système obsolète, délai de correction dépassé.
Vous ne suivez plus seulement des correctifs déployés, vous pilotez des objectifs de réduction du risque dans la durée.
Cette traçabilité permet d’alimenter les comités de pilotage, de démontrer la conformité (notamment NIS2) et de baser les décisions sur des indicateurs factuels issus du terrain.
CTEM : les points clés à retenir
Mettre en place un programme CTEM, c’est finalement changer de posture : passer d’une gestion ponctuelle des failles à un pilotage continu de la surface d’exposition.
Avec Cyberwatch, cette approche devient très concrète, car chaque étape du cycle trouve sa traduction opérationnelle dans la plateforme :
- Un inventaire fiable et vivant de l’ensemble de vos actifs, y compris ceux qui échappent aux approches traditionnelles
- Une segmentation de votre surface d’attaque alignée sur vos enjeux métier et vos niveaux de criticité
- La sortie du « backlog infini » pour concentrer l’effort sur les vulnérabilités exploitables, effectivement ciblées et critiques pour votre contexte
- Le passage de la CVE abstraite à l’exposition prouvée, avec re-scan systématique et catalogues de référence
- Une remédiation orchestrée et traçable, du correctif déployé à la démonstration de la baisse du risque
C’est cette continuité entre détection, décision et action qui permet de répondre concrètement aux enjeux actuels : résilience opérationnelle, conformité réglementaire (NIS2) et transparence vis-à-vis de votre gouvernance.
Vous souhaitez voir comment cette approche se traduit concrètement dans un environnement réel ? → Demandez une démo de Cyberwatch
FAQ CTEM
Qu’est-ce que le Continuous Threat Exposure Management (CTEM) ?
Le CTEM est un cadre défini par Gartner pour identifier en continu les actifs exposés, prioriser les vulnérabilités exploitables et réduire concrètement le risque de compromission.
Le CTEM est-il un outil ou une méthodologie ?
Le CTEM est une méthodologie qui s’appuie sur des outils de découverte, d’analyse et de remédiation pour piloter la réduction du risque.
Pourquoi le CTEM est-il devenu une approche de référence en cybersécurité ?
Il s’est notamment imposé car il permet d’adapter la cybersécurité à des environnements cloud et hybrides où la surface d’attaque évolue en permanence.
Quelles sont les 5 phases du CTEM ?
Le framework CTEM défini par Gartner suit un cycle continu : Discovery → Scoping → Prioritization → Validation → Mobilization.
Quel est le lien entre CTEM et NIS2 ?
Le CTEM facilite la conformité à NIS2 en apportant une vision continue du risque, avec un suivi des corrections et des indicateurs de performance.