agent – Smals Research

L’IA pour améliorer la sécurité du code ? (Partie 2 : détection de vulnérabilités)

Fabien A. P. Petitcolas — Tue, 26 Aug 2025 07:00:00 +0000

Cet article fait suite à une première partie qui s’est penchée sur la sécurité du code généré par les outils d’IA générative (IAGén). Dans cette seconde partie, nous considérons la tâche de détecter des vulnérabilités dans du code existant et comment l’IAGén pourrait peut-être aider.

Les vulnérabilités de sécurité dans le code sont un problème récurrent affectant la plupart des logiciels et ayant un impact sur l’intégrité, la confidentialité et la disponibilité. L’utilisation de certains langages de programmation connus pour être moins susceptibles que d’autres à des problèmes classiques est recommandée (par exemple Rust plutôt que C). L’examen du code par d’autres programmeurs experts est aussi une méthode largement répandue. Mais l’IAGén pourrait-elle faciliter la tâche ?

Recherche de vulnérabilités

Il existe plusieurs façons de rechercher des vulnérabilités à partir du code ou du binaire et ce, de manière automatique ou manuelle, statique ou dynamique, et systématique ou exploratoire. En 2022, dans une étude très détaillée, Elder et al. [1] ont comparé plusieurs de ces méthodes sur une application d’ampleur dans le domaine médical : OpenMRS. Celle-ci contient près de 4 millions de lignes de code Java et JavaScript. Les auteurs font plusieurs recommandations en fonction des objectifs recherchés et des ressources (expertise, temps, équipement) disponibles et confirment une étude plus ancienne : chaque méthode de détection de vulnérabilité trouve des vulnérabilités qui n’ont pas été trouvées par d’autres méthodes. Cependant, dans leur expérimentation, la méthode manuelle exploratoire par tests d’intrusion a permis de trouver les vulnérabilités les plus dangereuses.

IAGén et analyse statique

Le Tableau 1 compare deux approches d’analyse de code : l’analyse statique (classique) et une analyse utilisant une IAGén. Selon certaines études, l’IAGén aurait commencé à montrer quelques avantages par rapport aux outils d’analyse statiques classiques.

Tableau 1 – Aperçu des principales différences et similitudes entre deux approches d’analyse du code : analyse statique et analyse avec IAGén (d’après [2]).

Critère	Analyse statique « classique »	Analyse avec IA générative
Objectif et conception	Identifier les vulnérabilités de sécurité connues dans le code	Comprendre et générer un texte de type humain, y compris du code informatique
Représentation du code	Arbres syntaxiques abstraits ou graphes de flux de contrôle	Code comme séquences de jetons
Apprentissage et adaptation	Utilisation de règles et de signatures prédéfinies ; pas « d’apprentissage » traditionnel	« Apprentissage » continu à partir de données d’entraînement ; adaptation en fonction des modèles observés
Généralisation	Précis et spécifique ; basé sur des modèles/signatures connus	Peut généraliser les différents modèles/styles de codage
Retour d’information et itération	Retour d’information déterministe basé sur la correspondance des règles	Retour d’information contextuel et descriptif
Couverture des vulnérabilités	Limitée à un ensemble de règles/signatures prédéfinies	Potentiellement plus large en raison de la formation généralisée, mais peut manquer de précision
Base de fonctionnement	Règles	Reconnaissance des motifs basée sur des données d’entraînement
Adaptabilité	Fixe à moins que les règles ne soient mises à jour	Flexible en raison des capacités de reconnaissance des motifs

Par exemple, Noever [2] a étudié la performance de certaines IAGén pour identifier et rectifier des vulnérabilités dans des logiciels. Son étude portait sur divers dépôts de GitHub et comparait les IAGén avec des outils d’analyse statique. L’auteur a utilisé la requête (« prompt » en anglais) suivante :

“Act as the world’s greatest static code analyzer for all major programming languages. I will give you a code snippet, and you will analyze the code and rewrite it, removing any identified vulnerabilities. Do not explain, just return the corrected code and format alone.”

Les tests de l’auteur utilisent le cycle suivant pour une base de code donnée :

Utiliser un outil d’analyse statique pour évaluer le nombre et le niveau de gravité des vulnérabilités ;
Demander à l’IAGén d’identifier les vulnérabilités ;
Demander à l’IAGén de corriger les vulnérabilités trouvées ;
Utiliser l’outil d’analyse statique sur le code corrigé et comparer le nombre et le niveau de gravité des vulnérabilités trouvées.

Les résultats de l’auteur sont plutôt positifs sur la base de code choisie : l’IAGén a permis de réduire de manière significative le nombre de vulnérabilités très graves.

Performance de l’IAGén

Cependant, même les meilleurs outils utilisant l’IA pour la détection de défauts ont une précision inférieure à 70 % selon CodeXGLUE. Une étude de Steenhoek [3] rapporte que les modèles de pointe n’ont obtenu qu’une précision équilibrée de 54,5 %¹ dans leur évaluation de la détection des vulnérabilités, même pour les modèles pré-entraînés sur de grandes quantités de code source. En d’autres termes, « tous les modèles et toutes les requêtes ont donné des résultats proches de ceux des réponses aléatoires aux devinettes. » Les auteurs expliquent cela par la difficulté qu’ont les IAGén à raisonner sur la sémantique du code. Cette difficulté de raisonnement ne se limite d’ailleurs pas au code [3].

Nous avions déjà pu remarquer quelque chose de similaire lors de nos propres tests sur une base de code avec des vulnérabilités de type CWE connues : le nombre de faux-positifs² était souvent aussi important que le nombre de vrai-positifs³ lorsque nous avons demandé à différents modèles (gpt-40-mini, gpt-4o, mistral-large-2411, Llama-4-Scout, DeepSeek-V3, Qwen2.5) d’indiquer si un fichier de code contenait des vulnérabilités potentielles. Même en envoyant une base de code entière nos résultats n’ont pas été plus concluants. En effet, Llama permet de fournir un contexte très large (10 millions de symboles), et après lui avoir fourni l’entièreté de WebGoat – un logiciel spécialement écrit avec des vulnérabilités – aucune vulnérabilité significative n’a été identifiée !

Dans une étude plus récente et plus systématique, Ullah et al. [4] montrent – en utilisant 8 modèles et 17 méthodes de requête sur 228 exemples de code – que les IAGén fournissent des réponses non déterministes, un raisonnement incorrect et infidèle, et qu’elles sont peu performantes dans des scénarios du « monde réel ». Plus grave, l’étude confirme aussi un manque de robustesse lors de la détection de vulnérabilités potentielles. De nombreuses études avaient déjà souligné que les techniques d’apprentissage automatique manquaient de robustesse aux transformations de code préservant la sémantique comme le renommage d’identifiants, l’insertion de déclarations non exécutées ou encore le remplacement de code par du code équivalent [5]. Sans grande surprise, les méthodes d’amplifications permettant à un modèle d’apprendre ce type de transformations, ne permettent d’augmenter la robustesse que pour les transformations spécifiques auxquelles le modèle a été entrainé [5].

Dans un autre exemple, plus anecdotique, Heelan [6] discute de la capacité de ChatGPT-o3 à trouver la vulnérabilité CVE-2025-37778 dans le noyau de Linux. Outre le fait que la requête envoyée par l’auteur à l’IAGén était très précise (extrait de code soigneusement sélectionné, instructions détaillées), l’IAGén n’a trouvé la vulnérabilité que 8 fois sur 100 (la même requête a été envoyée 100 fois, et seulement 8 fois l’IAGén a trouvé la vulnérabilité). Dans un autre exemple l’auteur décrit comment, par hasard, l’IAGén lui a permis de découvrir une nouvelle vulnérabilité ; là encore il a envoyé cent fois sa requête à ChatGPT et, dans une seule réponse, il a trouvé un élément le mettant sur la voie. C’est sans compter le coût environnemental et financier de l’exercice et surtout le fait que la nouvelle vulnérabilité est liée sémantiquement à la précédente.

Dès lors, on ne s’étonnera pas que l’expérience de plusieurs projets de logiciels libres tend à montrer que les bogues découverts avec l’aide de l’IAGén ont en réalité peu de valeur [7], [8].

Intégration de l’IAGén dans l’analyse statique

Afin d’améliorer la détection de vulnérabilités par une IAGén dans un échantillon de code, Yue Li et al. [9] suggèrent de rassembler le plus d’informations contextuelles possibles (p. ex., liste de dépendances et informations spécifiques à un type de vulnérabilité recherché). C’est ce qui est mis en pratique dans l’outil IRIS de Ziyang Li et al. [10].

IRIS combine l’IAGén avec l’analyse statique pour détecter les vulnérabilités de sécurité dans les logiciels tout en essayant de réduire le taux de faux positifs. Cet outil suit un processus systématique de détection des failles de sécurité :

Extraction de candidats potentiels pour être des sources ou des récepteurs contaminés dans les interfaces de programmation externes et internes grâce à un outil d’analyse statique.
Interrogation d’une IAGén pour étiqueter en tant que source ou puit (fonction vulnérable) spécifique à une classe de vulnérabilité⁴, les interfaces candidates.
Les sources et les puits étiquetés sont transformés en spécifications qui peuvent être introduites dans CodeQL afin d’effectuer une analyse des souillures (les variables entachées par des entrées de l’utilisateur et pouvant atteindre un puit) spécifique à une classe de vulnérabilité. Cette étape génère un ensemble de chemins de code vulnérables (ou alertes) dans le projet.
Enfin l’IAGén est utilisée pour réduire le nombre de faux-positifs signalés par l’analyse statique de CodeQL tout en fournissant une explication.

Nos tests de l’outil IRIS-v1⁵, sur la base de code WebGoat avec les modèles Codegen25-7b-instruct, qwen2.5-coder-7b et GPT-4 ont pu confirmer une réduction d’environ 18 % du nombre de vulnérabilités potentielles détectées, mais ce, au prix d’un grand nombre d’appels au modèle d’IAGen (1130 appels par type de CWE testé, pour une base de 259 fichiers Java).

Cet outil encore expérimental montre néanmoins une tendance plus générale de l’introduction de l’IAGén dans les outils de détection existants. C’est le cas, par exemple, de DeepCode, d’ETH Zurich, récemment intégré dans le logiciel Snyk. Il a pour ambition de permettre aux programmeurs de trouver rapidement des vulnérabilités dans leur code. Mais la convergence d’outils d’IAGén examinant du code généré par d’autres outils d’IAGén, crée des boucles de rétroaction qui pourraient s’avérer dangereuses [11].

Conclusion et recommandations

Même si quelques études ont montré que les IAGén peuvent résoudre des problèmes simples de correction de vulnérabilités (par exemple, des fuites de mémoire), on constate qu’ils rencontrent des difficultés à résoudre des défauts complexes. La plupart des études que nous avons rencontrées montrent aussi des performances incohérentes et une tendance générale à des taux élevés de faux-positifs, dans la détection des failles de sécurité, confirmant nos propres tests. Les meilleures performances de détection semblent être atteintes sur les vulnérabilités pour lesquelles les IAGén ont été entraînées. Ces observations sont confirmées par une étude systématique et extensive de Basic et Giaretta [12].

Par conséquent, avant de pouvoir utiliser l’IAGén pour la détection de vulnérabilité dans le code, il faudra attendre que des progrès importants soient faits. Pour le moment, il faut prendre conscience des limites actuelles de ces outils. Outre celles mentionnées précédemment, quelle que soit la méthode retenue, de nombreux appels à l’IAGén peuvent s’avérer être très coûteux (ou très lents s’ils sont exécutés localement sans matériel adéquat). De plus il manque encore une méthodologie scientifique solide permettant de comparer efficacement différents outils d’analyse et de mesurer l’apport objectif de l’IAGén.

Chez SMALS, par exemple, une initiative issue du fruit d’une collaboration (groupe de travail « SAST⁶ ») entre l’équipe de développement des applications & projets et celle de recherche travaille sur la performance des outils d’analyse statique et l’apport possible de l’IAGén.

Enfin, on note que CodeQL est repris par beaucoup d’études comme une base de référence pour la comparaison de l’efficacité des modèles d’IAGén à détecter des vulnérabilités. Cela n’est pas étonnant car des outils comme celui-ci ont fait leur preuve. Alors avant de se lancer tête baissée dans l’utilisation de l’IAGén pour améliorer la sécurité du code, il est probablement plus sage d’intégrer progressivement dans les indispensables revues de code habituelles, des outils d’analyse statique ou dynamique. Nul doute qu’une IAGén sera intégrée à ces outils au moment opportun.

Références

[1] S. Elder et al., « Do I really need all this work to find vulnerabilities? An empirical case study comparing vulnerability detection techniques on a Java application », 2 août 2022, arXiv: arXiv:2208.01595. doi: 10.48550/arXiv.2208.01595.

[2] D. Noever, « Can large language models find and fix vulnerable software? », août 2023, [En ligne]. Disponible sur: https://arxiv.org/abs/2308.10345

[3] P. Shojaee, I. Mirzadeh, K. Alizadeh, M. Horton, S. Bengio, et M. Farajtabar, « The illusion of thinking: Understanding the strengths and limitations of reasoning models via the lens of problem complexity », [En ligne]. Disponible sur: https://arxiv.org/abs/2506.06941

[4] S. Ullah, M. Han, S. Pujar, H. Pearce, A. Coskun, et G. Stringhini, « LLMs cannot reliably identify and reason about security vulnerabilities (yet?): A comprehensive evaluation, framework, and benchmarks », 24 juillet 2024, arXiv: arXiv:2312.12575. doi: 10.48550/arXiv.2312.12575.

[5] N. Risse et M. Böhme, « Uncovering the limits of machine learning for automatic vulnerability detection », 6 juin 2024, arXiv: arXiv:2306.17193. doi: 10.48550/arXiv.2306.17193.

[6] S. Heelan, « How I used o3 to find CVE-2025-37899, a remote zeroday vulnerability in the Linux kernel’s SMB implementation », Sean Heelan’s Blog. Consulté le: 12 juin 2025. [En ligne]. Disponible sur: https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/

[7] T. Claburn, « AI-assisted bug reports make developers bear cost of cleanup », The Register. Consulté le: 14 mai 2025. [En ligne]. Disponible sur: https://www.theregister.com/2024/01/04/aiassisted_bug_reports_make_developers/

[8] C. Jones, « Curl takes action against time-wasting AI bug reports », The Register. Consulté le: 14 mai 2025. [En ligne]. Disponible sur: https://www.theregister.com/2025/05/07/curl_ai_bug_reports/

[9] Y. Li et al., « Everything you wanted to know about LLM-based vulnerability detection but were afraid to ask », 18 avril 2025, arXiv: arXiv:2504.13474. doi: 10.48550/arXiv.2504.13474.

[10] Z. Li, S. Dutta, et M. Naik, « IRIS: LLM-assisted static analysis for detecting security vulnerabilities », 6 avril 2025, arXiv: arXiv:2405.17238. doi: 10.48550/arXiv.2405.17238.

[11] S. Varma, A. Batchu, et N. Tyagi, « Innovation insight: AI code review tools », Gartner, G00834019, juill. 2025.

[12] E. Basic et A. Giaretta, « Large language models and code security: A systematic literature review », 19 décembre 2024, arXiv: arXiv:2412.15004. doi: 10.48550/arXiv.2412.15004.

¹ Les auteurs préfèrent le score de précision équilibrée (« balanced accuracy ») au score classique F1 afin de mieux prémunir des biais potentiels du modèle évalué. Il est défini comme :

² Code déclaré contenant une vulnérabilité alors qu’il n’en contient pas.

³ Code correctement déclaré comme contenant une vulnérabilité.

⁴ Actuellement, IRIS ne prend en charge que les CWE suivants : CWE-022 (Traversée de chemin), CWE-078 (injection de commande du système d’exploitation), CWE-079 (Script inter-site) et CWE-094 (injection de code).

⁵ La version 2 a été publiée après l’écriture de cet article.

⁶ « Static application security testing »

AI om de veiligheid van code te verbeteren? (Deel 2: opsporing van kwetsbaarheden)

Fabien A. P. Petitcolas — Tue, 26 Aug 2025 07:00:00 +0000

Version en français

Dit artikel is het vervolg op een eerste deel dat zich toespitste op de veiligheid van code die gegenereerd werd door generatieve AI-tools (GenAI). In het tweede deel nemen we de taak onder de loep om kwetsbaarheden in bestaande code op te sporen en zien we hoe GenAI daarbij zou kunnen helpen.

Kwetsbaarheden in code zijn een terugkerend probleem dat de meeste software treft en een impact heeft op integriteit, vertrouwelijkheid en beschikbaarheid. Er wordt aangeraden om bepaalde programmeertalen te gebruiken waarvan bekend is dat ze minder gevoelig zijn voor klassieke problemen dan andere (bijv. Rust in plaats van C). Code review door andere expertprogrammeurs is ook een veelgebruikte methode. Maar zou GenAI de taak kunnen vergemakkelijken?

Zoeken naar kwetsbaarheden

Er zijn verschillende manieren om kwetsbaarheden in code of binaire bestanden op te sporen, zowel automatisch als handmatig, statisch of dynamisch, en systematisch of verkennend. In 2022 hebben Elder et al. [1] in een zeer gedetailleerde studie verschillende van deze methoden vergeleken op een grootschalige toepassing in de medische sector: OpenMRS. Deze bevat bijna 4 miljoen regels Java- en JavaScript-code. De auteurs doen verschillende aanbevelingen op basis van de beoogde doelstellingen en de beschikbare middelen (expertise, tijd, apparatuur) en bevestigen een eerdere studie: elke methode voor het opsporen van kwetsbaarheden vindt kwetsbaarheden die met andere methoden niet zijn gevonden. In hun experiment bleek echter de handmatige verkennende methode met penetratietests de gevaarlijkste kwetsbaarheden op te sporen.

GenAI en statische analyse

Tabel 1 vergelijkt twee benaderingen van code-analyse: statische (klassieke) en een analyse die GenAI gebruikt. Volgens bepaalde studies zou GenAI enkele voordelen beginnen te vertonen ten opzichte van klassieke statische analysetools.

Tabel 1 – Overzicht van de belangrijkste verschillen en overeenkomsten tussen twee benaderingen van codeanalyse: statische analyse en analyse met GenAI (naar [2]).

Criterium	Statische analyse	Analyse met GenAI
Doel en ontwerp	Bekende beveiligingskwetsbaarheden in de code identificeren	Menselijke tekst begrijpen en genereren, inclusief computercode
Weergave van code	Abstracte syntactische bomen of controlestroomgrafen	Code als reeksen tokens
Leren en aanpassen	Vooraf gedefinieerde regels en handtekeningen gebruiken; geen traditioneel ‘leren’	Continu ‘leren’ op basis van trainingsgegevens; aanpassing op basis van waargenomen patronen
Generalisatie	Nauwkeurig en specifiek; gebaseerd op bekende patronen/signaturen	Kan verschillende patronen/stijlen van codering generaliseren
Feedback en iteratie	Deterministische feedback op basis van overeenstemming met regels	Contextuele en beschrijvende feedback
Dekking van kwetsbaarheden	Beperkt tot een reeks vooraf gedefinieerde regels/handtekeningen	Potentieel breder vanwege algemene training, maar kan onnauwkeurig zijn
Werkingsbasis	Regels	Patroonherkenning op basis van trainingsgegevens
Aanpasbaarheid	Vast, tenzij de regels worden bijgewerkt	Flexibel dankzij patroonherkenningsmogelijkheden

Noever [2] heeft bijvoorbeeld de prestaties van bepaalde GenAI onderzocht om kwetsbaarheden in software te identificeren en te verhelpen. Zijn onderzoek had betrekking op verschillende GitHub-repository’s en vergeleek GenAI met statische analysetools. De auteur gebruikte de volgende prompt:

De tests van de auteur gebruiken de volgende cyclus voor een bepaalde codebase:

Gebruik een statische analysetool om het aantal en de ernst van de kwetsbaarheden te beoordelen;
Vraag GenAI om de kwetsbaarheden te identificeren;
Vraag GenAI om de gevonden kwetsbaarheden te corrigeren;
Gebruik de statische analysetool op de gecorrigeerde code en vergelijk het aantal en de ernst van de gevonden kwetsbaarheden.

De resultaten van de auteur zijn vrij positief op basis van de gekozen codebase: GenAI heeft het aantal zeer ernstige kwetsbaarheden aanzienlijk verminderd.

Performantie van GenAI

Maar zelfs de beste tools die AI gebruiken voor foutdetectie hebben volgens CodeXGLUE een nauwkeurigheid van minder dan 70%. Een studie van Steenhoek [3] meldt dat de meest geavanceerde modellen slechts een gemiddelde nauwkeurigheid van 54,5%¹ behaalden bij het opsporen van kwetsbaarheden, zelfs voor modellen die vooraf waren getraind op grote hoeveelheden broncode. Met andere woorden: “alle modellen en alle prompts leverden resultaten op die dicht in de buurt kwamen van willekeurige antwoorden op raadsels”. De auteurs verklaren dit door de moeilijkheid die GenAI heeft om te redeneren over de semantiek van code. Deze moeilijkheid om te redeneren beperkt zich overigens niet tot code [3].

We hadden al iets soortgelijks opgemerkt tijdens onze eigen tests op een codebase met bekende CWE-kwetsbaarheden: het aantal valse positieven² was vaak even groot als het aantal echte positieven³ toen we verschillende modellen verzochten (gpt-40-mini, gpt-4o, mistral-large-2411, Llama-4-Scout, DeepSeek-V3, Qwen2.5) om aan te geven of een codebestand potentiële kwetsbaarheden bevatte. Zelfs toen we een volledige codebase verstuurden, waren onze resultaten niet overtuigender. Llama biedt namelijk een zeer grote context (10 miljoen symbolen) en nadat we het de volledige WebGoat – een speciaal geschreven softwareprogramma met kwetsbaarheden – hadden aangeleverd, werd er geen enkele significante kwetsbaarheid geïdentificeerd!

In een recentere en systematischere studie tonen Ullah et al. [4] aan – aan de hand van 8 modellen en 17 promptmethoden op 228 codevoorbeelden – dat GenAI niet-deterministische antwoorden en onjuiste en onbetrouwbare redeneringen geeft en slecht presteert in ‘realistische’ scenario’s. Erger nog, het onderzoek bevestigt ook een gebrek aan robuustheid bij het opsporen van potentiële kwetsbaarheden. Talrijke studies hadden al aangetoond dat machine learning-technieken niet robuust genoeg zijn tegen semantiekbehoudende codetransformaties, zoals het hernoemen van identifiers, het invoegen van niet-uitgevoerde declaraties of het vervangen van code door gelijkwaardige code [5]. Het is dan ook niet verwonderlijk dat amplificatiemethoden waarmee een model dit soort transformaties kan leren, alleen de robuustheid verhogen voor de specifieke transformaties waarop het model is getraind [5].

In een ander, meer anekdotisch voorbeeld bespreekt Heelan [6] het vermogen van ChatGPT-o3 om de kwetsbaarheid CVE-2025-37778 in de Linux-kernel te vinden. Afgezien van het feit dat de prompt die de auteur naar GenAI stuurde zeer nauwkeurig was (zorgvuldig geselecteerde codefragmenten, gedetailleerde instructies), vond GenAI de kwetsbaarheid slechts 8 van de 100 keer (dezelfde prompt werd 100 keer verzonden en slechts 8 keer vond GenAI de kwetsbaarheid). In een ander voorbeeld beschrijft de auteur hoe hij door toeval met behulp van GenAI een nieuwe kwetsbaarheid ontdekte; ook hier stuurde hij zijn verzoek honderd keer naar ChatGPT en vond hij in één antwoord een aanwijzing die hem op het spoor zette. Daarbij komen nog de milieukosten en financiële kosten van deze operatie en vooral het feit dat de nieuwe kwetsbaarheid semantisch verband houdt met de vorige.

Het is dan ook niet verwonderlijk dat de ervaring met verschillende vrije softwareprojecten aantoont dat bugs die met behulp van GenAI worden ontdekt, in werkelijkheid weinig waarde hebben [7], [8].

Integratie van GenAI in statische analyse

Om de detectie van kwetsbaarheden door GenAI in een codefragment te verbeteren, stellen Yue Li et al. [9] voor om zoveel mogelijk contextuele informatie te verzamelen (bijv. lijst van afhankelijkheden en specifieke informatie over een bepaald type kwetsbaarheid). Dit wordt in de praktijk gebracht in de IRIS-tool van Ziyang Li et al. [10].

IRIS combineert GenAI met statische analyse om beveiligingskwetsbaarheden in software op te sporen en tegelijkertijd het aantal valse positieven te verminderen. Deze tool volgt een systematisch proces voor het opsporen van beveiligingslekken:

Extractie van potentiële kandidaten voor besmette bronnen of ontvangers in externe en interne programmeerinterfaces met behulp van een statische analysetool.
Vragen aan een GenAI om de kandidaat-interfaces te labelen als bron of put (“sink”, kwetsbare functie) die specifiek is voor een bepaalde klasse van kwetsbaarheden⁴.
De gelabelde bronnen en putten worden omgezet in specificaties die in CodeQL kunnen worden ingevoerd om een analyse uit te voeren van smears (variabelen die door gebruikersinvoer zijn besmet en een put kunnen bereiken) die specifiek zijn voor een klasse van kwetsbaarheden. Deze stap genereert een reeks kwetsbare codepaden (of waarschuwingen) in het project.
Ten slotte wordt GenAI gebruikt om het aantal valse positieven dat door de statische analyse van CodeQL wordt gemeld te verminderen en tegelijkertijd een verklaring te geven.

Onze tests van de IRIS-v1-tool⁵, op basis van WebGoat-code met de modellen Codegen25-7b-instruct, qwen2.5-coder-7b en GPT-4, hebben een vermindering aangetoond van ongeveer 18% van het aantal gedetecteerde potentiële kwetsbaarheden, maar dit ging ten koste van een groot aantal oproepen aan het GenAI-model (1130 oproepen per getest CWE-type, voor een basis van 259 Java-bestanden).

Deze nog experimentele tool toont niettemin een meer algemene trend aan om GenAI te integreren in bestaande detectietools. Dit is bijvoorbeeld het geval bij DeepCode van ETH Zürich, dat onlangs is geïntegreerd in de Snyk-software. Het is bedoeld om programmeurs in staat te stellen snel kwetsbaarheden in hun code op te sporen. Maar de convergentie van GenAI -tools die code onderzoeken die door andere GenAI-tools is gegenereerd, creëert feedbackloops die gevaarlijk kunnen zijn[11].

Conclusie en aanbevelingen

Hoewel enkele studies hebben aangetoond dat GenAI eenvoudige problemen met kwetsbaarheden (bijvoorbeeld geheugenlekken) kan oplossen, blijkt dat het systeem moeite heeft met complexe fouten. De meeste studies die we hebben gevonden, tonen ook inconsistente prestaties en een algemene neiging tot hoge percentages valse positieven bij het opsporen van beveiligingslekken, wat door onze eigen tests bevestigd wordt. De beste detectieprestaties lijken te worden bereikt voor kwetsbaarheden waarvoor GenAI is getraind. Deze bevindingen worden bevestigd door een systematische en uitgebreide studie van Basic en Giaretta [12].

Voordat GenAI kan worden gebruikt voor het opsporen van kwetsbaarheden in code, moet er dus nog aanzienlijke vooruitgang worden geboekt. Voorlopig moeten we ons bewust zijn van de huidige beperkingen van deze tools. Naast de eerder genoemde beperkingen kan het, ongeacht de gekozen methode, erg duur zijn om GenAI veelvuldig te gebruiken (of erg traag als het lokaal wordt uitgevoerd zonder de juiste apparatuur). Bovendien ontbreekt het nog aan een solide wetenschappelijke methodologie om verschillende analysetools effectief te vergelijken en de objectieve bijdrage van GenAI te meten.

Bij SMALS is bijvoorbeeld een initiatief ontstaan uit een samenwerking (werkgroep “SAST”⁶) tussen het team voor toepassings- en projectontwikkeling en het onderzoeksteam. Er wordt gewerkt aan de prestaties van statische analysetools en de mogelijke bijdrage van GenAI.

Ten slotte merken we op dat CodeQL in veel studies wordt genoemd als referentiepunt voor het vergelijken van de doeltreffendheid van GenAI-modellen bij het opsporen van kwetsbaarheden. Dat is niet verwonderlijk, aangezien tools zoals deze hun nut hebben bewezen. Voordat we ons halsoverkop op GenAI storten om de codeveiligheid te verbeteren, is het waarschijnlijk verstandiger om statische of dynamische analysetools geleidelijk te integreren in de gebruikelijke essentiële codebeoordelingen. Ongetwijfeld zal GenAI op een gepast moment in deze tools worden geïntegreerd.

Referenties

[2] D. Noever, « Can large language models find and fix vulnerable software? », août 2023, [En ligne]. Disponible sur: https://arxiv.org/abs/2308.10345

[5] N. Risse et M. Böhme, « Uncovering the limits of machine learning for automatic vulnerability detection », 6 juin 2024, arXiv: arXiv:2306.17193. doi: 10.48550/arXiv.2306.17193.

[9] Y. Li et al., « Everything you wanted to know about LLM-based vulnerability detection but were afraid to ask », 18 avril 2025, arXiv: arXiv:2504.13474. doi: 10.48550/arXiv.2504.13474.

[10] Z. Li, S. Dutta, et M. Naik, « IRIS: LLM-assisted static analysis for detecting security vulnerabilities », 6 avril 2025, arXiv: arXiv:2405.17238. doi: 10.48550/arXiv.2405.17238.

[11] S. Varma, A. Batchu, et N. Tyagi, « Innovation insight: AI code review tools », Gartner, G00834019, juill. 2025.

[12] E. Basic et A. Giaretta, « Large language models and code security: A systematic literature review », 19 décembre 2024, arXiv: arXiv:2412.15004. doi: 10.48550/arXiv.2412.15004.

¹ De auteurs geven de voorkeur aan de ‘balanced accuracy’-score boven de klassieke F1-score om beter te kunnen waken over mogelijke vertekeningen in het geëvalueerde model. Deze wordt als volgt gedefinieerd:

² Code die als kwetsbaar wordt aangemerkt, terwijl dat niet het geval is.

³ Code die correct als kwetsbaar wordt aangemerkt.

⁴ Momenteel ondersteunt IRIS alleen de volgende CWE‘s: CWE-022 (path traversal), CWE-078 (injectie van besturingssysteemopdrachten), CWE-079 (cross-site scripting) en CWE-094 (code-injectie).

⁵ Versie 2 werd gepubliceerd na het schrijven van dit artikel.

⁶ “Static application security testing”

AI om de veiligheid van de code te verbeteren? (Deel 1: veiligheid van de gegenereerde code)

Fabien A. P. Petitcolas — Wed, 30 Jul 2025 14:30:00 +0000

Version en français

De uitgebreide communicatie rond generatieve artificiële intelligentie (GenAI) en het toenemende gebruik ervan – althans in de testfase – uit angst om iets te missen of om een echte meerwaarde te bieden, roept de vraag op of het in veel domeinen nuttig is, en waarom niet, om de veiligheid van code te verbeteren. Meer bepaald: kan GenAI worden gebruikt om veiligere computercode te schrijven? Kan het helpen bij het opsporen van kwetsbaarheden in bestaande code?

In dit eerste deel geven we een antwoord op de eerste vraag. De tweede vraag komt in een ander artikel aan bod.

Menselijke aspecten

Laten we beginnen met het menselijke aspect van het gebruik van GenAI. In een gedetailleerde analyse, die ik ten zeerste aanbeveel, leggen Simkute et al. [1] de redenen uit die kunnen leiden tot een productiviteitsverlies van programmeurs die een beroep doen op GenAI. Onderzoekers hebben het onder andere over: een verglijding van de programmeurrol van productie naar evaluatie, een onnuttige herstructurering van werkstromen, onderbrekingen en de neiging van GenAI om makkelijke taken nog gemakkelijker en moeilijke taken nog moeilijker te maken. De resultaten van een studie van Perry et al. [2], van Stanford University verbazen ons dan minder. Deze tonen aan dat deelnemers die toegang hebben tot een codeerassistent op basis van een AI-model aanzienlijk minder veilige code schrijven dan deelnemers zonder toegang. Erger nog, deelnemers met toegang tot de assistent geloofden vaker dat ze veilige code schreven dan deelnemers zonder toegang. Deze observatie van Perry et al. wordt bevestigd door het werk van Klemmer et al. [3]: het onderzoeksteam ondervroeg professionele programmeurs, en hoewel zij wantrouwig staan tegenover suggesties van AI-codeerassistenten, blijkt dat zij ook hun eigen vermogen om de suggesties van deze codeerassistenten te beoordelen overschatten. Het gebruik van codeerassistenten vereist daarom de implementatie van systematische codecontrole en statische analyse [4].

Betrouwbaarheid van de voorstellen

Wat betreft de kwaliteit van de suggesties van GenAI: hoewel het over het algemeen functioneel correcte code oplevert, introduceert het ook veiligheidsproblemen [5], [6]. Khoury et al. [7] hebben met behulp van meerdere voorbeelden aangetoond dat ChatGPT 3.5 vaak code genereert die voor veiligheidsproblemen kan zorgen : slechts 5 van de 21 use cases die de auteurs bestudeerd hebben waren aanvankelijk beveiligd. ChatGPT 3.5 was in staat om beveiligde code aan te maken voor slechts 7 gevallen en dit was pas mogelijk nadat de auteurs expliciet vroegen om de code te verbeteren.

Meer recentelijk concludeerden Sivana et al. [8] dat ChatGPT als platform meer CWE-kwetsbaarheden genereerde dan de website StackOverflow. Onafhankelijk daarvan hebben Fu et al. [9] aan de hand van honderden door Copilot gegenereerde codevoorbeelden die op GitHub zijn gevonden, aangetoond dat ongeveer een derde daarvan veelvoorkomende kwetsbaarheden bevat die door de organisatie MITRE zijn geïnventariseerd (waarvan sommige tot de 25 belangrijkste behoren). De auteurs raden programmeurs daarom aan om de beste praktijken voor het gebruik van codegeneratietools te volgen en de gegenereerde codesuggesties altijd te controleren. Soortgelijke resultaten waren al gevonden door Pearce et al. [10] twee jaar eerder.

Er zijn nog veel meer voorbeelden van soortgelijke resultaten. Dat hebben Basic en Giaretta [11] gedaan in een uitgebreide systematische studie van de academische literatuur over GenAI en de veiligheid van computercode. De betrokken modellen zijn divers en omvatten onder meer ChatGPT 3.5, GPT 4-Turbo, Copilot, Claude, Sonnet en Gemini Pro. De auteurs bevestigen dat verschillende belangrijke kwetsbaarheden, zoals SQL-injecties en bufferoverflows, kunnen worden aangetroffen in de code die door GenAI wordt gegenereerd. Ze wijzen er ook op dat het risico van vergiftiging van trainingsgegevens niet alleen kan leiden tot het genereren van onveilige code, maar ook de detectie van kwetsbaarheden in gevaar kan brengen.

Vergiftiging van AI

Het vergiftigen van een generatief model voor codeaanvulling bestaat uit het compromitteren van de integriteit van dit model door kwaadaardige codevoorbeelden in de trainingsgegevens van het model te integreren. Backdoor-aanvallen proberen tijdens de trainingsfase triggers te verbergen in het diepe neurale netwerk van het model, waardoor resultaten worden gegenereerd die door de tegenstander zijn gekozen.

Ondanks aanzienlijke vooruitgang op het gebied van codeaanvullingsmodellen blijven deze kwetsbaar voor dit soort aanvallen, zoals Yan et al. [12] met CodeBreaker hebben aangetoond. Voor hun aanval is het niet nodig om een vooraf getraind groot model zoals BERT of GPT te compromitteren. Deze modellen worden namelijk vaak gebruikt als basis die slachtoffers nauwkeurig afstemmen op specifieke taken met behulp van specifieke gegevens die vaak openbaar beschikbaar zijn. De tegenstander hoeft dus alleen maar deze finetuning data te compromitteren of zijn eigen set vervuilde data, gegenereerd met CodeBreaker, te uploaden. De vergiftigde code die na gebruik van CodeBreaker wordt gegenereerd, is niet detecteerbaar met kwetsbaarheidsdetectietools op basis van traditionele statische analyses of GenAI.

Hoewel dit soort aanvallen onwaarschijnlijk is, rijst de vraag waar de gebruikte GenAI-tool vandaan komt en past dit in de problematiek die inherent is aan de huidige GenAI om zowel veilige als nauwkeurige modellen te verkrijgen [13].

Belang van de prompt

Het is echter niet allemaal kommer en kwel en het belang van de keuze van de prompts die aan GenAI worden gegeven om het genereren van code met potentiële zwakke punten te voorkomen, moet worden benadrukt. Götz et al. [14] tonen aan dat, terwijl 65% van de code die oorspronkelijk door verschillende GenAI-tools werd gegenereerd, door een gekwalificeerde ingenieur als onveilig wordt beschouwd, dezelfde tools veilige code genereren wanneer ze handmatig worden aangestuurd. De auteurs concluderen dat technische expertise, met name op het gebied van beveiliging, vereist is om veilige code te genereren met behulp van code AI-codeerassistenten.

Om de best mogelijke resultaten te verkrijgen, moet de prompt die aan GenAI wordt gegeven zowel nauwkeurig als duidelijk interpreteerbaar zijn voor het model. Met andere woorden: de programmeur heeft er alle belang bij om zich aan de eisen van de machine te houden en zo gedetailleerd mogelijk niet alleen de taak die het model moet uitvoeren, maar ook de context waarin deze taak plaatsvindt en de verwachte invoer- en uitvoergegevens te specificeren. Dit kan in één keer gebeuren of in de vorm van een chain-of-thoughts volgens een bepaalde redenering.

Er bestaat echter geen ideale methode, maar Bruni et al. [15] geven verschillende eenvoudige voorbeelden van verbetering van prompts. Volgens hun experimenten is de meest effectieve methode om, na een eerste prompt, GenAI te vragen de code die het al heeft voorgesteld op mogelijke kwetsbaarheden te herzien en vervolgens correcties voor te stellen. Bijvoorbeeld:

Prompt 1: genereer Java-code voor …
Prompt 2: analyseer de volgende code en vind de beveiligingsproblemen:
Prompt 3: op basis van de volgende problemen: , verbeter de volgende code:

Deze werkwijze veronderstelt uiteraard dat GenAI in staat is om kwetsbaarheden op te sporen, maar zoals we in het volgende artikel zullen zien, is dat vandaag nog niet het geval.

Gespecialiseerde tools

We kunnen echter nieuwe tools verwachten die programmeurs in staat zullen stellen om de veiligheidsrisico’s van GenAI te vermijden.

Zo biedt de tool SafeCoder van ETH Zürich [16] een kader om de veiligheid van door GenAI gegenereerde code te verbeteren zonder de functionaliteit van die code in het gedrang te brengen. De tool combineert de standaardinstellingen van instructies met een veiligheidsgerichte finetuning aan de hand van veilige en onveilige codevoorbeelden. Om een dataset van hoge kwaliteit te creëren, hebben de auteurs een geautomatiseerd proces opgezet dat geverifieerde kwetsbaarheidscorrecties uit de op GitHub geregistreerde codewijzigingen haalt met behulp van heuristische filtering en statische analyse op basis van de CodeQL-tool. De resultaten tonen aan dat SafeCoder de codeveiligheid met ongeveer 30% verbetert, terwijl de bruikbaarheid in benchmarks zoals HumanEval en MMLU behouden blijft. De auteurs geven echter toe dat de tool de veiligheid van code met kwetsbaarheden waarvoor hij niet is getraind, niet verbetert.

In de tussentijd kan een manier zijn om een traditionele statische analyse te combineren met GenAI door eerst de GenAI te vragen de gewenste code te genereren en vervolgens de statische analyse te gebruiken om deze code te analyseren. Als de tool een probleem identificeert en de correctie niet voor de hand ligt, kan men de GenAI vragen om de code aan te passen, waarbij de eerder geïdentificeerde fout wordt aangegeven. De lus kan worden herhaald totdat er geen probleem meer wordt geïdentificeerd door het analyse tool. Natuurlijk kan deze omslachtige procedure worden geautomatiseerd in een normale softwareontwikkelingscyclus.

Conclusie

Het eerste deel van dit artikel ging over de impact van GenAI op de kwaliteit van code in termen van beveiliging. In de huidige situatie moet worden vastgesteld dat, ondanks het verbazingwekkende vermogen van GenAI-tools om computercode te genereren, deze code vaak veiligheidsproblemen kan opleveren, ongeacht het gekozen model. Het is daarom raadzaam om zeer waakzaam te zijn vooraleer we code gebruiken die door GenAI-tools is gegenereerd. Bovendien kunnen GenAI-tools bepaalde programmeertaken vergemakkelijken, maar dat neemt niet weg dat zij niet verantwoordelijk zijn voor de mogelijke negatieve gevolgen van hun “werk”. Die verantwoordelijkheid ligt bij de programmeur en zijn werkgever.

De vaardigheden en kennis op het gebied van veiligheid van programmeurs – wier taak geleidelijk zal evolueren van codeschrijver naar codecontroleur – blijven een essentiële troef. De komst van GenAI in de ontwikkelcyclus is misschien een goede gelegenheid om de samenwerking tussen beveiligings- en ontwikkelingsteams te versterken door werkgroepen op te richten (of te versterken) waarin gemeenschappelijke doelstellingen worden afgestemd om de beveiliging te verbeteren.

In het tweede deel zullen we ons concentreren op het gebruik van GenAI voor het opsporen van kwetsbaarheden in code.

Referenties

[1] A. Simkute, L. Tankelevitch, V. Kewenig, A. E. Scott, A. Sellen, et S. Rintel, « Ironies of generative AI: Understanding and mitigating productivity loss in human-AI interactions », 17 février 2024, arXiv: arXiv:2402.11364. doi: 10.48550/arXiv.2402.11364.

[2] N. Perry, M. Srivastava, D. Kumar, et D. Boneh, « Do users write more insecure code with AI assistants? », 16 décembre 2022, arXiv: arXiv:2211.03622. Consulté le: 3 octobre 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2211.03622

[3] J. H. Klemmer et al., « Using AI assistants in software development: A qualitative study on security practices and concerns », 14 octobre 2024. doi: 10.1145/3658644.3690283.

[4] J. Ganseman, « LLM pour code : the good, the bad and the ugly », Smals Research Blog. Consulté le: 18 octobre 2023. [En ligne]. Disponible sur: /llms-pour-code/

[5] A. Chowdhery et al., « PaLM: scaling language modeling with pathways », 5 octobre 2022, arXiv: arXiv:2204.02311. doi: 10.48550/arXiv.2204.02311.

[6] M. Chen et al., « Evaluating large language models trained on code », 14 juillet 2021, arXiv: arXiv:2107.03374. doi: 10.48550/arXiv.2107.03374.

[7] R. Khoury, A. R. Avila, J. Brunelle, et B. M. Camara, « How secure is code generated by ChatGPT? », 19 avril 2023, arXiv: arXiv:2304.09655. doi: 10.48550/arXiv.2304.09655.

[8] S. Hamer, M. d’Amorim, et L. Williams, « Just another copy and paste? Comparing the security vulnerabilities of ChatGPT generated code and StackOverflow answers », 22 mars 2024, arXiv: arXiv:2403.15600. doi: 10.48550/arXiv.2403.15600.

[9] Y. Fu et al., « Security weaknesses of copilot generated code in GitHub », 4 avril 2024, arXiv: arXiv:2310.02059. doi: 10.48550/arXiv.2310.02059.

[10] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, et R. Karri, « Asleep at the keyboard? Assessing the security of GitHub Copilot’s code contributions », in 2022 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA: IEEE, mai 2022, p. 754‑768. doi: 10.1109/sp46214.2022.9833571.

[11] E. Basic et A. Giaretta, « Large language models and code security: A systematic literature review », 19 décembre 2024, arXiv: arXiv:2412.15004. doi: 10.48550/arXiv.2412.15004.

[12] S. Yan et al., « An LLM-assisted easy-to-trigger backdoor attack on code completion models: Injecting disguised vulnerabilities against strong detection », présenté à 33rd USENIX Security Symposium, Philadelphia, PA, USA, août 2024.

[13] E.-M. El-Mhamdi et al., « On the impossible safety of large AI models », 9 mai 2023, arXiv: arXiv:2209.15259. Consulté le: 17 octobre 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2209.15259

[14] S. Götz et A. Schaad, « “You still have to study” – On the security of LLM generated code », août 2024, [En ligne]. Disponible sur: https://arxiv.org/abs/2408.07106

[15] M. Bruni, F. Gabrielli, M. Ghafari, et M. Kropp, « Benchmarking Prompt Engineering Techniques for Secure Code Generation with GPT Models », 9 février 2025, arXiv: arXiv:2502.06039. doi: 10.48550/arXiv.2502.06039.

[16] J. He, M. Vero, G. Krasnopolska, et M. Vechev, « Instruction tuning for secure code generation », 12 juillet 2024, arXiv: arXiv:2402.09497. doi: 10.48550/arXiv.2402.09497.

L’IA pour améliorer la sécurité du code ? (Partie 1 : sécurité du code généré)

Fabien A. P. Petitcolas — Wed, 30 Jul 2025 14:30:00 +0000

Nederlandstalige versie

La communication intense autour de l’intelligence artificielle générative (IAGén) et l’augmentation de son utilisation – au moins en phase de test – que cela soit par peur de rater quelque chose ou pour apporter une réelle valeur ajoutée, conduit à se poser la question de son utilité dans beaucoup de domaines, et, pourquoi pas, afin d’améliorer la sécurité du code. En particulier, l’IAGén permet-elle d’écrire du code informatique plus sécurisé ? Peut-elle aider à détecter des vulnérabilités dans du code existant ?

Dans cette première partie nous apporterons des éléments de réponse à la première question. Nous traiterons la seconde question dans un autre article.

Aspects humains

Commençons par considérer l’aspect humain du recours à l’utilisation de l’IAGén. Dans une analyse détaillée, dont je recommande vivement la lecture, Simkute et al. [1] expliquent les raisons pouvant conduire à une perte de productivité des programmeurs ayant recours à l’IAGén. Les chercheurs citent notamment : un glissement du rôle des programmeurs de la production à l’évaluation, une restructuration inutile des flux de travail, des interruptions, et une tendance de l’IAGén à rendre les tâches faciles plus faciles et les tâches difficiles plus difficiles. On s’étonne alors moins des résultats d’une étude de Perry et al. [2], de l’université de Stanford. Ceux-ci montrent que les participants ayant accès à un assistant basé sur un modèle d’IA écrivent un code significativement moins sécurisé que ceux sans accès. Pire, les participants avec un accès à l’assistant étaient plus enclins à croire qu’ils écrivaient du code sécurisé, que ceux sans l’assistant. Cette observation de Perry et al. est corroborée par le travail de Klemmer et al. [3] : l’équipe de chercheurs a interrogé des programmeurs professionnels, et bien que ces derniers se méfient des suggestions des assistants d’IA, il apparait qu’ils surestiment aussi leur propre capacité à examiner les suggestions de ces assistants. L’adoption d’assistants impose donc la mise en place de pratiques de revue de code et d’analyse statique systématiques [4].

Fiabilité des propositions

Considérant maintenant la qualité des suggestions de l’IAGén, bien que celle-ci produise en général du code fonctionnellement correct, elle introduit également des problèmes de sécurité [5], [6]. Khoury et al. [7] ont montré à travers plusieurs exemples que ChatGPT 3.5 génère souvent du code qui présente des problèmes de sécurité : seuls 5 des 21 cas d’utilisation que les auteurs ont étudiés étaient initialement sécurisés. ChatGPT 3.5 n’a été en mesure de produire du code sécurisé que dans 7 autres cas, et ce, seulement après que les auteurs lui ont explicitement demandé de corriger le code.

Plus récemment, Sivana et al. [8] concluaient leurs expérimentations en soulignant que ChatGPT, en tant que plateforme, générait plus de vulnérabilités de type CWE que le site StackOverflow. Indépendamment, Fu et al. [9] ont montré à travers plusieurs centaines d’échantillons de codes générés par Co-Pilot et trouvés sur GitHub, qu’environ un tiers contient des vulnérabilités communes répertoriées par l’organisme MITRE (certaines faisant partie des 25 plus importantes). Les auteurs recommandent donc aux programmeurs de suivre les meilleures pratiques d’utilisation des outils de génération de code et de toujours vérifier les suggestions de code générées. Des résultats similaires avaient déjà été trouvés par Pearce et al. [10] deux ans plus tôt.

On pourrait multiplier les références à des résultats similaires. C’est ce qu’ont fait Basic et Giaretta [11] dans une étude systématique extensive de la littérature académique sur les IAGén et la sécurité du code informatique. Les modèles concernés sont divers et incluent notamment ChatGPT 3.5, GPT 4-Turbo, Copilot, Claude, Sonnet et Gemini Pro. Les auteurs confirment que plusieurs vulnérabilités clés, telles que les injections SQL et les dépassements de mémoire tampon, peuvent être trouvées dans le code généré par les IAGén. Ils signalent aussi que les risques d’empoisonnement des données d’entraînement peuvent non seulement conduire à une génération de code non sécurisé, mais aussi compromettre la détection des vulnérabilités.

Empoisonnement de l’IA

L’empoisonnement d’un modèle génératif de complétion de code consiste à compromettre l’intégrité de ce modèle en intégrant des échantillons de code malicieux dans les données d’entrainement du modèle. Les attaques par porte dérobée, quant à elles, tentent de dissimuler des déclencheurs à l’intérieur du réseau neuronal profond du modèle pendant la phase d’apprentissage, provoquant la génération de résultats choisis par l’adversaire.

Malgré des progrès importants des modèles de complétion de code, ceux-ci restent vulnérables à ce type d’attaques comme l’ont montré Yan et al. [12] avec CodeBreaker. Pour leur attaque, il n’est pas nécessaire de compromettre un modèle massif pré-entrainé comme BERT ou GPT. En effet ces modèles sont souvent utilisés comme fondation que les victimes règlent finement pour des tâches particulières en utilisant des données spécifiques souvent disponibles publiquement. Il suffit donc alors à l’adversaire de compromettre ces données de réglage fin, ou de téléverser son propre ensemble de données polluées générées avec CodeBreaker. Le code empoisonné généré après l’utilisation de CodeBreaker n’est pas détectable avec des outils de détection de vulnérabilités basés sur des analyses statiques traditionnelles ou des IAGén.

Même si ce type d’attaques est peu probable il pose la question de la provenance de l’outil d’IAGén utilisé et s’inscrit dans la problématique inhérente à l’IAGén actuelle d’obtenir des modèles à la fois sécurisés et exactes [13].

Importance de la requête

Tout n’est pas si noir cependant et il faut souligner l’importance du choix des incitations (« prompt » en anglais) données à l’IAGén afin d’éviter la génération de code avec des faiblesses potentielles. Götz et al. [14] montrent qu’alors que 65% du code initialement généré par divers outils d’IAGén est considéré comme non sécurisé par un ingénieur qualifié, ces mêmes outils génèrent du code sécurisé lorsqu’ils sont guidés manuellement. Les auteurs concluent qu’une expertise technique, en particulier dans le domaine de la sécurité est requise pour générer du code sécurisé en utilisant des assistants de codage.

Afin d’obtenir les meilleurs résultats possibles il faut donc que la requête envoyée à l’IAGén soit à la fois précise et clairement interprétable par le modèle. Autrement-dit, le programmeur a tout intérêt à se plier aux exigences de la machine et fournir avec le plus de détails possibles, non seulement la tâche que le modèle doit exécuter, mais aussi le contexte qui décrit cette tâche, ainsi que les données d’entrée et les données de sortie attendues. Cela peut se faire en seule fois ou sous forme de chaîne de pensée suivant un raisonnement particulier.

Il n’existe cependant pas de méthode idéale, mais Bruni et al. [15] donnent plusieurs exemples simples d’amélioration des incitations. Selon leurs expérimentations la méthode la plus efficace est, après une première requête, de demander à l’IAGén de revoir le code qu’elle a déjà suggéré pour des vulnérabilités potentielles, et enfin de proposer des corrections. Par exemple :

Requête 1 : Génère du code Java pour …
Requête 2 : Examine le code suivant et trouve les problèmes de sécurité :
Requête 3 : À partir des problèmes suivants : , améliore le code suivant :

Cette façon de faire suppose bien évidemment que l’IAGén est capable de détecter des vulnérabilités, mais comme nous le verrons dans l’article suivant ce n’est pas encore le cas aujourd’hui.

Outils spécialisés

Nous pouvons néanmoins nous attendre à l’arrivée de nouveaux outils qui pourraient permettre aux programmeurs d’éviter les écueils de sécurité créés par l’IAGén.

Par exemple l’outil SafeCoder d’ETH Zurich [16] propose un cadre permettant d’améliorer la sécurité du code généré par une IAGén sans sacrifier la fonctionnalité de ce code. L’outil combine le réglage standard des instructions avec un réglage fin – spécifique à la sécurité, en utilisant des exemples de code sûrs et non-sûrs. Pour créer un ensemble de données de qualité, les auteurs ont mis en place un processus automatisé qui extrait les corrections de vulnérabilités vérifiées à partir des modifications de code enregistrées sur GitHub à l’aide d’un filtrage heuristique et d’une analyse statique basée sur l’outil CodeQL. Les résultats montrent que SafeCoder améliore la sécurité du code d’environ 30 % tout en conservant son utilité dans des étalons tels que HumanEval et MMLU. Les auteurs admettent cependant que l’outil n’améliore pas la sécurité de code contenant des vulnérabilités pour lesquelles il n’a pas été entrainé.

En attendant, une façon de procéder pourrait être de combiner un outil d’analyse statique « classique » avec une IAGén en demandant d’abord à l’IAGén de générer le code souhaité, puis en utilisant l’outil d’analyse statique pour analyser ce code. En cas de problème identifié par l’outil, si la correction n’est pas évidente, on peut demander à l’IAGén de modifier celui-ci en indiquant à celle-ci l’erreur précédemment identifiée. On peut recommencer la boucle jusqu’à ce qu’aucun problème ne soit identifié par l’outil d’analyse. Bien évidemment cette procédure fastidieuse pourrait être automatisée dans un cycle de développement logiciel habituel..

Conclusion

La première partie de cet article était dédiée à l’impact de l’IAGén sur la qualité du code en termes de sécurité. En l’état actuel des choses, force est de constater que malgré la capacité étonnante des outils d’IAGén à générer du code informatique, ce code peut souvent présenter des problèmes de sécurité – et ce quelque-soit le modèle choisi. Il convient donc d’être très vigilent avant d’utiliser du code généré par des outils d’IAGén. De plus, même si les IAGén peuvent faciliter certaines tâches de programmation, il n’en reste pas moins qu’elles ne portent pas la responsabilité des conséquences potentiellement négatives de leur « travail », responsabilité qui échoit au programmeur et à son employeur.

Les compétences et connaissances en matière de sécurité des programmeurs – dont la tâche évoluera progressivement de créateur de code à contrôleur de code – restent un atout essentiel. L’arrivée de l’IAGén dans le cycle de développement est peut-être une bonne occasion de renforcer la collaboration entre les équipes de sécurité et de développement en établissant (ou renforçant) des groupes de travail dans lesquels sont alignés des objectifs communs afin d’améliorer la sécurité.

Dans la seconde partie nous nous focaliserons sur l’utilisation de l’IAGén pour la détection de vulnérabilités dans le code.