La détection de vulnérabilités potentielles dans les logiciels open source est devenue plus facile grâce aux outils d’intelligence artificielle, mais la facilité à trouver un problème présumé ne signifie pas qu’il s’agit d’une vulnérabilité réelle et exploitable. En conséquence, les responsables de projets font face à un flux de signalements longs, imprécis ou répétitifs, qui consomme du temps qui pourrait être consacré à la correction des défauts et au développement des logiciels.
L’initiative Akrites, annoncée par la Linux Foundation en juin, tente de combler cette lacune grâce à une équipe commune de réponse aux incidents de sécurité (SIRT). Sa mission consiste à regrouper les signalements de vulnérabilités, à les vérifier et à coordonner les corrections avec les responsables des projets concernés. Lors d’un entretien accordé à The New Stack pendant l’Open Source Summit Europe à Prague, Christopher Robinson, directeur technique d’Akrites et architecte principal de la sécurité à l’Open Source Security Foundation (OpenSSF), ainsi que Laura Guazzelli, architecte de la sécurité de l’intelligence artificielle et des systèmes agentiques à la Linux Foundation, ont expliqué la nature du problème et le fonctionnement de l’initiative.
De la « recherche spontanée » à une charge opérationnelle
Selon Robinson, il suffit désormais de disposer d’un compte payant à 20 dollars pour commencer à rechercher des vulnérabilités, ce qui illustre l’abaissement de la barrière à l’entrée pour les non-spécialistes. Adrianne Marcum, directrice de cabinet de l’OpenSSF, a décrit ce phénomène de manière ironique en utilisant l’expression « vibe researching », pour désigner l’utilisation d’outils d’intelligence artificielle afin d’analyser du code et d’envoyer les résultats sans disposer du contexte de sécurité ni de l’expertise nécessaires pour les vérifier.
Robinson estime que l’examen d’un seul signalement de sécurité peut prendre jusqu’à huit heures à un ingénieur. En outre, les signalements automatisés sont, selon lui, très détaillés, mais souvent imprécis ; ils surestiment la gravité du problème et ne fournissent pas toujours les données nécessaires pour rédiger un correctif ou comprendre la méthode d’exploitation.
Pourquoi la détection de code suspect ne suffit-elle pas ?
L’une des principales limites tient au fait que le modèle peut repérer un extrait suspect sans comprendre l’ensemble de l’architecture de sécurité du projet. Des contrôles supplémentaires peuvent en effet se trouver ailleurs et empêcher l’exploitation de la faille, transformant le signalement en faux positif ou réduisant sa gravité réelle. De plus, les modèles similaires ont tendance à détecter les mêmes défauts, de sorte que plusieurs signalements concernant un seul et même problème parviennent aux responsables.
Akrites ne considère toutefois pas que l’ignorance des signalements générés par l’intelligence artificielle soit une option pratique. Robinson affirme que la qualité des résultats s’est améliorée au cours de l’année, en particulier avec les modèles payants les plus coûteux. Les outils peuvent également, dans certains cas, relier des problèmes de faible gravité et les transformer en une chaîne d’exploitation plus importante, une tâche qui pourrait demander des mois ou un an à un chercheur humain.
Une revue humaine avant l’arrivée du signalement dans le projet
Akrites utilise l’intelligence artificielle pour évaluer les signalements reçus et détecter les doublons, puis des ingénieurs détachés les examinent avant de les transmettre aux responsables. Leur rôle ne se limite pas à déterminer si la vulnérabilité existe : il consiste également à condenser le signalement et à ajouter des cas de test, des preuves de concept et des correctifs, afin que le projet puisse prendre une décision plus rapidement et sur la base d’éléments probants.
L’initiative compte parmi ses membres fondateurs Anthropic, OpenAI, Google, Microsoft, AWS, NVIDIA, Cisco, IBM, Red Hat, Citi et JPMorganChase. Selon Robinson, les membres doivent fournir des ressources d’ingénierie en plus du financement, et leur engagement peut atteindre 10 ingénieurs à temps plein par membre. Il affirme disposer d’environ 200 ingénieurs détachés, dont beaucoup sont déjà des contributeurs ou des responsables de projets open source.
Qu’est-ce qui change concrètement ?
Akrites ajoute une couche de tri et de vérification entre les outils de détection des vulnérabilités et les responsables de projets, au lieu de transmettre directement chaque résultat automatisé aux propriétaires du code. Cela pourrait réduire le bruit et améliorer la capacité d’action des signalements, mais n’élimine ni le besoin d’expertise humaine ni celui d’un financement continu, puisque l’infrastructure et l’utilisation des modèles de langage nécessitent d’importantes ressources.
Une autre initiative liée à la Linux Foundation, l’open source Cyber Reasoning System (OSS-CRS), développe des outils destinés à aider les projets eux-mêmes à enquêter sur les vulnérabilités et à proposer des correctifs. Alors qu’Akrites se concentre sur la coordination du cycle des signalements entre les projets, OSS-CRS cherche à permettre aux responsables d’effectuer une plus grande partie du travail. L’efficacité des correctifs proposés demeure une question ouverte, car il faut vérifier qu’ils traitent la cause profonde sans introduire de nouvelles vulnérabilités ni casser des fonctionnalités existantes.