False Security Confidence in Benign LLM Code Generation

Titre : Confiance de Sécurité Fausse (FSC) dans la Génération de Code Bénine par les LLM

Auteur : Xiaolei Ren (Université des Sciences et Technologies de Macao)
Date : Avril 2026 (Note technique / Cadre de recherche)

---

1. Le Problème : L'Écart entre Correction Fonctionnelle et Sécurité

L'article identifie un problème critique dans l'évaluation actuelle des modèles de langage (LLM) pour la génération de code. Traditionnellement, la correction fonctionnelle (le code produit le résultat attendu et passe les tests unitaires) et la correction de sécurité sont souvent traitées comme des objectifs alignés.

Cependant, l'auteur démontre qu'il existe une divergence systématique :

• Un code généré peut être fonctionnellement correct (il "fonctionne" selon les tests standards) mais vulnérable (il contient des injections SQL, une mauvaise gestion des identifiants, une désérialisation exploitable, etc.).
• Ce phénomène crée un "confort d'évaluation trompeur" : une fois qu'un échantillon est marqué comme "correct" sur le plan fonctionnel, les utilisateurs et les chercheurs ont tendance à surestimer sa qualité globale et à ignorer les risques de sécurité.
• Ce phénomène est nommé Confiance de Sécurité Fausse (False Security Confidence - FSC). Il ne s'agit pas d'une attaque active, mais d'une défaillance de sécurité qui survient dans des tâches de génération ordinaires et non malveillantes.

2. Méthodologie et Cadre Conceptuel

L'article ne propose pas une étude empirique massive avec des résultats chiffrés immédiats, mais établit un cadre de mesure rigoureux pour isoler et quantifier ce phénomène.

A. Définition Formelle de la FSC

La FSC est définie au niveau d'un échantillon de code $s$ généré par un modèle :

• Soit $FCR(s)$ l'indicateur de correction fonctionnelle (1 si correct, 0 sinon).
• Soit $SSR(s)$ l'indicateur de succès de sécurité (1 si sécurisé, 0 sinon).
• Un échantillon présente une FSC si et seulement si :
  $$FCR(s) = 1 \quad \land \quad SSR(s) = 0$$
  Cela signifie que le code fonctionne mais est intrinsèquement dangereux.

B. Le Taux de FSC (FSC Rate)

L'auteur propose une métrique conditionnelle pour mesurer la prévalence de ce problème :
$$FSC\text{-}rate(S) = \frac{|\{s \in S : FCR(s) = 1 \land SSR(s) = 0\}|}{|\{s \in S : FCR(s) = 1\}|}$$

• Dénominateur clé : Le taux est calculé uniquement sur l'ensemble des sorties fonctionnellement correctes, et non sur toutes les générations.
• Objectif : Isoler la part de "faux succès" qui devrait être remise en question. Cela permet de distinguer un modèle qui échoue souvent (faible correction fonctionnelle) d'un modèle qui réussit fonctionnellement mais échoue sur la sécurité (FSC élevé).

C. La Vue à Trois Écosystèmes

Pour comprendre où et comment la FSC se manifeste, l'article propose de diviser les tâches en trois catégories :

1. Programmation à usage général : Problèmes algorithmiques ou de traitement de données sans cadre de sécurité explicite. La FSC y survient lorsque des vulnérabilités latentes sont masquées par la réussite fonctionnelle.
2. Tâches en contexte de déploiement : Gestion de secrets, logique d'autorisation, routage, configurations. Ici, le code peut être fonctionnel mais échouer face aux hypothèses réelles de déploiement ou de menace.
3. Programmation explicite de sécurité : Tâches demandant directement de la validation, du chiffrement ou du contrôle d'accès. La FSC capture ici le cas où le modèle semble comprendre l'objectif de sécurité mais produit une implémentation vulnérable.

D. Le Concept de "FSC-hard"

L'article introduit une couche de raffinement pour les cas les plus dangereux :

• FSC-hard désigne les cas de FSC où les outils d'analyse statique standards ne détectent pas la vulnérabilité, mais où une validation dynamique ou sémantique légère confirme que le chemin d'exploitation est accessible.
• C'est la zone la plus trompeuse car elle combine un succès fonctionnel apparent avec un silence des outils de sécurité.

3. Contributions Clés

L'article apporte quatre contributions majeures à la communauté de la recherche sur la sécurité des LLM :

1. Introduction du concept de FSC : Une nouvelle notion orientée vers la mesure pour étudier les échecs de sécurité au sein des sorties fonctionnellement correctes.
2. Formalisation du Taux de FSC : Une métrique conditionnelle qui normalise les échecs de sécurité par rapport aux succès fonctionnels, évitant ainsi la confusion entre la capacité de codage globale et le comportement de sécurité.
3. Vue à trois écosystèmes : Une taxonomie pour analyser la FSC selon le contexte de la tâche (général, déploiement, sécurité explicite), reconnaissant que les causes de la fausse confiance varient selon le contexte.
4. Définition de FSC-hard : Une sous-catégorie critique identifiant les vulnérabilités qui échappent aux analyseurs statiques mais restent exploitables dynamiquement.

4. Résultats et État des Lieux

Note : Cet article est une "note technique" (framework statement) et non un rapport empirique complet.

• Pas de statistiques globales : L'article ne fournit pas de taux de FSC prévalents ni de classement (leaderboard) de modèles.
• Positionnement par rapport aux travaux antérieurs :
  • Contrairement à SAFE (qui compare les méthodes de génération de code sécurisé via une métrique conjointe), la FSC se concentre sur le risque de sur-confiance au sein des succès apparents.
  • Contrairement à CWEval (évaluation basée sur les résultats), la FSC se demande : "À quelle fréquence l'échec de sécurité survient-il parmi les sorties qui passent les tests fonctionnels ?"
  • L'article reconnaît que le phénomène existe déjà (cités dans [1, 2, 3, 4]), mais qu'il manque un cadre de mesure dédié pour l'analyser dans des contextes "bénins" (non-attaquants).

5. Signification et Implications

L'importance de ce travail réside dans le changement de perspective qu'il impose à l'évaluation des LLM :

• Changement de paradigme de mesure : Passer d'une logique de "détection d'attaques" à une logique de "prévalence des échecs cachés dans les succès".
• Impact sur le déploiement : Les développeurs et les systèmes d'automatisation (patching, intégration continue) risquent de déployer du code vulnérable s'ils se fient uniquement aux tests fonctionnels. La FSC quantifie ce risque spécifique.
• Guide pour les futures évaluations : L'article recommande que le taux de FSC ne soit jamais rapporté seul, mais toujours accompagné du taux de correction fonctionnelle et de preuves de validation (statique + dynamique).
• Nécessité de validation dynamique : Pour les cas "FSC-hard", l'analyse statique seule est insuffisante. Une validation dynamique ou une démonstration de chemin d'exploitation est nécessaire pour valider l'existence d'une FSC.

Conclusion

Ce rapport établit le vocabulaire et les limites de mesure nécessaires pour étudier comment les notions conventionnelles de "correction" peuvent masquer des échecs de sécurité dans la génération de code par les LLM. Il pose les bases pour de futures évaluations à grande échelle visant à quantifier ce risque de confiance fausse à travers différents modèles, langages et écosystèmes de tâches.