L’IA passe à l’action pour sécuriser le code open source

Un nouvel outil d’IA pour identifier et corriger les vulnérabilités des logiciels libres

L « état des logiciels libres La sécurité des logiciels libres est défaillante depuis longtemps. La plupart des vulnérabilités subsistent non pas parce qu’elles sont difficiles à détecter, mais parce que personne ne se préoccupe de les corriger à grande échelle. Les choses commencent à changer. Une équipe de chercheurs néerlandais et iraniens a mis au point un outil d’IA générative qui détecte et corrige les failles de sécurité dans d » énormes dépôts de code comme GitHub. L’outil s’attache à des modèles spécifiques de code dangereux, comme une faille de traversée de chemin dans Node.js qui existe depuis plus de dix ans, et génère automatiquement des correctifs.

Lors d’un test, l’IA a passé GitHub au peigne fin et a repéré 1 756 projets Node.js utilisant du code vulnérable, dont certains sont décrits comme « très influents ». Elle a envoyé des rapports aux responsables, et 63 projets avaient été corrigés au moment de la publication des résultats. Cet outil nous rapproche d’un monde où les machines se chargeront du travail de nettoyage de routine à grande échelle, afin que les développeurs puissent consacrer plus de temps à la résolution de problèmes plus difficiles.

Pour les dirigeants qui gèrent des portefeuilles de logiciels ou des infrastructures numériques, il s’agit d’une avancée indéniable. L’IA surveillant et atténuant les menaces avant qu’elles ne se transforment en incidents de sécurité, les risques diminuent et la vitesse de développement augmente.

Les données d’apprentissage contaminées conduisent à la reproduction de schémas vulnérables

Il y a un problème, et il est de taille. Les outils d’IA censés détecter le mauvais code le propagent parfois. Cela s’explique par le fait que LLM (Large Language Models)comme ceux qui font fonctionner cet outil de sécurité ou qui alimentent ChatGPT, s’entraînent sur des bases de code à source ouverte. Ces bases de code contiennent des modèles obsolètes, défectueux et vulnérables. Lorsqu’un modèle d’IA s’entraîne sur ces données, il peut, à son insu, reproduire ces mêmes vulnérabilités dans le code généré, même si vous lui demandez d’écrire quelque chose de sûr.

L’équipe de recherche a confirmé que ces modèles, lorsqu’ils étaient exposés à des exemples plus anciens comportant des failles de sécurité, répétaient simplement ces failles dans le nouveau code. Cela signifie que le bogue ne se trouve pas seulement dans votre projet GitHub, mais aussi dans le cerveau de l’IA. À ce stade, il ne suffit pas de corriger le code. Vous devez nettoyer le pipeline de données qui alimente les modèles.

Pour les dirigeants, en particulier les directeurs des systèmes d’information et les directeurs techniques, il s’agit d’un signal d’alarme. Il ne s’agit plus seulement d’auditer des applications, mais aussi des modèles. Si vos systèmes d’IA prennent des décisions ou écrivent du code, vous devez savoir sur quoi ils ont été formés. Des données d’entraînement contaminées signifient que vous intégrez d’anciennes erreurs dans de nouveaux systèmes. Corrigez cela et vos outils d’IA deviendront de véritables atouts pour votre stratégie de sécurité. Si vous n’en tenez pas compte, vous venez d’installer un générateur de vulnérabilités à grande vitesse.

Des pratiques humaines persistantes et des normes communautaires perpétuent l’insécurité des codes.

La technologie n’est pas le seul problème. Les personnes et, par extension, les habitudes qu’elles ont prises, expliquent en grande partie pourquoi le code non sécurisé reste en vie. Depuis 2010, les développeurs utilisent et réutilisent un extrait de code Node.js qui contient une dangereuse vulnérabilité de traversée de chemin. Le problème a été signalé à plusieurs reprises, en 2012, 2014 et 2018, mais le modèle n’a jamais disparu. Il a continué à être réaffiché, mis en œuvre et même utilisé dans des contenus éducatifs de niveau débutant, y compris des cours et de la documentation provenant de communautés de développeurs de confiance.

Le problème n’est pas seulement dû à l’ignorance. Les développeurs débattent souvent des problèmes de sécurité dans les forums publics, et même lorsque quelqu’un signale que le code est vulnérable, d’autres s’y opposent, insistant sur le fait qu’il est sûr après des tests limités. Il s’agit là d’un problème récurrent. Les outils de développement courants, tels que les navigateurs ou les commandes curl, ne déclenchent pas la vulnérabilité dans des conditions normales, mais cela ne signifie pas qu’elle n’est pas exploitable. Les attaquants n’utilisent pas les outils de la même manière que les développeurs.

Pour les cadres qui dirigent des organisations d’ingénierie, c’est le signe que la culture est aussi importante que le code. Vous ne pouvez pas compter sur la communauté pour s’auto-corriger, en particulier lorsque les connaissances en matière de sécurité ne sont pas réparties uniformément. C’est pourquoi les examens de sécurité internes, l’amélioration des normes de documentation et les programmes de formation doivent faire partie de la feuille de route. Vous ne sécurisez pas seulement les systèmes, vous mettez également à jour des habitudes qui n’ont pas été contrôlées pendant plus d’une décennie.

Les limites de l’outil d’IA ont une incidence sur son évolutivité et son efficacité

Malgré ses progrès, l’outil d’IA n’est pas une solution complète. Il analyse un modèle de vulnérabilité spécifique, ce qui signifie qu’il ne détectera pas les variantes ou des classes de failles entièrement différentes, à moins qu’il ne soit étendu et entraîné à nouveau. Et même lorsqu’il corrige une vulnérabilité, ce correctif peut être manqué ou contourné dans les projets forkés. Le développement open-source est distribué, des versions du même code vivent dans des milliers d’endroits, dont beaucoup sont obsolètes ou orphelins. Un correctif n’atteindra pas toutes les branches à moins qu’il ne soit appliqué projet par projet.

Il y a aussi la question de la qualité des correctifs. Les correctifs générés par l’IA peuvent introduire de nouveaux bugs. Pour l’instant, l’outil envoie le correctif aux responsables humains avec une note de gravité, mais rien ne garantit que le code a été entièrement testé. La responsabilité de l’intégration et de la validation du correctif incombe toujours au responsable du projet. Cela nécessite une supervision, un processus et un suivi.

Si vous dirigez des équipes techniques ou gérez des portefeuilles de produits, l’implication est claire : vous pouvez donner à l’IA un siège à la table, mais elle a toujours besoin d’un homologue humain. Utilisez les outils pour augmenter le rendement et découvrir les lacunes, mais maintenez des processus de révision solides et une gouvernance du code pour éviter d’échanger d’anciennes failles contre de nouvelles. L’automatisation durable commence par la compréhension de ses limites.

Problèmes de confiance, de responsabilité et de surveillance dans les correctifs alimentés par l’IA

L’automatisation des corrections de code grâce à l’IA semble efficace jusqu’à ce que vous vous demandiez qui assume la responsabilité en cas de panne. Cette question n’a toujours pas de réponse claire. Robert Beggs, directeur de DigitalDefence, soulève de réelles inquiétudes à ce sujet. Il se demande si les responsables des référentiels seront en mesure de détecter si un correctif généré par l’IA introduit une nouvelle vulnérabilité. Plus important encore, qui est responsable si cela se produit ? Le chercheur, le développeur, le fournisseur d’IA ou le responsable du projet ?

Si un patch généré par une machine nuit à un projet public, il y a un risque économique et de réputation. En fonction de la cible, un correctif peut affecter les dépendances en amont et en aval d’écosystèmes entiers. Le modèle actuel place la responsabilité finale sur le responsable du projet. L’outil d’IA crée un correctif, lui attribue une note CVSS (Common Vulnerability Scoring System) et inclut un rapport. Mais il n’y a pas encore de test ou de validation intégrés dans le processus de remédiation.

Les dirigeants doivent en tenir compte dans les politiques de risque liées à l’automatisation. L’ajout de l’IA aux flux de travail du code implique d’étendre la gouvernance, et non de la remplacer. Vous aurez besoin de points de contrôle, de cadres d’audit et de protocoles de communication clairs entre les équipes qui utilisent l’IA et celles qui maintiennent le code. Sans cela, l’automatisation des correctifs pourrait devenir un handicap. Avec elle, vous gagnez en rapidité, sans perdre le contrôle.

Améliorations futures et utilité accrue de l’outil d’IA

L « équipe à l’origine de l’outil de correction de l’IA ne s’arrête pas en si bon chemin. Ils prévoient de le rendre public lors d’une conférence sur la sécurité au Viêt Nam, avec une feuille de route pour l » étendre et l’améliorer. Pour l’instant, il ne cible efficacement qu’un seul modèle de vulnérabilité. Les prochaines versions étendront la détection à d’autres structures de code non sécurisées connues. La création de correctifs sera également affinée afin de réduire les risques et d’améliorer la précision, en particulier dans des environnements de codage diversifiés avec des implémentations non standard.

Ce développement itératif permet d’élargir l’impact, mais il accroît également la complexité. L’intégration de nouveaux types de vulnérabilités dans le modèle implique un recyclage et une revalidation. Chaque extension introduit de nouveaux cas limites et de nouvelles dépendances. Mais c’est la direction dont cet espace a besoin. Il ne s’agit pas seulement d’automatiser les corrections de bas niveau, mais de donner aux équipes des outils qu’elles peuvent adapter.

Les dirigeants devraient garder un œil sur ces développements. Au fur et à mesure que ces outils évolueront, ils deviendront des infrastructures clés pour la sécurisation des ressources open-source dont votre organisation dépend. Il sera essentiel de garantir la compatibilité, la stabilité et la confiance dans ces outils au fur et à mesure de leur adoption. Les investissements stratégiques dans cette technologie, en particulier lorsqu’ils sont associés à des flux de travail responsables et humains, créeront des avantages à long terme.

Principaux enseignements pour les décideurs

• L’application de correctifs à grande échelle par l’IA est désormais viable : Un outil d’IA générative a démontré sa capacité à analyser et à corriger efficacement des milliers de projets open-source, ce qui montre un fort potentiel pour l’automatisation de la maintenance de la sécurité à grande échelle.
• L’hygiène des données de formation est essentielle pour la fiabilité de l’IA : Les modèles d’IA formés sur un code source ouvert défectueux peuvent reproduire les vulnérabilités dans le nouveau code, ce qui rend impératif pour les dirigeants d’examiner minutieusement les données d’entraînement et d’investir dans des protocoles de recyclage des modèles.
• Les habitudes des développeurs continuent d’alimenter des risques de longue date : Les modèles de codes non sécurisés persistent sur toutes les plateformes en raison de la désinformation de la communauté et de la réutilisation systématique, ce qui souligne la nécessité d’améliorer les normes de codage internes et de former les développeurs de manière ciblée.
• L’automatisation a besoin d’une supervision structurée pour s « étendre en toute sécurité : La portée limitée des vulnérabilités de l’outil d’IA et sa dépendance à l » égard de la validation humaine soulignent l’importance d’une gouvernance rigoureuse et d’un contrôle de la qualité des correctifs générés par l’IA.
• La responsabilité doit être définie avant l’intégration : En l’absence de structures claires permettant de déterminer qui est responsable du risque lié aux correctifs générés par l’IA, les dirigeants devraient retarder l’intégration complète jusqu’à ce que la responsabilité, les flux de travail de révision et les sécurités contre les défaillances soient établis.
• La poursuite du développement permettra d’accroître l’utilité de l’outil : L’équipe de recherche prévoit de prendre en charge davantage de vulnérabilités et d’appliquer des correctifs plus intelligents, ce qui donnera aux premiers utilisateurs la possibilité de mettre en place une infrastructure sécurisée au fur et à mesure que l’outil arrivera à maturité.