- Chrome automatise la découverte, le tri, la correction, la publication et l’application des mises à jour de vulnérabilités avec des agents basés sur Gemini ; dans Chrome 149 et 150, 1 072 bugs de sécurité ont été corrigés, soit plus que sur les 23 jalons précédents cumulés
- Le système de détection des vulnérabilités combine plusieurs modèles, une base de connaissances issue des CVE et de l’historique Git de Chrome, des fichiers SECURITY.md et un agent critique distinct, dans un environnement où l’accès à Internet et au système local est strictement limité
- Le tri automatique élimine le spam et les doublons, collecte les reproductions et les traces de pile, ajoute des métadonnées comme la gravité, et assigne les responsables ; il est estimé qu’il économise des centaines d’heures de travail de développement chaque mois
- Pour réduire la fenêtre de correctif entre la publication d’un correctif et son exploitation, Chrome teste des versions de sécurité deux fois par semaine, développe des correctifs dynamiques qui remplacent les processus enfants sans redémarrage, ainsi qu’un redémarrage automatique sur macOS
- Au-delà des corrections de bugs individuelles, Chrome renforce la sûreté mémoire avec MiraclePtr,
std::spanet Rust, et prévient l’introduction de vulnérabilités grâce à des contrôles IA au moment de la soumission et à la mise à jour automatique de plus de 2 300 dépendances externes
Le cycle de vie des bugs de sécurité transformé par l’IA
- Les LLM ont étendu la détection automatique de vulnérabilités au-delà de ce que l’expertise humaine en sécurité peut traiter seule à grande échelle, et Chrome utilise l’IA pour trouver et corriger plus rapidement des centaines de bugs de sécurité
- Alors que les bugs fonctionnels ordinaires peuvent provoquer des problèmes comme le blocage de l’interface, les bugs de sécurité peuvent être exploités par des attaquants sous forme d’exploits pour lire des données personnelles ou contrôler l’ordinateur à l’insu de l’utilisateur
- Les bugs de sécurité suivent les étapes suivantes : découverte, tri, correction, publication de Chrome contenant le correctif, puis redémarrage et application dans le navigateur ; l’objectif est de raccourcir au maximum chacune de ces étapes
Étendre la détection des vulnérabilités
- L’équipe sécurité de Chrome a fait progresser pendant plusieurs années les techniques de détection basées sur les LLM
- En 2023, elle a développé une méthode pour accroître la portée et les performances du fuzzing de sécurité
- En 2024, elle a développé avec Project Zero Naptime, qui fournit aux LLM des outils spécialisés pour la recherche de vulnérabilités
- En 2025, elle a développé avec DeepMind et Project Zero Big Sleep, un agent qui a découvert des bugs dans le moteur JavaScript V8 et la pile graphique
- Le harnais d’agents Gemini mis en place début 2026 améliore l’efficacité de la détection et réduit les faux positifs sur une portion plus large de la base de code de Chrome
- Le bug d’évasion de sandbox découvert pouvait permettre à un renderer compromis de tromper le navigateur pour lui faire lire des fichiers locaux, et était resté dans le code pendant plus de 13 ans
- Les fonctionnalités suivantes ont été ajoutées au harnais de détection
- Interopérabilité des modèles, afin d’exploiter les forces respectives des modèles à poids ouverts et des modèles propriétaires
- Une base de connaissances couvrant l’ensemble des CVE existants et tout l’historique Git de Chrome
- Des consignes de rédaction de SECURITY.md qui explicitent clairement les frontières de confiance et le modèle de menace
- Un agent critique qui lit SECURITY.md dans un contexte distinct
- Des analyses répétées de la base de code pour tenir compte du caractère non déterministe des modèles et de leur amélioration dans le temps
- L’IA analyse uniquement du code source stocké sur des machines verrouillées sans accès à l’Internet général
- Toutes les requêtes réseau sont interceptées et des listes d’autorisation par application et par destination sont appliquées
- Les modèles ne sont pas exécutés en mode illimité, et les modifications système par les sous-agents ainsi que l’accès aux fichiers en dehors des répertoires source désignés sont restreints
- La détection par IA ne remplace pas les tests de sécurité existants
- Le fuzzing est particulièrement efficace pour les bugs résultant d’interactions à longue distance entre zones de code éloignées ou de combinaisons de plusieurs opérations apparemment sans lien
- Les chercheurs externes continuent d’être récompensés via le Chrome Vulnerability Reward Program pour trouver des vulnérabilités difficiles et à fort impact
- Début 2026, les signalements de tous types ont augmenté, et en mars, Chrome a reçu davantage de signalements de bugs que sur l’ensemble de 2025
- En conséquence, le VRP a été modifié afin d’apporter une valeur supplémentaire aux résultats de détection interne et de se concentrer sur les signalements facilement intégrables dans le pipeline de traitement automatique
Tri automatique et correction multi-agents
- Par le passé, trier un signalement de sécurité prenait de 5 minutes à plus de 30 minutes et reposait principalement sur l’expertise humaine ; aujourd’hui, Chrome combine des systèmes à base de règles et l’IA pour améliorer le débit et la précision
- Le tri automatique se déroule en quatre étapes
- Éliminer le spam et les doublons, vérifier si les critères de réception sont remplis et si une description claire de la vulnérabilité de sécurité Chrome est fournie
- Vérifier la preuve de concept et la reproductibilité, tester sur le système d’exploitation et la version du navigateur concernés, puis joindre des informations comme les traces de pile
- Ajouter le moment où le bug a été introduit pour la première fois et sa gravité
- Les consignes de gravité ont été clarifiées afin d’être plus faciles à appliquer automatiquement
- Les développeurs peuvent modifier une note de gravité incorrecte et compléter les informations sur les frontières de sécurité via SECURITY.md
- Assigner automatiquement le problème au bon composant et au bon responsable
- Même si une mesure précise est difficile, le tri automatique est estimé économiser des centaines d’heures de travail de développement chaque mois
- Un flux de travail multi-agents est appliqué à la correction des vulnérabilités
- L’agent de correction reçoit le contexte propre à chaque problème et génère plusieurs correctifs candidats
- L’agent critique évalue le candidat le plus adapté et produit les éléments nécessaires à la revue par les développeurs
- Les deux agents réalisent des itérations similaires à une revue de code pour vérifier le comportement fonctionnel, le respect du style Chromium et Google, ainsi que les conventions du code local
- L’agent de rédaction de tests vérifie les tests sur l’ensemble des plateformes et configurations prises en charge par Chrome avant la revue développeur, ce qui peut faire gagner jusqu’à plusieurs semaines
- Aujourd’hui, les LLM génèrent des correctifs candidats pour la plupart des vulnérabilités
- Dans Chrome 149 et 150, 1 072 bugs de sécurité ont été corrigés, soit plus que le total des 23 jalons précédents
- Big Sleep et CodeMender, développés avec DeepMind et Project Zero, sont intégrés à la CI et inspectent toutes les CL toutes les 24 heures
- En mai, plus de 20 vulnérabilités, dont des problèmes critiques S1+, ont été bloquées avant d’atteindre la production
Réduire la fenêtre de correctif et appliquer les mises à jour
- La période pendant laquelle un attaquant peut rétroconcevoir et exploiter un correctif après son arrivée dans le dépôt open source public mais avant sa distribution aux utilisateurs est appelée fenêtre de correctif pour les attaques N-day
- Il faut généralement plusieurs semaines pour qu’un correctif intégré à l’arbre principal atteigne le canal Stable utilisé par la majorité des utilisateurs
- Selon la gravité, les correctifs sont fusionnés directement dans la branche de version Stable actuelle, tout en surveillant en continu les nouveaux conflits ou régressions
- Depuis le passage des grands jalons Chrome à un cycle de deux semaines, des mises à jour de sécurité sont fournies chaque semaine
- Pour répondre à la vitesse des attaques assistées par IA, Chrome teste aussi des versions de sécurité deux fois par semaine
- Tous les bugs de sécurité qui atteignent Stable sont documentés publiquement, qu’ils aient été découverts en interne ou en externe
- Des travaux sont en cours pour générer automatiquement les notes de version et les descriptions CVE à partir des correctifs, afin d’éliminer les goulets d’étranglement manuels et de réduire le délai entre découverte et divulgation
- Depuis 2008, Chrome utilise des mises à jour automatiques qui téléchargent et préparent les nouveaux binaires en arrière-plan, puis les appliquent au redémarrage suivant
- Le tri, la correction, les tests et le déploiement prennent 1 à 2 jours, mais l’attente jusqu’au redémarrage par l’utilisateur peut aussi contribuer fortement au risque d’exploitation N-day
- Le redémarrage interrompt le travail et doit être planifié séparément, ce qui pousse facilement les utilisateurs à le repousser
- Des fonctionnalités sont en cours de développement pour ne pas faire porter la charge du redémarrage aux utilisateurs
- Le correctif dynamique exploite l’architecture multiprocessus de Chrome pour remplacer progressivement les processus enfants en arrière-plan, comme Renderer et GPU, par de nouveaux binaires ; l’objectif est de supprimer le redémarrage complet du navigateur dans la plupart des cas
- Chrome étudie la possibilité d’enregistrer davantage d’état localement afin de restaurer les sessions même dans des situations complexes
- Le redémarrage est déclenché automatiquement lorsque la restauration complète de session est garantie
- Chrome 150 détecte sur macOS le cas où toutes les fenêtres sont fermées mais où l’application reste en arrière-plan, et redémarre automatiquement si une mise à jour est en attente
- À long terme, l’objectif est un navigateur toujours à jour, combinant correctifs dynamiques continus et redémarrages automatiques à des moments peu intrusifs
- Les recommandations pour les administrateurs IT en entreprise sont les suivantes
- Utiliser la règle RelaunchNotification pour appliquer progressivement les notifications jusqu’au redémarrage forcé après une période définie
- Utiliser le Chrome Extended Stable Channel dans les environnements sensibles où les changements doivent être validés
- Suivre toutes les versions du navigateur et gérer finement les mises à jour via le tableau de bord indépendant du système d’exploitation de Chrome Enterprise Core ou Premium
Défenses C++ et transition vers Rust
- Chrome utilise une double stratégie : neutraliser à l’exécution les vulnérabilités C++ existantes tout en migrant à long terme vers des langages à sûreté mémoire
- Comme la majeure partie du code Chromium est en C++, la chaîne d’outils et les mitigations à l’exécution constituent une première ligne de défense immédiate
- La bibliothèque standard renforcée et les technologies de la famille MiraclePtr ont réduit les vulnérabilités Use-After-Free (UAF)
- La feuille de route des défenses C++ repose sur trois axes
- Extension de MiraclePtr et MiracleObject
- MiraclePtr est étendu à Skia, ANGLE, Dawn, aux itérateurs C++ et aux conteneurs
std:: - MiracleObject vise à neutraliser jusqu’à 90 % des vulnérabilités UAF du thread principal GPU en échangeant une performance runtime localisée contre une sûreté temporelle
- MiraclePtr est étendu à Skia, ANGLE, Dawn, aux itérateurs C++ et aux conteneurs
- Transition vers
std::span- Les structures existantes qui utilisent ensemble pointeur et taille sont remplacées par
std::span, vérifié par le compilateur, afin d’éliminer les accès hors limites (OOB) - 97 % du code propre à Chrome compile sans problème avec des avertissements stricts unsafe-buffer, et ces exigences sont étendues à Skia, ANGLE et Dawn
- Les structures existantes qui utilisent ensemble pointeur et taille sont remplacées par
- Renforcement des structures et de l’allocation
- Le checked math est appliqué aux calculs d’allocation mémoire afin de bloquer les chemins d’overflow entier
- Un partitionnement supplémentaire du tas, séparant strictement les types contenant des pointeurs et les types sans pointeurs, rend l’exploitation des UAF plus difficile
- Extension de MiraclePtr et MiracleObject
- L’utilité marginale des mitigations runtime C++ devrait diminuer dans les prochaines années
- Les contrôles runtime coûtent plus cher que les garanties à la compilation, et même des binaires C++ fortement mitigés nécessitent une sandbox stricte limitant les performances pour respecter la Rule of Two
- À long terme, Chrome pousse la transition vers Rust
- Volant d’inertie Rust : construire un SDK central fournissant directement à Rust des API et outils basés sur Chromium, afin d’en faire un choix courant pour les nouveaux composants
- Élimination des zones denses en bugs : remplacer stratégiquement le code historiquement très dense en bugs, comme les parseurs de données complexes, les codecs d’images et la pile de polices
- Modularisation à hauts privilèges : écrire les nouveaux modules en Rust pour exécuter des fonctionnalités complexes même dans des zones à hauts privilèges comme le processus navigateur, sans coût de performance lié à la sandbox
- Chrome étudie aussi la possibilité d’implémenter l’interface utilisateur de plus haut niveau du navigateur en HTML, CSS et TypeScript afin de réduire encore la dépendance aux frameworks C++ existants
Bloquer les vulnérabilités avant la soumission du code
- Les analyses périodiques de l’ensemble de la base de code ne suffisent pas à suivre le rythme rapide du développement de Chrome ; les contrôles IA sont donc placés au plus près du moment de la soumission du code
- Le modèle de défense de la CI et de la commit queue (CQ) vérifie automatiquement les changements
- Il propose des corrections de transition vers
std::span - Il signale les pointeurs pendants
- Il impose la sûreté des opérations numériques
- Il propose des corrections de transition vers
- Un code sûr pris isolément peut devenir un grave problème de sécurité potentiel lorsqu’il est combiné à une petite modification logique ailleurs
- L’analyse sémantique continue par LLM dans la CQ détecte des interactions subtiles ou complexes que l’analyse statique traditionnelle manque, et les bloque avant que le code n’entre dans l’arbre
Écosystème open source et dépendances externes
- La sécurité du Web dépend non seulement de Chrome, mais aussi de la capacité de réaction des projets open source et de leurs mainteneurs
- Google a fait don de 12,5 millions de dollars au projet Alpha-Omega avec d’autres participants afin que les mainteneurs disposent d’outils et d’un accompagnement pour répondre rapidement aux signalements de vulnérabilités
- Google est membre fondateur du projet Akrites, dont l’objectif est de réduire la charge des mainteneurs upstream en fournissant un point central de signalement des vulnérabilités et une équipe de réponse aux incidents de sécurité
- Chromium et des projets liés comme V8, BoringSSL, Skia, ANGLE et Dawn comptent plus de 2 300 dépendances externes
- Parmi elles, environ 1 700 sont distribuées aux utilisateurs via divers produits, notamment des appareils Android, des plateformes d’edge computing et les piles de grandes entreprises cloud
- Le pipeline automatique de vérification des vulnérabilités collecte des flux internes de Google, ainsi que des données de la NVD du gouvernement américain et de OSV, centré sur l’open source
- Comme la surveillance a posteriori peut laisser une fenêtre de risque, Chrome commence à migrer toutes ses dépendances externes vers un pipeline de mise à jour automatique qui les met proactivement à jour vers la dernière version upstream
- Le processus d’automatisation utilise des signaux de sûreté issus de projets comme GOSSIP afin de tenir compte d’autres risques dans l’écosystème open source externe
Un navigateur protégé en continu
- L’augmentation du nombre de bugs découverts et corrigés par les LLM n’est pas un échec : chaque bug corrigé retire un point d’appui potentiel à un attaquant
- Découvrir et corriger ne suffit pas ; il faut aussi distribuer les correctifs et les appliquer dans l’environnement utilisateur avant qu’un attaquant ne les exploite
- En combinant des releases plus rapides, des correctifs dynamiques, des redémarrages automatiques à des moments peu intrusifs et des défenses structurelles, Chrome vise une protection continue sans gêner les utilisateurs
1 commentaires
Avis de Hacker News
J’ai récemment beaucoup utilisé l’IA pour l’optimisation des performances pendant une période chargée au travail, mais elle s’est révélée presque inutile pour définir une direction de haut niveau. Même quand elle pointait des éléments suspects dans des requêtes SQL, l’écart de performance avant/après était quasi nul, j’ai perdu du temps avec des suggestions inutiles, et j’ai même dû gérer des gens qui balançaient des sorties IA brutes comme si c’étaient des contributions pertinentes.
En revanche, elle a rendu beaucoup plus facile l’implémentation de changements que j’avais moi-même identifiés, ou le déplacement de jointures vers des CTE.
Même en répétant aux outils d’IA « sois concis », « réponds uniquement à la question », « ne donne pas d’informations non demandées », ils produisent plus que nécessaire, ce qui ressemble à une subtile tentative de consommer davantage de tokens.
À partir du seul texte du code, on ne peut pas connaître la taille du cache, le volume de la base de données ni la latence réseau ; il faut donc donner ce contexte pour obtenir de meilleurs résultats.
Le fait essentiel est qu’au Pwn2Own de Berlin en mai dernier, Firefox n’a versé aucune récompense. Depuis 2007, toutes les éditions avaient donné lieu à des paiements, et l’absence totale de vulnérabilités confirmées laisse penser que les failles faciles ont désormais presque disparu, et que ce type de modèle est utile dans une certaine mesure.
Je veux bien croire qu’on puisse corriger beaucoup de bugs, mais je suis curieux du processus réel. Il est aussi possible que Google ait publié un billet de blog et que des managers aient encouragé pendant quelques sprints la correction de bugs pour montrer à la hiérarchie les résultats de l’adoption de l’IA, poussant les équipes à travailler bien plus que d’habitude.
Les performances d’un LLM dépendent de la boucle dans laquelle il est exécuté, et cette boucle dépend de la qualité du vérificateur ; cela suffit donc à l’expliquer, même sans démonstration de performance par les managers.
Plutôt que de laisser l’IA travailler au hasard, il faut l’utiliser comme outil d’accélération, mais les critiques semblent confondre les deux. C’est un peu le même homme de paille que de s’énerver contre Excel parce que le retour sur investissement est mauvais ; plutôt que de continuer à débattre, je préfère échanger discrètement des méthodes d’usage efficaces avec ceux qui veulent vraiment s’en servir correctement.
Si on la laisse faire, les résultats se dégradent en quelques itérations ; si on la guide soigneusement, elle apporte de la valeur, mais l’effort requis ressemble, surtout pour les tâches répétitives, à celui d’écrire directement le code.
Impossible de savoir combien de corrections automatiques ont été annulées, combien de nouveaux bugs elles ont créés, ni quel est le taux de faux positifs de l’agent de détection. Le billet ne donne que les chiffres de réussite, et rien sur ce qui pourrait mal tourner
Même si l’on crée 2 nouveaux bugs en en corrigeant 10, le gain net reste important tant qu’il ne s’agit pas de bugs graves exploitables isolément. Les attaques contre les navigateurs exigent des chaînes de vulnérabilités de plus en plus longues, donc l’intérêt de l’IA pour trouver des bugs potentiels est difficile à ignorer
https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1....
On peut craindre qu’à l’avenir Google estime ne plus avoir besoin d’une recherche collective de bugs publique dans Chromium et mette fin au développement ouvert. Dans ce cas, les navigateurs actuels basés sur Chromium deviendraient de facto des forks de la dernière version publique, et la difficulté de maintenance de chaque fork pourrait varier, faute de ressources comparables à celles de Chrome avec l’appui de Gemini
Les critiques de l’IA se concentrent souvent sur une catégorie étroite : la génération aveugle de code, jugée mauvaise, ce qui est facile à admettre. Mais les tests adversariaux, la vérification des hypothèses des développeurs, les suggestions de refactoring, les petits outils de développement, le codage accompagné, ainsi que le suivi des dépendances et des comportements dans de grandes bases de code relèvent d’un autre registre et peuvent être très utiles
On mélange trop facilement les critiques visant la génération aveugle de code avec l’ensemble de ces usages
La vraie question est de savoir combien de ces bugs proviennent au départ de code écrit par un LLM. Créer 100 fois plus de bugs et en corriger 100 fois plus n’a rien de glorieux
Puisqu’il s’agit d’un projet open source, on peut même vérifier directement si le bug a réellement été créé par un LLM
Je me demande si Chrome a aussi corrigé les bugs de suivi comportemental destinés à tracer les utilisateurs quoi qu’ils fassent et où qu’ils soient