La faille de Vercel et pourquoi nous ne jouons pas avec des secrets « non sensibles »
Vercel a été touché et le point pivot était un outil d'IA tiers. Voici pourquoi les protocoles de sécurité stricts de Sweent auraient assuré la sécurité de nos clients pendant que d'autres tournaient les clés en cas de panique.
Nous nous sommes réveillés en apprenant que Vercel avait été touché. Si vous êtes dans le monde du développement Web, c'est comme si vous appreniez que le coffre principal de la banque vient d'être sélectionné. Vercel n'est pas une entreprise amateur ; c'est l'épine dorsale de millions de sites, y compris l'écosystème Next.js. Mais même les géants peuvent trébucher lorsque la commodité commence à l'emporter sur la lutte contre la sécurité.
La faille n'a pas commencé par un impact direct sur les serveurs de Vercel. Tout a commencé avec un outil d'IA tiers appelé Context.ai. Un employé de Vercel l'a connecté à son Google Workspace via OAuth. Les attaquants ont accédé à Context.ai, ont connecté cette connexion OAuth au compte Google de l'employé, et à partir de là, ils ont obtenu une carte du royaume interne. Il s'agit d'un pivot classique de la chaîne d'approvisionnement, et il est compliqué.
Mais voici ce qui nous intéresse vraiment chez Sweent : les attaquants ont pu lire des variables d'environnement qui n'étaient pas marquées comme « sensibles ». Vercel dispose d'un système dans lequel les développeurs peuvent choisir si une variable est sensible ou non. Si vous ne cochez pas cette case, ces secrets sont stockés de manière à les rendre lisibles si un attaquant y pénètre. Chez Sweent, nous examinons ce choix de conception et nous y voyons un risque énorme et inutile. Nous ne pensons pas qu'il faille donner aux développeurs la possibilité d'être moins en sécurité pour des raisons de commodité.
L'erreur du secret « non sensible »
Dans le tableau de bord Vercel, il existe une distinction entre les variables d'environnement sensibles et non sensibles. L'idée est que certains éléments, comme une clé d'API publique ou une chaîne de configuration non critique, n'ont pas besoin du cryptage de haut niveau qu'un mot de passe de base de données nécessite. Mais en pratique ? Les développeurs sont occupés. Le code d'expédition sera envoyé à 2 heures du matin. Ils empruntent la voie de la moindre résistance. Si la valeur par défaut n'est pas « Sécurité maximale », des secrets seront divulgués. Ce n'est pas une question de savoir si, mais quand.
Nous avons vu cela se produire dans des dizaines de projets avant qu'ils ne nous soient confiés. Un développeur pense qu'un jeton spécifique présente un « faible risque », il ne se préoccupe donc pas de la couche de protection supplémentaire. Ensuite, une violation se produit et ce jeton « à faible risque » devient le point pivot d'une prise de contrôle complète du système.
Chez Sweent, notre protocole est simple : il n'existe pas de variable d'environnement non sensible. S'il s'agit d'une variable qui se trouve dans un fichier .env ou dans un pipeline CI/CD, elle est traitée comme un secret critique. Période. Nous ne proposons pas de bouton « pratique » qui laisse les touches en clair. En appliquant une politique stricte selon laquelle chaque variable est cryptée et restreinte, nous éliminons l'erreur humaine qui a conduit à l'exfiltration de données lors de l'incident de Vercel. Si un attaquant avait réussi à pénétrer dans l'un de nos environnements lors d'une faille similaire, il aurait découvert un mur de données cryptées qu'il ne pourrait pas lire, au lieu d'une liste de clés « non sensibles » qu'il pourrait utiliser pour intensifier son attaque.
Combattre les attaquants accélérés par l'IA grâce à un protocole
Le PDG de Vercel a indiqué que les attaquants se déplaçaient à une « vitesse surprenante » et avaient probablement été accélérés par l'IA. C'est la nouvelle réalité. Nous ne nous contentons plus de nous défendre contre un homme en sweat à capuche qui saisit manuellement des commandes. Nous nous défendons contre les agents automatisés capables d'analyser l'architecture d'un système, d'identifier les vulnérabilités et d'exécuter un exploit en quelques secondes.
Lorsque l'adversaire se déplace à la vitesse d'une machine, votre défense ne peut pas compter sur le fait qu'un humain choisisse la case à cocher sur laquelle vous souhaitez cliquer. Il doit être intégré à l'infrastructure. C'est pourquoi nous avons conçu nos flux de travail internes en partant du principe qu'une violation est toujours possible. Nous ne nous contentons pas de surveiller les intrusions ; nous réduisons la surface d'attaque afin que l'IA ne puisse rien trouver une fois qu'elle a franchi la porte.
L'un des principaux problèmes liés à la violation de Vercel était la connexion OAuth. OAuth est incroyablement utile, mais il s'agit d'une faille de sécurité massive s'il n'est pas géré avec une discipline extrême. Vous cliquez sur un bouton pour essayer un nouvel outil de productivité basé sur l'IA, et tout à coup, cet outil dispose d'un accès en lecture à l'intégralité de votre espace de travail Google. Si cet outil est piraté, comme l'a fait Context.ai, l'ensemble de votre organisation est exposée.
Notre équipe de Sweent applique une politique de confiance zéro pour les intégrations tierces. Nous ne laissons pas de « nouveaux outils » se connecter à nos systèmes principaux sans un audit de sécurité complet. Et même dans ce cas, nous limitons les champs d'application au strict minimum. Si un outil n'a besoin de lire qu'un seul calendrier, il n'a pas accès à l'ensemble de l'espace de travail. Cela semble demander beaucoup de travail, et ça l'est. Mais c'est la différence entre un incident mineur et une demande de rançon de 2 millions de dollars de la part d'un groupe comme ShinyHunters.
La règle de rotation secrète sur 24 heures
Même avec les meilleures défenses, les choses peuvent mal tourner. La caractéristique d'une équipe professionnelle ne réside pas seulement dans la façon dont elle prévient une violation, mais aussi dans la façon dont elle réagit à une telle violation. Vercel a recommandé à ses clients de procéder immédiatement à une rotation de leurs informations d'identification. Mais « immédiatement » est un terme vague dans le monde de l'entreprise. Pour certaines entreprises, cela signifie la semaine prochaine. Pour d'autres, cela signifie après un long week-end.
Chez Sweent, nous avons une règle stricte : en cas de suspicion de compromission, chaque secret, clé API et chaîne de base de données fait l'objet d'une rotation dans les 24 heures. Nous n'attendons pas une autopsie complète. Nous n'attendons pas de voir si les données ont été « réellement » exfiltrées. Nous nous déplaçons plus vite que l'attaquant.
Au moment où un attaquant réalise qu'il possède une clé, celle-ci est déjà morte. Nous utilisons des scripts automatisés et une infrastructure en tant que code pour gérer cela. Si nous avions utilisé Vercel pendant cette brèche, les clés de nos clients auraient été recyclées et sécurisées avant même que la nouvelle ne soit publiée sur les principaux blogs technologiques. La vitesse est le seul moyen de défense contre un attaquant qui se déplace avec une vélocité pilotée par l'IA.
La sécurité de la chaîne d'approvisionnement et la règle des 7 jours
La faille de Vercel a également suscité des inquiétudes concernant la chaîne d'approvisionnement du NPM. Vercel étant propriétaire de Next.js, un attaquant disposant des bons jetons pourrait potentiellement envoyer une version « empoisonnée » à des millions de développeurs. C'est l'option nucléaire de la cyberguerre. Si vous mettez à jour aveuglément vos dépendances à chaque fois qu'une nouvelle version sort, vous jouez à la roulette russe avec votre base de code.
Nous protégeons nos clients en mettant en place un délai obligatoire pour toutes les mises à jour de dépendances non critiques. Nous attendons généralement au moins 7 jours avant de télécharger les nouvelles versions des principales bibliothèques. Pourquoi ? Parce que la plupart des attaques de la chaîne d'approvisionnement sont identifiées et neutralisées au cours de la première semaine. En n'étant pas les « premiers utilisateurs » de tous les correctifs mineurs, nous veillons à ce que nos clients ne soient pas les premiers touchés lorsqu'un package est piraté.
Il se peut que nous ayons l'impression d'être trop prudents, mais considérez l'alternative. ShinyHunters vendrait la base de données interne de Vercel pour 2 millions de dollars. Ils disposent de 580 dossiers d'employés, de tableaux de bord internes et d'un code source. Il s'agit d'un échec catastrophique qui aurait pu être atténué par des protocoles internes plus stricts et une approche moins « pratique » de la gestion des secrets.
Pourquoi nous ne sautons pas les parties « difficiles »
La sécurité est souvent perçue comme un point de friction. Elle ralentit le développement. Il est donc plus difficile d'essayer de nouveaux outils. Elle ajoute des étapes au processus de déploiement. Et c'est exactement pourquoi tant de startups ignorent les étapes les plus difficiles. Ils veulent aller vite et faire bouger les choses. Mais lorsque vous brisez la confiance de vos clients, vous n'aurez peut-être pas l'occasion de la réparer.
Nous avons fondé Sweent sur l'idée que la transformation numérique ne devait pas se faire au détriment de la sécurité. Nous gérons les frictions pour que nos clients n'aient pas à le faire. C'est nous qui effectuons les audits de sécurité des outils d'IA. C'est nous qui appliquons le chiffrement obligatoire à chaque variable d'environnement. C'est nous qui faisons la rotation des clés dans les 24 heures, alors que le reste de l'industrie continue de lire les gros titres.
Si vous êtes sur Vercel en ce moment, vous devriez probablement consulter votre tableau de bord. Auditez chaque variable. Marquez-les tous comme sensibles. Séparez toutes les connexions OAuth dont vous n'avez pas absolument besoin. Mais si vous ne voulez plus vous inquiéter de savoir si vos développeurs ont coché la bonne case à 2 h du matin, vous avez besoin d'un partenaire qui ne considère pas la sécurité comme une fonctionnalité optionnelle.
À la fin de la journée, Vercel s'en remettra probablement. Ils ont des ingénieurs d'élite et beaucoup de capital. Mais pour une petite entreprise, une telle violation est une condamnation à mort. N'attendez pas le prochain gros titre pour réaliser que vos variables « non sensibles » constituent un handicap. Les attaquants se déplacent à la vitesse de la machine. L'êtes-vous ?
Questions fréquemment posées
Les assaillants ne se sont pas attaqués directement à Vercel. Ils ont piraté Context.ai, un outil d'IA tiers qu'un employé de Vercel avait connecté à son espace de travail Google via OAuth. À partir de cette autorisation OAuth, les attaquants ont accédé au compte Google de l'employé et ont obtenu une carte des systèmes internes de Vercel. Il s'agit d'un pivot classique de la chaîne d'approvisionnement : votre sécurité dépend de l'intégration la moins auditée sur laquelle un membre de l'équipe a cliqué sur « Autoriser ».
Permettre aux développeurs de basculer entre les secrets « chiffrés » et les secrets « lisibles » est un choix de conception qui mise sur le fait que chaque développeur choisira à chaque fois l'option sécurisée à 2 heures du matin sous la pression de la livraison. Ils ne le font pas. La faille de Vercel l'a confirmé : les attaquants sont sortis avec des valeurs techniquement marquées « non sensibles », mais qui se sont révélées très sensibles lorsqu'elles étaient combinées à d'autres résultats. Notre politique : il n'existe pas de secret non sensible : tout ce qui se trouve dans un pipeline .env ou CI/CD est chiffré de la même manière, sans bascule.
Chaque touche tourne dans les 24 heures, point final. Nous n'attendons pas une autopsie pour confirmer si les données ont bien été exfiltrées. Au moment où tout sera clair, l'attaquant aura déjà utilisé ce qu'il a volé. L'infrastructure en tant que code et les scripts de rotation automatisés rendent cela mécanique et non héroïque. Au moment où un attaquant réalise qu'il possède une clé, celle-ci est déjà morte.
La plupart des attaques de la chaîne d'approvisionnement dans l'écosystème npm sont détectées et neutralisées au cours de la première semaine suivant une publication malveillante, car d'autres équipes chargées de gérer plus étroitement le problème détectent le problème et le registre extrait le package. En attendant 7 jours avant de télécharger de nouvelles versions majeures, nos clients ne sont pas les premiers touchés lorsqu'un package populaire est piraté. Cela entraîne un léger retard ; cela permet d'éviter complètement une classe d'attaques.
Traitez chaque autorisation OAuth comme un trou permanent dans votre périmètre jusqu'à preuve du contraire. Exécutez un audit de sécurité sur l'outil avant de le connecter. Limitez les champs d'application au strict minimum : si un outil n'a besoin que d'un seul calendrier, il n'accède pas à l'ensemble de l'espace de travail. Passez en revue les subventions actives tous les trimestres et supprimez celles dont l'utilisation n'est pas démontrable. La commodité de l'intégration en un seul clic est la façon dont Context.ai est devenu le pivot de Vercel ; appliquez délibérément des frictions là où cela vous coûte le moins cher et vous permet de réaliser le plus d'économies.