Extracting Recurring Vulnerabilities from Black-Box LLM-Generated Software

Cet article présente FSTab, un cadre d'évaluation et d'attaque en boîte noire capable de prédire et de quantifier la persistance de vulnérabilités récurrentes dans le code généré par des LLMs, révélant ainsi des risques de sécurité systémiques même dans des domaines non vus lors de l'entraînement.

L'essentiel

🕵️‍♂️ Le Titre : "Détecter les failles cachées en regardant juste la façade"

Imaginez que vous achetez une maison construite par un robot très doué, mais un peu prévisible. Ce robot (une Intelligence Artificielle ou IA) peut construire des milliers de maisons en quelques secondes. Le problème ? Ce robot a tendance à utiliser toujours les mêmes plans pour les mêmes pièces.

Si ce robot a une habitude dangereuse (par exemple, il oublie toujours de mettre une serrure solide sur la porte de derrière quand il construit une cuisine), alors toutes les maisons qu'il construit avec une cuisine auront cette même faille, même si vous ne pouvez pas voir l'arrière de la maison.

C'est exactement ce que les chercheurs ont découvert avec les logiciels créés par les IA (comme GPT, Claude, etc.).

---

🏠 L'Analogie de la "Carte au Trésor" (FSTab)

Les chercheurs ont créé un outil appelé FSTab (Tableau Fonction-Sécurité). Pour le comprendre, imaginons une situation simple :

1. La Façade (Ce que vous voyez) : Quand vous visitez un site web, vous voyez des boutons : "Se connecter", "Télécharger un fichier", "Payer". Ce sont les fonctionnalités visibles.
2. La Cuisine (Ce qui est caché) : Derrière ces boutons, il y a du code complexe qui gère les mots de passe et les données bancaires. C'est le backend, souvent invisible.
3. Le Problème : Habituellement, pour trouver un bug de sécurité, il faut être un hacker et regarder le code caché. Mais si le site est protégé, c'est impossible.

La solution des chercheurs :
Ils ont remarqué que l'IA est comme un cuisinier qui utilise toujours la même recette.

• Si vous voyez un bouton "Se connecter" (Façade), l'IA a 90% de chances d'avoir utilisé la même mauvaise recette pour gérer les mots de passe (Cuisine).
• Si vous voyez un bouton "Télécharger un fichier", l'IA a tendance à oublier le même type de sécurité.

Le FSTab est une sorte de dictionnaire magique ou de carte au trésor.

• Entrée : Vous dites à la carte : "Je vois un bouton 'Se connecter'".
• Sortie : La carte vous dit : "Attention ! Si ce site a été fait par l'IA 'GPT-5', il y a 94% de chances qu'il y ait une faille de sécurité cachée juste derrière ce bouton."

Vous n'avez même pas besoin de voir le code ! Juste en regardant ce que l'utilisateur voit, vous pouvez deviner ce qui ne va pas dans l'ombre.

---

🧩 Comment ça marche en pratique ? (L'histoire du détective)

Imaginons un détective (le pirate) qui veut tester un nouveau site web créé par une IA, disons "Claude-4.5".

1. L'Observation (Reconnaissance) : Le détective arrive sur le site. Il voit un formulaire "Réinitialiser le mot de passe".
2. La Consultation (FSTab) : Il sort son carnet (le FSTab) qui dit : "Pour l'IA Claude, le bouton 'Réinitialiser mot de passe' est souvent associé à une faille de sécurité spécifique."
3. L'Attaque : Au lieu de deviner au hasard, le détective sait exactement où frapper. Il teste cette faille précise.
4. Le Résultat : Boom ! Il trouve la faille.

Le résultat choc : Les chercheurs ont montré que cette méthode fonctionne incroyablement bien. Même si le site est dans un domaine totalement différent (par exemple, un site de blog vs un site de banque), si c'est la même IA qui l'a construit, elle garde les mêmes "tics" de sécurité.

---

📊 Les Découvertes Majeures (En termes simples)

Les chercheurs ont testé cela sur les IA les plus célèbres (GPT-5, Claude, Gemini, etc.) et ont trouvé trois choses surprenantes :

1. L'IA a une "Signature" de sécurité : Tout comme un humain a une écriture unique, chaque IA a un style de code. Si l'IA "Grok" oublie souvent de verrouiller les fenêtres, elle le fera toujours, peu importe le projet. C'est une empreinte digitale de la vulnérabilité.
2. C'est prévisible : Même si vous changez la façon dont vous demandez à l'IA de faire le site (en reformulant la demande), elle continuera à faire les mêmes erreurs de sécurité. C'est comme si vous demandiez à un enfant de dessiner un chat en disant "Fais un chat" ou "Dessine un animal poilu", il dessinera toujours le même chat avec les mêmes oreilles pointues.
3. Le danger est partout : Le pire, c'est que cette méthode fonctionne même si vous n'avez jamais vu le modèle s'entraîner sur ce type de projet. L'IA transfère ses mauvaises habitudes d'un domaine à l'autre.

---

🛡️ Pourquoi c'est important pour nous ?

Aujourd'hui, de plus en plus de développeurs utilisent l'IA pour écrire du code. C'est rapide et efficace. Mais ce papier nous met en garde :

• Le risque : Nous risquons de construire des millions de logiciels avec les mêmes failles cachées, comme construire des millions de maisons avec la même serrure cassée.
• La bonne nouvelle : Grâce à cet outil (FSTab), les experts en sécurité peuvent maintenant prévoir les problèmes avant même que le logiciel ne soit fini. Ils peuvent dire : "Attends, ce bouton 'Payer' ressemble à un bouton qui a déjà causé des problèmes avec cette IA. Vérifions-le immédiatement."

En résumé

Ce papier nous dit que les IA ne sont pas seulement de superbes architectes, mais qu'elles ont aussi des tics de construction dangereux et répétitifs.

L'outil FSTab est comme un détecteur de métaux pour les logiciels : il vous dit "Attention, sous ce bouton visible, il y a probablement une bombe cachée" simplement en regardant la façade du bâtiment, sans avoir besoin de le démolir pour voir à l'intérieur. C'est une révolution pour sécuriser le futur du code généré par l'IA.

Résumé technique

1. Problématique

L'utilisation croissante des Modèles de Langage (LLM) pour la génération de code a transformé le développement logiciel, mais elle introduit un risque de sécurité majeur : la persistance des vulnérabilités.

• Le constat : Les LLMs, en raison de leur échantillonnage probabiliste et de leur tendance à réutiliser des modèles de code canoniques, génèrent souvent des programmes qui suivent des templates récurrents. Ces templates induisent des vulnérabilités prévisibles et systématiques.
• Le vide de la recherche existante : Les approches actuelles se concentrent sur des défenses a posteriori (analyse statique, benchmarks de vulnérabilités) qui traitent chaque programme de manière isolée. Elles ne modélisent pas les régularités inter-programmes induites par le modèle générateur lui-même.
• Le défi : Comment un attaquant peut-il prédire des vulnérabilités dans le code backend (caché) d'une application générée par un LLM, en n'ayant accès qu'aux fonctionnalités frontend (visibles) et à l'identité du modèle, sans disposer du code source ?

2. Méthodologie : FSTab (Feature–Security Table)

Les auteurs introduisent FSTab, un cadre d'attaque en boîte noire et un outil d'évaluation basé sur l'hypothèse que les choix de conception vulnérables d'un modèle sont intrinsèques et se répètent à travers différents domaines et prompts.

A. Construction de FSTab (Phase d'Entraînement)

1. Génération de corpus : Génération d'un grand nombre d'applications complètes à partir d'un LLM cible.
2. Annotation : Utilisation d'outils d'analyse statique (CodeQL, Semgrep) pour identifier les vulnérabilités réelles (backend) et des analyseurs de syntaxe (AST, regex) pour extraire les fonctionnalités frontend observables (ex: "connexion utilisateur", "téléchargement de fichier").
3. Calcul des scores (PMI) : Au lieu d'utiliser de simples fréquences, les auteurs utilisent l'Information Mutuelle Ponctuelle (PMI) pour mesurer l'association entre une fonctionnalité frontend $f$ et une règle de vulnérabilité backend $r$. Cela permet d'identifier les vulnérabilités spécifiques au modèle plutôt que des erreurs génériques.
   $$S_{PMI}(f, r) = \log \frac{\hat{P}(r|f)}{\hat{P}(r)}$$
4. Sélection diversifiée : Un algorithme glouton avec pénalité de diversité ($\lambda$) est appliqué pour éviter que les règles de vulnérabilité les plus courantes ne dominent toutes les entrées, assurant ainsi une couverture large et discriminative.

B. L'Attaque en Boîte Noire (Phase d'Inférence)

L'attaquant dispose uniquement de l'interface utilisateur (UI) et du nom du modèle (ex: GPT-5.2, Claude-4.5).

1. Reconnaissance : Identification des fonctionnalités frontend observables (ex: formulaire de login).
2. Mappage : Conversion de ces fonctionnalités en schéma standardisé.
3. Requête FSTab : Interrogation de la table de recherche spécifique au modèle pour récupérer les signatures de vulnérabilités les plus probables associées à ces fonctionnalités.
4. Résultat : Une liste priorisée de failles backend probables à exploiter, sans jamais avoir vu le code source.

C. Cadre d'Évaluation de la Persistance

Les auteurs définissent quatre métriques pour quantifier la stabilité des vulnérabilités :

• FVR (Feature Vulnerability Recurrence) : Fréquence à laquelle une fonctionnalité spécifique déclenche la même vulnérabilité.
• RVP (Rephrasing Vulnerability Persistence) : Robustesse de la vulnérabilité face aux variations sémantiques du prompt (reformulations).
• DVR (Domain Vulnerability Recurrence) : Persistance des vulnérabilités au sein d'un même domaine d'application.
• CDT (Cross-Domain Transfer) : Capacité d'un modèle à transférer ses schémas vulnérables d'un domaine à un autre (généralisation).

3. Contributions Clés

1. Attaque Universelle en Boîte Noire : Démonstration qu'il est possible d'inférer des vulnérabilités backend cachées uniquement à partir de l'interface frontend et de l'identité du modèle, en utilisant FSTab.
2. Cadre d'Évaluation Centrée sur le Modèle : Introduction de métriques (FVR, RVP, DVR, CDT) pour mesurer la persistance des vulnérabilités, permettant de comparer les modèles non pas sur leur capacité à générer du code, mais sur leur propension à reproduire des failles de sécurité.
3. Caractérisation Empirique : Analyse détaillée de six modèles d'état de l'art (GPT-5.2, Claude-4.5 Opus, Gemini-3 Pro/Flash, Composer, Grok) sur cinq domaines (E-commerce, Outils internes, Réseaux sociaux, etc.).

4. Résultats Expérimentaux

Les expériences ont été menées sur 1050 programmes générés (WebGenBench) et un jeu de données externe (E2EDev).

• Efficacité de l'Attaque (ASR et ACR) :

  • FSTab atteint un Taux de Succès d'Attaque (ASR) allant jusqu'à 100% sur certains modèles et domaines (ex: E-commerce avec Gemini-3 Flash et Composer).
  • Le Taux de Couverture (ACR) est également élevé, montrant que l'attaque identifie la majorité des vulnérabilités réelles.
  • Généralisation : Même lorsque le domaine cible est exclu de la construction de la table (Cross-Domain), l'attaque reste efficace (ASR moyen de ~80% pour GPT-5.2, jusqu'à 94% pour Claude-4.5 Opus sur les outils internes).

• Persistance des Vulnérabilités :

  • FVR : Certaines fonctionnalités (ex: "Créer un compte", "Connexion") déclenchent des vulnérabilités avec un taux de récurrence de 100% sur plusieurs modèles.
  • RVP : Les vulnérabilités persistent même lorsque le prompt est reformulé (ex: ~50% de persistance pour Composer et GPT-5.2), prouvant qu'elles ne sont pas des artefacts de formulation mais des biais internes au modèle.
  • CDT > DVR : Un résultat surprenant est que les vulnérabilités se transfèrent souvent mieux entre des domaines différents qu'elles ne se répètent à l'intérieur d'un même domaine (écart de +18,3% en moyenne). Cela indique que les vulnérabilités sont des biases architecturaux du modèle plutôt que des artefacts spécifiques à un domaine.

• Comparaison des Modèles :

  • Composer et GPT-5.2 montrent une persistance très élevée (RVP ~35-50%), rendant leurs vulnérabilités très prévisibles.
  • Grok présente une persistance plus faible (RVP ~12%), suggérant une génération plus stochastique, mais conserve une forte capacité de transfert cross-domain.

5. Signification et Implications

• Nouvelle Surface d'Attaque : L'article révèle une surface d'attaque sous-estimée : la corrélation entre les fonctionnalités visibles et les failles backend cachées, exploitée via la connaissance du modèle générateur.
• Risques de Sécurité Systémiques : La persistance des vulnérabilités suggère que les risques ne sont pas isolés à un prompt ou un projet, mais sont inhérents au modèle lui-même. Un attaquant peut "profiler" un modèle sur une application simple et utiliser ce profil pour compromettre des applications critiques dans des domaines totalement différents.
• Implications Défensives :
  • Nécessité d'évaluations de sécurité centrées sur le modèle (mesurant la persistance des failles) plutôt que sur des cas isolés.
  • Besoin de réduire la rigidité des templates de génération et d'intégrer des objectifs de sécurité lors du décodage ou de l'entraînement.
  • FSTab peut servir d'outil d'audit proactif pour prioriser les vérifications de sécurité avant le déploiement.

Conclusion :
Cette étude démontre que les LLMs générant du code possèdent des "empreintes digitales de vulnérabilité" stables et exploitables. La capacité à prédire des failles backend à partir de l'UI frontend en boîte noire constitue une menace sérieuse pour la sécurité des logiciels générés par l'IA, nécessitant une refonte des pratiques de validation et de déploiement.