Aller au contenu
Beveiligingsnieuws

Chrome et l’IA : 1 072 bugs corrigés en deux versions

AI helpt Chrome

Google affirme que Chrome et l’IA accélèrent nettement la découverte et la correction des failles. Dans ses deux versions les plus récentes, Chrome aurait ainsi corrigé 1 072 bugs de sécurité, soit davantage que la totalité des correctifs appliqués lors des 23 étapes précédentes réunies.

Ce bond s’appuie sur une utilisation plus large de modèles de langage à grande échelle tout au long de la gestion des vulnérabilités. Concrètement, ces systèmes ne se contentent pas de “signaler” des problèmes : ils aident aussi à structurer les rapports, à estimer la sévérité, à proposer des correctifs et à produire des tests.

1 072 vulnérabilités corrigées : un rythme en hausse

Selon Google, Chrome 149 et Chrome 150 ont corrigé ensemble 1 072 vulnérabilités. L’entreprise souligne que ce total dépasse largement le nombre de bugs corrigés lors de l’ensemble des 23 jalons antérieurs.

L’initiative s’inscrit dans une stratégie plus large : améliorer la capacité de détection et réduire le temps nécessaire pour passer de la découverte à la mise à jour distribuée.

Où intervient l’IA dans le traitement des failles

Google explique utiliser des modèles de langage tout au long du cycle de gestion des vulnérabilités. Le processus inclut notamment :

  • Découverte de failles
  • Reproduction de rapports afin de vérifier le problème
  • Évaluation de la sévérité
  • Assignation des bugs aux développeurs concernés
  • Génération de correctifs candidats
  • Création de tests pour valider les changements

Autrement dit, Chrome et l’IA ne remplacent pas entièrement les tests humains, mais automatisent une grande partie des tâches répétitives et accélèrent les étapes “pré-décision”.

De la fuzzing renforcée aux agents spécialisés

Google indique que son travail avec l’IA en sécurité a déjà plusieurs étapes.

Un premier pas : améliorer la fuzzing

Dès 2023, l’entreprise aurait commencé à utiliser des modèles pour renforcer la fuzzing, une technique qui consiste à soumettre un logiciel à de nombreuses entrées afin de provoquer des comportements inattendus et révéler des faiblesses.

Google affirme toutefois que la fuzzing reste pertinente : les nouveaux flux automatisés doivent compléter les méthodes de test existantes, pas les écarter.

Project Zero et des outils “outillés”

Par la suite, Google a collaboré avec Project Zero sur Naptime, un système qui fournissait aux modèles des outils spécialisés dédiés à la recherche de vulnérabilités.

Plus tard, l’entreprise s’est aussi appuyée sur une collaboration avec Google DeepMind et Project Zero autour de Big Sleep, décrit comme un agent orienté découverte. Cet agent aurait identifié des failles dans V8, le moteur JavaScript de Chrome, ainsi que dans des composants liés à l’affichage graphique.

Un agent pour explorer plus largement le code

Début 2026, Google a créé un agent basé sur Gemini pour rechercher des vulnérabilités dans une portion plus vaste du code de Chrome, tout en cherchant à réduire les faux positifs.

Dans ce cadre, Google mentionne un cas particulièrement marquant : une faille de type échappement du sandbox présente dans le code depuis plus de 13 ans. Si elle avait été exploitée, elle aurait permis à un processus compromis (par exemple un renderer) de sortir du sandbox et de tromper le navigateur pour qu’il lise des fichiers locaux.

Des rapports de sécurité en hausse : adaptation du programme

Google observe aussi une augmentation importante des soumissions via le Chrome Vulnerability Reward Program. En mars 2026, l’entreprise indique avoir reçu davantage de rapports que pendant l’ensemble de l’année 2025.

Face à cet afflux, Google a modifié son programme pour mieux prioriser les contributions qui complètent ce que ses outils automatisés détectent déjà.

Automatiser le tri : moins de bruit, plus de vitesse

L’entreprise décrit également une automatisation du triage des vulnérabilités. Les systèmes aideraient à :

  • Filtrer le spam et les doublons
  • Reproduire des preuves de concept lorsque c’est possible
  • Attribuer des cotes de sévérité
  • Orienter les rapports vers les équipes ou développeurs adéquats

Google estime que cette approche automatisée économise des centaines d’heures par mois aux équipes de développement.

En complément, une fois la vulnérabilité confirmée, des agents généreraient plusieurs correctifs potentiels. Un autre agent évaluerait ensuite les propositions et préparerait des éléments supplémentaires afin d’aider les développeurs à décider et à valider.

Google rapporte que ces systèmes auraient notamment évité, en mai, l’arrivée en production de plus de 20 vulnérabilités, dont un problème classé critique.

Corriger vite, mais aussi livrer plus vite

Google rappelle cependant un point clé : trouver et corriger plus rapidement ne suffit pas si la mise à jour met trop de temps à atteindre les utilisateurs.

Une fois qu’un correctif est engagé dans le code public, les attaquants peuvent inspecter le changement et tenter de reconstituer la vulnérabilité avant que la mise à jour soit largement déployée.

Vers deux mises à jour de sécurité par semaine

Pour réduire cet écart, Google indique qu’elle transitionne vers un cycle majeur de publication toutes les deux semaines, avec des mises à jour de sécurité hebdomadaires. L’entreprise pilote aussi l’idée de fournir deux sorties de sécurité par semaine, afin d’accélérer la mise à disposition des corrections.

Vers le “dynamic patching” pour limiter les interruptions

Google travaille également sur une approche appelée dynamic patching. L’objectif : appliquer certaines mises à jour sans redémarrer manuellement le navigateur.

À partir de Chrome 150 sur macOS, le navigateur pourrait redémarrer automatiquement pour activer une mise à jour en attente lorsqu’il est exécuté en arrière-plan, sans fenêtres ouvertes.

À plus long terme, Google vise à maintenir Chrome continuellement à jour grâce à la combinaison de mises à jour dynamiques, de redémarrages automatiques durant les périodes d’inactivité et d’améliorations de la restauration de session.

Améliorer la sécurité en documentant les frontières de confiance

Google encourage aussi ses développeurs à ajouter des fichiers SECURITY.md. Le but est de décrire les frontières de confiance et les modèles de menace, afin d’aider les systèmes d’IA à mieux identifier les opérations à impact sécurité.

Cette démarche vise à rendre les analyses plus contextualisées, en complément des capacités automatisées déjà en place.

Pourquoi Google insiste sur la complémentarité

Dans sa communication, Google insiste sur un message : les workflows multi-agents basés sur l’IA aident plutôt qu’ils ne remplacent entièrement les tests de sécurité, notamment la fuzzing, qui demeure efficace pour débusquer des vulnérabilités complexes.

En pratique, l’approche cherche un équilibre : réduire le temps perdu sur les tâches répétitives, tout en conservant des méthodes de validation éprouvées.

Conclusion : Chrome et l’IA comme levier d’accélération

Avec Chrome et l’IA, Google revendique une hausse spectaculaire du nombre de failles corrigées et détaille une chaîne de traitement plus automatisée : découverte, reproduction, triage, proposition de correctifs et génération de tests.

Mais l’entreprise relie aussi ces gains à un enjeu opérationnel : livrer plus vite les correctifs aux utilisateurs. En combinant des cycles de publication plus fréquents, des pilotes de sorties de sécurité renforcées et des redémarrages plus “discrets”, Google cherche à réduire la fenêtre pendant laquelle des failles peuvent être exploitées.

Source: https://www.bleepingcomputer.com/news/google/google-says-ai-helped-chrome-fix-1-072-security-bugs-in-two-releases/