Vercel exige l’OIDC de ses partenaires mais garde un token statique dans son propre pipeline GitHub Actions
Le 22 octobre 2026, Vercel a déclaré la mort des identifiants statiques après un sondage de plus de 1 000 éditeurs SaaS dont seuls 8,4 % supportent une authentification OIDC. Deux échéances s’appliquent au Marketplace, mais le guide officiel de déploiement GitHub Actions de Vercel impose encore un token longue durée.
22 octobre 2026. Vercel publie « Death to long-lived static credentials », signé par son CTO Malte Ubl. 22 octobre 2026, dans la foulée. Le CEO Guillermo Rauch résume sur X : il est temps de « tuer les identifiants statiques ». 23 octobre 2026. Des développeurs relèvent que le guide officiel de déploiement GitHub Actions de Vercel impose toujours un VERCEL_TOKEN longue durée. La contradiction est là, dès le premier jour : Vercel demande à ses partenaires ce qu’il n’a pas fini d’appliquer à ses propres outils.
Pour un RSSI, l’épisode est moins une leçon d’hypocrisie qu’une leçon de calendrier : migrer toute une chaîne d’authentification vers l’OIDC prend du temps, et le plus gros éditeur de la plateforme n’y est pas encore parvenu lui-même.
Un constat chiffré, deux échéances
Le billet de Malte Ubl part d’un chiffre unique : Vercel a sondé plus de 1 000 éditeurs SaaS et constaté que seuls 8,4 % supportaient ce que la société considère comme des méthodes d’authentification sécurisées — principalement l’OIDC et les tokens à courte durée de vie. Le parallèle assumé avec HTTPS Everywhere est central : l’authentification machine-à-machine ressemblerait aujourd’hui au web de 2010, où le chiffrement était encore l’exception.
L’annonce ne se contente pas de constater. Elle pose deux jalons sur le Marketplace de Vercel, qui distribue bases de données, CMS et outils d’observabilité tiers :
- 30 novembre 2026 : les intégrations qui ne supportent pas l’OIDC depuis Vercel et qui reposent encore sur des secrets longue durée porteront un label « Not secure » sur leur fiche.
- Janvier 2027 : les éditeurs qui n’offrent toujours pas d’authentification sécurisée seront déréférencés.
Vercel affirme appliquer « la même barre » à sa propre API et à ses intégrations natives. Le sondage, lui, n’est pas reproductible : la méthodologie n’est pas publiée, les éditeurs interrogés ne sont pas nommés, et le nombre de partenaires contraints de changer leur système n’est pas divulgué.
Pourquoi Vercel pense que le token statique est mort
Le raisonnement de fond tient en trois arguments, tous recevables. D’abord, les agents IA reçoivent de plus en plus de credentials pour agir sur des systèmes externes, et un token sans expiration reste exploitable jusqu’à sa révocation — y compris après une fuite passée inaperçue. Ensuite, la rotation d’un secret compromis est coûteuse : Vercel dit avoir dépensé « des milliers d’heures d’ingénierie » sur des rotations de clés douloureuses qu’il ne veut plus revivre. Enfin, les standards existent déjà : l’OIDC permet à une application d’obtenir un token signé et à courte durée de vie, sans jamais stocker la clé du fournisseur.
La société livre aussi des briques concrètes. OIDC UI, un registre shadcn/ui, fournit des formulaires de trust policy et un vérificateur de token côté serveur pour GitHub, GitLab, Google, AWS, Azure et les émetteurs OIDC maison. Vercel Connect permet de demander des tokens fournisseur scopés au runtime via l’identité de déploiement. Et la fédération OIDC de Vercel, disponible depuis 2024, échange déjà des tokens d’identité contre des credentials temporaires AWS, GCP ou Azure.
Les trois barrières qui freinent l’adoption
Le billet identifie trois obstacles qui expliquent pourquoi, même quand un service propose une méthode sécurisée, les développeurs continuent de coller une clé statique. Le premier est l’outillage : configurer une trust policy et vérifier un token OIDC reste plus compliqué que coller une clé dans une variable d’environnement. Le deuxième est la latence : récupérer ou échanger un token sur le chemin de la requête ajoute un aller-retour réseau qu’une clé déjà présente évite. Le troisième est l’incitation : un éditeur SaaS n’a guère de raison de prioriser l’authentification sécurisée si ses clients ne la réclament pas.
Vercel répond point par point. Les Vercel Functions reçoivent un token émis par la plateforme dans l’en-tête de requête, lu sans appel réseau supplémentaire ; les tokens non expirés sont réutilisés, et Vercel Connect met en cache les tokens fournisseur en processus pour les rafraîchir à l’approche de l’expiration. Quant à l’incitation, c’est précisément le rôle des deux échéances du Marketplace : transformer le label « Not secure » en coût commercial, exactement comme Chrome l’avait fait pour le HTTP non chiffré.
Le contexte donne raison à l’urgence. En octobre 2026 seul, la compromission de LiteLLM 1.107.0 a montré qu’un collecteur de credentials pouvait aspirer des clés de fournisseurs, des identités cloud et des secrets CI/CD dès le démarrage de Python, et la brèche de Railway a exposé des variables d’environnement de déploiement. Chaque incident de ce type transforme un token longue durée en actif réutilisable pendant des semaines. L’argument de Vercel — « un credential volé devrait se comporter comme une clé qui s’autodétruit » — n’est pas une posture marketing, c’est la conséquence directe de ces affaires.
Le trou dans le dogfooding
C’est ici que le récit se fissure. Le guide officiel de déploiement GitHub Actions de Vercel continue d’instruire l’authentification par un secret VERCEL_TOKEN — un token longue durée, précisément le type d’identifiant que la campagne veut éradiquer. Le développeur Yordis Prieto, ingénieur senior chez Fanatics, a résumé l’ironie : Vercel a « inventé » la fédération OIDC, mais son pipeline CI s’appuie encore sur un access token longue durée.
L’annonce du 22 octobre précise que Vercel « étend le support OIDC à travers l’API et la CLI » pour retirer les tokens longue durée des workflows de déploiement. Autrement dit : au moment du lancement, cette migration n’était pas terminée. L’authentification OIDC de GitHub pour le Container Registry, ajoutée fin septembre, ne retire pas non plus l’exigence VERCEL_TOKEN du flux GitHub Actions documenté.
Le décalage est d’autant plus visible que Vercel Connect admet toujours des clés API statiques pour les fournisseurs sans OAuth : la documentation décrit un stockage centralisé des secrets, tirés au runtime, mais dont la clé sous-jacente peut rester valide indéfiniment.
Comment vérifier votre propre exposition
La question pratique est vite posée : votre chaîne dépend-elle encore de secrets longue durée, et lesquels ? Trois vérifications suffisent pour un premier audit. D’abord, listez les secrets de votre CI/CD — tokens de déploiement, clés de registre, credentials de fournisseurs — et notez pour chacun s’il expire. Ensuite, vérifiez si vos intégrations Marketplace utilisent l’OIDC de Vercel ou une clé statique : c’est précisément le critère qui déclenchera le label « Not secure » le 30 novembre. Enfin, testez l’échange de token sur un service pilote, ne serait-ce que pour mesurer la latence ajoutée avant de généraliser.
Verdict
La direction est la bonne et le calendrier est ambitieux — peut-être trop. Si vous êtes un éditeur listé sur le Marketplace Vercel, vous avez environ cinq semaines pour implémenter l’OIDC ou afficher un label « Not secure », puis un délai supplémentaire avant déréférencement. Vérifiez dès maintenant si votre connecteur accepte l’OIDC de Vercel, ou planifiez l’échange de tokens temporaires plutôt qu’une clé persistante.
Si vous êtes client Vercel sur GitHub Actions, vous dépendez encore aujourd’hui d’un VERCEL_TOKEN : scopé-le au minimum, stocké-le dans les secrets du dépôt, tournez-le régulièrement, et surveillez la bascule OIDC promise pour votre workflow. La leçon transversale vaut pour toute plateforme : une campagne « zéro secret statique » ne devient crédible que le jour où son propre outillage n’a plus besoin du secret qu’elle demande aux autres d’abandonner.