Cloudflare a annoncé le 3 septembre 2026 le lancement de l’accès anticipé à son service Vulnerability Discovery and Remediation, intégré à Cloudflare Managed Defense, afin d’aider les équipes à identifier les vulnérabilités les plus urgentes dans leurs bases de code et à les traiter. Le service est actuellement disponible uniquement sur invitation pour certains clients, et chaque participation commence par une seule application à laquelle le client autorise l’accès au code pour l’enquête.
L’idée fondamentale ne consiste pas simplement à exécuter un analyseur de code puis à afficher une longue liste de résultats. La combinaison de l’analyse du code avec les données de trafic et les signaux de sécurité vise à déterminer si la vulnérabilité se trouve dans un chemin actif, quel est le volume d’utilisation de ce chemin, s’il fait l’objet de tentatives de ciblage et quelles protections lui sont déjà appliquées.
D’une liste de résultats à une priorité liée à la production
Cloudflare affirme que les outils d’analyse modernes, notamment les grands modèles de langage, peuvent détecter de nombreuses faiblesses en peu de temps, mais que cela rend plus difficile l’identification de ce qui doit être corrigé en premier. Un outil d’analyse peut révéler un problème dans un gestionnaire logiciel sans préciser si le code est effectivement déployé, si le chemin qui y mène est utilisé ou si des attaques ou des règles de protection lui sont associées.
Le service commence par collecter un instantané des données Web Assets et Web Application Firewall, comprenant les chemins actifs, le volume des requêtes qu’ils reçoivent et les événements de sécurité récents qui leur sont associés. Il considère les chemins à trafic élevé comme des chemins sensibles, soumis à une analyse de sécurité plus stricte lorsque le code déployé derrière eux fait l’objet d’un examen.
Pour Cloudflare Workers, le service récupère la version la plus récente du code et les chemins configurés pour celui-ci, puis les relie aux données des points de terminaison en production au moyen de Workers Observability et des données de requêtes. Ce contexte reste disponible pendant l’enquête afin que les agents logiciels puissent l’utiliser lorsque nécessaire.
Comment les modèles sont utilisés et ce qu’ils proposent
Le processus repose sur un agent de reconnaissance qui relie les chemins de requêtes aux parties du code qui les traitent, puis oriente les agents de recherche vers les zones concernées afin d’y trouver les vulnérabilités. Cloudflare utilise les modèles OpenAI Daybreak, notamment GPT-5.6 Cyber, lors des étapes de reconnaissance, de recherche et de vérification. Toutefois, le simple lien entre une vulnérabilité et un chemin actif ne suffit pas à prouver son existence ; Cloudflare exige que chaque résultat soit étayé par des éléments provenant du code lui-même.
Après vérification, le service produit une liste ordonnée de résultats, avec une classification initiale du risque qui augmente en présence d’indicateurs tels que la densité du trafic ou l’activité de reconnaissance sur le point de terminaison. Il propose également un correctif de code et peut suggérer une règle WAF personnalisée afin de réduire temporairement l’exposition pendant l’examen du correctif logiciel.
Si le client autorise le service à défendre son domaine, les règles WAF proposées peuvent être configurées avec une portée prudente, axée sur la méthode HTTP, le chemin et les détails de la requête nécessaires pour atteindre le code vulnérable. Le service ne propose pas de règle lorsque le modèle du chemin se compose uniquement de variables et de variantes génériques, car il préfère manquer une association potentielle plutôt que de fournir une protection que les éléments disponibles ne permettent pas d’étayer.
Contrôles de déploiement et limites de l’automatisation
Le système d’enquête fonctionne sur Cloudflare, tandis que les requêtes adressées aux modèles sont envoyées depuis Workers, via Cloudflare AI Gateway, vers les serveurs d’OpenAI. L’inférence des modèles n’est pas effectuée sur le réseau périphérique de Cloudflare, et le modèle ne peut pas appliquer le correctif ou la règle WAF qu’il propose.
Chaque opération se limite au code et aux éléments auxquels le client a accordé l’autorisation, avec suppression du contexte inutile et application des contrôles de rédaction définis pour le partage. Le système traite le code, les journaux et les données de requêtes comme des éléments de preuve à examiner, et non comme des instructions à suivre. Tous les appels d’outils sont également enregistrés et examinés conformément à la politique d’accès, tandis que les correctifs et les règles sont soumis à des tests hors modèle.
Avant de présenter un résultat au client, Cloudflare vérifie les sorties. L’examen des suggestions de protection périphérique comprend la vérification de la syntaxe de la règle et son exécution sur des cas de test synthétiques représentant les requêtes attendues, et non sur le trafic réel du client. Si un test échoue ou si le résultat reste ambigu, celui-ci est masqué lors de l’examen et transmis pour diagnostic.
Pourquoi cette annonce est-elle importante ?
Le changement pratique consiste à faire passer la priorité de traitement des vulnérabilités d’un score théorique dans un rapport d’analyse à une estimation qui tient également compte de leur exposition réelle en production. Cela pourrait aider les équipes confrontées à des milliers de résultats à se concentrer d’abord sur le code actif associé à un trafic élevé ou à une activité hostile, tout en fournissant une éventuelle mesure temporaire au niveau du WAF pendant l’examen du correctif.
Le service ne supprime toutefois pas le rôle des ingénieurs et ne transforme pas les suggestions automatisées en modifications automatiques. Il se trouve en phase d’accès anticipé, est limité aux invitations et nécessite une autorisation explicite pour accéder au code, aux données des actifs, aux contrôles WAF et à Workers Trace Events Logpush lorsqu’ils sont disponibles. Le client examine également chaque résultat avant de décider de le tester ou de le déployer, tandis que l’exactitude de la conclusion finale reste liée aux éléments disponibles et aux limites du périmètre d’application autorisé pour le service.