Résumé technique : Renseignement en sources ouvertes (OSINT) pour la provenance du code et les modèles de sécurité

Énoncé du problème

Les développeurs tirent actuellement leur code de deux origines distinctes : l'accumulation de réponses humaines sur des plateformes comme Stack Overflow et les sorties de modèles de langage de grande taille (LLM). Ces deux sources comportent des coûts de sécurité mesurables. Le code provenant de sources humaines propage souvent des modèles non sécurisés en raison de l'ancienneté des réponses les plus votées, tandis que le code généré par les LLM introduit de nouveaux risques, notamment des sorties non sécurisées et une dépendance excessive des développeurs. Cet article traite de ces deux questions concernant cette scission :

1. Provenance : L'origine d'un extrait de code (humain vs un LLM spécifique) peut-elle être récupérée à partir du code lui-même en utilisant des caractéristiques légères et interprétables ?
2. Divergence de sécurité : Ces deux sources adoptent-elles des modèles de sécurité différents pour les mêmes tâches de programmation, et si oui, où divergent-elles ?

L'étude est formulée comme un exercice de renseignement en sources ouvertes (OSINT), s'appuyant uniquement sur des données publiques (API Stack Overflow) et des modèles à poids ouverts pour garantir une reproductibilité totale.

Méthodologie

Les auteurs ont construit un pipeline entièrement reproductible et fondé sur les données pour collecter et analyser des échantillons de code à travers 31 tâches de programmation sensibles à la sécurité (ex: OAuth avec PKCE, vérification de JWT, hachage de mots de passe, accès SQL).

• Collecte de données :

  • Corpus humain : Récupéré via l'API publique de Stack Overflow en utilisant des requêtes de recherche spécifiques pour chaque tâche. L'étude a conservé les blocs de code les plus importants des réponses ayant reçu des scores positifs, en enregistrant leur âge et leur score pour tenir compte du biais temporel.
  • Corpus de modèles : Généré à l'aide d'une passerelle locale exposant 9 modèles divers à poids ouverts (couvrant des familles telles que Mistral, Nemotron, Qwen et Tencent) via une interface compatible OpenAI. Les prompts ont été envoyés textuellement avec une instruction système fixe demandant une solution complète unique.
  • Échelle : Le jeu de données final comprend 528 échantillons réels (117 humains, 411 modèles) à travers 5 langages (Python, JavaScript, Go, Java, HTML).

• Extraction de caractéristiques :

  • Vérifications de modèles de sécurité : Expressions régulières déterministes étiquetées comme « sûres » ou « non sûres » pour chaque tâche (ex : présence de bcrypt vs md5, requêtes paramétrées vs concaténation de chaînes).
  • Métriques de style : Métriques indépendantes du langage capturant la forme du code, incluant le nombre de lignes, le nombre de caractères, la densité de commentaires, le nombre d'imports, la présence de gestion d'erreurs et la longueur moyenne des lignes.

• Analyse :

  • Attribution de provenance : Un classifieur Random Forest a été entraîné pour distinguer le code humain du code de modèle (binaire) et pour attribuer le code de modèle à des modèles spécifiques (classification à 7 voies) par validation croisée.
  • Score de sécurité : Un score déterministe a été calculé pour chaque échantillon basé sur la fraction des modèles sûrs adoptés moins la fraction des modèles non sûrs présents.
  • Étude de cas de réparation de vulnérabilité : Un sous-ensemble de 21 extraits de code non sécurisés (couvrant 12 classes CWE) a été soumis aux modèles avec des instructions pour les corriger. Le succès a été défini strictement comme le fait de supprimer le modèle non sécurisé et d'ajouter la défense correcte.

Principales contributions

1. Pipeline OSINT reproductible : Un pipeline piloté par des spécifications où l'ajout d'une nouvelle tâche nécessite seulement une seule entrée de données (prompt, requête, détecteurs), permettant à l'étude de se généraliser sans nouveau code.
2. Résultats d'attribution de provenance : Démonstration que la provenance du code est hautement récupérable à partir de caractéristiques de surface.
3. Analyse de la divergence de sécurité : Une comparaison granulaire des modèles de sécurité adoptés par les humains versus les modèles, identifiant des domaines spécifiques d'amélioration et de régression.
4. Validation multi-langage : Analyse pour déterminer si les différences de sécurité et de style sont des propriétés de la source ou du langage de programmation.
5. Vérificateur "fail-closed" : Un mécanisme qui redérive chaque nombre rapporté à partir des artefacts stockés, garantissant l'intégrité des résultats.

Résultats clés

1. Attribution de provenance

• Humain vs Modèle : Un classifieur sépare le code humain du code de modèle avec une précision de 93 % (F1 0,955 pour la classe modèle), surpassant de manière significative la ligne de base de la classe majoritaire de 78 %.
• Modèle vs Modèle : Un classifieur à 7 voies attribue les échantillons écrits par des modèles à leur origine spécifique avec une précision de 48 % (contre 17 % pour la ligne de base).
• Importance des caractéristiques : Le signal est dominé par le style (taille du code, structure, échafaudage) plutôt que par le contenu de sécurité. Le code des modèles est nettement plus volumineux, plus structuré, et inclut plus de gestion d'erreurs et d'imports que les extraits humains.
• Spécificité du langage : La frontière de provenance n'est pas symétrique entre les langages. Un classifieur entraîné sur JavaScript se transfère bien à Python (89 % de précision), mais l'inverse (Python vers JavaScript) chute vers le hasard (93 % de précision dans le contexte de la formulation spécifique de l'article, ce qui implique une baisse de performance par rapport à la ligne de base ou à la performance intra-langage, indiquant que le signal est dépendant du langage).

2. Divergence de sécurité

• Sécurité globale : Les modèles adoptent des modèles sûrs à un taux sensiblement plus élevé que le corpus humain. Le score de sécurité agrégé est de 0,40 pour les modèles contre 0,12 pour les humains.
• Domaines d'amélioration : Les modèles excellent dans les tâches où les directives de codage sécurisé modernes sont bien établies et basées sur des bibliothèques, telles que :
  • L'utilisation de fonctions de dérivation de clé (KDF) fortes pour le hachage de mots de passe.
  • L'implémentation de PKCE pour OAuth.
  • L'utilisation de requêtes paramétrées pour SQL.
  • Le verrouillage des algorithmes et la vérification de l'expiration pour les JWT.
• Domaines de régression (Le "danger de complétude") : Les modèles introduisent un mode de défaillance spécifique : les secrets codés en dur. Parce que les modèles visent à produire un programme "complet et exécutable", ils intègrent fréquemment des secrets fictifs (ex : client_secret = "placeholder") qui restent inchangés. En revanche, les réponses humaines omettent souvent ces valeurs, les laissant à la configuration du lecteur.
• Capacités de réparation : Dans l'étude de cas de réparation de vulnérabilité, les modèles ont atteint un taux de succès de 77 %. Cependant, 16 % des "réparations" étaient des corrections partielles où le modèle non sécurisé était supprimé mais la défense sécurisée n'était pas ajoutée (ex : supprimer un appel md5 mais stocker le mot de passe en texte clair).

3. Analyse multi-langage

• Sécurité : La divergence de sécurité (les modèles étant plus sûrs sur les modèles défensifs mais moins bons sur la gestion des secrets) se maintient de manière cohérente dans Python, JavaScript et Go.
• Style : Les différences stylistiques qui pilotent l'attribution de provenance varient selon l'écosystème du langage. Par exemple, la quantité d'échafaudage diffère considérablement entre Go et Python, ce qui signifie qu'un classifieur de provenance doit être calibré par langage.

Signification et affirmations

L'article affirme que les deux sources de code ne se classent pas simplement comme "sûr" vs "non sûr". Au lieu de cela, elles échouent à des endroits différents :

• Code Humain : Sujet aux omissions héritées du passé (ex : absence de jetons CSRF, hachage faible) en raison de l'ancienneté du matériel source.
• Code de Modèle : Sujet aux "dangers de complétude" (ex : secrets intégrés, absence de vérifications pour des menaces non mentionnées comme le SSRF) en raison de l'objectif de générer un programme autonome.

Implications pour la revue :
Les auteurs proposent que l'attribution de provenance serve de routeur pour la revue de code.

• Le code identifié comme généré par un humain devrait être orienté vers des vérifications d'omissions défensives héritées (hachage, valeurs par défaut des jetons).
• Le code identifié comme généré par un modèle devrait être orienté vers des vérifications de secrets intégrés et de configurations fictives.

Limites et modestie :

• L'étude repose sur la correspondance de motifs lexicaux (regex), et non sur l'analyse sémantique ; un score de sécurité élevé indique l'adoption d'un motif, pas une sécurité absolue.
• Le corpus de modèles est limité aux modèles à poids ouverts disponibles via une passerelle spécifique, excluant les principaux assistants commerciaux.
• Le classifieur de provenance est une expérience en monde fermé ; sa précision diminuerait probablement dans un environnement ouvert avec des modèles inconnus.
• Les résultats sont des instantanés ; le corpus humain (vieillissant) et les données d'entraînement des modèles (évolutives) évolueront avec le temps.

L'article conclut que bien que les modèles aient mieux absorbé le consensus de sécurité récent que le corpus humain archivé, ils introduisent de nouveaux risques par leur volonté de complétude. Le pipeline fourni permet à la communauté de réévaluer ces métriques à mesure que les modèles et les pratiques évoluent.