Dans le monde numérique moderne, l'épine dorsale de presque tous les services en ligne est une vaste couche invisible d'ordinateurs et de logiciels connue sous le nom d'infrastructure. Pendant des décennies, la mise en place de cette infrastructure nécessitait des équipes d'ingénieurs pour configurer manuellement les serveurs, les bases de données et les paramètres de sécurité, un processus lent et sujet aux erreurs. Pour remédier à cela, l'industrie a adopté une méthode appelée « Infrastructure en tant que Code » (Infrastructure as Code), où l'ensemble de la configuration est écrit sous forme de fichiers texte, un peu comme une recette détaillée ou un plan de construction. Ces fichiers texte indiquent aux ordinateurs exactement comment construire et sécuriser un système, permettant un déploiement rapide, cohérent et automatisé. Cependant, tout comme une recette à laquelle il manque un ingrédient peut gâcher un repas, une seule erreur dans ces fichiers de code peut laisser un système grand ouvert aux pirates informatiques. Si le code contient des faiblesses cachées, telles que des mots de passe non chiffrés ou des règles d'accès trop permissives, ces failles sont instantanément transférées au système réel dès qu'il est activé.

Récemment, un nouvel outil est entré dans ce domaine : les assistants de codage par intelligence artificielle. Ces programmes peuvent lire une requête simple en langage courant et écrire automatiquement le code complexe nécessaire pour construire ces systèmes. Bien que cela promette d'accélérer le développement, cela soulève une question critique qui n'avait jamais été résolue jusqu'à présent : le code que ces machines écrivent garantit-il réellement la sécurité des systèmes ? Les chercheurs de l'Université de Waikato, en Nouvelle-Zélande, se sont donné pour mission de trouver la réponse. Ils ne cherchaient pas seulement des bogues ; ils enquêtaient pour savoir si le code généré par ces outils d'IA respectait les normes de sécurité strictes du monde réel requises par les gouvernements et les industries pour protéger les données. Leurs travaux révèlent un écart frappant entre ce que ces outils d'IA peuvent faire et ce qu'ils font réellement lorsqu'ils sont laissés à eux-mêmes, et ils offrent une voie claire pour résoudre le problème avant qu'une seule ligne de code ne soit déployée.

L'équipe a commencé par tester le comportement par défaut de seize modèles d'intelligence artificielle différents. Elle a demandé à chaque modèle d'écrire un ensemble spécifique d'instructions, appelé un rôle Ansible, pour installer deux types de logiciels courants : un serveur web appelé Apache Tomcat et un système de base de données appelé MongoDB. Elle n'a donné aux modèles aucun conseil de sécurité particulier, aucune mise en garde sur ce qu'il fallait éviter, ni aucun exemple de bon code. Elle a simplement demandé aux machines de faire le travail. Les résultats ont été immédiats et préoccupants. Chacun des seize modèles a produit un code contenant des failles de sécurité. Ces failles comprenaient des mots de passe codés en dur que n'importe qui pouvait lire, des protections manquantes pour les fichiers sensibles et un manque de gestion des erreurs qui pourrait provoquer le plantage du système ou un comportement imprévisible. Lorsque les chercheurs ont comparé ce code généré par l'IA au code écrit par des développeurs humains provenant de dépôts publics, le code de l'IA a obtenu de moins bons résultats. Il n'était pas seulement légèrement défectueux ; il était fondamentalement peu sûr, ne respectant pas les exigences de base en matière de sécurité qui sont la norme dans l'industrie.

Les chercheurs ont ensuite cherché à comprendre pourquoi cela se produisait. Ils ont découvert que le problème n'était pas nécessairement que les modèles d'IA manquaient de capacité à écrire du code, mais qu'ils manquaient de capacité à suivre des instructions complexes concernant la sécurité. Dans une deuxième phase de l'étude, l'équipe a changé d'approche. Au lieu de simplement demander du code, elle a fourni aux modèles un ensemble de règles hautement structuré. Ils ont utilisé une version étendue d'un cadre de prompting qui listait explicitement les meilleures pratiques de sécurité et les normes de sécurité gouvernementales spécifiques. Ils ont dit aux modèles exactement quelles permissions définir, comment gérer les mots de passe de manière sécurisée et quelles documentations inclure, traitant ces exigences comme des contraintes obligatoires plutôt que comme des suggestions. Ce passage d'une simple requête à une instruction détaillée basée sur des règles a radicalement changé le résultat.

Lorsque les chercheurs ont appliqué cette approche structurée, les résultats se sont considérablement améliorés. Quatre des seize modèles ont été capables de suivre les instructions complexes et de générer un code exempt des failles de sécurité observées lors du premier tour. Le modèle le plus performant a produit un code respectant entre quatre-vingt-quinze et cent pour cent des critères de sécurité stricts, un bond massif par rapport à la base de référence. En fait, ce meilleur modèle d'IA a surpassé le code moyen écrit par des humains, qui ne respectait que vingt-trois à quarante-trois pour cent des mêmes normes. L'étude a montré que pour ces modèles capables, le problème n'était pas un manque de connaissances, mais un échec de l'application de ces connaissances lorsque les instructions étaient vagues. Lorsque les règles étaient claires et les contraintes explicites, l'IA pouvait synthétiser un code sécurisé et de haute qualité en une seule tentative, éliminant ainsi le besoin de corrections chronophages une fois le code déjà écrit.

L'étude a également mis en évidence une distinction cruciale entre les modèles. Les quatre modèles ayant réussi étaient tous des systèmes à code source fermé, ce qui signifie que leurs processus internes ne sont pas publics, tandis que de nombreux modèles en code source ouvert ont échoué à suivre les instructions complexes. Cela suggère que la capacité à générer du code sécurisé dépend fortement de la manière dont le modèle a été entraîné et des capacités spécifiques qu'il a développées lors de cet entraînement, plutôt que de la simple taille de sa mémoire ou du nombre de ses paramètres. Les chercheurs ont constaté que les modèles qui ont réussi étaient capables d'analyser les instructions multicouches, de comprendre la différence entre les règles obligatoires et les pratiques recommandées, et de les appliquer de manière cohérente à travers le code. Les modèles qui ont échoué, même ceux ayant obtenu de bons scores lors d'autres tests de codage, n'ont tout simplement pas pu maintenir les multiples contraintes nécessaires à la construction d'un système sécurisé.

Ce travail remet en question la manière dont l'industrie gère actuellement la sécurité. Traditionnellement, les experts en sécurité attendent que le code soit écrit pour ensuite l'analyser afin de trouver et de corriger les erreurs, un processus connu sous le nom de détection. Les chercheurs soutiennent que pour le code généré par l'IA, cette approche est insuffisante car les failles sont introduites au moment même où le code est créé. Au lieu de cela, ils proposent une méthode de prévention, où les exigences de sécurité sont intégrées au processus de génération lui-même. En intégrant les règles de sécurité directement dans les instructions données à l'IA, les organisations peuvent garantir que le code est sécurisé dès le départ. Cette approche ne nécessite pas de réentraîner les modèles d'IA ni de changer leur architecture sous-jacente ; elle nécessite seulement un changement dans la façon dont les humains leur parlent. L'étude conclut que, bien que les assistants de codage par IA soient très prometteurs, on ne peut pas leur faire confiance pour générer des infrastructures sécurisées sans une orientation claire et explicite. Avec les bons prompts, cependant, ils peuvent produire un code qui est non seulement fonctionnel, mais aussi plus sûr que ce que produisent beaucoup de développeurs humains aujourd'hui.