Le développement de code sécurisé va au-delà des outils et des logiciels : c’est une activité complexe fondée sur la gestion des risques et qui implique de comprendre les forces et les faiblesses d’un développeur.
Reconnaître le niveau d’expertise de vos développeurs est très utile et aide à déterminer où les problèmes de sécurité sont les plus susceptibles de survenir, ainsi que quel développeur est le mieux adapté à telle ou telle tâche.
À mesure que les grands modèles de langage (LLM) d’IA générative écrivent davantage de code, leur gestion exige la même approche.
Chaque modèle a son propre style de programmation, avec notamment des points forts dans des domaines comme la création de code, et des points faibles en matière d’angles morts de sécurité. En définitive, les modèles d’IA ont eux aussi chacun leur propre personnalité.
Bien que le code généré par l’IA soit « fabriqué par une machine », chaque modèle et le code qu’il produit nécessitent une approche personnalisée de leur sécurisation et de leur revue, afin de ne pas négliger l’atténuation des risques et des vulnérabilités potentiels introduits par les LLM.
Les organisations doivent établir des examens précis de sécurité, avec des développeurs humains au cœur du processus pour mettre en œuvre des contrôles de sécurité efficaces, tout en gérant le tempérament particulier de chaque LLM utilisé.
généré par l’IA, le code ne doit pas être traité différemment du code produit par des développeurs humains et doit faire l’objet des mêmes évaluations personnalisées des risques.
Points clés à retenir
- Les LLM présentent des « personnalités de programmation » distinctes qui influencent la qualité du code, sa complexité, sa documentation et les résultats en matière de sécurité.
- Une analyse de Sonar a révélé que les principaux modèles d’IA de programmation partagent des faiblesses communes, notamment des angles morts de sécurité, une dette technique et la possibilité d’introduire des vulnérabilités de gravité élevée.
- Aucun modèle n’excelle dans toutes les tâches ; il est donc important d’adapter les forces et les faiblesses des LLM aux cas d’usage spécifiques du développement.
- Les développeurs doivent posséder de solides compétences en sécurité pour examiner, valider et sécuriser efficacement le code généré par l’IA tout au long du cycle de vie du développement logiciel.
- Les organisations devraient traiter le code généré par l’IA comme du code écrit par des humains, en lui appliquant les mêmes évaluations des risques, pratiques de programmation sécurisée et processus de revue.
Pour créer du code, les LLM sont aussi des personnes
Dans un rapport récent de Sonar, l’entreprise a entrepris une analyse approfondie de cinq LLM de premier plan : Claude Sonnet 4 et 3.7 d’Anthropic, GPT-4o d’OpenAI, Llama 3.2 90B de Meta et l’OpenCoder-8B open source.
Le rapport compare les forces des modèles à différents égards, notamment leur capacité à produire du code syntaxiquement valide, à faire preuve de compétence technique et à fonctionner avec différents langages de programmation.
Il met également en évidence des faiblesses communes, notamment un manque flagrant de sensibilisation à la sécurité, qui se traduit en particulier par des logiciels vulnérables aux attaques présentant les niveaux de gravité les plus élevés, un manque de rigueur d’ingénierie et une tendance à produire du code désordonné.
Autre constat clé soulignant l’importance de la gestion des risques : les LLM ne se ressemblent pas vraiment ; chacun possède ses propres particularités, préférences et angles morts de sécurité.
Tout comme les personnalités des développeurs humains, chaque modèle possède son propre style, qualifié de « personnalité de programmation » dans le rapport, qui peut influer sur la manière dont les développeurs humains examinent et analysent les résultats générés par l’IA.
Le rapport a identifié trois traits principaux et mesurables parmi les LLM testés : la complexité et la communication, la verbosité et la documentation.
Un modèle plus verbeux, par exemple, génère bien plus de lignes de code pour accomplir une tâche qu’un modèle comparativement plus laconique, ce qui peut rendre la revue du code plus fastidieuse.
De même, les modèles verbeux tendent à produire des solutions plus complexes. Ils peuvent être nécessaires pour certaines tâches, mais ils exigent davantage d’effort cognitif de la part des réviseurs du code qu’un modèle à l’approche plus directe.
Les modèles testés ont également présenté tout un éventail de styles de communication, comme en témoigne la quantité de documentation qu’ils fournissent pour expliquer leur travail.
Ensemble, ces indicateurs constituent un type de personnalité, comparable aux types de développeurs humains, selon le rapport :
- L’architecte senior (Claude Sonnet 4). Bon pour concevoir des systèmes complexes destinés aux entreprises, mais tout ce code impressionnant pourrait dissimuler de graves bugs.
- Le prototypage express (OpenCoder 8B). Rapide et déchaîné, il est doué pour lancer rapidement des projets, mais génère une montagne de dette technique susceptible de créer des difficultés par la suite.
- La promesse non tenue (Llama 3.2 90B). Beaucoup de potentiel, mais des performances moyennes, avec des angles morts critiques en matière de sécurité.
- Le généraliste efficace (GPT-4o). Ni excessivement verbeux ni particulièrement concis, il peut être utilisé pour une grande variété de tâches et tend à éviter les problèmes de sécurité les plus graves, mais il peut manquer de rigueur et ouvrir la voie à des erreurs qui compromettent la qualité et la fiabilité.
- Le prédécesseur équilibré (Claude 3.7 Sonnet). Il produit du code très fonctionnel, accompagné d’une excellente documentation, mais peut également générer des vulnérabilités de gravité élevée.
C’est une excellente illustration du fait que les différents modèles ont chacun leurs forces et leurs faiblesses, qu’il est extrêmement utile de connaître pour décider quel LLM affecter à certains projets, tout comme on pourrait confier une application critique à un architecte senior plutôt qu’à un programmeur débutant.
Mais cela souligne également l’importance de doter les développeurs des compétences dont ils ont besoin pour examiner efficacement et rapidement le code généré par l’IA.
Les développeurs doivent maîtriser la sécurité pour gérer les personnalités de l’IA
En définitive, si les LLM présentent des avantages et peuvent améliorer efficacement le code, un facteur essentiel réside dans la rigueur avec laquelle ils sont gérés au sein du cycle de vie du développement logiciel (SDLC).
Les développeurs doivent renforcer leurs compétences en sécurité afin de garantir une gestion efficace des risques.
La présence d’humains dans la boucle ne suffit pas : ils doivent disposer de la formation et des compétences nécessaires pour garantir la fiabilité du code généré par l’IA et éviter que la dette technique ne s’accumule dans un environnement de développement accéléré par les assistants d’IA.
Tout aussi important, les développeurs doivent également savoir formuler des requêtes aux modèles d’IA de manière à favoriser la génération de code sécurisé et effectuer des revues de sécurité compétentes des résultats produits par l’IA.
Comprendre la personnalité de programmation d’un modèle d’IA peut aider, mais il est essentiel de renforcer les compétences des développeurs.
La meilleure façon de réduire les risques et de garantir que les logiciels sont sécurisés consiste à prévenir les vulnérabilités dès le début du SDLC.
Quelle que soit la source du code créé, la formation des développeurs est un moyen incontournable de garantir une programmation, une revue de code et des tests sécurisés.
Les RSSI devraient également donner la priorité aux modèles les moins risqués pour les tâches concernées et renforcer les capacités des développeurs grâce à la formation et au développement de leurs compétences.
En tenant compte des « personnalités » des LLM et en veillant à la maîtrise de la sécurité par les développeurs, les organisations peuvent combler les lacunes en matière de connaissances de sécurité, s’attaquer à la dette technique et contribuer à atténuer le risque croissant présent dans leurs propres bases de code.
Cet article invité a été rédigé par Matias Madou, Ph.D., CTO et cofondateur de Secure Code Warrior.