Une passerelle de transfert de fichiers exposée sur internet, à jour de l’ensemble de ses correctifs, se met un soir à établir des connexions sortantes vers une infrastructure inconnue. L’investigation confirme l’intrusion, puis en identifie la cause : une faille logicielle dont l’éditeur du produit ignorait lui-même l’existence. Ni correctif disponible, ni bulletin d’éditeur, et les bases de vulnérabilités publiques ne mentionnent rien de tel. L’équipe chargée des mises à jour n’a rien manqué, puisqu’il n’y avait rien à appliquer.
Ce scénario porte un nom : le zero-day. Le terme désigne une vulnérabilité encore inconnue de l’éditeur du logiciel concerné et, par extension, le code d’exploitation qui en tire parti. « Zéro jour », parce que c’est le délai dont l’éditeur a disposé pour préparer une correction au moment où l’attaque débute. Tant que la faille reste secrète, les défenses fondées sur la connaissance du problème, comme les signatures antivirales ou les règles de filtrage dédiées, restent sans prise.
Le cycle d’une zero-day, de la découverte à la fenêtre résiduelle
La vie de ces failles suit un parcours assez régulier. Quelqu’un met d’abord la main sur le défaut, dans le code d’un système d’exploitation ou d’un équipement de bordure de réseau. Lorsque ce découvreur est un attaquant, s’ouvre une phase d’exploitation discrète qui peut durer des mois : le code d’exploitation est réservé à des opérations ciblées, précisément pour ne pas éventer le secret.
Vient ensuite la divulgation, provoquée par un chercheur qui signale le problème à l’éditeur ou par la détection d’une campagne en cours. Un correctif est développé puis publié ; la vulnérabilité reçoit un identifiant et une évaluation de gravité, et entre dans le champ ordinaire de la gestion des vulnérabilités et du score CVSS. Entre la publication du correctif et son déploiement effectif sur l’ensemble des systèmes concernés s’étend une fenêtre d’exposition résiduelle, parfois longue, durant laquelle la faille — devenue « n-day » — est exploitée à bien plus grande échelle qu’au temps du secret. Les équipes de renseignement sur la menace suivent ce basculement de près, car l’exploitation passe alors d’opérations ciblées rares à des campagnes opportunistes de masse.
Qui découvre ces failles
Les chercheurs en sécurité représentent une part importante des découvertes, qu’ils travaillent chez l’éditeur, dans des laboratoires spécialisés ou de manière indépendante. La divulgation dite coordonnée s’est imposée comme cadre de référence : le découvreur informe l’éditeur et lui laisse le temps de corriger avant toute publication. Les programmes de bug bounty structurent cette collaboration en rémunérant les signalements.
Un autre circuit existe, moins visible. Des courtiers achètent des vulnérabilités inédites pour les revendre à des États ou à des acteurs privés qui les emploient dans leurs propres opérations. Ce marché parallèle explique qu’une partie des zero-days ne parvienne jamais aux éditeurs concernés.
Se défendre sans correctif
Aucune politique de mise à jour, si rigoureuse soit-elle, ne protège d’une faille que personne ne connaît. Ce constat fonde le principe de défense en profondeur que l’ANSSI place au cœur de ses guides : chaque couche de protection part de l’hypothèse que la précédente peut céder.
La détection s’appuie alors sur le comportement plutôt que sur des signatures. Les outils EDR et XDR repèrent une élévation de droits inattendue ou un début de mouvement latéral, sans avoir besoin de connaître la faille exploitée. La centralisation des journaux dans un SIEM permet de croiser ces signaux à l’échelle du système d’information, et un leurre de type honeypot trahit une présence intruse dès qu’il est touché, puisqu’aucun usage légitime ne le justifie.
L’architecture compte tout autant. Une segmentation réseau stricte empêche le serveur compromis de servir de tremplin vers les fonctions critiques, tandis que l’application du moindre privilège — appuyée sur une gestion des comptes à privilèges — borne ce qu’un attaquant peut accomplir avec les droits dérobés.
Bulletins du CERT-FR et catalogue KEV : suivre l’exploitation réelle
En France, le CERT-FR, centre gouvernemental de veille et de réponse rattaché à l’ANSSI, publie des avis et des alertes de sécurité ; ces dernières signalent notamment les vulnérabilités faisant l’objet d’une exploitation active et précisent les mesures de contournement possibles en l’absence de correctif. Le traitement de ces bulletins relève typiquement d’un CSIRT interne, dont le rôle diffère de celui du SOC.
Aux États-Unis, la CISA maintient un catalogue des vulnérabilités exploitées connues, dit KEV, qui recense les failles dont l’exploitation en conditions réelles est avérée ; les agences fédérales civiles américaines ont l’obligation de les traiter dans des délais imposés. Au-delà de ce périmètre réglementaire, la CISA recommande à toutes les organisations de s’appuyer sur ce catalogue pour prioriser leurs corrections : une faille qui y figure passe avant d’autres au score de gravité comparable mais jamais exploitées.
Encore faut-il savoir si son propre parc est concerné. Une vulnérabilité nichée dans une bibliothèque open source largement réutilisée touche des applications qui n’en mentionnent le nom nulle part ; disposer d’une nomenclature logicielle (SBOM) à jour et d’une vision claire de sa chaîne d’approvisionnement logicielle transforme une alerte générique en réponse précise : on sait quels systèmes embarquent le composant et dans quel ordre agir.
