Stratégie

Les attaques sur les pipelines de développement de l'IA inquiètent les RSSI

La supply chain en IA est une cible de plus en plus attrayante pour les acteurs de la menace, qui manipulent les données, les modèles d'entraînement et les bibliothèques logicielles. (Photo : Flyd/Unsplash)

Les attaques visant le code utilisé par les développeurs d'applications d'IA soulignent la nécessité d'élaborer des programmes complets fondés sur les risques. Des programmes s'étendant aux dépendances et composants logiciels.

PublicitéLa multiplicité des failles dans les logiciels Open Source et les logiciels commerciaux tiers, ainsi que les campagnes malveillantes ciblant les pipelines de développement de l'IA, exacerbent les problèmes de sécurité de la supply chain logicielle. Selon ReversingLabs (RL), les incidents liés à l'exposition de secrets intégrés à des développements via de composants Open Source librement accessibles ont augmenté de 12 % l'année dernière par rapport à 2023.

Une analyse de 30 logiciels libres parmi les plus populaires laisse apparaître une moyenne de six failles de gravité critique et de 33 failles de gravité élevée... pour chacun d'entre eux. Les progiciels propriétaires sont également une source fréquente de risques, selon d'autres conclusions du rapport de ReversingLabs sur la sécurité de la supply chain logicielle.

Les risques liés à celle-ci sont devenus de plus en plus fréquents et complexes, car les environnements informatiques modernes reposent largement sur des fournisseurs et des composants Open Source. Le problème a pris de l'ampleur après le piratage de SolarWinds en 2020, qui a touché plus de 30 000 organisations, y compris des agences gouvernementales américaines.

De nombreux incidents résultant d'attaques contre la supply chain logicielle - qu'elle que soit la forme qu'elle prenne - se sont produits depuis le piratage historique de SolarWinds Orion, attribué à une unité du Service de renseignement extérieur de Russie.

Sous le microscope

L'analyse par RL de plus de deux douzaines de binaires de logiciels propriétaires largement utilisés - y compris des OS, des gestionnaires de mots de passe, des navigateurs web et des logiciels de réseaux privés virtuels (VPN) - montre la persistance de toute une série de problèmes tels que des secrets exposés, la présence de vulnérabilités logicielles activement exploitées, des preuves d'altération possible du code et un durcissement inadéquat des applications.

Mais, selon RL, ce sont les modules Open Source et les référentiels de code qui représentent toujours la grande majorité des risques liés à la chaîne d'approvisionnement en 2024. L'analyse de packages populaires comme npm, PyPI et RubyGems montre que de nombreux modules Open Source largement utilisés contiennent des composants anciens et obsolètes - un phénomène connu sous le nom de « code rot » (pourriture de code). Par exemple, de npm, module comptant près de 3 000 téléchargements hebdomadaires et 16 applications dépendantes, a permis d'identifier 164 vulnérabilités de code distinctes, dont 43 de gravité « critique » et 81 de gravité « élevée ». La même analyse identifie sept vulnérabilités logicielles connues pour avoir été activement exploitées par des acteurs de la menace.

PublicitéL'IA : nouvelle frontière pour les attaques par la supply chain

L'étude révèle également que les campagnes ciblant la supply chain logicielle visent désormais l'infrastructure de développement et le code utilisé par les développeurs d'applications de Machine Learning et d'IA. Par exemple, les chercheurs de RL ont découvert une technique malveillante baptisée « nullifAI », au sein de laquelle un code malveillant est placé dans les fichiers de sérialisation Pickle de Python. Cette technique a échappé aux protections intégrées dans la plateforme Open Source Hugging Face - un ensemble de ressources populaire pour les développeurs d'IA et de ML.

« Les chaînes d'approvisionnement en IA sont une cible de plus en plus importante, les attaquants manipulant les données, les modèles d'entraînement et les bibliothèques logicielles », souligne Michael Adjei, directeur de l'ingénierie des systèmes chez l'éditeur de solutions de micro-segmentation Illumio. « De nombreuses organisations s'appuient sur des services tiers pour les modèles pré-entraînés et les outils basés sur le cloud, mais des ressources non sécurisées peuvent introduire des portes dérobées et des vulnérabilités. » Selon lui, « pour protéger la supply chain de l'IA, les couches cachées secrètes des modèles devraient être exposées à des tests de pénétration et à des entraînements contradictoires (adversarial training, consistant à réentraîner un modèle sur des examples permettant d'en dégrader la fiabilité, NDLR). »

Peter Garraghan, PDG de Mindgard, fournisseur de tests de sécurité pour l'IA et professeur à l'université britannique de Lancaster, reconnaît que les menaces pesant sur la supply chain constituent une préoccupation émergente pour les développeurs d'IA. « Les composants d'IA - par exemple, LLM, RAG - sont intégrés dans la chaîne d'approvisionnement en logiciels, ce qui en fait une nouvelle frontière pour les attaques sophistiquées », dit-il. « Comme le souligne l'OWASP (voir LLM 03:2025), les LLM s'intègrent fréquemment à des API externes et à des sources de données, ce qui introduit des risques importants en raison de ces dépendances. »

Et encourager les pratiques de codage sécurisé ne suffit pas « Les RSSI doivent adopter une posture de sécurité proactive qui inclut des tests continus des applications d'IA, une transparence sur la structure des logiciels et la détection automatisée des menaces tout au long du cycle de vie du développement de l'IA », conseille Peter Garraghan.

Code généré par l'IA : un faux sentiment de sécurité

Les chaînes d'approvisionnement en logiciels s'appuient fortement sur des codes Open Source, émanant de tiers et/ou générés par l'IA, ce qui introduit des risques échappant au contrôle des équipes de développement. De meilleurs contrôles sur les logiciels que l'industrie construit et déploie sont nécessaires, selon ReversingLabs.

« Les outils AppSec traditionnels passent à côté de menaces telles que l'injection de malwares, la modification malveillante de dépendances et les failles cryptographiques », indique Saša Zdjelar, Chief trust officer de ReversingLabs. « La véritable sécurité exige une analyse approfondie des logiciels, une évaluation automatisée des risques et une vérification continue tout au long du cycle de développement. »

Les développeurs et les équipes chargées de la sécurité des applications doivent avoir accès à des outils leur permettant de s'assurer que leurs composants fondamentaux sont exempts de vulnérabilités connues ou, pire encore, de malwares cachés ou de manipulations diverses.

L'introduction de codes générés par l'IA ne résout pas ce problème. On a observé que les logiciels générés par l'IA reprenaient des codes présentant des vulnérabilités connues, remettaient au goût du jour des algorithmes de chiffrement obsolètes ou contenaient des composants Open Source périmés.

ReversingLabs affirme qu'il est nécessaire de mettre en place une nouvelle génération de solutions pour la supply chain logicielle, conçues pour identifier les malwares et les manipulations, ainsi que les changements de comportement d'une application entre deux versions successives.

Extension de la nomenclature logicielle

ReversingLabs et des experts indépendants estiment encore qu'il est temps d'adopter et d'étendre le concept de nomenclature des logiciels (SBOM, pour software bill of materials). Un SBOM fournit un inventaire complet des dépendances logicielles - des données qui aident les organisations à atténuer les risques de sécurité et à répondre rapidement aux vulnérabilités dans les bibliothèques et autres composants.

« Actuellement, le SBOM est simplement une liste d'ingrédients et, peut-être, de vulnérabilités existantes, dit Saša Zdjelar de ReversingLabs. Les récents ajouts visant à prendre en compte une nomenclature étendue - aux composants de Machine Learning, cryptographiques et SaaS - constituent un grand pas dans la bonne direction. »

Darren Meyer, du fournisseur de tests de sécurité des applications d'entreprise Checkmarx, souligne que les entreprises devaient développer des programmes complets basés sur les risques afin de maîtriser les menaces pesant sur leur supply chain logicielle. « Pour rester au fait des codes tiers vulnérables et malveillants, il faut disposer d'une chaîne d'outils complète, notamment de fonctions d'analyse de la composition des logiciels (SCA) pour identifier les vulnérabilités connues dans les composants logiciels tiers, d'une analyse des conteneurs pour identifier les vulnérabilités dans les paquets issus de tiers au sein des conteneurs, et de renseignements sur la menace centrés sur les paquets malveillants afin de repérer les composants compromis », énumère Darren Meyer.

David Spillane, directeur de l'ingénierie des systèmes chez le fournisseur de cybersécurité Fortinet, fait valoir que les RSSI ont un rôle clé à jouer dans l'atténuation des risques potentiels liés à la sécurité de la supply chain : « outre les pratiques de développement sécurisé, les RSSI et les équipes informatiques au sens large peuvent prendre plusieurs mesures pour atténuer les attaques contre la supply chain logicielle des entreprises, à commencer par l'audit de l'infrastructure existante, afin d'identifier les vulnérabilités dont les cybercriminels pourraient tirer parti. Il est essentiel de disposer d'un inventaire actualisé des actifs logiciels pour réduire les vecteurs d'attaque potentiels en classant les solutions en fonction de leur degré de sécurité. »