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]).

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é :

1. 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.
2. 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.
3. 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.
4. 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 »

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]).

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:

“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.”

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:

1. Extractie van potentiële kandidaten voor besmette bronnen of ontvangers in externe en interne programmeerinterfaces met behulp van een statische analysetool.
2. 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⁴.
3. 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.
4. 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

[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.

¹ 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”

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é : <réponse fournie à la requête 1>
• Requête 3 : À partir des problèmes suivants : <problèmes signalés par la requête 2>, améliore le code suivant : <réponse fournie à la requête 1>

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.

Références

[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 rechniques 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.

_________________________

Ce post est une contribution individuelle de Fabien A. P. Petitcolas, spécialisé en sécurité informatique chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

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: <antwoord op prompt 1>
• Prompt 3: op basis van de volgende problemen: <problemen gemeld door prompt 2>, verbeter de volgende code: <antwoord gegeven op prompt 1>

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.

Cet article a été traduit du néerlandais. Les liens peuvent pointer vers des sources en néerlandais.

Dans un article précédent, nous avons discuté de manière générale du potentiel de l’IA générative dans le Software Development Lifecycle. Examinons maintenant la question du point de vue du développeur : quel est l’état d’avancement de la génération de code et que devons-nous encore prendre en compte ? Pour faire court : les assistants IA ou les plugins pour IDE sont une aubaine pour ceux qui savent en faire bon usage, mais comme tous les systèmes d’IA, ils présentent aussi des inconvénients.

Avant-propos

Une partie de cette hype en termes d’IA générative est propulsée par des modèles de langages puissants – les grands modèles de langue ou LLM. Depuis la sortie du GPT-3 en 2020, ces modèles parviennent à écrire des textes normaux d’une certaine longueur. De là, il n’y a qu’un pas vers les langages de programmation. En effet, ils ont aussi une syntaxe et une sémantique.

Dans la pratique, il existe de nombreuses variantes de modèles de langue, chacun ayant ses forces et ses faiblesses, en fonction des choix faits par les créateurs pour les entraîner, et en fonction des données d’entraînement qui les sous-tendent. Testez vous-même certains des modèles open source existants sur votre propre ordinateur via l’outil GPT4All (voir également notre quick review de cet outil).

Le code informatique consiste en une collection de fichiers texte. Rien n’empêche un modèle de langue d’essayer de prédire les différents tokens (= unités grammaticales) qui composent le code, plutôt que des mots. Cependant, contrairement au texte brut, le code a beaucoup moins de tolérance à l’erreur : la moindre faute d’orthographe ou la plus petite variation peut invalider un morceau de code ou lui faire exécuter quelque chose de complètement différent.

Pourtant, aujourd’hui, les plus grands modèles de langue, tels que GPT-3.5 et les versions ultérieures, peuvent produire d’eux-mêmes des morceaux de code informatique tout à fait corrects en réponse à une requête. Cette fonctionnalité est due à la quantité massive de textes sur lesquels ils sont formés, notamment de nombreux tutoriels, articles de blog, questions et réponses provenant de forums de développeurs populaires tels que StackOverflow, et code documenté provenant de repositories de code publics tels que Github.

Canards en plastique bavards

Depuis Socrate, le dialogue est un moyen efficace de parvenir à de nouvelles perspectives. Ce n’est pas pour rien que le rubber ducking est une méthode de correction de bugs qui revient dans tous les cours de génie logiciel. Il existe entre-temps plusieurs plugins qui mettent à disposition une interface de chat alimentée par l’IA dans l’IDE même (par exemple ceux pour VS Code, beaucoup d’autres peuvent être trouvés via les marketplaces pour VS Code ou IntelliJ IDEA). Si ces plugins utilisent un service cloud externe, il vous suffit d’entrer votre propre clé API.

Un cadre de dialogue avec une dynamique de questions-réponses peut être bien utilisé pour générer des morceaux de code relativement autonomes, sans trop de dépendances externes. En général, pour obtenir le meilleur résultat, il faut pouvoir énoncer facilement toutes les conditions préalables et les hypothèses nécessaires dans le dialogue lui-même, de manière à ce qu’il s’inscrive dans la fenêtre contextuelle du modèle de langue. Les use cases comprennent entre autres :

• La génération from scratch d’une version initiale du code ou d’un fichier de configuration
• La génération de fonctions ou de procédures relativement courtes à partir d’une description
• La génération de code snippets autonomes : requêtes SQL, expressions régulières…
• Demande de modification d’un morceau de code ou d’un fichier de configuration
• Correction de bugs : recherche d’erreurs dans un code qui ne fonctionne pas, poser des questions sur une erreur
• Faire expliquer ce qu’un morceau de code fait

Les plus grands modèles de langue disposent de fenêtres contextuelles de plusieurs milliers de mots dans lesquelles il est possible d’insérer toutes les informations nécessaires. Un modèle de langue open source plus petit, installé localement sur du matériel moins puissant, sera sans aucun doute moins performant. Voici quelques exemples de conversations avec GPT-4 d’OpenAI, qui montrent qu’il est possible d’aller très loin avec quelques questions bien ciblées (cliquez sur l’image pour obtenir la pleine résolution) :

Complétion de code sous stéroïdes

Au cours du développement, un développeur travaille sur de nombreux fichiers dans un IDE. À des endroits aléatoires de ces fichiers, le code doit être modifié, supprimé ou écrit. L’édition de code existant de cette manière n’a pas grand-chose à voir avec le dialogue ; en fait, nous préférerions utiliser l’auto-complétion avancée dans ce cas. Les modèles de langue peuvent également faire l’affaire, mais les modèles les plus appropriés sont plutôt ceux formés aux tâches de “remplir au milieu” – et qui peuvent donc prendre en compte le code présent avant et après l’endroit que l’on édite.

Après la sortie de GPT-3, OpenAI a travaillé avec Microsoft (qui possède Github) pour créer un modèle de langue spécialisé, formé exactement pour ce use case. Cette variante a été nommée Codex, et le premier outil à l’utiliser a été Github CoPilot. Depuis, nous en sommes à plusieurs versions, mais les plugins pour VSCode et IntelliJ fonctionnent toujours de la même manière : via un raccourci clavier dans l’éditeur, on peut utiliser CoPilot pour récupérer diverses suggestions, générées par Codex, qui pourraient correspondre à l’endroit où se trouve le curseur.

D’après notre expérience actuelle, le contexte pris en compte est généralement limité au contenu (partiel) du fichier édité. Cela implique évidemment le téléchargement vers le modèle de langue – veillez donc à respecter les directives en matière de confidentialité lorsque vous utilisez un service externe. Pour l’instant, nous semblons obtenir de meilleurs résultats dans les projets de programmation composés de quelques gros fichiers, tels que les pages web avec JavaScript en ligne, ou Jupyter Notebooks en Python, où il y a souvent un gros fichier à parcourir qui contient à la fois la documentation, le code et l’output. En revanche, dans les projets comportant de nombreux petits fichiers, il semble plus difficile de générer de bonnes suggestions, et il est plus important de disposer d’une documentation supplémentaire dans le fichier édité afin que le modèle de langue puisse puiser dans suffisamment d’informations contextuelles.

L’une des alternatives les plus intéressantes au modèle commercial Github CoPilot est StarCoder, un modèle open source issu de l’initiative BigCode HuggingFace et ServiceNow. Bien que la performance soit moindre que CoPilot, ils font la différence dans de nombreux autres domaines qui peuvent être des obstacles dans des contextes commerciaux ou publics :

• Entraînés sur un dataset public : The Stack. Bien qu’il ait été collecté par scraping, il ne contient que du code avec des licences logicielles permissives, et les développeurs peuvent, s’ils le souhaitent, toujours faire retirer leur code du dataset.
• Comprend un outil de vérification de plagiat, qui permet de vérifier que les suggestions générées n’ont pas été copiées mot pour mot à partir des données d’apprentissage (éventuellement protégées par des droits d’auteur).
• Pourvu d’un filtre d’informations sensibles, qui détecte les adresses électroniques, les clés API et les adresses IP (pas exact à 100 %).
• Contient des instructions pour installer localement, ainsi qu’un plugin VSCode. Un plugin IntelliJ a entre-temps également été développé par un tiers.
• Le modèle standard a une taille de 15 milliards de paramètres et nécessite au moins 60 GB de RAM ou autant de mémoire GPU (en fonction de l’utilisation ou non d’un GPU) pour être utilisé. Il existe également de plus petits modèles à 7, 3 ou 1 milliard de paramètres, ainsi que des versions quantisées utilisant des types de données à 4 bits, sans grande perte de précision.

Plusieurs autres systèmes ont vu le jour cet été et ont obtenu de bons résultats dans de nombreux benchmarks : WizardLM et sa variante spécifique WizardCoder, qui est désormais considéré comme le nec plus ultra de l’open source, et PanGu-Coder, avec lequel Huawei s’est également lancé dans le monde des assistants IA pour le code. 

Au cœur de l’action

Le StarCoder paper offre un bel aperçu du fonctionnement d’un modèle de langue pour le code.
Ce n’est certainement pas comme si vous pouviez “brancher” votre propre codebase pour obtenir des suggestions adaptées. Si vous voulez vraiment affiner le modèle (et vous ne ferez cet énorme effort que si vous n’y arrivez pas avec des modifications astucieuses du prompt), il y a beaucoup de choses à faire, du prétraitement des données d’entraînement au post-traitement de l’output brut du modèle de langue. Ne vous attendez pas non plus à ce que le réglage fin soit trop élevé : StarCoder l’a fait pour Python, mais n’a obtenu que quelques points de pourcentage d’amélioration par rapport au modèle global qui pourrait traiter tous les langages de programmation. Le peaufinage est difficile et il n’y a aucune garantie de succès ; il y a même un risque d’overfitting, ce qui pourrait dégrader les résultats.

L’étape la plus importante est probablement la collecte et le nettoyage des données. Ces données sont constituées de code, mais tous les codes ne sont pas inclus : vous devez également être autorisé à utiliser le code (licences) et, de préférence, l’avoir aussi correct que possible et écrit dans le langage de programmation que vous souhaitez soutenir. Le code est également collecté à partir des issue trackers et du commit history. En outre, un filtrage additionnel peut être effectué pour supprimer les (quasi-)doublons, et des pondérations peuvent être attribuées ici et là pour maintenir l’équilibre : un peu moins de poids pour le code “boilerplate”, et/ou un peu plus pour les repositories très populaires qui sont susceptibles d’être de meilleure qualité. Le code source peut contenir des informations sensibles qui doivent être rendues anonymes ou supprimées au préalable, pour éviter qu’elles ne soient divulguées ou suggérées (adresses IP, mots de passe, identifiants, adresses électroniques, coordonnées…). Tout cela, bien sûr, de préférence aussi automatiquement que possible.

Le code source se compose non seulement de code, mais aussi de descriptions, de commentaires et d’autres informations. Dans une étape de formatage, le code est donc enrichi par l’ajout de métadonnées et de tokens supplémentaires qui rendent explicites certaines structures implicites. Cela peut avoir des conséquences : si tout ce prétraitement a été effectué sur l’ensemble des données d’apprentissage, le modèle résultant ne fonctionnera correctement sur de nouvelles données que s’il a subi le même prétraitement. Ainsi, les plugins éditeur qui souhaitent utiliser un tel modèle peuvent, pour obtenir un bon résultat, devoir d’abord effectuer un prétraitement similaire sur le code qu’ils souhaitent envoyer au modèle de langue.

Exactitude et autres benchmarks

Comme c’est le cas pour les LLM, il ne peut y avoir de garantie concluante de l’exactitude ou de l’exhaustivité de ce qu’un tel plugin présente, tant sur le plan syntaxique que sur le plan sémantique. Cette précision est évidemment importante : un morceau de code généré ne doit pas seulement être syntaxiquement correct et compiler sans faille, mais aussi être sémantiquement significatif et s’exécuter correctement. La métrique “pass@x” est devenue une mesure importante à cet égard. Elle exprime en pourcentage si un modèle de langue pour une mission donnée peut passer avec succès les tests correspondants après X tentatives. “pass@1” est le pourcentage pour lequel le modèle de langue utilisé pour la première fois a pu générer la bonne réponse, “pass@10” est le pourcentage pour lequel au moins 1 tentative sur 10 a été correcte.

Dans le monde de l’IA générative, il existe un besoin général de pouvoir comparer les nouveaux modèles, qui apparaissent désormais presque quotidiennement, avec le meilleur de la technologie. Il n’y a donc pas de pénurie de benchmarks, et de nouveaux modèles plus importants apparaissent régulièrement. Des résumés utiles sont les “leaderboards”, qui montrent en temps réel quels modèles représentent l’état actuel de la technique selon une série de benchmarks. L’étape peut changer chaque semaine. Voici quelques leaderboards généraux intéressants :

• Papers with Code : l’état de l’art dans diverses tâches d’intelligence artificielle, avec des documents d’accompagnement.
• Stanford HELM : analyse comparative d’un large éventail de tâches en se focalisant sur le “human reasoning” (raisonnement humain).
• LMsys.org FastChat : se concentre sur les capacités chatbot.
• HuggingFace OpenLLM leaderboard.
• LLM-Leaderboard.

En ce qui concerne le code, il existe des benchmarks qui fonctionnent plus ou moins comme un concours de programmation. L’idée est de confier un ensemble de tâches au modèle de langue, d’évaluer les résultats automatiquement et de mesurer le “pass@1” et, si possible, d’autres paramètres. Souvent, il s’agit de “remplir la fonction” : à partir d’une description de l’input, de l’output et d’un function header, le contenu de la fonction doit être généré. L’inconvénient est que ce type de problème n’est parfois pas très représentatif de celui auquel est confronté le développeur lambda. Parmi les initiatives intéressantes, on peut citer :

• HuggingFace Big Code Models leaderboard (uniquement LLM publics).
• Microsoft CodeXGLUE : évaluation de diverses sous-tâches selon des méthodes connues de Natural Language Processing. Ce leaderboard semble dépendre de contributions volontaires et est quelque peu incomplet.
• Papers with Code a des sections séparées pour la génération de code, la création de documents, la synthèse de programmes entiers et la correction de bugs.
• Le HumanEval dataset et MBPP dataset : problèmes de programmation typique (Python).
• Le DS-1000 dataset : ensemble de problèmes de data processing / data science concrets.
• HumanEval-X ou MultiPL-E : versions multilingues de HumanEval, mesurant les performances dans plusieurs langages de programmation.

Bien entendu, le fait qu’un morceau de code généré survive aux tests ne signifie pas qu’il s’agit d’un code sécurisé ou qu’il respecte les “best practices”. Entre-temps, il existe de nombreux exemples connus de code généré qui s’avère sensible aux “buffer overflows”, à l’injection SQL et à d’autres risques classiques. Le benchmark de sécurité “Asleep at the Keyboard” consiste en 89 scénarios de génération de code basés sur la liste MITRE top-25 vulnerability. Starcoder paper montre que même les meilleurs modèles génèrent encore du code non sécurisé dans 40 % de ces scénarios. En outre, il ne semble guère y avoir de différence entre les meilleurs modèles et les autres – le choix d’un meilleur modèle semble garantir des résultats syntaxiquement plus corrects, mais pas encore un code plus sûr. Il est donc possible que nous devions nous pencher sur les données d’apprentissage elles-mêmes, où le code non sécurisé devrait être encore mieux filtré. Quoi qu’il en soit, il convient de rappeler que l’utilisation de code généré dans un projet doit impérativement s’accompagner d’une solide politique de test et d’acceptation.

Performance

En ce qui concerne plus particulièrement les exigences computationnelles, le leaderboard Huggingface OpenLLM-perf et les benchmarks sur le site web TextSynth Server constituent des sources intéressantes. Ce dernier montre quelques chiffres de performance utiles pour ceux qui envisagent un hébergement par leurs propres moyens. Ceux qui n’ont pas de GPU peuvent compter sur une vitesse de 12 tokens par seconde avec le modèle LLaMa2 de 13 milliards de paramètres, avec un processeur de serveur EPYC 7313 relativement haut de gamme. Dans un code informatique, un token ne représente parfois qu’un seul caractère, de sorte qu’à cette vitesse, il faut parfois attendre une dizaine de secondes pour obtenir une suggestion de complétion de code. La dernière carte graphique RTX-4090 peut le faire 7 fois plus vite, mais pas encore au point de l’exprimer en millisecondes.

Les besoins en mémoire sont proportionnels au nombre de paramètres d’un modèle, et la vitesse de génération inversement proportionnelle. À titre d’approximation, on peut supposer qu’un modèle comportant 13 milliards de paramètres doit également effectuer 13 milliards de calculs pour chaque token de sortie, même s’il ne comporte qu’un seul caractère. En outre, si chaque paramètre est un nombre de 32 bits, il faut au moins 52 Go de stockage et autant de mémoire (V)RAM. Une “quantization“, arrondissant les paramètres à 8 bits ou même à 4 bits, peut réduire proportionnellement ce besoin en mémoire.

GPT4All permet de l’essayer sur votre propre matériel. Cela donne une idée de l’énorme puissance de calcul qu’OpenAI, Microsoft Azure ou Amazon AWS déploient pour que leurs modèles, dont beaucoup sont encore plus grands que les LLM disponibles en libre accès, fonctionnent aussi vite qu’ils le proposent. On parle d’investissements de milliards de dollars en matériel informatique, si importants qu’ils déstabiliseraient le marché mondial.

Même les solutions open source sont loin d’être légères, en dépit des grandes initiatives d’optimisation. On peut en tout cas supposer que le déploiement local n’est possible que sur du matériel récent et puissant. Actuellement, on ne peut pas s’attendre à ce qu’une installation locale sur un ordinateur portable de bureau moyen offre une expérience fluide à l’utilisateur.

Productivité

Internet regorge de contes de fées sur le développeur 10x, et les gourous de l’IA générative aimeraient vous faire croire que cette technologie peut élever n’importe quel programmeur à ce niveau. La réalité est plus nuancée. Les développeurs ne passent pas 100 % de leur temps à écrire du code, pas plus que les médecins ne passent 100 % de leur temps à rédiger des ordonnances. La majorité des développeurs passe moins d’une heure par jour à coder. Le reste de leur temps est consacré à l’analyse, à la lecture, à l’apprentissage, aux tâches de maintenance, à la communication, etc. Jusqu’à présent, cette réflexion et cette consultation avec les collègues ne sont pas comprimées par l’emploi de LLM.

Il est difficile de trouver des chiffres précis sur la productivité parce qu’elle est difficile à définir et donc à mesurer. Une première estimation utile provient de Google même, qui a examiné le temps d’itération (de la connaissance du problème à la solution). Avec une première version de son propre assistant de complétion de code par l’IA, l’entreprise a pu constater un gain de temps de 6 %. Github affirme que le codage pur peut être environ 55 % plus rapide avec son CoPilot – bien qu’il précise dans le même temps que l’intervalle de confiance à 95 % de sa mesure est de [21 %-89 %]. En outre, l’adoption d’un outil n’apporte aucune valeur ajoutée si elle n’est pas accompagnée d’un parcours pour apprendre à l’utiliser de manière optimale (tout comme aujourd’hui encore, de nombreux employés de bureau perdent du temps avec Office en raison d’une connaissance ou d’une expérience insuffisante de tous les types de références, de formules et de raccourcis).

Le code généré fournit une solution initiale rapide, mais cette solution doit encore être comprise par le programmeur. Un score “pass@1” de 50 % signifie que la moitié des bouts de code générés nécessitent encore des ajustements manuels avant de passer les tests unitaires – sans parler de l’optimalité ou de la sécurité. Le code généré peut être complexe et utiliser des constructions qui dépassent le niveau de connaissance du programmeur. Le code généré est donc plus difficile à maintenir et à corriger que le code écrit manuellement. Un code généré qui n’a pas été correctement examiné et testé ajoute une dette technique considérable à un projet.

L’utilisation de plugins qui vont jusqu’à générer des blocs entiers de code et de documentation en un claquement de doigts (ou un peu plus lentement) n’est une bonne idée que si plusieurs autres aspects du processus d’ingénierie logicielle sont en ordre : des normes élevées doivent être maintenues dans tous les domaines en termes de stratégie de test, de code reviews, de documentation de code et de savoir-faire des développeurs.

Confidentialité

Les entreprises et les gouvernements ont rarement le luxe d’utiliser n’importe quel modèle de langue. Il existe non seulement des barrières contractuelles, mais aussi des questions de confidentialité, en particulier lors de l’utilisation du cloud. Après tout, on n’obtient une bonne suggestion de modèle de langue qu’en introduisant suffisamment d’informations au préalable. Ne pas tout mettre en place en interne implique inévitablement de donner à un tiers l’accès à vos données.

Le degré d’ouverture et de licence peut varier considérablement – à un extrême, tout est en “boîte noire” et uniquement accessible via le cloud/API (c’est là que vous trouverez OpenAI, Anthropic, Cohere et la plupart des autres start-ups établies). Celles-ci promettent dans les versions Enterprise parfois plus de garanties – mais vous n’avez pas d’autre choix que de les croire sur parole. À l’autre extrême, tout est en “open access” (libre accès) et sous licence permissive. Entre les deux, une entreprise peut également construire un modèle de langue en libre accès sur un dataset fermé. Au moins un de ces datasets a depuis été divulgué comme contenant des ebooks illégalement copiés et protégés par le droit d’auteur, ce qui constituera sans aucun doute un argument de poids dans le recours collectif intenté contre Meta sur ce sujet. Les ensembles de données des Code LLM Salesforce CodeGen et Tsinghua CodeGeeX ne sont pas non plus publics.

Transparence, licences, options de déploiement, prix, taille et scalabilité… l’importance relative de toutes ces caractéristiques dictera les outils que vous pourrez utiliser. Ceux qui souhaitent une transparence maximale seront souvent limités aux LLM en Open Access. Certaines licences ouvertes limitent en outre l’utilisation à des fins non commerciales. La nécessité d’accéder à des données de formation ou la facilité d’héberger soi-même une instance sur site limitent davantage les choix.

Conclusion

Les outils basés sur le dialogue (chatGPT et autres) peuvent vous être utiles en tant que développeur pour, entre autres, les tâches suivantes :

• Initialiser un projet/fichier/classe/configuration : créer une première version de quelque chose
• Correction de bugs et modification sous forme de questions-réponses
• Morceaux de code relativement indépendants

Les outils qui complètent le code ou remplissent le code manquant (type Github Co-Pilot) sont utiles, entre autres, pour :

• Compléter du code à partir d’exemples déjà réalisés
• Documenter le code
• Apporter des modifications au milieu d’un fichier plus volumineux

Pour un développeur, l’environnement de développement optimal est quelque chose de tout à fait personnel et chacun aura sa propre préférence. À notre avis, ces deux façons d’obtenir des suggestions de code sont quelque peu complémentaires, et une combinaison intelligente des deux peut permettre d’obtenir les meilleurs gains de productivité. Dans le même temps, nous tenons à dire qu’une gestion de projet saine, avec une attention portée à la qualité du code, aux tests, aux révisions, à la documentation, etc. est indispensable.

Le monde de l’IA est en pleine effervescence. De nouveaux modèles d’IA pouvant servir de base aux plugins IDE sont ajoutés avec une grande régularité. Pour les industries où la confidentialité du code est importante, les variantes open source sont très intéressantes. Même si les benchmarks montrent qu’ils sont encore moins performants aujourd’hui que les dernières initiatives commerciales basées sur le cloud, nous pouvons nous attendre à ce que de meilleures versions apparaissent à l’avenir. De nombreux efforts sont déjà déployés pour créer des modèles pouvant fonctionner sur du matériel grand public (certes haut de gamme).

P.S.

Quelques heures après la publication de cet article, HuggingFace annonce la venue de SafeCoder : une solution d’entreprise pour les assistants de codage basés sur LLM qui peut être déployée sur site. Huggingface fournit le tout dans des conteneurs qui peuvent être installés dans un data center propre et fournir des endpoints privés, ainsi que des plugins compatibles avec les principaux IDE. D’autres frameworks de déploiement général existent depuis un certain temps, notamment Seldon, BentoML et KServe, qui peuvent également héberger des LLM, TextSynth Server et GPT4All peuvent fonctionner comme des endpoints d’API. Cependant, vous avez toujours besoin de plugins pour les utiliser dans l’IDE lui-même, et pour effectuer les traitements préalables et postérieurs nécessaires – et s’ils ne sont pas fournis, vous devez en créer un vous-même ou modifier un plugin existant.

P.P.S.

Ces derniers mots à peine écrits, Meta a lancé CodeLLama, une variante de LLaMa 2 spécifiquement entraînée pour le code. Les médias sociaux suggèrent qu’il est possible de faire tourner la version originale avec 34 milliards de paramètres sur un ordinateur équipé de 4 GPU RTX3090 avec 24 GB de VRAM chacun, générant environ 20 tokens par seconde. Il est sans doute plus facile d’essayer la version de chat en ligne. Les versions quantisées suivront sans doute très prochainement, et nous attendons les premiers benchmarks sur les différents leaderboards.

______________________

Cette contribution a été soumise par Joachim Ganseman, consultant IT chez Smals Research. Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.

In een vorig artikel bespraken we op algemene wijze het potentieel van generatieve AI in de software development lifecycle. Laat ons nu eens kijken vanuit het standpunt van de developer: wat is de stand van zaken wat betreft het genereren van code, en waar moeten we nog rekening mee houden? Lang verhaal kort: AI-assistenten of -plugins voor IDEs zijn een zegen voor wie ze goed kan aanwenden, maar komen, zoals alle AI-systemen, ook met de nodige caveats.

Vooraf

De hype qua generatieve AI wordt onder andere gestuwd door krachtige taalmodellen – Large Language Models of LLMs. Zeker sinds GPT-3 uitkwam in 2020, slagen die erin om normaal uitziende teksten te schrijven van enige lengte. Van daar is het maar een korte sprong naar programmeertalen – die hebben immers ook een syntax en semantiek.

In de praktijk bestaan er talloze varianten van taalmodellen, die elk hun sterktes en zwaktes hebben, al naargelang de keuzes die de makers hebben gemaakt bij het trainen ervan, en al naargelang de trainingsdata die eraan ten grondslag liggen. Probeer bijvoorbeeld zelf enkele van de bestaande open source modellen uit op je eigen computer via de tool GPT4All (zie ook onze korte review van deze tool).

Computercode bestaat uit een collectie van tekstbestanden. Niets verhindert dat een taalmodel, in plaats van woorden, de verschillende tokens ( = grammaticale eenheden) waaruit code bestaat, probeert te voorspellen. In tegenstelling tot gewone tekst is er bij code echter veel minder ruimte voor fouten: de kleinste spelfout of variatie kan een stuk code ongeldig maken of iets helemaal anders laten uitvoeren.

Toch kunnen de allergrootste taalmodellen, zoals GPT-3.5 en later, vandaag uit eigen beweging vrij correcte stukken computercode produceren in een antwoord op een vraag. Deze functionaliteit is het gevolg van de massieve hoeveelheid tekst waarop ze getraind zijn, waaronder talloze tutorials, blogartikels, vragen en antwoorden uit populaire developerfora zoals StackOverflow, en gedocumenteerde code uit publieke code repositories zoals Github.

Babbelende badeentjes

Al sinds Socrates is de dialoog een beproefde manier om tot nieuwe inzichten te komen. Niet voor niets is rubber ducking een methode voor debugging die ter sprake komt in elke cursus software engineering. Er bestaan ondertussen verschillende plugins die een AI-powered chat-interface in de IDE zelf beschikbaar stellen (bvb deze voor VS Code , vele andere kunnen gevonden worden via de marketplaces voor VS Code of IntelliJ IDEA). Als die gebruikmaken van een externe cloud-dienst moet je daarbij enkel nog je eigen API-key ingeven.

Een dialogerende setting met een vraag-antwoord dynamiek kan goed aangewend worden voor het genereren van relatief op zichzelf staande stukken code, zonder te veel externe afhankelijkheden. In het algemeen kan je stellen dat je, voor het beste resultaat, alle noodzakelijke randvoorwaarden en aannames gemakkelijk in de dialoog zelf moet kunnen vermelden, zodat het binnen het context-venster van het taalmodel past. De use cases omvatten onder andere:

• From scratch genereren van een eerste versie van code of een configuratiebestand
• Genereren van relatief korte functies of procedures aan de hand van een beschrijving
• Genereren van op zichzelf staande code snippets: SQL queries, reguliere expressies, …
• Vragen om een aanpassing aan een stuk code of een configuratiebestand
• Debugging: fouten zoeken in niet-werkende code, vragen stellen over een error
• Laten uitleggen wat een stuk code doet

De grootste taalmodellen hebben ondertussen contextvensters van duizenden woorden waarin je alle nodige informatie kwijt kan. Een kleiner open-source taalmodel, lokaal geïnstalleerd op minder krachtige hardware, zal ongetwijfeld minder goed presteren. Enkele voorbeelden van conversaties met OpenAI’s GPT-4 staat hieronder – hieruit blijkt dat je al heel ver kan geraken met een paar welgemikte vragen (klik voor de volledige resolutie):

Code completion on steroids

Tijdens het ontwikkelen werkt een developer aan talloze bestanden in een IDE. Op willekeurige plekken in die bestanden moet er code aangepast, verwijderd of geschreven worden. Het bewerken van bestaande code op deze manier heeft weinig te maken met dialogeren, eigenlijk willen we hier eerder een geavanceerde auto-complete inzetten. Ook dat kunnen taalmodellen goed, maar de meest geschikte modellen zijn eerder diegene die getraind zijn op “fill in the middle” taken – en die dus rekening kunnen houden met de aanwezige code voor én na de plek die men aan het bewerken is.

Na het uitbrengen van GPT-3, werkte OpenAI samen met Microsoft (dat Github bezit) aan een gespecialiseerd taalmodel dat voor exact deze use case werd getraind. Deze variant werd Codex genoemd, en de eerste tool die ervan gebruikmaakte was Github CoPilot. Ondertussen zijn we al enkele versies verder, maar de plugins voor VSCode en IntelliJ werken nog op dezelfde manier: via een sneltoets in de editor kan men via CoPilot verschillende suggesties opvragen, gegenereerd door Codex, die zouden kunnen passen op de plek van de cursor.

Voor zover onze ervaring vandaag reikt, is de context die daarbij in rekening wordt genomen vandaag meestal beperkt tot (stukken van) de inhoud van het bewerkte bestand. Daarbij wordt uiteraard code geüploaded naar het taalmodel – let dus zeker op richtlijnen qua confidentialiteit bij gebruik van een externe dienst. Vooralsnog lijken we betere resultaten te krijgen bij programmeerprojecten die bestaan uit weinig grote bestanden, zoals webpagina’s met inline JavaScript, of Jupyter Notebooks in Python, waarbij vaak sprake is van 1 groot bestand dat doorlopen wordt waarin zowel de documentatie, de code als de output staat. In projecten met vele kleine bestandjes daarentegen, lijkt het moeilijker om goede suggesties te genereren, en is het belangrijker dat er extra documentatie aanwezig is in het geëditeerde bestand zodat er voldoende contextuele informatie is die het taalmodel kan aangrijpen.

Een van de interessantere alternatieven voor het commerciële Github CoPilot is StarCoder, een open source model van het BigCode initiatief van HuggingFace en ServiceNow. De performantie is weliswaar minder dan CoPilot, maar zij maken op vele andere vlakken, die mogelijk dealbreakers zijn in commerciële of publieke context, het verschil:

• Getraind op een open dataset: The Stack. Deze is weliswaar via scraping verzameld, maar bevat alleen code met permissieve softwarelicenties, en developers kunnen desgewenst alsnog hun code eruit laten verwijderen.
• Bevat een plagiaat-check tool, waarmee je kan controleren of de gegenereerde suggesties niet verbatim uit de (mogelijk copyrighted) trainingsdata zijn overgenomen.
• Voorzien van filter van gevoelige informatie, die emailadressen, API keys en IP adressen detecteert (niet 100% accuraat).
• Voorzien van instructies om het lokaal te installeren, evenals een VSCode plugin. Een IntelliJ plugin werd ondertussen ook ontwikkeld door een derde partij.
• Het standaardmodel is 15 miljard parameters groot en vergt minstens 60GB RAM of evenveel GPU memory (afhankelijk van of een GPU benut wordt of niet) om te kunnen gebruiken. Ondertussen bestaan ook kleinere modellen met 7, 3 of 1 miljard parameters, evenals “quantized” versies die gebruikmaken van 4bit datatypes zonder veel accuraatheidsverlies.

Deze zomer zagen nog enkele andere systemen het licht die goed scoren op vele benchmarks: WizardLM en de specifieke variant ervan WizardCoder, dat ondertussen wordt beschouwd als de open source state-of-the-art, en PanGu-Coder, waarmee ook Huawei zich heeft gelanceerd in de wereld van AI-assistants voor code. 

Achter de schermen

De StarCoder paper geeft een goed zicht op de werking van een taalmodel voor code. Het is zeker niet zo dat je je eigen codebase kan “inpluggen” om suggesties te krijgen die daarop zijn toegespitst. Als je echt zou willen finetunen (en die enorme inspanning doe je in principe alleen maar als je er niet raakt met slimme aanpassingen aan de prompt), komt er heel wat bij kijken, van preprocessing van de trainingsdata tot postprocessing van de rauwe output van het taalmodel. Leg de verwachtingen van finetuning ook niet te hoog: StarCoder deed het voor Python, maar haalde hooguit enkele procentpunten verbetering in vergelijking met het algemene model dat met alle programmeertalen overweg kon. Finetunen is moeilijk en er is geen garantie op succes; er bestaat zelfs een risico op overfitting wat tot slechtere resultaten kan leiden.

De belangrijkste stap daarbij is waarschijnlijk het verzamelen en schoonmaken van data. Die data bestaat uit code, maar niet alle code komt in aanmerking: je moet de code ook mogen gebruiken (licenties), en je hebt ze liefst zo correct mogelijk en geschreven in de programmeertaal die je wenst te ondersteunen. Code wordt ook verzameld uit issue trackers en commitgeschiedenis. Daarnaast kan je nog extra filteren om (bijna-)duplicaten te verwijderen, en wil je misschien hier en daar gewichten toekennen om de balans te bewaren: wat minder gewicht voor boilerplate code, en/of wat meer voor erg populaire repositories die waarschijnlijk van hogere kwaliteit zijn. Broncode kan gevoelige informatie bevatten die eerst geanonymiseerd of verwijderd moet worden, om te voorkomen dat die lekt of wordt gesuggereerd (IP adressen, paswoorden, identifiers, emailadressen, contactgegevens, …). Dit alles natuurlijk liefst zo automatisch mogelijk.

Broncode bestaat niet alleen uit code maar ook uit beschrijvingen, commentaren en andere informatie. In een formatteringsstap wordt de code daarom nog verrijkt, door het toevoegen van metadata en bijkomende tokens die bepaalde impliciete structuren expliciet maken. Dit kan implicaties hebben: als al deze preprocessing op de hele trainingsdataset is gebeurd, dan zal het resulterende model pas goed werken op nieuwe data als die dezelfde preprocessing heeft ondergaan. Het is dus mogelijk dat editorplugins die willen gebruikmaken van zo’n model, om een goed resultaat te bekomen, eerst gelijkaardige preprocessing moeten uitvoeren op de code die ze naar het taalmodel willen sturen.

Correctheid en andere benchmarks

Typisch voor LLMs, kan er geen sluitende garantie worden gegeven op de correctheid of volledigheid van wat zo’n plugin je voorschotelt, zowel syntactisch als semantisch. Die correctheid is uiteraard van belang: een stuk gegenereerde code moet niet alleen syntactisch correct zijn en foutloos compileren, maar ook semantisch betekenisvol zijn en goed runnen. De “pass@x” metriek is daarbij uitgegroeid tot belangrijke graadmeter. Ze drukt uit als een percentage, of een taalmodel voor een bepaalde opdracht na X pogingen de bijhorende testen succesvol kan passeren. “pass@1” is het percentage dat het taalmodel van de eerste keer het juiste antwoord heeft kunnen genereren, “pass@10” is het percentage waarbij minstens 1 van 10 pogingen correct was.

Er is een algemene nood in de wereld van generatieve AI om nieuwe modellen, die ondertussen bijna dagelijks verschijnen, te kunnen vergelijken met de state-of-the-art. Aan benchmarks is er dus geen gebrek, en er verschijnen er geregeld ook nieuwe en grotere. Handige samenvattingen zijn de “leaderboards”, die real-time tonen welke modellen de huidige state-of-the-art vertegenwoordigen volgens een waaier aan benchmarks. Het podium kan wekelijks veranderen. Enkele interessante algemene leaderboards zijn:

• Papers with Code: state-of-the-art in verschillende AI taken, voorzien van begeleidende papers
• Stanford HELM: benchmarkt een breed scala aan taken met focus op “human reasoning”
• LMsys.org FastChat: focus op chatbot-vaardigheden
• HuggingFace OpenLLM leaderboard
• LLM-Leaderboard

Specifiek voor code zijn er benchmarks die min of meer werken zoals een programmeerwedstrijd. Het idee is om een set opdrachten te geven aan het taalmodel, de resultaten automatisch te evalueren, en de “pass@1” en zo mogelijk enkele andere metrieken te meten. Vaak neemt dat een “fill in the function”-vorm aan: gegeven een beschrijving van input en output en een functieheader, moet de inhoud van de functie gegenereerd worden. Een nadeel is dat dit soort problemen soms weinig representatief is voor dat waarmee de doorsnee developer wordt geconfronteerd. Interessante initiatieven zijn onder andere:

• HuggingFace Big Code Models leaderboard (enkel open LLMs)
• Microsoft CodeXGLUE: evaluatie van verschillende subtaken volgens methodes bekend uit Natural Language Processing. Hun leaderboard lijkt af te hangen van vrijwillige contributie en enigszins onvolledig.
• Papers with Code heeft aparte secties voor genereren van code , genereren van documentatie, synthese van hele programma’s en bugfixing
• De HumanEval dataset en MBPP dataset: typische programmeerproblemen (Python)
• De DS-1000 dataset: een set van concrete data science / data processing problemen
• HumanEval-X of MultiPL-E: multi-language versies van HumanEval, meet performantie in meerdere programmeertalen

Dat een gegenereerd stuk code de testen overleeft betekent natuurlijk nog niet dat het ook veilige code is of “best practices” volgt. Er zijn ondertussen voorbeelden genoeg bekend van gegenereerde code die vatbaar blijkt te zijn voor buffer overflows, SQL injection, en andere klassieke risico’s. De “Asleep at the Keyboard” security benchmark bestaat uit 89 code generation scenario’s gebaseerd op de MITRE top-25 vulnerability lijst. Uit de Starcoder paper blijkt dat zelfs de beste modellen in 40% van deze scenario’s toch nog onveilige code genereren. Ook lijkt er nauwelijks verschil te merken tussen de beste modellen en de rest – een beter model kiezen lijkt wel te zorgen voor syntactische correctere resultaten, maar vooralsnog niet voor veiliger code. Mogelijk moet daarom eens gekeken worden naar de trainingsdata zelf, waar onveilige code nog beter uitgefilterd zou moeten worden. In ieder geval moeten we op dit moment adviseren: het gebruik van gegenereerde code in een project moet absoluut gepaard gaan met een robuust beleid inzake testing en acceptatie.

Performantie

Specifiek wat betreft computationele vereisten, zijn het Huggingface OpenLLM-perf leaderboard en de benchmarks op de website van TextSynth Server interessante bronnen. Die laatste toont enkele cijfers over performantie, die handig zijn voor wie met het idee speelt om het zelf te gaan hosten. Wie het zonder GPU doet, kan met het LLaMa2 model van 13 miljard parameters rekenen op een snelheid van 12 tokens per seconde, gegeven een relatief high-end EPYC 7313 serverprocessor. Een token in computercode is soms maar 1 karakter, dus aan dat tempo moet je soms een tiental seconden wachten op een code completion suggestie. De recentste RTX-4090 grafische kaart kan het 7x sneller, maar nog steeds niet zo snel dat je het in milliseconden zou uitdrukken.

De geheugenvereisten zijn evenredig met het aantal parameters van een model, en de generatiesnelheid omgekeerd evenredig. Als een grove benadering mag je aannemen dat een model van 13 miljard parameters, ook 13 miljard berekeningen moet maken voor elk output token, zelfs al is het maar 1 karakter lang. Daarnaast vereist het, als elke parameter een 32-bit getal is, minstens 52GB opslagruimte en evenveel (V)RAM-geheugen. Een “quantization“, die de parameters afrondt naar 8-bit of zelfs 4-bit, kan die geheugenvereiste evenredig doen dalen.

GPT4All laat toe het zelf eens te proberen op je eigen hardware. Dit geeft een idee van de enorme rekenkracht die OpenAI , Microsoft Azure, of Amazon AWS inzetten om hun modellen, die veelal nog groter zijn dan de beschikbare Open Access LLMs, zo snel te kunnen doen draaien als zij dat aanbieden. Er wordt gesproken van investeringen van miljarden dollars in hardware, zodanig groot dat ze de wereldwijde markt destabiliseren.

Zelfs open source oplossingen zijn allesbehalve lightweight te noemen, ondanks verregaande initiatieven tot optimalisatie. Je mag er alleszins van uitgaan dat het lokaal deployen alleen maar haalbaar is op recente en krachtige hardware. Een vlotte user experience kan je momenteel nog niet verwachten van een lokale installatie op de doorsnee kantoorlaptop.

Productiviteit

Het internet staat vol sprookjes over de 10x developer, en goeroes van generatieve AI zouden u graag doen geloven dat deze technologie elke programmeur tot dat niveau kan verheffen. De realiteit is hardnekkiger. Developers spenderen om te beginnen geen 100% van hun tijd aan het schrijven van code, net zomin als dokters 100% van hun tijd voorschriften schrijven. Het merendeel van developers spendeert minder dan 1 uur per dag aan het effectief schrijven van code. De rest van de tijd gaat naar analyseren, lezen, leren, onderhoudstaken, communicatie,… Dat denkwerk en het overleg met de collega’s wordt vooralsnog niet gecomprimeerd door LLMs in te zetten.

Het is moeilijk om harde cijfers te vinden over productiviteit omdat het moeilijk te definiëren en dus te meten is. Een nuttige eerste schatting komt van Google zelf, die de iteratietijd (van kennisname van het probleem tot oplossing) onder de loep nam. Met een eerste versie van hun eigen AI code completion assistent, konden zij 6% tijdswinst noteren. Github zelf beweert dat het pure codeerwerk zo’n 55% sneller kan met hun CoPilot – al zeggen ze er in één adem bij dat het 95%-confidence interval van hun meting [21%-89%] is. De adoptie van een tool brengt bovendien geen meerwaarde als ze niet gepaard gaat met een traject om ze optimaal te leren benutten (net zoals vandaag nog vele kantoormedewerkers tijd verliezen met Office door onvoldoende kennis of ervaring met alle types van referenties, formules en snelkoppelingen).

Gegenereerde code biedt wel snel een eerste oplossing, maar die oplossing moet nog steeds begrepen worden door de programmeur. Een “pass@1” score van 50%, betekent dat de helft van de gegenereerde code snippets nog manuele aanpassingen behoeft voordat ze de unit tests passeert – en dan spreken we nog niet over optimaliteit of veiligheid. Gegenereerde code kan complex zijn en gebruikmaken van constructies die boven het kennisniveau van de programmeur liggen. Dat maakt gegenereerde code moeilijker om te onderhouden en te debuggen dan code die manueel geschreven is. Gegenereerde code die onvoldoende werd gereviseerd en getest, voegt aanzienlijke technical debt toe aan een project.

Het gebruik van plug-ins die zo ver gaan dat ze hele blokken code en documentatie met een vingerknip (of iets trager) kunnen genereren, is slechts een goed idee wanneer verschillende andere aspecten van het software engineering proces op orde zijn: er moeten over de hele lijn hoge standaarden aangehouden worden wat betreft teststrategie, code reviews, documenteren van code en kenniscompetenties van de developers.

Vertrouwelijkheid

Bedrijven en overheden hebben zelden de luxe om eender welk taalmodel te benutten. Er zijn niet alleen contractuele drempels, maar ook vragen over confidentialiteit, zeker bij gebruik van de cloud. Een goede suggestie van een taalmodel krijg je immers alleen door eerst voldoende informatie te uploaden. Als je niet alles in-house opzet, impliceert dat onvermijdelijk dat je een derde partij inzage geeft in jouw gegevens.

De mate van openheid en licentiëring kan aanzienlijk verschillen – in het ene uiterste is alles “black box” en enkel via cloud/API toegankelijk (hier vind je OpenAI, Anthropic, Cohere en de meeste andere gevestigde startups). Deze beloven in Enterprise versies soms meer garanties – maar je hebt nog steeds geen andere optie dan ze daarin te geloven op hun woord. In het andere uiterste is alles “open access” en permissief gelicentieerd. Daartussenin kan een bedrijf ook een Open Access taalmodel bouwen op een gesloten dataset. Van minstens 1 zo’n dataset is ondertussen uitgelekt dat ze illegaal gekopieerde auteursrechtelijk beschermde ebooks bevat, wat ongetwijfeld een sterk argument wordt in de class action lawsuit over het thema tegen Meta. De datasets van de code-LLMs Salesforce CodeGen en Tsinghua CodeGeeX zijn evenmin publiek.

Transparantie, licentiëring, deployment mogelijkheden, prijszetting, grootte en schaalbaarheid,… het relatief belang van al deze kenmerken zal dicteren welke tools je kan gebruiken. Wie maximale transparantie wil, zal sowieso vaak beperkt zijn tot Open Access LLMs. Sommige open licenties beperken het gebruik daarnaast tot niet-commerciële doeleinden. Een noodzaak tot inzage in de trainingsdata of gemakkelijke voorzieningen om zelf on-premise een instantie te kunnen hosten, beperkt de keuzemogelijkheden nog verder.

Conclusie

Dialoog-gebaseerde tools (chatGPT en aanverwanten) kan je als developer nuttig inzetten bij o.a.:

• Het initialiseren van een project/bestand/klasse/configuratie: maak een eerste versie van iets
• Het debuggen en aanpassen op vraag-antwoord-wijze
• Relatief onafhankelijke snippets van code

Tools die code aanvullen of ontbrekende code invullen (type Github Co-Pilot) komen dan weer goed van pas bij o.a.:

• Het vervolledigen van code aan de hand van eerder voorkomende voorbeelden
• Het documenteren van code
• Het maken van veranderingen midden in een groter bestand

De optimale ontwikkelomgeving is voor een developer iets vrij persoonlijks en iedereen zal een eigen voorkeur hebben. In onze ogen zijn deze twee manieren om codesuggesties te krijgen enigszins complementair, en het slim combineren van de twee kan voor de meeste productiviteitswinst zorgen. In één adem willen we daarbij wel zeggen dat een gezond projectmanagement, met aandacht voor codekwaliteit, testing, reviews, documentatie, … daar wel onontbeerlijk bij hoort.

De AI-wereld is in volle beweging. Er komen met de regelmaat van de klok nieuwe AI-modellen bij die kunnen dienen als back-end voor IDE-plugins. Voor industrieën waar vertrouwelijkheid van code belangrijk is, zijn de open-source varianten erg interessant. Zelfs al tonen benchmarks dat die vandaag nog minder performant zijn dan de laatste commerciële cloud-based initiatieven, kunnen we verwachten dat daar in de toekomst ook betere versies van zullen verschijnen. Er zijn alvast veel inspanningen om modellen te maken die op (weliswaar high-end) consumentenhardware kunnen draaien.

P.S.

Enkele uren na het publiceren van dit artikel, kondigt HuggingFace SafeCoder aan: een enterprise-level oplossing voor LLM-gebaseerde coding assistants die on-premise uitgerold kan worden. Huggingface voorziet alles in containers die in het eigen datacenter geïnstalleerd kunnen worden en private endpoints voorzien, én voorziet compatibele plugins voor de belangrijkste IDEs. Andere algemene deployment frameworks bestaan al langer – o.a. Seldon, BentoML en KServe kunnen LLMs hosten, ook TextSynth Server en GPT4All kunnen functioneren als API endpoint. Je hebt echter nog steeds plugins nodig om er gebruik van te kunnen maken in de IDE zelf, en om de nodige pre- en postprocessing te doen – en als ze niet voorzien worden, moet je er zelf eentje maken of een bestaande plugin aanpassen.

P.P.S.

Deze laatste woorden waren nog niet koud of Meta lanceerde Code LLama , een LLaMa 2 variant specifiek getraind voor code. Op sociale media wordt vermeld dat het mogelijk is de originele versie met 34 miljard parameters te draaien op een computer uitgerust met 4 RTX3090 GPUs met elk 24GB VRAM, waarmee ongeveer 20 tokens/seconde gegenereerd kunnen worden. Gemakkelijker is misschien de online chat-versie uit te proberen. Quantized versies zullen ongetwijfeld erg snel volgen, en we verwachten de eerste benchmarks eerstdaags op de verschillende leaderboards.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Even in het kort: het grote verschil tussen een centraal versiecontrolesysteem (CVCS), zoals Subversion (SVN), en een DVCS, is dat je met een DVCS lokale (offline) commits kan doen en je die later kan samenvoegen met de rest, terwijl je bij een CVCS altijd met de centrale server moet communiceren. Dit laat veel kleinere commits toe en vergemakkelijkt het zogenaamde “branchen”, wat dan weer de hele workflow vergemakkelijkt. Eén probleem is wel dat het beheer van zo’n systeem moeilijker wordt, omdat je voor een deel de controle geeft aan de gebruikers.

Voor de rest laat ik de algemene uitleg over VCS aan het internet over, in deze post wil ik het even hebben over Git. Een drietal jaar geleden maakte ik een studie naar VCS, omdat het tijd werd voor een migratie van onze oude CVS-systemen. Doel van de studie was toen om na te gaan welk systeem de opvolger moest worden. Het resultaat was SVN, wat vooral kwam doordat een CVCS systeem beter zou integreren met de huidige organisatie. Een verdienstelijke tweede plaats was toen voor Mercurial (Hg), een DVCS.

Waarom dus niet Git? Heb ik dat dan toen niet bekeken? Zeker wel, maar ik vond dat Git zich toen beter thuis voelde in een *-nix wereld, terwijl wij iets nodig hadden voor Windows. Verder bleek toen ook dat Git werd gebruikt voor het ontwikkelen van de Linux Kernel, en Hg voor de Java OpenJDK, en vermits wij voornamelijk in Java ontwikkelen, voelde Hg dus natuurlijker aan.

De belangrijkste reden waarom ik toen Hg boven Git heb geplaatst, was echter de relatieve eenvoud van Mercurial. Git was eerder een platform, waar je heel krachtige dingen mee kon doen, en Mercurial was eerder een echte eindgebruikerstoepassing, die eenvoudiger was in gebruik en dus een kortere leercurve zou kennen.

Tegenwoordig zijn de gebruikershandleidingen van Git een stuk beter geworden, maar zijn ook de mogelijkheden van Mercurial flink uitgediept. De producten zijn dus wat naar elkaar toegegroeid. Toch is er nog altijd een zekere “feel” die anders is, zoals ook besproken wordt op deze site: Git is MacGyver, Mercurial is James Bond. Op StackOverflow staan er wat nuttiger vergelijkingen tussen de beide. We onthouden hiervan opnieuw dat Mercurial cleaner en eleganter aanvoelt, maar dat Git meer mogelijkheden tot customizatie biedt.

Sinds mijn vergelijkende studie een aantal jaren geleden, zijn de producten echter niet alleen geëvolueerd, maar is ook hun relatieve populariteit veranderd. In de software-ontwikkelingswereld in het algemeen merken we dat de voorkeur meer en meer naar gedistribueerde systemen zoals Git evolueert. Zelfs de grotere Application Lifecycle Management vendors ondersteunen het nu in hun producten. In onderstaande figuur zien we dat, omstreeks 2010, SVN nog steeds het populairste systeem was. Nu liggen de kaarten echter anders, en naar het einde toe zien we dat CVS zelfs onderaan de lijst bengelt. Dit wordt echter tegengesproken door de tweede figuur, waar we merken dat CVS stand houdt qua gebruik in bestaande projecten, ook al is het als zoekterm onderaan het peleton geëindigd. In de eerste figuur is Git echter duidelijk het populairste, en zelfs in de tweede figuur staat het systeem met kop en schouders boven de andere gedistribueerde systemen: Mercurial en Bazaar (bzr).

 VCS systemen volgens google search

Gebruik van VCS volgens Ohloh

Deze trend is al een tijdje aan de gang en lijkt voorlopig niet te keren: wanneer men tegenwoordig een versiecontrolesysteem nodig heeft, grijpt men, zeker in het geval van open source, in de eerste plaats naar Git. Het systeem is de laatste jaren dan ook erg matuur geworden, en heeft het grote voordeel van de gratis online dienst github voor open source projecten. Op deze manier kan Git in de hoofden van nieuwere generaties developers steeds vaker het eerste zijn waar ze aan denken bij de woorden “source code control”.