Patch virtuel : gagner du temps face aux failles zero-day

La fenêtre entre la divulgation et le correctif

Le scénario est classique et redouté : une vulnérabilité critique est publiée pour un composant que vous utilisez. L’exploit circule en quelques heures. Le correctif officiel de l’éditeur, lui, prendra des jours — et son déploiement chez vous prendra encore du temps : tests de régression, fenêtre de maintenance, dépendances à mettre à jour. Entre la divulgation et le déploiement, votre origine est exposée et l’attaquant le sait.

Le patch virtuel comble cette fenêtre. Plutôt que de modifier le code vulnérable, on ajoute une règle de filtrage à la périphérie qui reconnaît et bloque la forme de l’exploit avant qu’il n’atteigne votre serveur. Le composant reste vulnérable en théorie, mais la requête qui l’exploiterait n’arrive jamais jusqu’à lui. Vous gardez le contrôle du calendrier de correction au lieu de le subir.

Ce qu’un patch virtuel fait — et ne fait pas

Un patch virtuel est une contre-mesure temporaire, pas un remplacement du correctif :

• Il bloque la forme connue de l’exploit. La plupart des attaques post-divulgation reprennent un patron reconnaissable — un chemin, un en-tête, une charge utile caractéristique. Une règle de filtrage ciblée sur ce patron neutralise la vague opportuniste, qui représente l’essentiel du risque immédiat.
• Il vous rend le calendrier. Vous appliquez le vrai correctif quand vous êtes prêt — après tests, dans une fenêtre planifiée — et non dans la panique du vendredi soir.
• Il ne corrige pas la faille. Le code reste vulnérable. Un attaquant qui trouve une variante non couverte par la règle passe. Le patch virtuel réduit l’exposition, il ne la supprime pas.

C’est une couche de temps, pas une couche de vérité. Utilisée comme telle, elle est précieuse ; présentée comme un substitut au correctif, elle devient un piège.

Pourquoi la périphérie est le bon endroit

Déployer une contre-mesure en urgence sur chaque serveur d’origine est lent et risqué : il faut toucher la production, redémarrer des services, coordonner des équipes. À la périphérie, la règle est poussée en configuration à travers toute la flotte de nœuds avec une propagation sous la seconde via un mécanisme de surveillance du magasin de configuration. Aucun redéploiement de votre application, aucune fenêtre de maintenance : la protection est active partout, presque immédiatement.

La base de règles OWASP fournit déjà une large couverture des familles d’attaques courantes sans que vous écriviez quoi que ce soit ; pour une faille spécifique et fraîche, une règle ciblée s’ajoute par-dessus. Nos deux moteurs WAF à signatures — un dans un bac à sable WASM, un natif — appliquent l’ensemble sur le chemin chaud, dans un budget de conception de ≤5 ms, mesuré en staging et jamais présenté comme un benchmark de production.

La traçabilité pendant la crise

Quand vous posez un patch virtuel, votre équipe et vos auditeurs voudront savoir : quand la règle a-t-elle été activée, combien de tentatives a-t-elle bloquées, depuis quelles origines. Chaque blocage est inscrit dans un journal d’audit immuable, en ajout seul, hébergé sur des nœuds européens. Cette piste vérifiable transforme une réponse à incident en dossier documenté — ce que le RGPD attend et ce qu’un audit de sécurité exigera. Voyez notre approche de la journalisation conforme au RGPD.

Le patch virtuel dans une posture plus large

Un patch virtuel n’a de sens que dans une chaîne : détecter tôt, gagner du temps, corriger proprement. Il se combine avec le réglage des faux positifs — une règle d’urgence trop large peut casser du trafic légitime, il faut la surveiller — et avec la visibilité générale que donne le filtrage périphérique. Découvrez l’ensemble des fonctionnalités.

Ce que nous ne prétendons pas

Nous ne prétendons pas bloquer toute exploitation d’une faille inconnue : une variante suffisamment créative contournera une règle écrite pour un patron précis. Le patch virtuel achète du temps, il ne dispense pas de corriger. Et nous ne publions pas de délai « garanti » de réponse aux zero-days : la vitesse dépend de la nature de la faille et de la disponibilité d’une signature fiable. Ce que nous offrons, c’est le mécanisme pour agir vite, à la périphérie, avec une trace complète.

Vous voulez une couche qui vous rende le contrôle du calendrier de correction ? Donnez-nous votre domaine.