L'open source fait tourner l'internet. Les données sur les vulnérabilités sont éclatées entre 40 bases

OSV, la base Open Source Vulnerabilities pilotée depuis Google, ne rédige pas les avis. Elle les agrège. Sa page d'accueil affiche des compteurs par écosystème, un recensement de tout ce sur quoi repose le logiciel moderne : npm à 228 732 avis, Chainguard à 1 023 658, Wolfi à 288 261, MinimOS à 144 169, GIT à 108 035, Debian à 68 356, Ubuntu à 65 370. Ces chiffres comptent les avis par écosystème, pas les bugs uniques. La même faille peut apparaître dans plusieurs d'entre eux.

Ce chevauchement est justement le sujet. Le site se décrit comme « une approche ouverte, précise et distribuée de production et de consommation d'informations sur les vulnérabilités de l'open source », bâtie sur le schéma OpenSSF OSV. Ce schéma existe pour qu'une vulnérabilité puisse être rattachée « précisément à des versions de paquets open source ou à des hachages de commit » plutôt qu'à des noms de produits vagues. La fiche de la CISA sur OSV est directe sur le coût en outillage : elle « exige un compte Google Cloud Platform et un compte Google Group ».

De vrais incidents montrent pourquoi la précision au niveau des versions compte.

Log4Shell, CVE-2021-44228, a obtenu 10,0 au score CVSS. Selon une analyse de Safeguard sur les risques de l'open source, il a été « activement exploité par des groupes de rançongiciels et des acteurs soutenus par des États pendant plus d'un an après l'existence d'un correctif ». La porte dérobée XZ Utils, CVE-2024-3094, a elle aussi été notée 10,0. Elle a été découverte par hasard le 29 mars 2024, après qu'un contributeur utilisant le nom « Jia Tan » a passé plus de deux ans à construire un historique de commits et de la confiance. Elle avait déjà atteint Debian testing et les préversions Fedora 40/41. Heartbleed, CVE-2014-0160, a exposé les clés privées d'environ 500 000 serveurs en avril 2014. La fuite d'Equifax en 2017 remonte à une faille Apache Struts non corrigée, CVE-2017-5638, et a coûté 1,4 milliard de dollars en règlements et en remédiation.

Le correctif n'est pas le goulot d'étranglement

Le texte de Safeguard établit une distinction qui se perd dans les tableaux de bord de sévérité : le problème vient rarement de l'absence de correctif. Il vient de ce que les organisations ne savent pas quels services en production appellent réellement la fonction vulnérable. La correction passe alors au second plan, face à une file d'attente où tout semble également urgent. Le catalogue Known Exploited Vulnerabilities de la CISA ne retient que les CVE dont l'exploitation active est confirmée. Il a dépassé 1 300 entrées en 2025, et une large part concerne des composants open source largement intégrés comme Apache, OpenSSL et Spring.

La profondeur des dépendances aggrave la situation. Le rapport State of Open Source Security 2020 de Synk, cité par Safeguard, relevait qu'un projet JavaScript moyen tire 683 dépendances, dont 79 % transitives. Le rapport Open Source Security and Risk Analysis 2024 de Synopsys estimait l'open source à 70 % à 90 % du code des applications modernes. Le guide de SentinelOne présente le même problème comme une question de gouvernance. Pour être efficaces, les programmes ont besoin d'une cartographie des dépendances, d'une application automatisée des politiques qui signale ou bloque les builds, et d'un score de risque pour décider quoi corriger en premier quand le personnel et le temps manquent.

Il y a ensuite la couche humaine. En mars 2016, le développeur Azer Koçulu a dépublié left-pad, un paquet npm de 11 lignes, pendant un conflit de nommage. Des builds se sont cassés dans tout l'écosystème JavaScript en quelques heures, jusqu'à ce que npm le rétablisse. Log4j, bien qu'intégré dans une estimation de plusieurs centaines de milliers d'applications, était maintenu en grande partie par une petite équipe de bénévoles. Le mainteneur principal Volkan Yazıcı a déclaré publiquement que l'équipe avait géré la réponse à Log4Shell sans être payée. Il n'existe pas de SLA sur le travail bénévole.

Les licences comportent leur propre exposition. Le Software Freedom Conservancy a poursuivi Vizio en 2021 au sujet du code source GPL de ses téléviseurs connectés. En février 2024, une cour d'appel de Californie a jugé que les termes de la GPL sont opposables en tant que droits contractuels de tiers bénéficiaires.

Corriger le code est un travail. Le trouver en est un autre

L'outillage autour de la couche de bases de données se consolide. OSV-Scanner, installé via Go, analyse les SBOM, les fichiers de verrouillage, les répertoires de projet et les images de conteneurs. Il fournit des workflows GitHub réutilisables pour que les pipelines CI/CD vérifient les dépendances ajoutées dans les pull requests et lancent des analyses régulières sur un projet. L'API répond aux requêtes par hachage de commit ou par version de paquet, avec des exemples d'appels pour un SHA de commit ou pour jinja2 2.4.1 sur PyPI. OSV-Scanner propose aussi un mode de correction avec des stratégies in-place et relock pour package-lock.json.

Tous les projets ne visent pas la même mesure. typed-lm, un projet Rust publié sur GitHub, suit une autre voie : il transforme des modèles décodeurs denses, dont Llama, Qwen2, Qwen3, Mistral, Gemma, Gemma2 et Gemma3, en une API de routage sémantique typée, qui renvoie des booléens, des choix et des scores au lieu de texte généré. Son README affirme qu'une seule passe avant signifie des millisecondes plutôt que des secondes, et publie des tableaux de latence pour une seule RTX 3070 avec des poids F16. Sur CPU, il rapporte un prefill de 1 024 tokens passant de 28,23 secondes à 13,13 secondes avec le flash CPU et MKL activés, et recommande un checkpoint GGUF Q4_K_M avec la fonctionnalité mkl. Ce sont des chiffres publiés par le projet, non vérifiés indépendamment.

L'économie qui sous-tend tout cela reste instable. Écrivant en août 2026, le développeur Debamitro raconte avoir interviewé Christian Hammond, fondateur et PDG de ReviewBoard, et en avoir tiré un constat contre-intuitif : les entreprises paient pour ReviewBoard « non pas parce que c'est de l'open source, mais bien que ce soit de l'open source ». Les clients paient pour le support, et certains paient pour la version hébergée. Hammond lui a aussi dit que l'usage de ReviewBoard recule dans certaines entreprises qui suppriment les revues de code, et il a soutenu que les langages de programmation, et les logiciels fondamentaux en général, devraient être open source.

Cela laisse le problème des vulnérabilités là où il a commencé : réparti sur plus de quarante bases d'écosystèmes, la plupart maintenues par les mêmes personnes non payées ou faiblement financées qui livrent le code au départ. L'agrégation aide. Elle ne comble pas l'écart entre un avis publié et une organisation qui sait si la fonction concernée tourne en production.