Sécurité du vibe coding : les risques que vous livrez avec, et comment les attraper

Qu'est-ce que le vibe coding ?

Le vibe coding consiste à construire des logiciels en promptant un agent IA en langage naturel au lieu d'écrire le code vous-même. Vous décrivez le résultat (« ajoute un point de terminaison de paiement qui débite la carte enregistrée »), l'agent génère et modifie les fichiers, et vous itérez en promptant à nouveau. Le basculement, c'est que l'auteur du code est désormais le modèle, et l'humain est le relecteur d'une sortie qu'il ne peut souvent pas lire entièrement.

Le terme s'est répandu début 2025 pour décrire un workflow où un développeur, ou de plus en plus un non-développeur, s'appuie sur l'agent et accepte ce qu'il produit tant que le résultat se comporte bien. Des outils comme Claude Code, Cursor, Windsurf, OpenAI Codex et GitHub Copilot l'ont rendu pratique : ils indexent un dépôt, modifient à travers l'arborescence, exécutent des commandes, et produisent des fonctionnalités fonctionnelles à partir d'un paragraphe d'intention. C'est véritablement puissant. C'est aussi là que s'ouvre l'écart de sécurité, parce que la vitesse qui rend le vibe coding attrayant est la même vitesse qui enfouit les failles.

Le vibe coding est-il sûr ?

Le vibe coding est sûr pour les choses pour lesquelles le logiciel a toujours été sûr par accident, et non sûr précisément pour les choses qui exigent un jugement qu'un prompt ne porte pas. L'agent produit de façon fiable du code qui compile et passe le chemin nominal. Il ne produit pas de façon fiable du code qui résiste à un attaquant, parce que la sécurité est une absence (d'une vérification manquante, d'une entrée non échappée) qu'un prompt « fais que ça marche » ne demande jamais.

La réponse honnête est que le vibe coding est aussi sûr que les contrôles autour de lui, et la plupart des configurations de vibe coding n'en ont aucun qui agit avant que le code n'atterrisse. Le modèle a appris d'un corpus public plein de motifs non sécurisés, donc il les reproduit à la vitesse machine. Les tests indépendants atterrissent sans cesse au même endroit : une large part du code généré par IA échoue aux tests de sécurité même quand il est fonctionnellement correct, et l'écart entre « marche » et « sûr » est l'endroit où vit la brèche.

40%

du code généré par IA était vulnérable à travers les scénarios de sécurité du Top 25 de MITRE (NYU, Asleep at the Keyboard)

10.5%

des solutions d'agents de code IA étaient sécurisées, contre 61 % fonctionnellement correctes (Carnegie Mellon SusVibes)

#1

l'injection de prompt, premier risque LLM pour la 3e année consécutive (OWASP LLM01)

L'enseignement n'est pas « ne faites pas de vibe coding ». C'est que le code à l'air fonctionnel est précisément le genre qu'un relecteur pressé laisse passer, et que plus de 80 % des solutions IA fonctionnellement correctes du benchmark SusVibes de Carnegie Mellon portaient encore une vulnérabilité. La vitesse sans point de contrôle de sécurité, c'est ainsi que vous livrez la faille et la fonctionnalité dans le même commit.

Quels sont les risques de sécurité du vibe coding ?

Les risques ne sont pas de nouveaux types de vulnérabilités. Ce sont les incontournables du Top 10 OWASP, reproduits plus vite que la revue ne peut suivre, parce que le modèle écrit le motif courant et que le motif courant est souvent le motif non sécurisé. Voici les classes qui reviennent, chacune ancrée à son CWE.

Deux de ces classes méritent un regard plus attentif, parce qu'elles montrent à quel point le code généré est ordinaire. L'injection d'abord. Demandez « un point de terminaison de recherche qui filtre les utilisateurs par nom » et le chemin de moindre résistance est la concaténation.

# Vulnerable (CWE-89): user input concatenated into SQL
q = f"SELECT * FROM users WHERE name = '{name}'"
db.execute(q)

# Fixed: parameterized query, input never becomes code
db.execute("SELECT * FROM users WHERE name = %s", (name,))

L'autorisation rompue est plus subtile, parce que la version vulnérable a l'air complète. Elle renvoie la bonne forme, passe le test qui demande « récupère la commande 42 », et est livrée.

// Vulnerable (CWE-639 IDOR): any logged-in user reads any order
app.get('/orders/:id', auth, async (req, res) => {
  const order = await Order.findById(req.params.id)
  res.json(order)
})

// Fixed: scope the lookup to the caller who owns it
app.get('/orders/:id', auth, async (req, res) => {
  const order = await Order.findOne({ _id: req.params.id, userId: req.user.id })
  if (!order) return res.status(404).end()
  res.json(order)
})

La différence entre les deux versions est une clause. Un relecteur lisant 5 000 lignes par jour ne voit pas la clause manquante ; il voit un point de terminaison qui renvoie une commande et passe à la suite.

Pourquoi le vibe coding produit-il ces failles ?

Parce que le prompt optimise pour le comportement et le modèle optimise pour le motif le plus courant, et aucun des deux n'est la même chose que la sécurité. « Fais marcher le paiement » est une spécification fonctionnelle. Elle ne contient aucune instruction de valider l'entrée, de délimiter l'autorisation, ou de paramétrer une requête, donc l'agent comble l'écart avec ce que son corpus d'entraînement a rendu statistiquement probable, ce qui est fréquemment la version non sécurisée.

Il y a trois raisons cumulatives. Premièrement, le problème du corpus : le modèle a appris d'un code public plein des incontournables d'OWASP, donc non-sécurisé-par-défaut est sa prédisposition. Deuxièmement, le problème de l'absence : la sécurité est généralement une vérification qui est présente, et un modèle à qui on demande un résultat positif n'ajoute pas un garde-fou négatif que personne n'a demandé. Troisièmement, et le plus décisif, le problème du lecteur.

“

La personne qui prompte peut dire si la fonctionnalité marche. Elle ne peut généralement pas dire si elle est sûre. Cet écart, entre l'intention de l'auteur et la capacité du relecteur, est tout le problème de sécurité.

C'est pourquoi le vibe coding est structurellement différent d'un développeur junior écrivant le même code. Le junior est assez lent pour que la revue tienne le rythme, et le relecteur lit du code qu'un humain a écrit à vitesse humaine. Le vibe coding retire les deux freins : la sortie arrive à la vitesse machine, et la personne qui en est responsable manque souvent de la littératie de sécurité pour l'évaluer. La pull request, l'endroit où l'AppSec a toujours vécu, devient un compte-rendu de décisions déjà prises plutôt qu'un point de contrôle.

Comment faire du vibe coding sécurisé ?

Le vibe coding sécurisé consiste à placer un contrôle de sécurité là où le code est réellement rédigé, c'est-à-dire le prompt, pas la pull request. Vous gardez la vitesse et ajoutez une couche qui façonne ce que l'agent écrit avant qu'il ne l'écrive, plus la validation indépendante habituelle derrière. Les principes ci-dessous sont ce qui sépare « on fait du vibe coding » de « on fait du vibe coding en sécurité ».

1. Donnez les règles à l'agent au moment du prompt. Le modèle ne peut pas suivre un standard qu'il ne voit jamais. Chargez vos exigences de sécurité (paramétrer les requêtes, délimiter chaque recherche à l'appelant, ne jamais intégrer un secret en ligne) dans le contexte de l'agent avant chaque modification, pour que le motif sûr soit le réglage par défaut qu'il atteint, pas une réflexion après coup qu'un analyseur signale plus tard.

2. Gardez les secrets entièrement hors de portée. Aucun identifiant en clair dans l'espace de travail que l'agent peut lire. Utilisez un coffre-fort, injectez à l'exécution, et ajoutez des règles deny pour les fichiers .env et les coffres d'identifiants pour que l'agent ne puisse pas intégrer en ligne (CWE-798) ce qu'il ne peut pas voir. Faites tourner tout ce qui apparaît un jour dans un transcript.

3. Traitez chaque point de terminaison généré comme non autorisé jusqu'à preuve du contraire. L'habitude de revue la plus précieuse pour le code en vibe coding est de vérifier que chaque chemin renvoyant des données se délimite à l'appelant. L'autorisation (CWE-862, CWE-639) est la faille que l'agent omet le plus fiablement et celle qu'aucun test n'attrape.

4. Validez l'entrée comme une exigence stricte, pas un agrément optionnel. Exigez des bornes, des types et des listes d'autorisation sur chaque gestionnaire généré. CWE-20 est en amont de l'injection et de la désérialisation, donc le fermer ferme plusieurs classes d'un coup.

5. Gardez un humain dans la boucle, et une barrière SAST derrière lui. Faites passer le code généré par la revue avec une vigilance accrue sur l'auth, les requêtes et la validation, et faites échouer le build sur les constats à sévérité élevée. Les tests fonctionnels laissent passer un point de terminaison vulnérable mais fonctionnel ; seule une vérification sensible à la sécurité ne le fait pas.

6. Surveillez explicitement les failles de logique métier. Les analyseurs n'attrapent pas une remise à quantité négative ou un coupon cumulé. Extrayez les conventions que votre propre code encode déjà (l'argent est Decimal128, les remboursements passent par requireOwner) et faites-les respecter pendant que l'agent écrit. Nous approfondissons cela dans failles de logique métier dans le code généré par IA.

Le motif à travers les six est le même : cessez de vous appuyer sur un contrôle qui arrive une fois le code sur le disque, et déplacez-le au moment où le code est écrit.

Là où l'analyse est insuffisante : l'application au moment de l'agent

Reparcourez les classes de risque et une seule faiblesse de l'approche standard se démarque. Le SAST, les analyseurs de secrets et la revue de code agissent tous sur du code qui existe déjà. Ils se regroupent autour de la pull request, parce que c'est là que l'AppSec a toujours vécu. Mais la PR n'a jamais été un point de contrôle que parce qu'un humain la lisait, et à la cadence du vibe coding, plus personne ne la lit de bout en bout. L'analyseur devient un historien, documentant les failles après que l'agent les a livrées et est passé à autre chose.

L'endroit où faire appliquer une règle est le prompt, avant que la ligne non sécurisée ne soit écrite. Quelle que soit la règle que vous voulez que l'agent suive, elle doit être entre ses mains au moment où il écrit, pas en attente dans un outil qui arrive une fois le code sur le disque.

Lisez la colonne de droite comme l'objectif. Analyser n'est pas faux ; c'est tard. L'application au moment de l'agent ne remplace pas l'analyseur, la revue ou la barrière CI. Elle place un contrôle en amont de tous, pour que la ligne non sécurisée soit réécrite avant même d'être suggérée, au lieu d'être attrapée trois étapes plus tard par un outil lisant un diff que personne n'avait le temps de lire.

Quels outils attrapent les vulnérabilités du vibe coding ?

Vous avez besoin de deux sortes de contrôle, et la plupart des équipes n'en ont qu'une. La sorte familière est la détection : le SAST pour l'injection et la cryptographie faible, l'analyse de composition logicielle pour les dépendances vulnérables, et l'analyse de secrets pour les identifiants dans l'historique. Celles-ci sont nécessaires, et elles ont leur place en CI sur chaque pull request. Elles sont aussi réactives, et à la vitesse du vibe coding elles arrivent après que la faille a été livrée.

La sorte qui manque à la plupart des configurations est la prévention au point de rédaction : une couche qui vit dans la boucle de l'agent et façonne le code au moment où il est écrit. C'est l'écart que comble VibeDefend. C'est un CLI npm gratuit qui s'installe en cinq secondes environ et câble Claude Code, Cursor, Windsurf, OpenAI Codex et GitHub Copilot dans quatre couches de gouvernance qui s'exécutent à l'intérieur de la boucle de l'agent, de sorte que la version sûre du code soit la première version. Pour l'image complète de la façon dont cela s'inscrit à travers chaque agent de code IA, voyez notre pilier sur la sécurité des agents de code IA.

npx -y @cybedefend/vibedefend@latest installChoisissez l'UE ou les US, confirmez votre agentDéposez .cybedefend/config.json dans le dépôtLe prochain prompt est gouverné

Les quatre couches traitent les modes de défaillance que ce guide a nommés. Règles métier Les conventions extraites de votre propre dépôt (l'argent est Decimal128, l'autorisation passe par requireOwner), chargées dans l'agent avant chaque modification pour que les failles de logique métier ne soient jamais écrites. Règles de sécurité Apportent OWASP Top 10, SOC 2, RGPD et ISO 27001 dans le code au moment où il est écrit, de sorte que l'injection, la validation manquante et l'autorisation rompue rencontrent une règle à la rédaction au lieu d'une case à cocher au moment de l'audit. Garde-fou d'actions Intercepte les appels destructeurs (un sudo rm -rf, une lecture brute d'une variable d'environnement en forme de secret, un psql improvisé contre un hôte de production) avant qu'ils ne se déclenchent, avertissant ou bloquant selon la règle, avec chaque interception dans la piste d'audit. Live Findings câble l'agent dans la plateforme AppSec complète de CybeDefend, ses scanners (SAST avec atteignabilité, SCA, secrets, IaC et CI/CD) tournant en continu, de sorte que l'agent n'écrit pas seulement du code sûr, il trie et corrige les vulnérabilités que vous avez déjà. Crucialement, rien de votre code ne traverse le réseau : les décisions se prennent localement à côté de l'agent, et seules des métadonnées de gouvernance structurées (la règle qui s'est déclenchée, le chemin du fichier, la sévérité, un horodatage) atteignent le backend. Les tenants UE et US sont physiquement séparés, et vous choisissez la région au moment de l'installation, de sorte que le contrôle se situe aussi près du code sans devenir lui-même un risque d'exfiltration de données.

Questions fréquentes

Le vibe coding est-il sûr ?

Le vibe coding est sûr pour produire des logiciels fonctionnels et peu fiable pour produire des logiciels sécurisés, parce qu'un prompt « fais que ça marche » ne demande jamais la vérification de sécurité manquante. Les tests indépendants trouvent sans cesse qu'une large part du code généré par IA échoue aux tests de sécurité même quand il est fonctionnellement correct. Il devient sûr à pratiquer quand vous ajoutez un contrôle qui agit au moment de la rédaction, donnez à l'agent vos règles de sécurité dans son contexte, gardez un humain dans la boucle, et contrôlez les pull requests avec du SAST. Sans cela, le vibe coding livre le Top 10 OWASP à la vitesse machine.

Quelles sont les vulnérabilités les plus courantes du vibe coding ?

Les classes récurrentes sont les secrets codés en dur (CWE-798), l'autorisation rompue et IDOR (CWE-862, CWE-639), l'injection (CWE-89 pour le SQL, CWE-78 pour les commandes), la validation d'entrée manquante (CWE-20), la désérialisation non sécurisée (CWE-502), et les failles de logique métier. Aucune n'est nouvelle. Ce sont les incontournables d'OWASP, reproduits plus vite que la revue ne peut suivre, parce que le modèle écrit le motif le plus courant et que le motif le plus courant est fréquemment le motif non sécurisé.

Pourquoi le code généré par IA comporte-t-il autant de failles de sécurité ?

Trois raisons se cumulent. Le modèle a appris d'un corpus public plein de motifs non sécurisés, donc non-sécurisé-par-défaut est sa prédisposition. La sécurité est généralement un garde-fou qui est présent, et un modèle à qui on demande un résultat positif n'ajoute pas une vérification négative que personne n'a demandée. Et la personne qui prompte peut dire si la fonctionnalité marche mais ne peut souvent pas dire si elle est sûre, donc la faille passe la revue. Le résultat est du code à l'air fonctionnel qui livre la vulnérabilité avec la fonctionnalité.

Un non-développeur peut-il faire du vibe coding en sécurité ?

Seulement avec un contrôle qui ne dépend pas du fait que la personne lise les implications de sécurité, parce que c'est exactement la compétence qui manque à un non-développeur. Un linter ou un analyseur qui produit des constats à trier suppose que le lecteur peut les interpréter. Une couche au moment de l'agent qui charge les règles dans l'agent et réécrit la ligne non sécurisée avant qu'elle n'atterrisse retire cette dépendance : le motif sûr est le réglage par défaut que l'agent atteint, donc la sécurité ne repose pas sur la capacité de celui qui prompte à repérer une vérification d'autorisation manquante.

En quoi le vibe coding diffère-t-il de l'utilisation d'une autocomplétion comme l'ancien Copilot ?

L'ancienne autocomplétion suggérait un bloc de code qu'un humain choisissait d'accepter ; le rayon d'impact se limitait à un extrait qu'un développeur devait encore coller. Le vibe coding laisse l'agent effectuer des actions : il modifie à travers l'arborescence, exécute des commandes, et livre des fonctionnalités fonctionnelles à partir d'un paragraphe d'intention, à un volume qu'aucun relecteur ne peut lire. Le modèle de sécurité doit passer de la revue d'un brouillon qu'un humain accepte à la contrainte et au façonnage de ce qu'un agent écrit en premier lieu.

Un analyseur SAST attrape-t-il les vulnérabilités du vibe coding ?

Un analyseur SAST en attrape une part significative, surtout l'injection et la cryptographie faible, et il a sa place en CI sur chaque pull request. Ce qu'il rate largement, ce sont les failles de logique métier, parce qu'une remise à quantité négative ou un remboursement qui saute la vérification de propriété est syntaxiquement parfait et sémantiquement faux, sans signature à faire correspondre. Il est aussi réactif : il agit après que le code est écrit, ce qui à la vitesse du vibe coding signifie après que la faille a été livrée. Associez la détection en CI à la prévention au moment de la rédaction.

Quel est le contrôle le plus efficace pour un vibe coding sécurisé ?

Déplacer le point de contrôle de sécurité de la pull request vers le prompt. La détection qui s'exécute après que le code existe relit toujours l'histoire à la cadence de l'agent, parce que personne ne relit des milliers de lignes générées de bout en bout. Une couche qui charge vos règles de sécurité et métier dans l'agent avant chaque modification, et réécrit la ligne non sécurisée avant qu'elle n'atterrisse, prévient la faille au lieu de la trouver plus tard. Tout le reste (SAST, revue, barrières CI) est de la défense en profondeur derrière cela.

Par où commencer pour sécuriser un projet existant en vibe coding ?

Commencez par fermer les deux classes que l'agent omet le plus : analysez l'historique à la recherche de secrets codés en dur et faites tourner tout ce qui est exposé, puis auditez chaque point de terminaison renvoyant des données pour une vérification d'autorisation délimitée à l'appelant. Ajoutez une barrière SAST à la CI qui échoue sur les constats à sévérité élevée, et placez une couche au moment de l'agent comme VibeDefend en amont pour que le nouveau code soit gouverné au moment où il est écrit. Le but est de cesser d'ajouter des failles d'abord, puis de réduire l'arriéré que les premiers prompts ont laissé derrière eux.