Les applications issues du vibe coding sont la nouvelle informatique fantôme

L'informatique fantôme était autrefois un problème de SaaS. Quelqu'un de l'équipe marketing s'inscrivait à un outil, le connectait à Google Workspace, et votre premier signal était une autorisation OAuth que vous n'aviez pas validée. Agaçant. Détectable. Maîtrisable.

La nouvelle informatique fantôme n'apparaît pas dans vos logs OAuth. Elle apparaît sous forme d'infrastructure, tournant dans votre compte cloud, construite par un ingénieur bien intentionné qui a demandé à un agent IA de la monter en un après-midi. Pas de ticket, pas de revue, pas d'implication de l'équipe sécurité. Juste quelqu'un avec une bonne idée et un outil qui a supprimé toute la friction qui aurait autrefois ralenti la démarche.

Cette friction n'était pas que de l'inefficacité. Une partie de celle-ci accomplissait un vrai travail de sécurité.

Le problème avec les bonnes intentions

L'informatique fantôme classique avait un parfum de contournement délibéré de l'IT. Une équipe qui ne voulait pas attendre les achats. L'enjeu sécurité tournait au moins en partie autour de l'application des politiques.

Ce n'est pas de cela qu'il s'agit ici.

L'ingénieur qui code en mode vibe un outil interne pour son équipe n'essaie de contourner rien du tout, il essaie d'aider. Il a accès à un agent IA capable d'écrire du code, de générer du Pulumi, et de monter de l'infrastructure plus vite qu'aucun processus de revue n'a été conçu pour le gérer. Et sauf s'il a déjà passé du temps à réfléchir à la sécurité cloud, rien ne lui indique que ce qu'il vient de mettre en production pose un problème.

C'est ce qui rend la situation plus difficile : on ne peut pas s'en sortir par la contrainte, il faut prendre les devants rapidement.

Voici à quoi ressemble le mauvais jour : un ingénieur construit une application interne légère pour automatiser une tâche que son équipe fait manuellement. Il demande à l'agent IA de gérer l'infrastructure. L'agent provisionne des ressources dans le compte AWS de l'équipe, ouvre les ports nécessaires, et déploie l'application. Ça fonctionne, et l'équipe adore. Personne ne dépose de ticket, car il n'y a rien à déposer. Six semaines plus tard, votre CSPM signale un point de terminaison exposé publiquement, avec un rôle IAM trop permissif attaché. À ce moment-là, l'application tourne en production depuis assez longtemps pour qu'un mouvement latéral soit un scénario réaliste, pas théorique.

L'intention était bonne. Le résultat a un rayon d'impact.

Pourquoi c'est différent de la prolifération SaaS

Quand l'informatique fantôme signifiait du SaaS non autorisé, votre surface de détection était bien définie. Autorisations OAuth, trafic réseau, notes de frais, anomalies SSO. L'outil existait hors de votre infrastructure. Il était externe. Vous pouviez le trouver, le couper, et les dégâts étaient généralement limités.

L'outillage interne construit par des agents vit à l'intérieur de votre infrastructure. Il a des rôles IAM. Il peut avoir un accès direct aux données de production, aux API internes ou à des systèmes sensibles. Il paraît légitime, car il a été construit par un employé légitime utilisant un outillage légitime. Il n'y a pas de coupure évidente où détecter quoi que ce soit. Le code ne s'annonce pas comme non gouverné. Il tourne, tout simplement.

C'est le glissement qu'il vaut la peine de nommer clairement : nous sommes passés de la prolifération SaaS à la prolifération de code. Le playbook de détection de l'un ne se transpose pas à l'autre.

Une baseline qu'on utilise réellement

L'objectif ici n'est pas de ralentir les ingénieurs. C'est de faire du chemin sûr le chemin facile. La baseline vers laquelle nous travaillons chez Webflow comporte deux couches, et cette distinction compte.

Les contrôles de plateforme sont des éléments que vous configurez une fois au niveau de l'organisation ou du compte, et qui rendent structurellement plus difficile de faire accidentellement la mauvaise chose.

Garde-fous IAM du moindre privilège. Les permissions disponibles pour les comptes AWS au niveau de l'équipe devraient être restreintes par défaut. Un ingénieur ne devrait pas pouvoir provisionner une ressource exposée publiquement avec un rôle largement permissif sans se heurter à un garde-fou. Le garde-fou n'arrête pas le travail. Il empêche la pire version du travail de partir en production silencieusement.

Application obligatoire d'un gestionnaire de secrets. Des identifiants codés en dur dans des applications issues du vibe coding ne sont pas une hypothèse. C'est une quasi-certitude si vous ne rendez pas le bon chemin évident. Imposer l'utilisation d'un gestionnaire de secrets au niveau de l'infrastructure retire entièrement cette décision à l'ingénieur individuel.

Cibles de déploiement protégées par VPN. L'outillage interne devrait atterrir par défaut derrière votre VPN d'entreprise. Si quelque chose doit réellement être exposé publiquement, cela devrait exiger une décision explicite, pas un défaut accidentel.

Les contrôles de processus sont ce qui doit se produire au niveau de l'outil avant que quoi que ce soit ne parte en production.

Vérification automatisée de la baseline. Avant qu'une personne avertie en sécurité ne regarde quoi que ce soit, exécutez automatiquement le code et la configuration d'infrastructure face à votre baseline. Signalez les violations, classez-les par gravité, et donnez à l'ingénieur des indications précises de correction. C'est la couche qu'un skill Claude ou un outillage similaire peut prendre en charge. La revue humaine se concentre alors sur ce que la vérification automatisée a fait ressortir, plutôt que de repartir de zéro.

Revue de code éclairée par la sécurité, avec escalade vers l'équipe sécurité. Tout outil construit en interne qui touche à l'infrastructure de production a besoin qu'une personne dotée d'un contexte sécurité le regarde avant sa mise en production. Pour un outillage à moindre risque, il s'agit d'un ingénieur pair qui comprend le rayon d'impact de ce qu'il examine. Pour tout ce qui touche à l'infrastructure cloud, à un accès direct aux données, ou à des rôles IAM inédits, cela escalade vers une revue formelle de l'équipe sécurité. Le même contrôle, mais échelonné selon le risque. Le point clé : la personne qui relit doit réellement comprendre le code. Avec les outils issus du vibe coding, l'auteur lui-même peut ne pas pleinement comprendre ce qu'il a construit. Cela rend la revue plus importante, pas plus formelle. Ce n'est pas seulement un contrôle qualité. C'est un contrôle de compréhension.

Le filet de sécurité

La baseline est préventive. La détection rattrape ce qui passe entre les mailles du filet.

Votre CSPM est le bon outil pour trouver les mauvaises configurations dans ce qui existe déjà. Wiz et les outils du même genre feront apparaître le point de terminaison exposé publiquement, le rôle trop permissif, le bucket de stockage sans contrôles d'accès appropriés.

Mais le CSPM ne trouve que ce qui est déjà déployé. La baseline et le processus de revue sont ce sur quoi vous comptez pour empêcher cela. La détection est la couche de rattrapage, pas la première ligne.

Le problème de détection le plus difficile est de savoir qu'une chose existe, tout simplement. Un outil issu du vibe coding tournant localement ou dans un compte d'équipe peut ne laisser aucune trace dans votre couche de visibilité habituelle. Pas de pipeline de déploiement. Pas de ticket de changement. Pas d'entrée dans l'inventaire des actifs.

C'est là que les signaux comportementaux dans votre télémétrie cloud commencent à compter. Création de rôles IAM en dehors de votre activité de pipeline habituelle. Apparition de nouvelles ressources exposées publiquement sans enregistrement de changement correspondant. Appels d'API provenant directement des machines de développement vers des comptes de production, plutôt que via votre outillage standard. Aucun de ces signaux n'est probant à lui seul. Combinés, ils commencent à ressembler à quelque chose qui mérite un examen plus approfondi.

La plupart des équipes ne recherchent pas ces signaux spécifiquement dans le contexte de l'outillage construit par des agents. C'est l'écart qui vaut la peine d'être comblé.

La baseline codifiée

Une documentation qui vit dans un wiki est une baseline que personne n'utilise au moment où on en a besoin. La meilleure approche consiste à rendre la baseline disponible directement dans les outils que les ingénieurs utilisent déjà, au moment même où ils construisent.

Un skill Claude ou un outillage nativement IA équivalent, qui vérifie les descriptions d'architecture ou l'infrastructure générée face à votre baseline de sécurité spécifique, est plus utile qu'une checklist dans Confluence. L'ingénieur obtient un retour précis et exploitable avant même qu'un relecteur humain ne le voie. L'équipe sécurité reçoit un premier passage déjà filtré des échecs évidents. La revue est meilleure parce qu'elle part d'une image plus complète.

Rien de tout cela ne fonctionne si les ingénieurs ne savent pas que le skill ou le processus de revue existe. La prise de conscience est elle-même une couche de prévention. Introduire les deux dès l'intégration rend le chemin sûr visible, et faire en sorte que le retour du skill serve aussi à expliquer pourquoi chaque vérification compte est ce qui fait que cela reste ancré. Un garde-fou qui ne s'annonce pas n'est pas préventif.

C'est là que nous nous dirigeons en interne. Cet article de blog est l'argument expliquant pourquoi cela compte. Le skill est ce qui l'opérationnalise.

Ce qu'il faut retenir

Les outils internes issus du vibe coding ne vont pas disparaître. La friction qui ralentissait autrefois l'infrastructure non gouvernée a disparu, et elle ne reviendra pas. La question est de savoir si votre baseline de sécurité rattrape le retard avant que votre CSPM ne le fasse.

Les contrôles de plateforme font du chemin sûr le défaut. Les contrôles de processus garantissent qu'une personne dotée d'un contexte sécurité voit tout avant la mise en production. La détection vous donne une couche de rattrapage pour ce qui passe malgré tout entre les mailles du filet.

Rien de tout cela ne nécessite une équipe AppSec dédiée ou un SOC. Cela nécessite une baseline claire, l'outillage pour l'appliquer, et des ingénieurs qui comprennent ce qu'ils examinent. C'est un problème qu'une petite équipe sécurité bien structurée peut résoudre. Les contrôles de plateforme sont détenus au niveau de l'organisation ou de l'ingénierie sécurité, définis une fois et appliqués partout. Les contrôles de processus sont distribués : un ingénieur pair doté d'un contexte sécurité gère l'outillage à moindre risque, tandis que tout ce qui touche à l'infrastructure cloud, à un accès direct aux données, ou à de l'IAM inédit, escalade vers une revue formelle de l'équipe sécurité. C'est une responsabilité distribuée avec un chemin d'escalade clair, pas une seule équipe qui examine tout.

Construisez la baseline avant que votre CSPM ne la trouve pour vous.