En bref : couverture CTEM côté client
- CTEM oublie le navigateur : Les programmes CTEM sont présentés comme continus, mais la plupart couvrent l'infrastructure côté serveur et les CVE au rythme mensuel, tandis que le JavaScript qui s'exécute dans les navigateurs des utilisateurs est traité comme du code statique qui ne change jamais entre deux versions de l'éditeur.
- Découverte continue des scripts : cside découvre en continu chaque script qui tourne sur une propriété web, signale lorsqu'un script accède à des éléments sensibles du DOM ou envoie des données à un nouvel endpoint, et génère les alertes et les preuves dont les équipes de Mobilization ont besoin sans enquête manuelle.
- Dans le périmètre ou un constat ? Les Exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1 sont obligatoires depuis le 31 mars 2025, donc la question est de savoir si votre programme CTEM traite le JavaScript côté client comme un périmètre à part entière ou comme une ligne d'exposition que l'auditeur trouvera pour vous.
Peu de temps ? Découvrez le blocage de Magecart et de skimmers dans le navigateur de cside. Elle couvre tout ce qui suit en un seul déploiement.
La gestion continue de l'exposition aux menaces (CTEM, Continuous Threat Exposure Management) est un cadre de sécurité qui gère le risque comme un programme permanent plutôt que comme un audit périodique. Gartner a introduit ce terme pour décrire un cycle répété qui découvre les expositions, les classe selon leur exploitabilité réelle et valide que les correctifs ferment effectivement le chemin d'attaque.
Le principe est simple. Votre surface d'attaque change chaque jour. De nouveaux fournisseurs sont intégrés, de nouveaux scripts arrivent sur vos propriétés web et de nouvelles vulnérabilités sont publiées, si bien qu'une évaluation trimestrielle ou annuelle est déjà obsolète au moment où le rapport est rédigé. Les programmes CTEM s'exécutent en continu, priorisent les expositions selon leur exploitabilité dans votre environnement réel et suivent la remédiation jusqu'à une clôture vérifiée.
Les cinq étapes du CTEM
Les programmes CTEM s'articulent autour de cinq étapes qui se répètent comme un cycle continu plutôt que comme un projet linéaire.
| Étape | Tâche CTEM | Preuves côté client |
|---|---|---|
| Cadrage | Définir les actifs et les surfaces d'attaque du cycle en cours | Propriétés web, flux d'authentification, pages de paiement et scripts tiers |
| Découverte | Recenser les expositions dans le périmètre défini | Inventaire complet des scripts, injections dynamiques, endpoints et accès au DOM |
| Priorisation | Classer les expositions selon leur exploitabilité et leur impact métier | Accès aux données sensibles, nouvelles destinations et schémas d'e-skimming |
| Validation | Tester l'exposition et confirmer la correction | Historique du comportement réel, preuves des changements et vérification après correction |
| Mobilisation | Attribuer les responsables et suivre chaque constat jusqu'à sa clôture | Alertes, journaux d'événements et preuves pour les équipes sécurité et applicatives |
Étape 1 : le cadrage
Le programme définit quels actifs et quelles surfaces d'attaque entrent dans le périmètre du cycle en cours. Le cadrage n'est pas permanent. Il s'élargit à mesure que le programme mûrit. Les premiers programmes CTEM cadrent en général d'abord les actifs les plus critiques pour l'activité : applications web de production, flux d'authentification et infrastructure de paiement. Les cycles suivants intègrent les systèmes internes, les intégrations tierces et la chaîne d'approvisionnement. Le cadrage répond à une question simple : que protégeons-nous, et contre quelle menace nous défendons-nous ?
Étape 2 : la découverte
La découverte identifie chaque exposition à l'intérieur du périmètre défini, et elle va bien au-delà des CVE connues et des vulnérabilités installées. Dans un contexte CTEM, la découverte couvre quels composants tiers sont présents, quels scripts s'exécutent dans une application web, quels services sont accessibles depuis l'extérieur, quelles identités peuvent toucher des ressources sensibles et où les données franchissent les frontières des systèmes. Elle met au jour la surface d'attaque telle qu'elle existe à l'instant présent, y compris les expositions dont l'équipe de sécurité ignorait la présence.
Étape 3 : la priorisation
Toutes les expositions ne peuvent pas être corrigées en même temps. La priorisation les classe selon le risque réel, c'est-à-dire la combinaison de la gravité, de l'exploitabilité dans l'environnement actuel et de l'impact sur l'activité en cas d'exploitation. Le CTEM déprioritise délibérément les vulnérabilités théoriques qui ne sont ni atteignables ni exploitables en pratique, et met en avant celles que les acteurs malveillants ciblent activement. C'est l'étape qui distingue le CTEM d'un simple scan de vulnérabilités. Le résultat est une liste classée de ce qu'il faut corriger en premier, et non une liste plate de chaque constat.
Étape 4 : la validation
La validation teste si les expositions identifiées sont réellement exploitables et si les contrôles en place tiennent. Elle recourt aux tests d'intrusion, aux exercices de red team et à la simulation de brèche et d'attaque pour confirmer qu'une exposition priorisée représente un risque réel. La validation confirme aussi que la remédiation a bien fermé l'exposition, c'est-à-dire que le chemin d'attaque ne fonctionne plus, et pas seulement qu'un correctif a été appliqué. Elle répond à une question franche : notre défense fonctionne-t-elle vraiment ?
Étape 5 : la mobilisation
La mobilisation transforme les constats validés en actions de remédiation auprès des équipes qui possèdent les systèmes concernés. Les équipes de sécurité possèdent rarement les actifs qu'elles défendent. Les équipes applicatives, les équipes d'infrastructure et les fournisseurs tiers ont tous un rôle à jouer. La mobilisation traduit les constats en tâches concrètes pour ces équipes et suit chacune d'elles jusqu'à un achèvement vérifié.
Pourquoi le JavaScript côté client est un angle mort du CTEM
La plupart des programmes CTEM analysent bien l'infrastructure côté serveur, les CVE connues et les expositions au niveau réseau. La couche côté client, c'est-à-dire le JavaScript qui s'exécute dans le navigateur d'un utilisateur lorsqu'il interagit avec votre application web, est systématiquement sous-représentée.
Quelques caractéristiques rendent la surface d'attaque côté client difficile à couvrir avec l'outillage CTEM traditionnel.
Elle change sans préavis. Les scripts tiers (outils d'analytics, widgets de chat, gestionnaires de balises, bibliothèques chargées via CDN) mettent à jour leur contenu quand le fournisseur le décide. Un script jugé sûr le mois dernier a pu être modifié depuis, compromis par un attaquant ou doté d'un nouveau comportement. Ce changement permanent est invisible pour les évaluations ponctuelles.
Les scripts autorisés peuvent être détournés. Les attaques Magecart le montrent clairement. Le risque ne se limite pas aux scripts non autorisés. Les scripts autorisés qui changent ce qu'ils font sont le problème le plus difficile. Une page de paiement qui charge un script d'analytics approuvé est exposée si ce script est compromis et se met à lire les champs de carte. Le script était dans le périmètre. Son comportement, lui, n'était pas surveillé.
Les scanners de CVE ne le détectent pas. Les scanners basés sur les CVE recherchent des vulnérabilités logicielles connues. Ils ne détectent pas les changements de comportement du JavaScript, l'ajout de nouveaux scripts tiers ni les chemins d'exfiltration de données côté client.
Les régulateurs l'exigent désormais. Les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1, obligatoires depuis le 31 mars 2025, imposent un inventaire des scripts des pages de paiement, des contrôles d'autorisation et une détection des changements au moment de l'exécution. Ces exigences existent précisément parce que la surface d'attaque côté client n'était pas gérée.
Comment cside s'intègre dans les programmes CTEM
cside couvre la couche d'exposition côté client que la plupart des programmes CTEM n'atteignent jamais. Rapporté aux étapes du CTEM :
- Découverte : cside découvre en continu chaque script qui s'exécute sur une propriété web, y compris les scripts ajoutés via des gestionnaires de balises, les dépendances CDN et le code injecté dynamiquement, ce qui vous donne l'inventaire complet dont l'étape de découverte a besoin.
- Priorisation : la surveillance comportementale de cside signale quand des scripts accèdent à des éléments sensibles du DOM, envoient des données vers des points de terminaison externes ou correspondent à des schémas liés aux attaques de skimming, autant de signaux qui distinguent les expositions côté client exploitables des expositions théoriques.
- Validation : cside produit des preuves en temps réel des changements de comportement des scripts, confirmant si une exposition est active et quelles données elle touche.
- Mobilisation : cside génère les alertes, les journaux d'événements et la documentation probante qui permettent aux équipes de sécurité et applicatives d'agir sur les constats côté client sans investigation manuelle.
Pour les pages de paiement en particulier, c'est aussi ainsi que cside satisfait à PCI DSS 6.4.3 et 11.6.1 en un seul déploiement : un inventaire de scripts continu avec des contrôles d'autorisation, plus une détection automatisée des altérations.
