La mise à jour Chrome n’est plus une tâche de fond que l’on peut repousser au prochain comité de changement : trois versions récentes du navigateur ont corrigé 1 442 vulnérabilités, soit davantage que les vingt-trois mises à jour précédentes réunies. Pour une PME ou une ETI, cela change la nature du risque : le navigateur est devenu le composant le plus exposé et le plus rapidement exploité du parc. Ce tutoriel détaille comment industrialiser le patch navigateur, de l’inventaire à la vérification, sans mobiliser une équipe dédiée.
Pourquoi la mise à jour Chrome devient un sujet de sécurité prioritaire
Deux évolutions récentes expliquent cette accélération. D’abord, l’usage de l’IA dans la recherche de vulnérabilités : un agent de Google a mis au jour une faille présente depuis treize ans dans le navigateur, invisible pour les campagnes d’audit classiques. Ensuite, l’industrialisation du fuzzing, qui produit un volume de correctifs sans commune mesure avec les années précédentes.
La conséquence pratique est simple : le rythme de publication des correctifs dépasse désormais le rythme de déploiement de la plupart des PME-ETI. Chaque semaine de retard sur une version de Chrome élargit une surface d’attaque qui s’exécute sur tous les postes, avec les droits de l’utilisateur, et qui traite quotidiennement du contenu non maîtrisé. C’est exactement le scénario décrit dans notre article sur la réduction de la fenêtre de patch, du N-day au N-hour.
Ce que le navigateur expose réellement
- Les sessions authentifiées vers vos applications SaaS (Microsoft 365, CRM, outils RH).
- Les jetons OAuth et cookies de session, cibles privilégiées des infostealers.
- Les extensions installées, qui héritent d’une partie de ces privilèges.
- Le rendu de contenu distant, principal vecteur d’exécution de code à distance.
Étape 1 : établir l’inventaire des versions déployées
Sans inventaire, aucune politique de patch n’est vérifiable. L’objectif est d’obtenir, pour chaque poste, la version exacte du navigateur et la date du dernier redémarrage — car un Chrome mis à jour mais jamais relancé continue d’exécuter le binaire vulnérable.
Sous Windows, la version est lisible dans la base de registre :
reg query "HKLM\SOFTWARE\WOW6432Node\Google\Update\Clients" /s /v pvSous macOS :
defaults read "/Applications/Google Chrome.app/Contents/Info" CFBundleShortVersionStringSous Linux :
google-chrome --version || dpkg -l google-chrome-stableCes trois commandes se scriptent sans difficulté et alimentent un tableau de bord de conformité. L’essentiel est de collecter la donnée automatiquement, à intervalle fixe, plutôt que de la demander aux utilisateurs.
Étape 2 : forcer la mise à jour Chrome par politique
Chrome dispose d’un mécanisme de mise à jour automatique, mais il est fréquemment neutralisé — par une image système figée, un compte sans privilèges, ou un service de mise à jour désactivé. La bonne pratique consiste à imposer le comportement par stratégie plutôt qu’à s’en remettre au réglage par défaut.
Parc Windows géré par GPO
Importez les modèles d’administration Chrome (fichiers ADMX) dans votre magasin central, puis appliquez :
UpdateDefault= Always allow updates — autorise installation et mise à jour.AutoUpdateCheckPeriodMinutes=300— vérification toutes les cinq heures.RelaunchNotification= Required — impose le redémarrage du navigateur.RelaunchNotificationPeriod=86400000— délai de grâce de 24 heures, puis relance forcée.
Les deux dernières valeurs sont les plus importantes : elles règlent le problème du correctif installé mais jamais activé, qui représente en pratique une part significative des postes considérés à tort comme conformes.
Parc géré par Intune ou MDM
Déployez le catalogue de paramètres Chrome et appliquez les mêmes clés, en ajoutant une politique de conformité qui marque non conforme tout appareil dont la version est inférieure à la version stable en cours. Sur macOS, distribuez un profil de configuration portant le domaine com.google.Chrome avec les mêmes directives de relance.
Postes Linux
Vérifiez que le dépôt de l’éditeur est bien actif et que les mises à jour de sécurité s’appliquent sans intervention :
sudo apt update && sudo apt install --only-upgrade google-chrome-stableIntégrez cette opération à votre configuration unattended-upgrades afin qu’elle ne dépende d’aucune action manuelle.
Étape 3 : réduire la surface avant même le correctif
Le patch réduit le risque connu ; la configuration réduit le risque résiduel. Trois réglages apportent un bénéfice immédiat en PME-ETI :
- Liste blanche d’extensions via
ExtensionInstallAllowlistetExtensionInstallBlocklist— sujet détaillé dans notre guide sur la sécurisation des extensions navigateur. - Isolation de site (
SitePerProcess) activée, pour contenir une compromission du moteur de rendu à un seul domaine. - Blocage des téléchargements dangereux via
DownloadRestrictions, qui limite la chaîne d’exécution après une exploitation réussie.
Étape 4 : vérifier, détecter, corréler
Une politique non vérifiée n’est qu’une hypothèse. La vérification repose sur deux niveaux complémentaires.
Le premier est déclaratif : votre inventaire doit prouver que la version déployée correspond à la version stable publiée. Un écart de plus de sept jours constitue un signal à traiter comme un incident de conformité, pas comme une tâche d’exploitation courante.
Le second est comportemental. Un navigateur à jour reste exploitable par un zero-day ; c’est le comportement du processus qui trahit l’attaque — un processus enfant inattendu lancé depuis chrome.exe, une écriture dans un répertoire de démarrage, une connexion sortante inhabituelle. C’est le rôle du capteur EDR CrowdStrike Falcon, qui remonte ces séquences depuis le poste. Au-dessus, l’Agentic SOC ucyber.ai corrèle ces signaux avec l’état de patch réel, l’inventaire d’extensions et l’exposition applicative, afin de distinguer un poste simplement en retard d’un poste réellement compromis.
Indicateurs à suivre chaque semaine
- Pourcentage de postes sur la version stable en cours.
- Délai médian entre publication du correctif et relance effective du navigateur.
- Nombre d’extensions hors liste blanche détectées.
- Alertes EDR impliquant un processus enfant du navigateur.
Ce qu’il faut retenir
Le volume de correctifs publiés récemment n’est pas une anomalie passagère : c’est le nouveau régime, accéléré par la recherche de vulnérabilités assistée par IA. Traiter la mise à jour Chrome comme une simple opération bureautique revient à laisser ouvert le composant le plus exposé du système d’information. Industrialisez l’inventaire, imposez la relance par stratégie, réduisez la surface par configuration, et vérifiez le résultat par la détection comportementale plutôt que par la déclaration.