Vibe coding et cybersécurité ne progressent pas au même rythme

Les outils de codage vibratoire alimentés par l’IA génèrent souvent du code non sécurisé

L’IA prend en charge une part croissante du travail de développement, et c’est une bonne chose. La génération de code à grande vitesse permet de gagner du temps, d’automatiser la logique de routine et de rapprocher la livraison des logiciels du temps réel. Mais nous constatons également que ces outils ne sont pas à la hauteur. La sécurité ne suit pas. Des outils tels que Claude Code, OpenAI Codex, Cursor, Replit et Devin, tous testés par la startup de cybersécurité Tenzai, génèrent des vulnérabilités dans les applications finies. Il ne s’agit pas seulement de bogues mineurs. Sur les 69 failles de sécurité identifiées dans 15 applications créées à l’aide de la technologie vibe codingla moitié d’entre elles étaient graves et une demi-douzaine d’entre elles étaient critiques.

Il est important de bien comprendre ce que cela signifie. Des choses comme l’injection SQL ou le cross-site scripting, des menaces de la vieille école, ne sont pas apparues. C’est une victoire. En revanche, les problèmes liés au contexte, tels que la faiblesse des autorisations API ou une logique commerciale défectueuse, sont apparus à plusieurs reprises. Il s’agit de failles graves. Elles permettent un accès involontaire à des systèmes sensibles ou à des actions que les utilisateurs ne devraient pas être en mesure d’effectuer. Il s’agit là d’une violation de données en attente de se produire.

L’implication est claire : nous ne pouvons pas supposer que ces outils construiront des systèmes sûrs simplement parce qu’ils génèrent un code fonctionnel. Ils ne sont pas encore conçus pour prendre des décisions nuancées. Vous avez toujours besoin d’une supervision expérimentée et d’un processus de développement qui comprend un véritable audit et un examen de la sécurité. L’automatisation est utile, mais elle n’est pas à l’abri de la complexité. En particulier le type de complexité où la « sécurité » dépend de la compréhension du contexte du flux de travail, des rôles des utilisateurs et des règles dynamiques. C’est là que le raisonnement humain a encore une longueur d’avance.

Les chercheurs de Tenzai ont été clairs à ce sujet. Ce n’est pas parce que les outils modernes évitent les anciens exploits qu’ils comprennent comment les systèmes fonctionnent réellement dans le monde réel. S’ils ont raté leur coup, ce n’est pas parce qu’ils ont été négligents, mais parce qu’ils sont agnostiques à l’égard de l’intention. Ils ne se posent pas la question suivante : cette action devrait-elle être possible ? Si votre entreprise fonctionne à l’aide de logiciels, et c’est le cas aujourd’hui de presque toutes les entreprises sérieuses, vous ne devez pas vous fier à un code qui ne tient pas compte de ces questions.

Le manque de compréhension du contexte entraîne des vulnérabilités au niveau de la logique d’entreprise et de l’API.

Qu’est-ce qui différencie les résultats d’une IA immature d’un code de qualité humaine ? Le contexte. Les agents d’IA suivent bien les instructions. Mais ce n’est pas la même chose que de comprendre ce qui est juste dans une situation donnée. Les conclusions de Tenzai ont mis en évidence cette lacune. Les outils de codage de l’IA ont toujours eu des difficultés avec la logique commerciale et l’autorisation des API, ce qui s’explique par le fait qu’ils ne comprennent pas les flux de travail du monde réel comme le font les ingénieurs expérimentés.

Prenez l’autorisation de l’API. C’est là que les systèmes déterminent qui est autorisé à faire quoi. Il ne suffit pas de vérifier l’existence d’un indicateur de permission, il faut aussi interpréter si une action donnée, dans un scénario spécifique, a un sens. Les défaillances de la logique d’entreprise suivent le même schéma. Les outils ont permis des actions qui auraient dû être restreintes. L’IA ne les a pas signalées parce qu’elle ne pense pas en termes d’impact organisationnel. Elle peut suivre des ordres, mais sans contexte, elle ne peut pas distinguer une fonction voulue d’un exploit potentiel.

Cette limitation n’est pas un bogue. Il s’agit d’un problème d’hypothèses de conception. Les générateurs de code de l’IA s’appuient sur des messages explicites. Les développeurs humains s’appuient sur leur expérience, leur parti pris pour la sécurité et leur perception intuitive du comportement des utilisateurs. C’est ce qui fait la différence. Si nous voulons que l’IA écrive un meilleur code, elle doit s’intégrer plus profondément dans le modèle de raisonnement qui sous-tend les applications, elle doit aller au-delà de la syntaxe et commencer à saisir l’intention.

Bien sûr, c’est plus facile à dire qu’à faire. Il est même difficile de se prémunir contre des failles sophistiquées telles que la falsification des requêtes côté serveur (SSRF) à l’aide de règles générales. Tenzai l’a clairement souligné : déterminer si une opération de récupération par le serveur est sûre ou non dépend entièrement de l’endroit où elle est dirigée, de ce qu’elle fait ensuite et de la question de savoir si elle était censée se produire. Il s’agit là de jugements, et non de simples applications de règles.

Pour les dirigeants qui s’appuient sur l’IA et l’automatisation, cela vaut la peine d’être intériorisé. Un code qui semble propre mais qui enfreint les règles logiques sous-jacentes n’est pas sûr, il est fragile. La rapidité de livraison n’a pas d’importance si vous ouvrez des portes qui ne devraient pas exister. Vous avez besoin de systèmes capables de raisonner, ou au moins de contrôles permettant de valider si le raisonnement a été effectué. Jusqu’à ce que l’IA s’en rende compte, votre meilleure défense est la validation humaine intégrée à chaque couche. Pas après le déploiement, mais pendant la création.

La supervision humaine reste essentielle pour sécuriser le code généré par l’IA

L’automatisation permet de gérer l’échelle. Mais la sécurité ne se limite pas à la quantité que vous pouvez produire, elle concerne aussi ce qui passe inaperçu. Le code généré par l’IA est rapide et cohérent, mais il passe à côté de choses que l’expérience humaine peut encore déceler. C’est là que la surveillance est importante. Elle n’est pas facultative. Le code doit être soumis à des processus d’examen sécurisés qui incluent la modélisation des menaces, l’analyse statique et dynamique et la validation en temps réel par rapport aux vulnérabilités connues. Si quelque chose se brise à l’intérieur de la logique, le résultat devient un handicap, et non un avantage.

Les recherches menées par Tenzai montrent que l’IA peut fournir une bonne structure et éviter les défauts prévisibles. C’est un progrès. Mais dans les applications réelles, les comportements imprévus, comme l’octroi d’un accès par une logique d’autorisation mal alignée, ne peuvent pas toujours être détectés par la seule analyse des résultats. Il faut une attention humaine et un examen structuré pour valider ce que l’IA ne comprend pas entièrement. Il ne s’agit pas de cas marginaux. Il s’agit de problèmes récurrents ayant des conséquences directes sur l’intégrité du système.

Matthew Robbins, responsable de la sécurité offensive chez Talion, a présenté une solution claire. Il a conseillé aux entreprises d’assurer l’examen du code sécurisé soit intégré à chaque étape du cycle de vie du développement de logiciels sécurisés. Il existe des cadres standard pour cela : les Secure Coding Practices de l’OWASP fonctionnent avec n’importe quel langage, et les normes SEI CERT vont plus loin lorsque des conseils spécifiques à un langage sont nécessaires. Les entreprises qui ignorent ces pratiques augmentent leur rayon d’action, même si ce n’est pas intentionnel.

Une mauvaise logique de sécurité n’est pas seulement coûteuse en termes de réputation, elle peut aussi être source d’exposition juridique et réglementaire. Pour tout dirigeant de la C-suite qui gère des initiatives technologiques, la supervision doit être allouée comme tout autre intrant stratégique : délibérément et structurellement. Faire confiance aux outils d’IA sans contrôles rigoureux revient à supposer un niveau d’interprétation qui n’existe tout simplement pas dans les agents de codage d’aujourd’hui. Les gains de productivité doivent être réels, et non sapés par des désastres post-déploiement.

Les méthodes de débogage traditionnelles sont inadaptées au développement rapide de l’IA

Le débogage traditionnel dépend de l’examen du code une fois qu’il existe. Avec le codage vibratoire, ce délai s’aplatit. Le volume et la vitesse de production dépassent ce que de nombreuses équipes peuvent inspecter avec les processus traditionnels. Et le risque est simple : ce n’est pas parce qu’une faille apparaît tardivement qu’elle a commencé tardivement. La plupart des vulnérabilités logiques sont déjà en place au moment où le code est généré. C’est cet écart, entre la création et la détection, qui constitue le véritable problème.

Eran Kinsbruner, vice-président du marketing produit chez Checkmarx, a soulevé un point direct : il n’est pas réaliste de supposer que les humains peuvent déboguer à grande échelle le code généré par l’IA. Il ne s’agit pas seulement de travailler plus dur. Il s’agit de changer notre façon d’aborder la validation. La sécurité doit être transférée au moment de la génération, elle doit être intégrée dans l’environnement de codage lui-même. Non pas parce que les développeurs n’en sont pas capables, mais parce que la vitesse de l’IA l’exige.

Il ne s’agit pas de spéculation. C’est opérationnel. Les vulnérabilités qui apparaissent à cause de chemins logiques incorrects, d’appels externes non sécurisés ou de permissions inappropriées sont souvent introduites au cours de la première itération. Le débogage a posteriori mobilise les ressources et ralentit l’élan. La seule réponse pratique est la sécurité en temps réel : des contrôles automatisés qui s’exécutent aux côtés d’agents d’intelligence artificielle et qui comprennent non seulement ce que fait le code, mais aussi s’il devrait le faire en premier lieu.

Pour les dirigeants qui lancent des pipelines de développement soutenus par l’IA, cela signifie qu’il faut planifier la sécurité agentique dès le départ. Intégrez-la directement dans les plateformes utilisées, ne comptez pas sur des outils complémentaires en aval. La conformité, le risque en aval et l’intégrité de votre cycle de publication dépendent tous de la détection des problèmes avant qu’ils n’évoluent. Et cela n’arrivera pas si votre stratégie de sécurité est toujours basée sur l’examen des choses après qu’elles se soient brisées.

Opportunité de marché pour les solutions complètes de validation des codes d’IA

L’écart a été identifié et il est important. Les générateurs de code pilotés par l’IA produisent du code à grande échelle, mais aucun système complet n’est en place pour valider les risques de sécurité en temps réel. Ce décalage présente une opportunité immédiate. Les entreprises qui se lancent dans des environnements de développement axés sur l’IA ont besoin de plus que de la vitesse, elles ont besoin d’une clarté intégrée sur ce qui rend le code sûr. À l’heure actuelle, aucune plateforme n’offre cette possibilité dans son intégralité. Tenzai, une startup spécialisée dans la cybersécurité, a été claire : les outils de codage vibratoire existants sont incomplets sans les agents de sécurité correspondants formés pour comprendre le contexte, la logique et les abus.

Il ne s’agit pas seulement de réparer quelque chose de cassé, mais aussi de fermer une boucle de risque. Les technologies de codage vibratoire sont adoptées sans outils de validation également développés, ce qui crée un déséquilibre entre la génération et l’inspection. Les outils qui se contentent d’analyser le code après sa création ou de signaler les problèmes connus ne couvrent pas les risques plus profonds, tels qu’une logique commerciale défectueuse ou une logique d’autorisation dangereuse, qui sont liés au comportement et non à la syntaxe. C’est à ce niveau que les entreprises ont besoin d’une solution, et c’est là que les fournisseurs qui agissent rapidement peuvent définir une nouvelle catégorie de produits.

Tenzai pense avoir trouvé cette opportunité. Ils se concentrent sur le développement d' »agents de vérification du code vibratoire » – des outils conçus spécifiquement pour évaluer les logiciels générés par l’IA à la même vitesse et à la même échelle qu’ils sont écrits. Ils ont clairement indiqué qu’aucune solution actuelle ne résume efficacement le problème, en particulier lorsque la frontière entre sécurité et vulnérabilité dépend entièrement du contexte du cas d’utilisation. Cet espace est ouvert et exploitable.

Pour les dirigeants de la suite C qui naviguent dans l’adoption de l’IA, c’est là que l’innovation rencontre le contrôle. Intégrer une validation en temps réel et contextuelle dans chaque création générée par l’IA n’est pas seulement une question d’avenir, c’est une nécessité opérationnelle. En investissant très tôt dans des plateformes capables de fournir ce niveau, ou en s’associant avec des fournisseurs qui développent ces capacités, les entreprises se positionnent en amont du risque. Celles qui attendent devront rattraper leur retard, avec une marge d’erreur réduite et une surveillance accrue de la part des parties prenantes.

La sécurité n’est pas un goulot d’étranglement à ce stade. C’est une couche qui attend d’être optimisée grâce à de nouveaux outils, de meilleurs modèles et une conception plus intelligente. Plus le développement s’accélère, plus cela compte.

Principaux enseignements pour les dirigeants

• Le code généré par l’IA manque de jugement contextuel : Les outils de codage vibratoire passent souvent à côté de vulnérabilités critiques dans la logique d’entreprise et le contrôle d’accès à l’API, des décisions qui nécessitent une compréhension nuancée au-delà des résultats fonctionnels. Les dirigeants devraient imposer des examens de sécurité adaptés à la logique et à la conception des autorisations.
• La cécité du contexte crée des lacunes exploitables : Sans la capacité d’interpréter l’intention du monde réel, les outils d’IA permettent souvent des actions inappropriées de la part des utilisateurs. Les dirigeants devraient donner la priorité à la validation humaine dans la boucle pour toute application impliquant des rôles, des flux de travail ou des opérations sensibles.
• La supervision humaine reste essentielle : Même les outils d’IA les plus performants ont besoin d’une supervision structurée pour détecter les failles que l’IA ne peut pas résoudre. Les dirigeants devraient intégrer des examens de code sécurisés, en utilisant des normes reconnues, dans les pipelines de développement, indépendamment de l’automatisation.
• Le débogage traditionnel n’est pas adapté à la vitesse de l’IA : Les vérifications du code après développement sont trop lentes et superficielles pour une production d’IA à grande vitesse. Pour garder une longueur d’avance, les entreprises doivent déplacer la sécurité vers la gauche, en intégrant l’analyse en temps réel dans l’environnement de codage de l’IA lui-même.
• Les lacunes du marché sont le signe d’une opportunité pour les outils de conception sécurisée : Malgré l’adoption généralisée de l’IA, il n’existe actuellement aucune solution mature pour valider à grande échelle le code généré par l’IA. Les décideurs devraient considérer cette lacune à la fois comme un risque à prendre en compte et comme un domaine potentiel d’investissement stratégique ou de partenariat.