Roter, redéployer, révoquer : notre réponse à l'incident Vercel

Le 19 avril 2026, Vercel a divulgué un incident de sécurité attribué à une application OAuth tierce compromise au sein de leur Google Workspace. Nous avons appliqué la réponse à chaque projet Vercel géré par webvise avant la fin du week-end, et les journaux d'audit sur Vercel comme sur les Google Workspaces que nous administrons sont revenus sans anomalie. Il ne s'agissait pas d'une vulnérabilité dans le code de Vercel. C'était une compromission de la chaîne d'approvisionnement SaaS-to-SaaS via une limite de confiance OAuth, et la nature de cet incident change ce à quoi doit ressembler une réponse adéquate.

Faire tourner les secrets dans votre tableau de bord Vercel représente peut-être la moitié de la réponse. L'autre moitié se trouve dans Google Workspace, et la plupart des analyses publiées ne la couvrent pas.

Vous avez lu la divulgation et renouvelé chaque clé que vous avez pu trouver. C'est le bon premier réflexe. Cet article décrit ce que nous avons réellement exécuté de bout en bout, le point technique qui rend la rotation applicable aux fonctions en cours d'exécution, et pourquoi la nature de cet incident doit changer l'apparence de votre plan de réponse pour la prochaine fois.

• Faire tourner les variables d'environnement Vercel modifie le tableau de bord, pas les fonctions en cours d'exécution. Les valeurs ne prennent effet qu'au prochain déploiement.

• L'audit OAuth Google Workspace est la moitié qui est à peine abordée. C'est le chemin de confiance emprunté par l'attaquant pour atteindre Vercel.

• Il ne s'agissait pas d'une vulnérabilité Vercel. C'était une compromission SaaS-to-SaaS via un grant OAuth, et une réponse standard de type CVE ne ferme pas la boucle.

• À long terme, sortez les secrets des variables d'environnement et placez-les dans un gestionnaire de secrets à l'exécution. Exigez un MFA résistant au phishing pour toute personne pouvant installer des applications OAuth.

• Des audits mensuels des grants OAuth tiers dans votre fournisseur d'identité font désormais partie de la référence de base, pas d'une amélioration de maturité.

Ce que Vercel a réellement divulgué

En résumé : une application SaaS tierce disposant d'un accès OAuth au sein du Google Workspace de Vercel a été compromise, et l'attaquant a utilisé cette limite de confiance pour accéder aux valeurs des variables d'environnement sur un sous-ensemble de projets clients. Vercel a publié un identifiant de client OAuth comme indicateur de compromission et a demandé à chaque client de faire tourner tout secret stocké comme variable d'environnement. Rien dans cet incident n'implique une vulnérabilité dans le propre code de Vercel. La surface d'attaque était le graphe de confiance d'identité entre deux outils SaaS.

Cela importe pour la façon dont vous répondez. Si la vulnérabilité se trouve dans le code de la plateforme elle-même, vous corrigez, faites tourner ce qui a fui, et passez à autre chose. Si la vulnérabilité se trouve dans le chemin de confiance entre les plateformes, la rotation est nécessaire mais elle ne ferme pas la faille. Vous devez également révoquer le grant emprunté par l'attaquant, sans quoi la prochaine compromission de ce même outil reproduira le même rayon de souffle.

Si vous souhaitez un regard extérieur sur votre configuration Vercel avant que le post-mortem du prochain week-end soit écrit à votre sujet, nous réalisons des audits de sécurité sur les équipes Vercel, les Google Workspaces et les grants SaaS-to-SaaS.

Étape 1 : faire tourner les secrets qui comptent vraiment

Nous avons traité chaque variable d'environnement susceptible d'accorder un accès à quoi que ce soit comme compromise par défaut. C'est l'hypothèse qu'impose la divulgation. Voici les catégories de secrets que nous avons réémis sur les projets gérés.

• Identifiants de base de données. Chaînes de connexion, mots de passe des réplicas en lecture seule et clés de rôle de niveau administrateur sur chaque projet avec un backend de base de données.

• Clés API Resend pour les e-mails transactionnels sur chaque projet envoyant des messages de vérification, de notification ou d'inscription.

• Identifiants Google API pour les intégrations Workspace, Calendar, Drive et Analytics exécutées côté serveur.

• Clés AI Gateway incluant les jetons d'accès aux modèles, les identifiants fournisseurs et les jetons de limitation de débit pour tout ce qui transite par la passerelle.

• Identifiants d'intégration d'ingestion pour les endpoints webhook, les pipelines d'événements et tout ce qui extrait des données dans le projet depuis l'extérieur.

Deux catégories méritent une double vérification : les variables se terminant par `_URL` qui intègrent des identifiants dans des chaînes de connexion, et tout ce qui est étiqueté `_TEST` ou `_DEV` qui s'avère pointer vers la production. Faites-les tourner avec le reste. Un attaquant lisant des variables d'environnement ne se soucie pas du drapeau que vous avez choisi ni de ce que le nom de la variable suggère qu'elle fait.

Étape 2 : redéployer (le point technique qui rend la rotation réelle)

C'est la partie qui importe le plus et qui reçoit le moins d'attention. Vercel applique les modifications de variables d'environnement au moment de la construction et du déploiement, pas à l'exécution. Un projet que vous avez mis à jour et laissé tel quel continue d'exécuter la construction que vous avez livrée hier, qui a toujours l'ancien secret intégré dans son environnement d'exécution. Vous avez fait tourner le tableau de bord, pas le système.

Version concrète : vous faites tourner votre clé API Resend à 10 h 14 et ouvrez un nouvel onglet pour vérifier autre chose. Une fonction tente d'envoyer un e-mail de vérification à 10 h 17, appelle Resend avec l'ancienne clé toujours intégrée dans son environnement déployé, et Resend rejette la requête. Votre utilisateur ne reçoit pas son e-mail. Multipliez cela par chaque fonction, chaque tâche planifiée et chaque gestionnaire de webhook exécutant l'ancienne construction.

Pour vérifier votre réponse, ouvrez l'onglet Deployments sur chaque projet et trouvez un déploiement horodaté après votre rotation. Si la première ligne affiche un horodatage antérieur au moment où vous avez effectué la rotation, celle-ci n'a été intégrée dans aucun processus en cours d'exécution. La deuxième étape explicite de notre réponse a été un redéploiement forcé en production sur chaque projet géré après la rotation, avant de passer à la suite.

Étape 3 : révoquer le grant OAuth Google Workspace

C'est la moitié de la réponse qui a à peine été abordée dans les fils du week-end. L'incident a pris naissance dans Google Workspace. L'attaquant est entré via une application OAuth tierce disposant d'une portée accordée dans Workspace, puis a pivoté vers Vercel via un chemin de confiance SaaS-to-SaaS. Si vous n'avez effectué la rotation que du côté Vercel, la même application OAuth est toujours présente avec la même portée, prête à être exploitée la prochaine fois qu'elle sera compromise.

Le chemin dans votre console d'administration : admin.google.com, sécurité, contrôles API, contrôle d'accès des applications, applications tierces. Recherchez l'identifiant de client OAuth publié par Vercel comme indicateur. Révoquez-le s'il est présent. Puis faites la chose plus difficile : passez en revue chaque autre grant OAuth dans la liste, confirmez que chaque portée était intentionnelle, et révoquez tout ce que vous n'avez pas de raison valable de conserver.

Nous avons effectué cet audit sur chaque Workspace que nous administrons. L'indicateur était absent, et la plupart des grants avaient une finalité commerciale légitime. Quelques-uns n'en avaient pas, et nous les avons révoqués. Nous sommes depuis passés à une cadence mensuelle : auditer les grants OAuth au début de chaque mois, révoquer tout ce qui n'a pas été utilisé depuis 30 jours.

Étape 4 : les mesures à long terme

La rotation et la révocation ont traité l'exposition immédiate. Les mesures à plus long terme sont ce qui empêche le prochain incident de se transformer en course contre la montre un week-end. Nous les déployons sur les projets gérés au cours des prochaines semaines, et ce sont celles que nous recommandons à toute équipe opérant une infrastructure fortement orientée SaaS.

• Récupérer les secrets à l'exécution depuis un gestionnaire de secrets plutôt que de les intégrer dans des variables d'environnement. La rotation devient une mise à jour centralisée, pas un redéploiement.

• Des identifiants à courte durée de vie pour les bases de données et les API partout où le fournisseur les prend en charge. Une validité de quelques minutes, pas de plusieurs mois.

• Une rotation planifiée pour les identifiants qui ne peuvent pas être rendus éphémères. Pilotée par le calendrier, pas par les incidents.

• Un MFA résistant au phishing sur chaque compte administrateur pouvant installer des applications OAuth dans votre fournisseur d'identité. Passkeys ou jetons matériels, rien de basé sur SMS.

• Des audits mensuels des grants OAuth dans Workspace, Microsoft 365, ou quel que soit le fournisseur d'identité que vous utilisez. Le chemin de l'attaquant cette fois était un grant OAuth ; il le sera aussi la prochaine fois.

La plupart des équipes n'ont pas de responsable unique pour aucune de ces mesures. C'est la raison silencieuse pour laquelle les incidents continuent de se terminer avec les mêmes points dans le post-mortem. Parlez-nous de la façon dont webvise intègre ces éléments dans le contrat de maintenance de chaque projet géré.

Pourquoi cet incident est différent

Le modèle de compromission pour lequel la plupart des programmes de sécurité sont conçus : un attaquant trouve un CVE dans un serveur que vous exploitez, l'exploite, et exfiltre vos données. La rotation, les correctifs et la surveillance du périmètre couvrent ce modèle. L'incident survenu le 19 avril présente une forme différente.

Un attaquant compromet un outil SaaS que votre équipe a autorisé, puis exploite la relation de confiance entre cet outil et vos autres outils SaaS pour accéder à des données qu'aucun des deux n'aurait données à un inconnu. Votre compte Vercel n'a pas été compromis, votre Google Workspace non plus. Un outil tiers que quelqu'un a connecté il y a des mois a été compromis, et les portées que vous aviez accordées à cet outil ont propagé la compromission en aval.

Le modèle défensif doit correspondre au modèle d'attaque. Cela signifie traiter les grants OAuth comme des dépendances de production, les auditer selon un calendrier, et sortir les secrets des variables d'environnement où un attaquant disposant de ce grant peut les lire. Nos journaux d'audit sont revenus sans anomalie ce week-end, mais c'est le bénéfice propre à cet incident, pas la preuve que le modèle de réponse est pérenne.

Nous réalisons des audits de sécurité sur les équipes Vercel, les Google Workspaces et les graphes d'identité SaaS-to-SaaS dans le cadre de chaque engagement géré chez webvise. Si vous souhaitez un regard extérieur sur votre configuration avant que la prochaine divulgation tombe un week-end, commencez une conversation.