Lorsque les équipes de sécurité pensent aux logiciels open source en fin de vie (EOL), la conversation commence et se termine généralement au même endroit : plus de correctifs. C'est vrai, mais ce n'est que la moitié de l'histoire, et sans doute la moitié la moins dangereuse. Il existe deux problèmes cumulatifs dont la plupart des équipes ignorent l'existence. ## Problème Un : L'écosystème CVE n'enquête pas sur ce qu'il ne prend pas en charge Lorsqu'une vulnérabilité est découverte dans un projet open source, les mainteneurs déterminent quelles versions sont affectées et déposent un **CVE** avec une plage affectée définie. Chaque scanner de vulnérabilité, outil SBOM et flux CVE de l'industrie consomme cette plage. Si votre version se situe en dehors, vous ne recevez aucune alerte. Pas parce que vous êtes en sécurité, mais parce que personne n'a vérifié. Les versions EOL se situent presque par défaut en dehors de cette plage. La raison est simple : c'est un problème d'échelle. En seulement cinq ans, le nombre mondial de CVE a doublé tandis que le nombre de CVE non notés a augmenté de 37 fois, selon le rapport 2026 State of the Software Supply Chain de **Sonatype**. Les mainteneurs sont déjà débordés par l'examen et le correctif des versions qu'ils prennent activement en charge, et comme le volume des CVE et le nombre total de versions de paquets continuent de croître, la bande passante d'investigation nécessaire pour couvrir les anciennes lignes de publication n'existe tout simplement pas. Les mainteneurs doivent être réalistes quant à la profondeur de leur propre historique de publication qu'ils peuvent raisonnablement couvrir. La recherche de Sonatype a explicitement cité les "versions EOL omises des avis" comme un moteur de fausse confiance en matière de sécurité, contribuant aux 167 286 faux négatifs, des composants exploitables qui sont passés complètement inaperçus, qu'ils ont identifiés en 2025 seulement. ### À quoi cela ressemble en pratique Deux vulnérabilités critiques récentes dans l'écosystème Spring illustrent cela concrètement. **CVE-2026-22732 — Spring Security (Critique, Mars 2026, CVSS 9.1)** Cette vulnérabilité provoque l'abandon silencieux des en-têtes de réponse de sécurité, notamment `Cache-Control`, `X-Frame-Options`, `Strict-Transport-Security` et `Content-Security-Policy`, dans certaines configurations d'applications servlet. La plage officielle affectée couvre Spring Security 5.7.x à 7.0.x. Spring Security 6.2.x n'est pas listé. Il a atteint sa fin de vie en décembre 2025. Spring Boot 3.2 inclut Spring Security 6.2. Toute organisation exécutant Boot 3.2, une version mineure derrière la plage listée, ne reçoit aucun signal de scanner. **HeroDevs** a confirmé que Spring Security 6.2.x est affecté et a rétroporté un correctif pour les clients NES. L'enregistrement CVE en amont ne reflète pas cela. ### Quelle est la fréquence de ces occurrences ? Les exemples Spring ci-dessus ne sont pas des cas isolés. Ils reflètent un schéma que HeroDevs rencontre constamment dans le cadre de sa pratique Never-Ending-Support. Lorsqu'un nouveau CVE est divulgué sur un paquet pris en charge, HeroDevs constate qu'il doit corriger une version EOL que l'enregistrement CVE officiel ne liste pas comme affectée **environ 80 % du temps**. Le rayon d'impact de toute vulnérabilité donnée est systématiquement plus large que ce que montre l'enregistrement. En termes simples : pour quatre CVE sur cinq divulgués sur une version prise en charge, il existe une probabilité raisonnable qu'une version EOL que vous utilisez soit également affectée, et aucun scanner au monde ne vous le dira. ## Problème Deux : L'industrie compte le mauvais logiciel EOL L'écart d'investigation CVE ci-dessus s'applique aux logiciels EOL que la communauté sait effectivement être EOL. Cela s'avère n'être qu'une très petite fraction du problème réel. La source de données EOL la plus citée est [endoflife.date](http://endoflife.date/), qui suit environ 350 projets activement maintenus ; des frameworks et runtimes majeurs pour lesquels les mainteneurs ont explicitement publié des dates de fin de vie. Sur ces 350 projets, environ 7 000 versions spécifiques de paquets sont identifiées comme EOL. C'est l'univers avec lequel la plupart des scanners et des équipes de sécurité travaillent. Voici l'échelle réelle du problème. Dans le rapport 2026 State of the Software Supply Chain de Sonatype, produit en partenariat avec HeroDevs, les données racontent une histoire différente. En analysant le statut du cycle de vie sur 12 millions de versions de paquets couvrant npm, PyPI, Maven, NuGet, RubyGems, Go, Packagist et crates.io, HeroDevs a constaté que **5,4 millions de ces versions sont en fin de vie**. Cependant, la source publique la plus complète de l'industrie (endoflife.date) ne représente qu'environ 7 000 d'entre elles. La répartition par écosystème est frappante. Environ 25 % des versions de paquets npm sont EOL. NuGet se situe autour de 18 %, Cargo à 13 %, PyPI à 11 % et Maven Central à 10 %. Ce sont des versions qui apparaissent activement dans les SBOM d'entreprise aujourd'hui, sans couverture d'investigation CVE ni chemin de correction. Le rapport Sonatype a révélé que 5 à 15 % des composants dans les graphes de dépendances d'entreprise sont EOL, indiquant une exposition EOL même lorsque les équipes pensent n'utiliser que des bibliothèques de premier niveau prises en charge. Les dépendances transitives, les paquets dont dépendent vos paquets, portent la majorité de cette exposition cachée. La plupart des organisations sous-estiment profondément leur exposition EOL, et ce n'est pas de leur faute. Leurs outils n'ont jamais été conçus pour détecter l'abandon à grande échelle. HeroDevs a confirmé plus de 81 000 versions de paquets EOL avec des CVE connus et aucun chemin de correction disponible, ce qui signifie qu'il s'agit de CVE qui ont été activement examinés et confirmés. Étant donné qu'environ 80 % des CVE sur les versions prises en charge affectent également les versions EOL qui n'ont jamais été officiellement examinées, le nombre réel est probablement beaucoup plus élevé. HeroDevs estime que le chiffre réel pourrait être plus proche de **>400 000** sur tous les registres. ## Pourquoi cela s'aggrave Cette dynamique n'est pas nouvelle. Ce qui est nouveau, c'est le rythme auquel elle s'aggrave. L'écosystème OSS évolue plus rapidement que l'infrastructure de sécurité construite pour le surveiller. npm à lui seul a enregistré plus de 838 000 versions associées à des scores CVSS 9.0+ critiques en 2025. Le volume de téléchargements PyPI a augmenté de plus de 50 % d'une année sur l'autre. Chaque nouvelle version de paquet qui entre dans un registre est une future version EOL, et la population EOL croît continuellement, tandis que la capacité d'investigation pour la couvrir ne le fait pas. La fonction de forçage la plus importante, cependant, pourrait être l'**IA**. En avril 2026, **Anthropic** a annoncé le projet Glasswing aux côtés de Claude Mythos Preview, documentant sa capacité à identifier et exploiter des vulnérabilités zero-day sur tous les principaux systèmes d'exploitation et navigateurs, y compris des vulnérabilités non détectées depuis des décennies. L'initiative est explicitement défensive, visant à trouver et corriger les vulnérabilités critiques avant que les attaquants ne puissent les exploiter. Pour les logiciels bénéficiant d'un support actif, c'est une excellente nouvelle. Les vulnérabilités trouvées à l'échelle de l'IA peuvent être acheminées vers des ingénieurs capables de les résoudre. Pour les logiciels EOL, le calcul est différent. Une IA qui trouve des vulnérabilités dans l'ensemble du paysage du code source mettra en évidence des découvertes dans des versions qu'aucun mainteneur ne surveille. Ces découvertes ne seront pas officiellement examinées par rapport aux plages affectées par l'EOL. Elles ne déclencheront pas d'alertes de scanner pour les utilisateurs EOL. Aucun correctif en amont ne les abordera jamais. La même capacité qui accélère la défense pour les logiciels pris en charge élargit le fossé d'exposition pour tout ce qui a déjà été laissé pour compte. Les premiers signaux de ce changement sont déjà visibles. L'impact complet n'est pas encore arrivé. ## Quelle partie de votre pile est déjà EOL ? Vous ne le savez pas. Votre scanner ne le sait pas. Votre flux CVE ne le sait pas. Les données de Sonatype indiquent que 5 à 15 % des composants d'une pile d'entreprise typique sont EOL. Pour npm seul, c'est 25 % de toutes les versions de paquets. Spring Boot 3.2 a inclus Spring Security 6.2, EOL depuis décembre, sans alerte de scanner. **Quel est votre chiffre ?** Le jeu de données EOL de HeroDevs vous le révèle en moins de cinq minutes. Téléchargez un SBOM ou exécutez le CLI. Nous le comparons à plus de 12 millions de versions de paquets sur npm, PyPI, Maven, NuGet et tous les autres registres majeurs, y compris les dépendances transitives que votre scanner a ignorées. Vous obtenez un rapport listant chaque paquet EOL dans votre pile. Pas d'appel commercial. Pas de carte de crédit. Alors que la recherche de vulnérabilités assistée par l'IA s'intensifie, le nombre de vulnérabilités non divulguées dans les paquets EOL non examinés ne fera qu'augmenter. **[Exécutez mon scan EOL gratuit →](http://www.herodevs.com/eol-dataset/eol-data?utm_source=sponsored-article&utm_medium=paid-sponsorship&utm_campaign=2026q2_eolds-ga-phase2_global&utm_content=bleeping-computer_20260505)**