Les vulnérabilités des logiciels open source : un problème qui touche désormais toutes les entreprises

Autrefois, seules les sociétés de logiciels spécialisées et les géants de la technologie avaient des raisons de s’inquiéter des failles de sécurité des logiciels open source et des attaques contre la chaîne d’approvisionnement. Mais les choses ont changé. Aujourd’hui, même les petites entreprises disposent de leurs propres équipes de développement, si bien que ce problème concerne tout le monde. Dans une entreprise sur deux, les équipes informatiques internes s’affairent à écrire du code, à configurer des intégrations et à automatiser des flux de travail, même si leur activité principale n’a absolument rien à voir avec les logiciels. C’est ce qu’exige l’efficacité des entreprises modernes. Cependant, il en résulte une nouvelle catégorie de vulnérabilités logicielles – celles qui sont bien plus difficiles à corriger qu’une simple installation de la dernière mise à jour de Windows.

Le développement logiciel moderne est inséparable des composants open source. Cependant, les risques associés se sont multipliés ces dernières années, gagnant à la fois en diversité et en complexité. Nous constatons l’injection de code malveillant dans des dépôts populaires, des données de vulnérabilité fragmentées et erronées, l’utilisation systématique de composants obsolètes et vulnérables, ainsi que des chaînes de dépendances de plus en plus complexes.

La pénurie de données sur les vulnérabilités des logiciels open source

Même si votre organisation dispose d’un processus de gestion des vulnérabilités extrêmement solide pour les logiciels commerciaux tiers, vous constaterez que le code open source nécessite une refonte complète de ce processus. Les bases de données publiques les plus couramment utilisées sont souvent incomplètes, inexactes ou trop lentes à mettre à jour lorsqu’il s’agit de logiciels libres. Résultat : la hiérarchisation des vulnérabilités se transforme en un véritable jeu de devinettes. Aucun niveau d’automatisation ne pourra vous aider si vos données de référence sont incomplètes.

D’après les données de Sonatype, environ 65 % des vulnérabilités des logiciels open source auxquelles un ID CVE est attribué ne possèdent pas d’indice de gravité (CVSS) dans le NVD, la base de connaissances sur les vulnérabilités la plus utilisée. Parmi ces vulnérabilités non notées, près de 46 % seraient en réalité classées comme « élevées » si elles étaient correctement analysées.

Même lorsqu’un score CVSS est disponible, les différentes sources ne s’accordent sur le niveau de gravité que dans environ 55 % des cas. Une base de données peut classer une vulnérabilité comme « critique », tandis qu’une autre lui attribuera un niveau « moyen ». Les métadonnées plus détaillées, telles que les versions des paquets concernés, sont souvent elles aussi truffées d’erreurs et d’incohérences. Vos outils de détection des vulnérabilités qui comparent les versions logicielles finissent par donner de fausses alertes ou par vous garantir à tort que tout va bien.

Le manque de données sur l’exposition aux risques s’accentue, et le processus de communication de ces informations ralentit. Au cours des cinq dernières années, le nombre total de CVE a doublé, mais le nombre de CVE ne disposant pas de note de gravité a été multiplié par 37. Selon la société Tenable, en 2025, le code d’exploitation public de type « preuve de concept » (PoC) était généralement disponible dans la semaine suivant la découverte d’une vulnérabilité, mais il fallait en moyenne 15 jours pour que cette même vulnérabilité soit répertoriée dans le NVD. Les processus d’enrichissement, tels que l’attribution d’un score CVSS, sont encore plus lents : dans cette même étude, Sonatype estime que le délai médian pour attribuer un score CVSS est de 41 jours, certaines vulnérabilités restant sans score pendant près d’un an.

Le problème des anciens codes open source

Selon HeroDevs, on trouve des bibliothèques, des applications et des services qui ne sont plus maintenus (soit parce qu’ils ont été abandonnés, soit parce qu’ils ont depuis longtemps atteint leur fin de vie officielle (EOL)) dans 5 à 15 % des projets d’entreprise. Sur cinq registres de codes open source très utilisés, on recense au moins 81 000 paquets qui contiennent des vulnérabilités connues, mais qui appartiennent à des versions obsolètes et non prises en charge. Ces paquets ne bénéficieront jamais de correctifs officiels. Ce « bagage hérité » représente environ 10 % des paquets sur Maven Central et PyPI, et pas moins de 25 % dans l’écosystème npm.

L’utilisation de ce type de code open source brise le cycle de vie standard de la gestion des correctifs : il est impossible de mettre à jour, que ce soit automatiquement ou manuellement, une dépendance qui n’est plus prise en charge. De plus, lorsque les versions en fin de vie ne sont pas mentionnées dans les bulletins officiels sur les vulnérabilités, les outils d’analyse de sécurité peuvent les classer comme « non concernées » par une vulnérabilité et les ignorer.

Un excellent exemple en est Log4Shell, la vulnérabilité critique (CVSS 10) de la célèbre bibliothèque Log4j découverte en 2021. La version vulnérable représentait 40 millions des 300 millions de téléchargements de Log4j effectués en 2025. Rappelons-nous qu’il s’agit là de l’une des vulnérabilités les plus tristement célèbres et les plus médiatisées de l’histoire, qui a été activement exploitée, corrigée par le développeur et traitée dans tous les principaux produits dérivés. La situation est bien pire pour les failles moins médiatisées.

À cela s’ajoute le problème du manque de visibilité. De nombreuses organisations ne disposent pas des outils nécessaires pour établir un arbre de dépendances complet ou pour disposer d’une visibilité totale sur les paquets et versions spécifiques intégrés à leur pile logicielle. De ce fait, ces composants obsolètes restent souvent invisibles et ne sont même jamais inclus dans la liste des éléments à corriger.

Programmes malveillants dans les registres open source

Les attaques impliquant des paquets open source infectés ou intrinsèquement malveillants sont devenues l’une des menaces qui connaissent la croissance la plus rapide pour les chaînes d’approvisionnement. Selon les chercheurs de Kaspersky, environ 14 000 paquets malveillants ont été détectés dans des registres populaires à la fin de l’année 2024, soit une augmentation de 48 % par rapport à l’année précédente. Sonatype a signalé une hausse encore plus spectaculaire tout au long de l’année 2025, avec plus de 450 000 paquets malveillants détectés.

Les motivations derrière ces attaques sont très variées : vol de cryptomonnaies, collecte d’identifiants de développeurs, espionnage industriel, obtention d’un accès aux infrastructures via des pipelines CI/CD, ou compromission de serveurs publics pour héberger des campagnes de spam et de phishing. Ces tactiques sont utilisées tant par les groupes d’espionnage APT que par les cybercriminels motivés par l’argent. De plus en plus souvent, la compromission d’un logiciel open source n’est que la première étape d’une violation en plusieurs phases visant une entreprise.

Parmi les scénarios d’attaque courants, on peut citer le piratage des identifiants d’un responsable officiel de paquets open source, la publication d’une bibliothèque « utile » contenant du code malveillant, ou encore la publication d’une bibliothèque malveillante dont le nom est presque identique à celui d’une bibliothèque populaire. Une tendance particulièrement inquiétante observée en 2025 a été la prolifération des attaques automatisées de type « ver ». L’exemple le plus célèbre est la campagne de Shai-Hulud. Dans ce cas précis, un code malveillant a dérobé des jetons GitHub et npm et a continué à infecter de nouveaux paquets, finissant par se propager à plus de 700 paquets npm et à des dizaines de milliers de dépôts. Il a ainsi divulgué au grand public des secrets CI/CD et des clés d’accès au cloud.

Même si ce scénario n’est techniquement pas lié aux vulnérabilités, les outils et les stratégies de sécurité nécessaires pour le gérer sont les mêmes que ceux utilisés pour la gestion des vulnérabilités.

Comment les agents d’IA augmentent les risques liés à l’utilisation de code open source

L’intégration précipitée et généralisée d’agents d’IA dans le développement logiciel accélère considérablement le rythme de travail des développeurs, mais elle amplifie également toute erreur. Sans une surveillance rigoureuse et des garde-fous clairement définis, le code généré par l’IA est extrêmement vulnérable. Des études montrent que 45 % du code généré par l’IA contient des failles figurant dans le classement OWASP Top 10, tandis que 20 % des applications basées sur l’IA déjà en phase de déploiement comportent des problèmes de configuration dangereux. Cela s’explique par le fait que les modèles d’IA sont entraînés à partir d’ensembles de données colossaux qui contiennent de grandes quantités de code obsolète, de code de démonstration ou de code purement pédagogique. Ces problèmes systémiques refont surface lorsqu’un modèle d’IA doit décider quels composants open source intégrer à un projet. Le modèle ignore souvent quelles versions des paquets sont actuellement disponibles, ou lesquelles ont été signalées comme vulnérables. Au lieu de cela, il propose une version de la dépendance extraite de ses données d’apprentissage, qui est très certainement obsolète. Dans certains cas, les modèles tentent d’appeler des versions inexistantes ou des bibliothèques purement imaginaires. C’est une porte ouverte aux attaques par confusion de dépendances.

En 2025, même les meilleurs modèles de langage (LLM) ont recommandé des versions de dépendances erronées (en inventant tout simplement une réponse) dans 27 % des cas.

L’IA peut-elle tout réparer ?

L’idée est simple et séduisante : il suffit de confier votre base de code à un agent d’IA pour qu’il détecte et corrige toutes les vulnérabilités. Malheureusement, l’IA ne peut pas résoudre entièrement ce problème. Les obstacles fondamentaux dont nous avons parlé constituent un frein aussi bien pour les agents d’IA que pour les développeurs humains. Si les données relatives aux vulnérabilités sont manquantes ou peu fiables, au lieu de repérer les vulnérabilités connues, vous êtes obligé de les redécouvrir à partir de zéro. Cette démarche est extrêmement gourmande en ressources et nécessite une expertise pointue qui reste hors de portée de la plupart des entreprises.

De plus, si une faille de sécurité est détectée dans un composant obsolète ou dont le support n’est plus pris en charge, un agent d’IA ne peut pas la « corriger automatiquement ». Il vous faut toujours développer des correctifs personnalisés ou effectuer une migration complexe. Si une faille est dissimulée au plus profond d’une chaîne de dépendances, l’IA risque fort de ne pas la détecter du tout.

Que faire ?

Pour réduire au minimum les risques décrits ci-dessus, il sera nécessaire d’étendre le processus de gestion des vulnérabilités afin d’y inclure les stratégies de téléchargement des paquets open source, les règles de fonctionnement des assistants d’IA et le processus de compilation des logiciels. Ce qui inclut :

• l’utilisation d’une solution complète de sécurité des charges de travail dans le cloud;
• la vérification des paquets open source utilisés dans votre processus de développement logiciel à l’aide de flux de Threat Intelligence destinés aux composants open source;
• la prise en compte des mesures de sécurité visant à protéger le code et les agents d’IA ;
• la suppression systématique des composants open source obsolètes.

Pour en savoir plus sur la gestion des vulnérabilités dans les logiciels libres, consultez l’article de blog consacré à ce sujet.