{"id":23821,"date":"2026-04-21T10:08:04","date_gmt":"2026-04-21T08:08:04","guid":{"rendered":"https:\/\/www.kaspersky.fr\/blog\/?p=23821"},"modified":"2026-04-21T11:58:26","modified_gmt":"2026-04-21T09:58:26","slug":"open-source-vulnerabilities-in-ai-era","status":"publish","type":"post","link":"https:\/\/www.kaspersky.fr\/blog\/open-source-vulnerabilities-in-ai-era\/23821\/","title":{"rendered":"Les vuln\u00e9rabilit\u00e9s des logiciels open source : un probl\u00e8me qui touche d\u00e9sormais toutes les entreprises"},"content":{"rendered":"

Autrefois, seules les soci\u00e9t\u00e9s de logiciels sp\u00e9cialis\u00e9es et les g\u00e9ants de la technologie avaient des raisons de s\u2019inqui\u00e9ter des failles de s\u00e9curit\u00e9 des logiciels open source et des attaques contre la cha\u00eene d\u2019approvisionnement. Mais les choses ont chang\u00e9. Aujourd\u2019hui, m\u00eame les petites entreprises disposent de leurs propres \u00e9quipes de d\u00e9veloppement, si bien que ce probl\u00e8me concerne tout le monde. Dans une entreprise sur deux,<\/a> les \u00e9quipes informatiques internes s\u2019affairent \u00e0 \u00e9crire du code, \u00e0 configurer des int\u00e9grations et \u00e0 automatiser des flux de travail, m\u00eame si leur activit\u00e9 principale n\u2019a absolument rien \u00e0 voir avec les logiciels. C\u2019est ce qu\u2019exige l\u2019efficacit\u00e9 des entreprises modernes. Cependant, il en r\u00e9sulte une nouvelle cat\u00e9gorie de vuln\u00e9rabilit\u00e9s logicielles \u2013 celles qui sont bien plus difficiles \u00e0 corriger qu\u2019une simple installation de la derni\u00e8re mise \u00e0 jour de Windows.<\/p>\n

Le d\u00e9veloppement logiciel moderne est ins\u00e9parable des composants open source. Cependant, les risques associ\u00e9s se sont multipli\u00e9s ces derni\u00e8res ann\u00e9es, gagnant \u00e0 la fois en diversit\u00e9 et en complexit\u00e9. Nous constatons l\u2019injection de code malveillant dans des d\u00e9p\u00f4ts populaires, des donn\u00e9es de vuln\u00e9rabilit\u00e9 fragment\u00e9es et erron\u00e9es, l\u2019utilisation syst\u00e9matique de composants obsol\u00e8tes et vuln\u00e9rables, ainsi que des cha\u00eenes de d\u00e9pendances de plus en plus complexes.<\/p>\n

La p\u00e9nurie de donn\u00e9es sur les vuln\u00e9rabilit\u00e9s des logiciels open source<\/h2>\n

M\u00eame si votre organisation dispose d\u2019un processus de gestion des vuln\u00e9rabilit\u00e9s<\/a> extr\u00eamement solide pour les logiciels commerciaux tiers, vous constaterez que le code open source n\u00e9cessite une refonte compl\u00e8te de ce processus. Les bases de donn\u00e9es publiques les plus couramment utilis\u00e9es sont souvent incompl\u00e8tes, inexactes ou trop lentes \u00e0 mettre \u00e0 jour lorsqu\u2019il s\u2019agit de logiciels libres. R\u00e9sultat\u00a0: la hi\u00e9rarchisation des vuln\u00e9rabilit\u00e9s se transforme en un v\u00e9ritable jeu de devinettes. Aucun niveau d\u2019automatisation ne pourra vous aider si vos donn\u00e9es de r\u00e9f\u00e9rence sont incompl\u00e8tes.<\/p>\n

D\u2019apr\u00e8s les donn\u00e9es de Sonatype, environ 65\u00a0% des vuln\u00e9rabilit\u00e9s des logiciels open source<\/a> auxquelles un ID CVE est attribu\u00e9 ne poss\u00e8dent pas d\u2019indice de gravit\u00e9<\/a> (CVSS) dans le NVD, la base de connaissances sur les vuln\u00e9rabilit\u00e9s la plus utilis\u00e9e. Parmi ces vuln\u00e9rabilit\u00e9s non not\u00e9es, pr\u00e8s de 46 % seraient en r\u00e9alit\u00e9 class\u00e9es comme \u00ab\u00a0\u00e9lev\u00e9es\u00a0\u00bb si elles \u00e9taient correctement analys\u00e9es.<\/p>\n

M\u00eame lorsqu\u2019un score CVSS est disponible, les diff\u00e9rentes sources ne s\u2019accordent sur le niveau de gravit\u00e9 que dans environ 55 % des cas. Une base de donn\u00e9es peut classer une vuln\u00e9rabilit\u00e9 comme \u00ab\u00a0critique\u00a0\u00bb, tandis qu\u2019une autre lui attribuera un niveau \u00ab\u00a0moyen\u00a0\u00bb. Les m\u00e9tadonn\u00e9es plus d\u00e9taill\u00e9es, telles que les versions des paquets concern\u00e9s, sont souvent elles aussi truff\u00e9es d\u2019erreurs et d\u2019incoh\u00e9rences. Vos outils de d\u00e9tection des vuln\u00e9rabilit\u00e9s qui comparent les versions logicielles finissent par donner de fausses alertes ou par vous garantir \u00e0 tort que tout va bien.<\/p>\n

Le manque de donn\u00e9es sur l\u2019exposition aux risques s\u2019accentue, et le processus de communication de ces informations ralentit. Au cours des cinq derni\u00e8res ann\u00e9es, le nombre total de CVE a doubl\u00e9, mais le nombre de CVE ne disposant pas de note de gravit\u00e9 a \u00e9t\u00e9 multipli\u00e9 par 37. Selon la soci\u00e9t\u00e9 Tenable, en 2025, le code d\u2019exploitation public de type \u00ab\u00a0preuve de concept\u00a0\u00bb (PoC) \u00e9tait g\u00e9n\u00e9ralement disponible dans la semaine<\/a> suivant la d\u00e9couverte d\u2019une vuln\u00e9rabilit\u00e9, mais il fallait en moyenne 15\u00a0jours pour que cette m\u00eame vuln\u00e9rabilit\u00e9 soit r\u00e9pertori\u00e9e dans le NVD. Les processus d\u2019enrichissement, tels que l\u2019attribution d\u2019un score CVSS, sont encore plus lents\u00a0: dans cette m\u00eame \u00e9tude<\/a>, Sonatype estime que le d\u00e9lai m\u00e9dian pour attribuer un score CVSS est de 41\u00a0jours, certaines vuln\u00e9rabilit\u00e9s restant sans score pendant pr\u00e8s d\u2019un an.<\/p>\n

Le probl\u00e8me des anciens codes open source<\/h2>\n

Selon HeroDevs, on trouve des biblioth\u00e8ques, des applications et des services qui ne sont plus maintenus (soit parce qu\u2019ils ont \u00e9t\u00e9 abandonn\u00e9s, soit parce qu\u2019ils ont depuis longtemps atteint leur fin de vie officielle (EOL)) dans 5 \u00e0 15\u00a0% des projets d\u2019entreprise<\/a>. Sur cinq registres de codes open source tr\u00e8s utilis\u00e9s, on recense au moins 81 000 paquets qui contiennent des vuln\u00e9rabilit\u00e9s connues, mais qui appartiennent \u00e0 des versions obsol\u00e8tes et non prises en charge. Ces paquets ne b\u00e9n\u00e9ficieront jamais de correctifs officiels. Ce \u00ab\u00a0bagage h\u00e9rit\u00e9\u00a0\u00bb repr\u00e9sente environ 10 % des paquets sur Maven Central et PyPI, et pas moins de 25 % dans l\u2019\u00e9cosyst\u00e8me npm.<\/p>\n

L\u2019utilisation de ce type de code open source brise le cycle de vie standard de la gestion des correctifs : il est impossible de mettre \u00e0 jour, que ce soit automatiquement ou manuellement, une d\u00e9pendance qui n\u2019est plus prise en charge. De plus, lorsque les versions en fin de vie ne sont pas mentionn\u00e9es dans les bulletins officiels sur les vuln\u00e9rabilit\u00e9s, les outils d\u2019analyse de s\u00e9curit\u00e9 peuvent les classer comme \u00ab\u00a0non concern\u00e9es\u00a0\u00bb par une vuln\u00e9rabilit\u00e9 et les ignorer.<\/p>\n

Un excellent exemple en est Log4Shell<\/a>, la vuln\u00e9rabilit\u00e9 critique (CVSS 10) de la c\u00e9l\u00e8bre biblioth\u00e8que Log4j d\u00e9couverte en 2021. La version vuln\u00e9rable repr\u00e9sentait 40\u00a0millions<\/a> des 300\u00a0millions de t\u00e9l\u00e9chargements de Log4j effectu\u00e9s en 2025. Rappelons-nous qu\u2019il s\u2019agit l\u00e0 de l\u2019une des vuln\u00e9rabilit\u00e9s les plus tristement c\u00e9l\u00e8bres et les plus m\u00e9diatis\u00e9es de l\u2019histoire, qui a \u00e9t\u00e9 activement exploit\u00e9e, corrig\u00e9e par le d\u00e9veloppeur et trait\u00e9e dans tous les principaux produits d\u00e9riv\u00e9s. La situation est bien pire pour les failles moins m\u00e9diatis\u00e9es.<\/p>\n

\u00c0 cela s\u2019ajoute le probl\u00e8me du manque de visibilit\u00e9. De nombreuses organisations ne disposent pas des outils n\u00e9cessaires pour \u00e9tablir un arbre de d\u00e9pendances complet ou pour disposer d\u2019une visibilit\u00e9 totale sur les paquets et versions sp\u00e9cifiques int\u00e9gr\u00e9s \u00e0 leur pile logicielle. De ce fait, ces composants obsol\u00e8tes restent souvent invisibles et ne sont m\u00eame jamais inclus dans la liste des \u00e9l\u00e9ments \u00e0 corriger.<\/p>\n

Programmes malveillants dans les registres open source<\/h2>\n

Les attaques impliquant des paquets open source infect\u00e9s ou intrins\u00e8quement malveillants sont devenues l\u2019une des menaces qui connaissent la croissance la plus rapide pour les cha\u00eenes d\u2019approvisionnement. Selon les chercheurs de Kaspersky<\/a>, environ 14\u00a0000\u00a0paquets malveillants ont \u00e9t\u00e9 d\u00e9tect\u00e9s dans des registres populaires \u00e0 la fin de l\u2019ann\u00e9e\u00a02024, soit une augmentation de 48\u00a0% par rapport \u00e0 l\u2019ann\u00e9e pr\u00e9c\u00e9dente. Sonatype a signal\u00e9 une hausse encore plus spectaculaire tout au long de l\u2019ann\u00e9e\u00a02025, avec plus de 450\u00a0000\u00a0paquets malveillants d\u00e9tect\u00e9s.<\/p>\n

Les motivations derri\u00e8re ces attaques sont tr\u00e8s vari\u00e9es\u00a0: vol de cryptomonnaies, collecte d\u2019identifiants de d\u00e9veloppeurs, espionnage industriel, obtention d\u2019un acc\u00e8s aux infrastructures via des pipelines CI\/CD, ou compromission de serveurs publics pour h\u00e9berger des campagnes de spam et de phishing. Ces tactiques sont utilis\u00e9es tant par les groupes d\u2019espionnage APT<\/a> que par les cybercriminels motiv\u00e9s par l\u2019argent<\/a>. De plus en plus souvent, la compromission d\u2019un logiciel open source n\u2019est que la premi\u00e8re \u00e9tape d\u2019une violation en plusieurs phases visant une entreprise.<\/p>\n

Parmi les sc\u00e9narios d\u2019attaque courants, on peut citer le piratage des identifiants d\u2019un responsable officiel de paquets open source, la publication d\u2019une biblioth\u00e8que \u00ab\u00a0utile\u00a0\u00bb contenant du code malveillant, ou encore la publication d\u2019une biblioth\u00e8que malveillante dont le nom est presque identique \u00e0 celui d\u2019une biblioth\u00e8que populaire. Une tendance particuli\u00e8rement inqui\u00e9tante observ\u00e9e en 2025 a \u00e9t\u00e9 la prolif\u00e9ration des attaques automatis\u00e9es de type \u00ab\u00a0ver\u00a0\u00bb. L\u2019exemple le plus c\u00e9l\u00e8bre est la campagne de Shai-Hulud<\/a>. Dans ce cas pr\u00e9cis, un code malveillant a d\u00e9rob\u00e9 des jetons GitHub et npm et a continu\u00e9 \u00e0 infecter de nouveaux paquets, finissant par se propager \u00e0 plus de 700\u00a0paquets npm et \u00e0 des dizaines de milliers de d\u00e9p\u00f4ts. Il a ainsi divulgu\u00e9 au grand public des secrets CI\/CD et des cl\u00e9s d\u2019acc\u00e8s au cloud.<\/p>\n

M\u00eame si ce sc\u00e9nario n\u2019est techniquement pas li\u00e9 aux vuln\u00e9rabilit\u00e9s, les outils et les strat\u00e9gies de s\u00e9curit\u00e9 n\u00e9cessaires pour le g\u00e9rer sont les m\u00eames que ceux utilis\u00e9s pour la gestion des vuln\u00e9rabilit\u00e9s.<\/p>\n

Comment les agents d\u2019IA augmentent les risques li\u00e9s \u00e0 l\u2019utilisation de code open source<\/h2>\n

L\u2019int\u00e9gration pr\u00e9cipit\u00e9e et g\u00e9n\u00e9ralis\u00e9e d\u2019agents d\u2019IA dans le d\u00e9veloppement logiciel acc\u00e9l\u00e8re consid\u00e9rablement le rythme de travail des d\u00e9veloppeurs, mais elle amplifie \u00e9galement toute erreur. Sans une surveillance rigoureuse et des garde-fous clairement d\u00e9finis, le code g\u00e9n\u00e9r\u00e9 par l\u2019IA est extr\u00eamement vuln\u00e9rable. Des \u00e9tudes montrent que 45\u00a0% du code g\u00e9n\u00e9r\u00e9 par l\u2019IA contient des failles figurant dans le classement OWASP Top 10<\/a>, tandis que 20\u00a0% des applications bas\u00e9es sur l\u2019IA d\u00e9j\u00e0 en phase de d\u00e9ploiement comportent des probl\u00e8mes de configuration dangereux. Cela s\u2019explique par le fait que les mod\u00e8les d\u2019IA sont entra\u00een\u00e9s \u00e0 partir d\u2019ensembles de donn\u00e9es colossaux qui contiennent de grandes quantit\u00e9s de code obsol\u00e8te, de code de d\u00e9monstration ou de code purement p\u00e9dagogique. Ces probl\u00e8mes syst\u00e9miques refont surface lorsqu\u2019un mod\u00e8le d\u2019IA doit d\u00e9cider quels composants open source int\u00e9grer \u00e0 un projet. Le mod\u00e8le ignore souvent quelles versions des paquets sont actuellement disponibles, ou lesquelles ont \u00e9t\u00e9 signal\u00e9es comme vuln\u00e9rables. Au lieu de cela, il propose une version de la d\u00e9pendance extraite de ses donn\u00e9es d\u2019apprentissage, qui est tr\u00e8s certainement obsol\u00e8te. Dans certains cas, les mod\u00e8les tentent d\u2019appeler des versions inexistantes ou des biblioth\u00e8ques purement imaginaires. C\u2019est une porte ouverte aux attaques par confusion de d\u00e9pendances<\/a>.<\/p>\n

En 2025, m\u00eame les meilleurs mod\u00e8les de langage (LLM) ont recommand\u00e9 des versions de d\u00e9pendances erron\u00e9es (en inventant tout simplement une r\u00e9ponse) dans 27\u00a0% des cas<\/a>.<\/p>\n

L\u2019IA peut-elle tout r\u00e9parer\u00a0?<\/h2>\n

L\u2019id\u00e9e est simple et s\u00e9duisante\u00a0: il suffit de confier votre base de code \u00e0 un agent d\u2019IA pour qu\u2019il d\u00e9tecte et corrige toutes les vuln\u00e9rabilit\u00e9s. Malheureusement, l\u2019IA ne peut pas r\u00e9soudre enti\u00e8rement ce probl\u00e8me. Les obstacles fondamentaux dont nous avons parl\u00e9 constituent un frein aussi bien pour les agents d\u2019IA que pour les d\u00e9veloppeurs humains. Si les donn\u00e9es relatives aux vuln\u00e9rabilit\u00e9s sont manquantes ou peu fiables, au lieu de rep\u00e9rer les vuln\u00e9rabilit\u00e9s connues, vous \u00eates oblig\u00e9 de les red\u00e9couvrir \u00e0 partir de z\u00e9ro. Cette d\u00e9marche est extr\u00eamement gourmande en ressources et n\u00e9cessite une expertise pointue qui reste hors de port\u00e9e de la plupart des entreprises.<\/p>\n

De plus, si une faille de s\u00e9curit\u00e9 est d\u00e9tect\u00e9e dans un composant obsol\u00e8te ou dont le support n\u2019est plus pris en charge, un agent d\u2019IA ne peut pas la \u00ab\u00a0corriger automatiquement\u00a0\u00bb. Il vous faut toujours d\u00e9velopper des correctifs personnalis\u00e9s ou effectuer une migration complexe. Si une faille est dissimul\u00e9e au plus profond d\u2019une cha\u00eene de d\u00e9pendances, l\u2019IA risque fort de ne pas la d\u00e9tecter du tout.<\/p>\n

Que faire\u00a0?<\/h2>\n

Pour r\u00e9duire au minimum les risques d\u00e9crits ci-dessus, il sera n\u00e9cessaire d\u2019\u00e9tendre le processus de gestion des vuln\u00e9rabilit\u00e9s afin d\u2019y inclure les strat\u00e9gies de t\u00e9l\u00e9chargement des paquets open source, les r\u00e8gles de fonctionnement des assistants d\u2019IA et le processus de compilation des logiciels. Ce qui inclut\u00a0:<\/p>\n