Google affirme qu’un agent d’intelligence artificielle utilisé en interne a détecté plus de 500 vulnérabilités de type cross-site scripting dans les applications Web propriétaires de l’entreprise.
Baptisé PageBreak, le système associe des hypothèses de sécurité générées par l’IA à des validateurs distincts, qui tentent d’exécuter des charges utiles sur des applications en fonctionnement. Selon Google, cette étape de validation évite de confondre des résultats plausibles produits par l’IA avec des vulnérabilités réellement exploitables.
Le total annoncé est important, mais il convient de bien en cerner la portée. Il s’agit de vulnérabilités détectées, et non du nombre d’utilisateurs touchés. Les informations disponibles ne permettent pas non plus d’établir que toutes les failles signalées ont été corrigées. Elles ne font état d’aucun identifiant CVE, score CVSS, indice d’exploitation malveillante ni impact confirmé sur des clients de Google.
PageBreak est passé du projet pilote au produit interne
L’équipe Product Security de Google a conçu PageBreak pour évaluer les applications Web et les extensions de navigateur de l’entreprise. L’ingénieur en sécurité de l’information Michał Bentkowski a déclaré que le système avait détecté plus de 500 failles XSS.
Selon le rapport décrivant PageBreak et ses résultats, le projet a débuté sous la forme d’un pilote en novembre dernier, avant de devenir un produit à part entière en janvier. La source ne précise pas les années correspondant à ces deux étapes. Google a présenté le système dans un article de blog publié le mois dernier.
Ces références portent sur le développement du système et les étapes de sa présentation, et non sur les dates auxquelles chaque vulnérabilité a été introduite, découverte ou corrigée. Il n’y a pas non plus de date d’incident unique : PageBreak est un outil de test de sécurité, pas une faille ayant donné lieu à une intrusion signalée.
Parmi les exemples rendus publics par Google figurent trois vulnérabilités distinctes :
- Une vulnérabilité d’empoisonnement du cache affectant
apis.google.com - Une vulnérabilité XSS dans
admin.google.com - Des procédures de négociation externes non sécurisées impliquant des extensions de navigateur
Selon les informations publiées, l’article complémentaire de Google indiquait que ces trois problèmes avaient été corrigés. Cela ne permet pas d’établir l’état de correction du reste des vulnérabilités, notamment des plus de 500 failles XSS attribuées à PageBreak.
Les informations publiées ne mentionnent pas non plus d’organisations externes affectées. Le périmètre des tests indiqué couvre les services propriétaires de Google et ses extensions de navigateur.
L’IA propose des vulnérabilités, mais un autre mécanisme doit en apporter la preuve
L’architecture de PageBreak vise à répondre à une limite récurrente des tests de sécurité assistés par l’IA : un modèle peut produire une explication techniquement convaincante sans pour autant identifier une vulnérabilité réellement exploitable.
D’après le processus décrit par Bentkowski, l’agent commence par examiner une application et formuler une hypothèse de vulnérabilité. Il soumet ensuite cette piste à un validateur spécialisé, qui tente d’exécuter une véritable charge utile sur l’application dans un environnement actif. PageBreak ne signale le problème qu’une fois la vulnérabilité mise en évidence par cette tentative.
Selon cette description, les validateurs ne sont pas écrits par l’IA. Leur logique et leurs interfaces varient en fonction de la catégorie de vulnérabilité et de la surface de l’application testée.
Les méthodes de validation diffèrent, par exemple, selon qu’il s’agit de XSS, d’injection SQL ou d’exécution de code à distance. Tester une application HTTP ne nécessite pas non plus la même interface qu’évaluer un service gRPC. PageBreak ne s’appuie donc pas sur une invite ou une routine de validation universelle pour toutes les cibles.
Cette séparation est importante : le composant d’IA n’a pas le dernier mot sur ses propres résultats. Il propose des pistes, tandis qu’un autre mécanisme doit produire des preuves d’exécution.
Google présente le système comme une combinaison de détection autonome et de validation déterministe. Bentkowski a qualifié son taux de faux positifs de « proche de zéro ». Ce chiffre reste une affirmation de l’entreprise : les informations disponibles ne font état d’aucune évaluation indépendante de la précision de détection, du taux de faux positifs ou de la couverture de PageBreak.
Les modèles Gemini assurent la détection, pas la vérification finale
PageBreak utilise principalement les modèles Gemini 3.1 Pro et Gemini 3.5 Flash de Google, même si l’entreprise précise que le système peut fonctionner avec d’autres modèles.
La distinction entre les modèles et les validateurs est au cœur de la conception. Gemini intervient dans la phase de détection : l’accès au code source et aux outils de sécurité peut aider l’agent à formuler des pistes d’attaque. Le validateur, qui ne repose pas sur l’IA, détermine ensuite si la piste peut être démontrée sur la cible en fonctionnement.
Bentkowski a déclaré que l’IA pouvait détecter des vulnérabilités plus rapidement que des chercheurs humains. Il a également reconnu le coût opérationnel que représente le tri entre les véritables failles et les hallucinations convaincantes. Sans validation efficace, une détection plus rapide risque simplement de reporter le travail sur les équipes chargées de la sécurité des produits et de l’ingénierie.
Les informations disponibles ne fournissent aucun résultat comparatif face à des chercheurs humains ou à d’autres scanners automatisés. Elles ne démontrent pas non plus de manière indépendante les performances des deux modèles Gemini cités dans ce contexte.
Des experts externes approuvent la distinction entre détection et preuve
Rickard Carlsson, PDG de Detectify, a évoqué un problème plus général auquel sont confrontées les équipes de sécurité : les outils d’IA peuvent générer davantage de vulnérabilités présumées que les équipes ne peuvent raisonnablement en examiner.
Carlsson estime qu’un agent ne devrait pas vérifier lui-même ses conclusions. Selon lui, un validateur distinct doit exécuter une véritable charge utile sur l’application en fonctionnement avant qu’une vulnérabilité présumée soit retenue. Cette approche rejoint la séparation attribuée à PageBreak entre détection par l’IA et validation sans IA.
Darin Fredde, directeur principal de l’ingénierie marketing technique chez Ridge Security, inscrit cette démarche dans une évolution vers des tests d’intrusion continus, autonomes et fondés sur des preuves. Selon lui, la détection ne suffit pas : le processus doit aller jusqu’à la démonstration de la faille, sa correction et la vérification de l’efficacité du correctif.
Ces commentaires reflètent des analyses du secteur ; ils ne constituent pas une confirmation indépendante des performances de PageBreak. Aucun ne permet de déterminer dans quelle mesure l’agent a examiné les applications de Google, à quelle fréquence il a manqué des vulnérabilités ni si toutes les failles validées ont ensuite été corrigées.
La correction automatisée reste une étape à venir
Google prévoit de connecter PageBreak à CodeMender, son système automatisé de correction des vulnérabilités. Dans le processus envisagé, PageBreak validerait une faille, puis CodeMender générerait une proposition de modification du code. Les ingénieurs produit examineraient ensuite le correctif proposé, le valideraient et l’appliqueraient.
Cette intégration est présentée comme un projet à venir, et non comme un processus de correction déjà opérationnel. Les plus de 500 vulnérabilités signalées ne doivent donc pas être interprétées comme autant de failles automatiquement corrigées.
Pour les équipes produit de Google, PageBreak pourrait réduire le temps consacré à reproduire manuellement les résultats générés par l’IA. L’exécution réussie d’une charge utile fournit aux ingénieurs des éléments plus solides pour déterminer si une faiblesse présumée mérite leur attention. Elle ne suffit toutefois pas, à elle seule, à établir la gravité de la faille, son impact sur les utilisateurs ou la validité d’un correctif ultérieur.
Pour les utilisateurs et les administrateurs externes, le rapport ne fournit ni consignes de mise à jour propres à un produit, ni indicateurs de compromission, ni solution de contournement. Il n’apporte pas non plus de preuve que les attaquants ont exploité les failles détectées. La responsabilité immédiate de la correction incombe donc à Google et aux équipes qui gèrent les services et extensions propriétaires testés.
D’après les informations publiées par Google, PageBreak illustre un modèle précis de tests internes : laisser un agent d’IA ratisser large, mais exiger une preuve exécutable distincte avant de transmettre un résultat aux ingénieurs. Les affirmations concernant son faible taux de faux positifs à grande échelle n’ont pas été vérifiées de manière indépendante.
