Yoan AGOSTINI

Yoan AGOSTINI

1337 G33k

The EOL Blind Spot in Your CVE Feed: What SCA Tools Miss

1 minute de lecture

Mis à jour :

L’angle mort des logiciels en fin de vie (EOL) dans la sécurité logicielle

Les outils de gestion des vulnérabilités actuels échouent à détecter les risques associés aux logiciels en fin de vie (EOL) pour deux raisons majeures : l’absence d’investigation sur les versions obsolètes et la sous-estimation massive du nombre de composants abandonnés.

Points clés :

  • Déficit d’investigation : Lorsqu’une vulnérabilité est découverte, les mainteneurs se concentrent uniquement sur les versions actives. Les versions EOL sont exclues des rapports CVE par défaut, ce qui génère une “fausse confiance” sécuritaire.
  • Étendue du problème : Environ 80 % des CVE affectant des versions supportées touchent également des versions EOL non documentées.
  • Sous-estimation massive : Alors que les outils publics (comme endoflife.date) ne recensent qu’environ 7 000 versions EOL, l’analyse réelle des registres (npm, PyPI, Maven, etc.) révèle plus de 5,4 millions de versions EOL.
  • Risque lié à l’IA : L’émergence d’outils d’IA capables d’identifier des vulnérabilités à grande échelle va exposer davantage de failles dans des logiciels EOL qui ne seront jamais corrigées par les mainteneurs officiels.
  • Dépendances transitives : 5 à 15 % des composants au sein d’une pile logicielle d’entreprise sont en fin de vie, souvent dissimulés dans les dépendances indirectes.

Vulnérabilité illustratrice :

  • CVE-2026-22732 (Spring Security) : Critique (CVSS 9.1). Bien que la version 6.2.x soit vulnérable, elle n’apparaît pas dans l’avis officiel car elle a atteint sa fin de vie, laissant les entreprises utilisant Spring Boot 3.2 sans alerte de leurs outils de scan.

Recommandations :

  • Audit approfondi des dépendances : Ne pas se fier uniquement aux scanners de vulnérabilités classiques, qui ignorent la majorité des composants EOL.
  • Utilisation d’outils dédiés : Analyser les nomenclatures logicielles (SBOM) avec des bases de données spécialisées dans le cycle de vie des versions (ex: HeroDevs EOL Dataset) pour identifier les composants abandonnés.
  • Stratégie de remédiation : Mettre en place un plan de migration pour remplacer les composants EOL ou envisager des solutions de support étendu pour les briques critiques impossibles à mettre à jour immédiatement.

Source

Vous pourriez aimer