Failles de logique métier dans le code généré par IA : pourquoi votre analyseur est aveugle

Qu'est-ce qu'une faille de logique métier ?

Une faille de logique métier est une vulnérabilité où le code est syntaxiquement correct, exempt d'injection, et bâti sur des bibliothèques corrigées, mais où il viole une règle que votre application est censée faire respecter. Les exemples classiques sont l'autorisation rompue, le cloisonnement de tenant manquant, l'abus d'entier ou de quantité, les références directes à des objets non sécurisées (IDOR) et les courses d'ordre d'opérations. Rien n'est malformé. La logique se trompe simplement sur ce qui est autorisé.

C'est la catégorie qu'OWASP suit sous le nom de Business Logic Vulnerabilities et, pour la part autorisation, de Broken Access Control, le premier risque du Top 10 OWASP. Ces failles sont dangereuses précisément parce qu'elles ressemblent à du trafic normal. Il n'y a pas de charge utile malformée, pas de trace de pile, pas de signature qu'un système de détection d'intrusion puisse faire correspondre. La requête est bien formée ; elle n'aurait simplement pas dû être honorée. Nous en avons parcouru une de bout en bout dans le panier à 0 € : un pipeline CI/CD parfait, chaque tableau de bord au vert, et un inventaire entier passé en caisse pour rien.

Pourquoi le SAST ne peut-il pas trouver les failles de logique métier ?

Parce que le SAST raisonne sur le code, et une règle métier vit en dehors du code. Un analyseur statique peut suivre une donnée corrompue d'une source vers un puits et prouver qu'une injection est atteignable. Il n'a aucune source pour le fait que « seul le propriétaire d'un document peut le modifier » ou que « la quantité doit être un entier positif ». Ces règles sont dans votre tête, vos tickets et votre domaine, pas dans un motif que l'analyseur livre.

C'est une limite structurelle, pas un écart de maturité qu'un analyseur plus récent comble. Le SAST excelle à l'analyse de teinte : entrée non fiable, puits dangereux, aucun assainisseur entre les deux. Une vérification d'autorisation manquante est la forme inverse. Il n'y a pas d'entrée corrompue ni de puits dangereux, juste une instruction if qui n'a jamais été écrite. On ne peut pas faire correspondre l'absence d'une règle qu'on ne vous a jamais donnée. C'est aussi pourquoi la plupart des équipes se noient sous une sortie d'analyseur qui rate le vrai risque, le sujet de pourquoi la plupart des constats SAST sont du bruit. Le bon modèle mental est un iceberg.

Tout ce qui est sous la ligne de flottaison passe une exécution SAST et SCA propre. Le code compile, les bibliothèques sont à jour, aucune injection n'est atteignable. Le rapport est tout-vert, et l'application est exploitable.

Pourquoi les agents de code IA en produisent-ils davantage ?

Parce qu'un agent IA est un comparateur de motifs entraîné sur la forme d'un code fonctionnel, et une règle métier n'est pas une forme. Quand vous demandez à un agent d'« ajouter un point de terminaison pour mettre à jour un projet », il produit un gestionnaire qui parse l'id, charge la ligne et enregistre le changement, parce que c'est ce que font des millions de gestionnaires à l'air correct. Il n'a aucune raison d'ajouter une vérification de propriétaire ou un filtre de tenant, puisque ceux-ci sont spécifiques à votre domaine et absents du motif générique.

Donc la faille n'est pas un bug que le modèle introduit par accident ; c'est le résultat prévisible de la génération de la moyenne de tout code similaire. Le point de terminaison de mise à jour moyen sur Internet ne fait pas respecter votre modèle d'autorisation. Pire, la sortie est fluide et assurée, ce qui est exactement ce qui la fait passer la revue. Un relecteur survole un gestionnaire qui ressemble à tous les autres gestionnaires et l'approuve. À la vitesse machine, les agents génèrent désormais des milliers de lignes par jour, bien plus que quiconque ne lit de bout en bout, donc l'écart entre « a l'air correct » et « est correct » est l'endroit où les brèches s'accumulent. Nous couvrons la surface de risque plus large dans notre guide sur la sécurité des agents de code IA.

“

Un analyseur demande : « cette ligne est-elle dangereuse ? » Une faille de logique métier répond « non », et est exploitée quand même. La bonne question est : « ce code suit-il les règles de cette base de code ? » et aucun outil syntaxique n'a jamais été construit pour y répondre.

À quoi ressemblent les failles de logique métier dans le code IA ?

Elles ressemblent à du code propre et idiomatique avec un garde-fou manquant. Voici trois classes qu'un agent livre de façon routinière. Chacune compile, chacune passe le SAST, et chacune est un constat critique.

Panier à quantité négative. Demandez un point de terminaison « ajouter au panier » et vous obtenez de l'arithmétique sans contrainte de domaine. Une quantité de -1 soustrait du total.

// Vulnerable: no constraint on quantity
function addToCart(cart, item, quantity) {
  cart.total += item.price * quantity; // quantity = -1 lowers the total
  return cart;
}

// Fixed: enforce the business rule
function addToCart(cart, item, quantity) {
  if (!Number.isInteger(quantity) || quantity < 1) {
    throw new ValidationError("quantity must be a positive integer");
  }
  cart.total += item.price * quantity;
  return cart;
}

Autorisation manquante / IDOR. Demandez une route « mettre à jour un projet » et vous obtenez un gestionnaire qui charge par id et enregistre. N'importe quel utilisateur authentifié peut passer n'importe quel id.

# Vulnerable: loads by id, never checks ownership (IDOR)
@app.put("/projects/{project_id}")
def update_project(project_id, body, user):
    project = db.get(Project, project_id)
    project.name = body.name
    db.commit()
    return project

# Fixed: require the caller to own the record
@app.put("/projects/{project_id}")
def update_project(project_id, body, user):
    project = db.get(Project, project_id)
    require_owner(project, user)  # 403 if user.id != project.owner_id
    project.name = body.name
    db.commit()
    return project

Cloisonnement de tenant manquant. Dans une application multi-tenant, une requête filtrée uniquement par id fuit d'un tenant à l'autre.

# Vulnerable: filtered by id only, crosses tenant boundary
invoice = db.query(Invoice).filter(Invoice.id == invoice_id).first()

# Fixed: scope every query to the caller's tenant
invoice = db.query(Invoice).filter(
    Invoice.id == invoice_id,
    Invoice.tenant_id == user.tenant_id,
).first()

Dans les trois cas, la différence entre sûr et exploitable est une ligne qui encode une règle que l'agent n'avait aucun moyen de connaître. Le cas de la quantité négative est aussi une chaîne d'exploitation complète à lui seul.

Comment attraper les failles de logique métier au moment de l'agent ?

Vous les attrapez en donnant à l'agent vos règles avant qu'il n'écrive, pas en analysant après qu'il a livré. Si l'agent sait que « l'argent utilise Decimal, chaque écriture passe par requireOwner, chaque requête est délimitée à tenant_id » au moment où il génère le gestionnaire, il écrit la version protégée du premier coup. La faille n'est jamais créée, donc il n'y a rien à trouver, trier ou corriger plus tard.

C'est le geste central : décaler la vérification en amont de la frappe. Un analyseur a posteriori ne peut signaler que ce qui existe déjà dans le diff, ce qui signifie qu'un humain doit encore lire, comprendre et rejeter du code à l'air fluide sous la pression du temps. Charger les règles dans le contexte de l'agent transforme la règle en réglage par défaut. L'agent cesse de produire le point de terminaison moyen et se met à produire votre point de terminaison. Pour les domaines où ces failles sont les plus coûteuses, la banque et la fintech, l'application au moment de l'agent est la différence entre un garde-fou qui existe par conception et un qui dépend d'un relecteur attrapant son absence.

En quoi est-ce différent du SAST et du SCA ?

C'est une couche différente du problème. Le SAST et le SCA répondent à « ce code est-il dangereux ou obsolète ? » L'application de règles au moment de l'agent répond à « ce code suit-il les règles de cette base de code ? » Vous voulez les deux : gardez le SAST pour l'injection et la teinte, gardez le SCA pour les dépendances vulnérables, et ajoutez une couche qui porte vos règles métier au moment de la génération.

La stack classique est nécessaire et insuffisante. Elle a été construite pour un problème de forme syntaxique et reste le bon outil pour ce problème. Les failles de logique métier sont un problème de forme intentionnelle, et elles ont besoin d'une couche qui connaît votre intention.

VibeDefend est cette couche. Il extrait les règles métier déjà présentes dans votre dépôt et les charge dans votre agent de code IA avant chaque modification, de sorte que l'agent écrive du code qui respecte vos règles d'autorisation, d'argent et de tenant dès la première frappe. C'est un CLI npm gratuit et il s'installe en cinq secondes environ.

La couche de règles métier est extraite de votre propre dépôt, utiliser Decimal pour l'argent, router chaque écriture via requireOwner, délimiter chaque requête au tenant, et est chargée dans l'agent avant chaque modification. Une quatrième couche, Live Findings, câble l'agent dans la plateforme AppSec complète de CybeDefend, de sorte que chaque résultat de ses scanners (SAST avec atteignabilité, SCA, secrets, IaC et CI/CD) soit en direct dans le contexte de l'agent pour être trié et corrigé, pas seulement les règles de logique métier au regard desquelles il écrit. Le modèle de confidentialité est strict : rien de votre code ne traverse le réseau, seulement des métadonnées de gouvernance, et les tenants UE et US sont gardés séparés pour que vos données restent dans votre région.

Questions fréquentes

Qu'est-ce qu'une faille de logique métier en termes simples ?

C'est du code qui fonctionne exactement comme écrit mais fait quelque chose qu'il ne devrait pas autoriser. La syntaxe est valide, il n'y a pas d'injection, et les bibliothèques sont corrigées, mais l'application enfreint l'une de ses propres règles : un panier qui accepte une quantité négative, un point de terminaison qui renvoie les données d'un autre client, une route de mise à jour sans vérification de propriété. Comme la requête est bien formée, elle ressemble à du trafic normal et passe à travers les analyseurs et la détection d'intrusion.

Pourquoi le SAST ou le SCA ne peuvent-ils pas attraper les vulnérabilités de logique métier ?

Parce que les deux outils raisonnent sur le code, et une règle métier vit en dehors du code. Le SAST suit une donnée non fiable vers un puits dangereux, ce qui est un problème de forme syntaxique. Une vérification d'autorisation manquante n'a pas d'entrée corrompue ni de puits, juste un garde-fou qui n'a jamais été écrit, et on ne peut pas faire correspondre l'absence d'une règle que l'analyseur n'a jamais reçue. Le SCA compare seulement vos dépendances à une base de données de CVE. Aucun des deux n'a été construit pour connaître votre modèle d'autorisation ou votre frontière de tenant.

Pourquoi les agents de code IA produisent-ils davantage de failles de logique métier ?

Parce qu'ils génèrent la moyenne statistique d'un code similaire, et le point de terminaison moyen sur Internet ne fait pas respecter vos règles spécifiques. Quand on lui demande d'écrire un gestionnaire de mise à jour, un agent en produit un qui charge une ligne et l'enregistre, puisque c'est le motif courant, sans la vérification de propriétaire ou le filtre de tenant que votre domaine requiert. La sortie est fluide et a l'air correcte, ce qui la fait passer la revue, et les agents génèrent bien plus de code par jour que quiconque ne lit attentivement.

Quelles sont les failles de logique métier les plus courantes dans le code généré par IA ?

Les récurrentes sont l'autorisation rompue (un chemin d'écriture sans vérification de propriété), les références directes à des objets non sécurisées ou IDOR (changer un id dans l'URL pour accéder à l'objet de quelqu'un d'autre), le cloisonnement de tenant manquant (une requête filtrée par id mais pas par tenant), et l'abus de quantité ou d'argent (quantités négatives ou nulles, arrondi de flottant, un prix recalculé à zéro au paiement). Les courses critiques (race conditions) sur les flux multi-étapes sont une cinquième classe. Toutes passent une exécution SAST et SCA propre.

Comment prévenir les failles de logique métier au lieu de simplement les détecter ?

Vous déplacez la vérification à avant que le code ne soit écrit. Si l'agent connaît vos règles, utiliser un type pour l'argent, router les écritures via une vérification de propriété, délimiter chaque requête au tenant, au moment où il génère le gestionnaire, il écrit la version protégée du premier coup et la faille n'existe jamais. Un analyseur a posteriori ne peut signaler que ce qui est déjà dans le diff, ce qui dépend encore d'un humain rejetant du code à l'air fluide. Charger les règles dans l'agent fait du motif sûr le réglage par défaut.

Cela remplace-t-il mon analyseur SAST et SCA ?

Non, cela les complète. Le SAST reste le bon outil pour l'injection et l'analyse de teinte, et le SCA reste le bon outil pour les dépendances vulnérables ; les deux résolvent bien des problèmes de forme syntaxique et de forme de dépendance. Les failles de logique métier sont un problème de forme intentionnelle que ces outils ne peuvent pas voir par conception. L'image complète, c'est vos analyseurs existants pour la syntaxe et les CVE, plus une couche au moment de l'agent qui porte vos règles métier au moment de la génération.

Comment VibeDefend connaît-il mes règles métier sans lire mon code ?

Il extrait les règles qui existent déjà dans votre dépôt, le type pour l'argent que vous utilisez, l'assistant d'autorisation que vos chemins d'écriture appellent, la colonne de tenant sur vos requêtes, et les transforme en métadonnées de gouvernance. Seules ces métadonnées sont utilisées pour orienter l'agent ; le code source lui-même ne traverse jamais le réseau, et les tenants UE et US sont isolés pour que vos données restent dans votre région. Le résultat est un agent qui applique vos conventions comme réglages par défaut avant chaque modification, plutôt qu'un analyseur inspectant votre code après coup.