Cyber Resilience Act : les SBOM mises à l’épreuve par les agents IA

L’inadéquation des SBOM à l’ère de l’IA

Les auteurs des réglementations n’ont évidemment pas pu prendre en compte la vitesse à laquelle l’IA générative et agentique s’imposerait chez les éditeurs de logiciels et les mainteneurs de projets open source.

Une enquête de la Linux Foundation intitulée « World of Open Source », menée auprès de plus de 600 répondants du monde entier sous-entend que 94 % des organisations utilisent ou testent des outils de programmation GenAI. Environ 48 % ont déclaré que ces outils avaient accru leur utilisation de librairies open source, selon un rapport publié lors du sommet de cette semaine.

Parallèlement, le nombre de vulnérabilités que tout développeur peut potentiellement introduire dans un logiciel de production en s’appuyant sur du code généré par l’IA a augmenté de façon exponentielle, selon Torsten Volk, analyste chez Omdia, une division d’Informa TechTarget.

Les outils IA facilitent l’expérimentation – et finalement la mise en production – d’une gamme beaucoup plus large de bibliothèques de code et d’artefacts que les développeurs ne pouvaient gérer auparavant, poursuit-il.

Selon lui, les développeurs n’ont plus à configurer les bibliothèques et, plus important encore, ils n’ont plus à éplucher la documentation API pour les faire fonctionner.

« Un agent pourrait récupérer un ancien code source ouvert comportant des CVE, le copier dans une application, puis transporter ces vulnérabilités, sans que le composant d’origine n’apparaisse jamais dans la SBOM », soutient l’analyste.

Les SBOM répertorient en principe chaque composant d’un produit logiciel et seront obligatoires en vertu du Cyber Resiliency Act à compter de décembre 2027, mais elles sont lamentablement inadaptées face au déluge de code généré par l’IA, en particulier pour les packages et les bibliothèques open source, considère Torsten Volk.

« Comme les agents d’IA sont capables d’insérer toutes sortes de code dans nos applications, il est crucial de ne pas se fier à une analyse statique qui repose sur l’hypothèse que ces agents obéissent toujours à nos consignes », souligne-t-il. « Pour relever ce défi, nous devons analyser en permanence tout nouveau code dans le contexte du code source existant. »

L’inadéquation des SBOM pour l’open source à l’ère de l’IA agentique concerne les centaines de projets gérés par la CNCF, déclare Mario Fahlandt, architecte de livraison client chez Kubermatic, membre du comité de surveillance technique de la CNCF et responsable du projet SBOM CNCF de Kubermatic.

« Nous ignorons la composition interne de nos environnements. Toutes ces dépendances restent un mystère pour tous, y compris pour les mainteneurs », affirme Mario Fahlandt lors d’une présentation à l’Open Source Summit. « Nous avons moins de mainteneurs pour une charge de travail accrue à cause des pull requests générées par l’IA. Si nous ne connaissons pas les paquets présents dans nos logiciels, nous ne pouvons pas savoir s’il existe une faille de sécurité, une vulnérabilité CVE ou une attaque de la chaîne d’approvisionnement ».

Les risques liés à l’IA ne se limitent pas aux agents de chasse aux vulnérabilités

Le « slopsquatting » est un exemple de risque de sécurité lié à la chaîne d’approvisionnement des logiciels d’IA, sans lien avec la recherche de vulnérabilités dans du code légitime existant. Bien que le terme soit relativement récent, la pratique existe depuis au moins deux ans.

Elle consiste pour un individu malveillant à demander à des agents d’IA, comme Claude, de lister des bibliothèques. Ces agents proposent alors des noms pour des bibliothèques inexistantes. L’attaquant publie ensuite ces noms sur npm ou PyPI, par exemple, accompagnés de code exploitable. Un autre développeur, de bonne foi, installe ce code en pensant qu’il s’agit d’une bibliothèque légitime (Claude en fournit le nom et le lien).

Le développeur ignore que l’attaquant a accès à son programme et peut exécuter diverses actions malveillantes, telles que le vol de clés, de données ou d’autres actions. Le SBOM échoue finalement, car Claude a inventé le nom de la bibliothèque, et celle-ci existe sous ce nom avec un code que personne ne souhaite installer.

Le code généré par l’IA et les copilotes pour les commandes ou tâches BASH de base représente également un risque majeur. Même des tâches apparemment anodines peuvent exposer des ports, des secrets et d’autres informations sensibles. Comme la configuration d’un noyau sur un cluster Kubernetes dans une infrastructure cloud ou la configuration de fichiers YAML en vibe coding. Les erreurs humaines susceptibles d’exposer des logiciels à des attaques existent depuis des années. Affirmer que l’IA générative aggrave ce risque serait un euphémisme.

Cette dynamique représente un enjeu majeur pour la maintenance du kernel Linux, selon les propos de Linus Torvalds, créateur de Linux et de Git, lors de la conférence d’ouverture de l’Open Source Summit. Il souligne la hausse du nombre de correctifs affectant le « réacteur » de plusieurs systèmes d’exploitation.

La mise à jour du kernel Linux 7.2 en août a été l’une des plus importantes de son histoire, avec l’ajout de 600 000 lignes de code apportées par un nombre record de 2 652 développeurs. On a dénombré 1 111 commits dans Linux 7.2 avec l’étiquette « Assisted-by », contre seulement 31 dans Linux 7.0. Ces étiquettes signalent l’utilisation de l’IA dans les correctifs intégrés sous forme de commits, mais la proportion réelle de contributions assistées par l’IA pourrait être plus élevée.

Selon Linus Torvalds, certaines de ces corrections pourraient provenir de failles de sécurité liées à l’IA.

« Nous recevons beaucoup plus de correctifs […] parfois très importants et pour des problèmes de sécurité bien réels, et parfois pour des choses que personne n’a touchées depuis 20 ans, parce que personne ne s’en soucie », note Linus Torvalds. Il confirme là une tendance observée par les mainteneurs d’autres projets open source.

Bien que le nombre croissant de correctifs améliore le code source du noyau Linux et que l’IA soit utile pour la surveillance des correctifs, ce déluge « met les responsables de la maintenance à rude épreuve », signale-t-il. « C’est en partie pourquoi le recours à l’IA pour la révision est important : pour alléger cette charge de travail. »

L’automatisation par IA, l’isolation des microVM comme solutions potentielles

L’essentiel des discussions lors du Sommet Open Source portait sur la manière de rendre les outils d’IA, tant pour la génération que pour la révision de code, « moins stressants, plus performants et plus utiles pour tous », comme l’a formulé Linus Torvalds.

Lors de sa présentation, Mario Fahlandt de Kubermatic a décrit un script GitHub Action exécuté chaque dimanche et qui déploie 2 500 processus pour analyser les dépôts de projets de la CNCF. Ces processus génèrent des SBOM à partir des étiquettes de version et les stockent dans un compartiment Amazon S3, qui contient actuellement 16 000 nomenclatures.

« Chaque dimanche, la tâche cron s’exécute et je contacte quelqu’un de GitHub pour résoudre les problèmes, et la situation s’améliore chaque dimanche », témoigne-t-il.

Les progrès en matière d’isolation des charges de travail des conteneurs constituent une autre contre-mesure potentielle face à la pression exercée par l’IA sur la sécurité de la chaîne d’approvisionnement. Ils peuvent empêcher les attaquants d’exploiter une vulnérabilité pour atteindre le réseau plus large via l’hôte du conteneur, selon une présentation faite par des porte-parole du fournisseur de sécurité des conteneurs et des réseaux Edera lors de l’Open Source Summit.

Les conteneurs Kata open source constituent une solution au problème d’isolation, mais leur déploiement à grande échelle peut s’avérer coûteux, remarque Kavitha Daula, vice-présidente de l’ingénierie chez Edera. Les microVM partagées peuvent engendrer des vulnérabilités du noyau invité, des dérives entre le kernel hôte et le kernel invité, une seconde surface de débogage, le transfert direct du GPU et d’autres risques, précise-t-elle.

Edera commercialise un mécanisme d’isolation concurrent qui enveloppe les agents d’IA et les charges de travail conteneurisées dans des zones, ou des microVM isolées matériellement, dans Kubernetes.

« Chaque agent – et nous insistons sur le mot “chaque” – possède sa propre microVM et son propre noyau Linux privé », déclare Kavitha Daula, lors d’un entretien séparé. « Ils s’exécutent également sur les clusters Kubernetes que vous possédez déjà ».

[N.D.L.R. Un principe d’isolation que les éditeurs et les fournisseurs de LLM entendent généraliser. Vercel, AWS, Chainguard Docker ou encore Mistral AI sont quelques-uns des acteurs à proposer des solutions d’orchestration de microVM].

Bruce Gain est le fondateur et analyste principal de ReveCom. Ses articles ont été publiés dans Wired, PC World, CIO, Technology Review, Popular Science et EETimes.