Le nouveau paysage des vulnérabilités

Résumé analytique

Cet ebook examine les nouvelles réalités liées aux vulnérabilités logicielles, ce que toute organisation utilisant des logiciels libres doit savoir, et tire trois conclusions.

‍

Tout d'abord, l'intelligence artificielle a bouleversé à jamais la dynamique économique de la découverte des vulnérabilités. Les modèles d'IA de pointe sont désormais capables d'analyser une base de code et d'émettre des hypothèses sur les points de faiblesse. La découverte s'accélère pour atteindre la vitesse des machines, et chaque correctif publié devient un point de départ pour le développement d'exploits.

‍

Deuxièmement, c’est au niveau des logiciels open source en fin de vie (EOL) que cette accélération cause le plus de dégâts. Lorsqu’un framework, un runtime ou une bibliothèque cesse de recevoir des correctifs de sécurité, toutes les vulnérabilités divulguées à son sujet à partir de ce jour-là restent définitivement non corrigées, un type d’exposition que cet ebook qualifie de « vulnérabilités Forever-Day ». Pour aggraver le problème, la plupart des scanners de vulnérabilités ne détectent pas ce risque, car ils répertorient les CVE connues et non le statut du cycle de vie, et la plupart des paquets open source n’annoncent jamais officiellement leur fin de vie.

‍

Troisièmement, l'exposition aux risques est gérable, mais uniquement de manière délibérée. Les organisations doivent dresser l'inventaire de leurs composants logiciels en indiquant leur statut de cycle de vie parallèlement à leur statut de vulnérabilité, puis appliquer un cadre décisionnel comportant quatre options : la migration comme objectif à long terme, le support étendu commercial ou des contrôles compensatoires comme solution transitoire, et l'acceptation du risque uniquement pour des exceptions strictement délimitées et assorties de dates d'expiration.

‍

Des concepts de base au cycle de vie des vulnérabilités, en passant par les recommandations, cet ebook présente un état des lieux actualisé des vulnérabilités dans les logiciels libres.

‍

Introduction

Pendant la majeure partie des deux dernières décennies, la gestion des vulnérabilités a suivi un rythme bien rodé. Un chercheur ou un fournisseur découvrait une faille ou une vulnérabilité, un identifiant CVE lui était attribué, les scanners de sécurité la signalaient, un correctif était publié, puis les entreprises s'attaquaient à leur retard pour déployer ces correctifs. Ce processus n'a jamais été rapide, mais aujourd'hui, le nombre de vulnérabilités divulguées n'a jamais été aussi élevé.

‍

La composition de ce volume est tout aussi importante que son ampleur. L'écosystème des autorités de numérotation des vulnérabilités (CNA) a évolué. Avec l'émergence de CNA spécialisées, axées sur les écosystèmes tiers et l'open source, la divulgation des vulnérabilités n'est plus dominée par une poignée de grands éditeurs disposant de programmes de sécurité aboutis ; il s'agit désormais d'un flux distribué et à haut volume, largement alimenté par la détection assistée par l'IA.

‍

Selon la CSA, le délai médian entre la divulgation d’une vulnérabilité et la confirmation de son exploitation est tombé à seulement cinq jours. Les attaques ciblant les vulnérabilités des sites web ont atteint 6,29 milliards en 2025, soit une augmentation de 56 % par rapport à l’année précédente, selon le rapport « The State of Application Security 2026 ». Parallèlement, les délais de conformité auxquels la plupart des organisations sont soumises, tels que le délai de correction de 30 jours prévu par l’exigence 6.3.3 de la norme PCI DSS, ont été définis à une époque où les attaquants mettaient des semaines, voire des mois, à exploiter une faille. Aujourd’hui, les attaquants agissent systématiquement plus vite que le délai de correction obligatoire le plus court. Pour les logiciels open source abandonnés, qui ne bénéficient plus d’aucun support ou qui ont atteint leur fin de vie (EOL), il n’y a pas de délai de correction, car il n’existe tout simplement pas de correctif. À des fins pratiques, le présent document désigne l’ensemble de ces logiciels non maintenus sous le terme de « logiciels EOL » : des logiciels qui ne reçoivent plus aucun correctif de sécurité, aucune nouvelle version et aucun patch d’aucune sorte.

‍

Cet ebook traite de la manière d'évoluer dans ce nouveau contexte : bien comprendre les vulnérabilités afin d'élaborer des stratégies adaptées à toute organisation utilisant des logiciels libres.

‍

Vulnérabilités, failles et exploits

Une gestion efficace des risques nécessite une taxonomie commune aux équipes d'ingénierie, de sécurité et de gouvernance. Des termes identiques peuvent correspondre à des objets différents selon les bases de données et les systèmes, et les confondre peut entraîner des malentendus, une mauvaise allocation des ressources, un faux sentiment de sécurité et, en fin de compte, des risques pour la sécurité.

‍

Bugs, failles, vulnérabilités et exploits

Un bug désigne tout défaut entraînant un comportement incorrect d’un logiciel. La plupart des bugs n’ont aucune conséquence sur la sécurité. Une faiblesse est une catégorie d’erreur pouvant entraîner des problèmes de sécurité, comme l’absence de validation de la longueur d’une entrée. Les faiblesses sont répertoriées dans la Common Weakness Enumeration (CWE), gérée par MITRE. Une vulnérabilité est une instance spécifique et concrète d’une faiblesse dans un logiciel et une version donnés, dont un attaquant pourrait effectivement tirer parti. Les vulnérabilités se voient attribuer des identifiants CVE. Un exploit est un code ou une technique fonctionnelle qui transforme une vulnérabilité en compromission. Une vulnérabilité peut exister pendant des années sans qu’aucun exploit ne soit rendu public, et la publication d’un exploit modifie son profil de risque (gravité) du jour au lendemain. Il est essentiel de bien comprendre ces concepts distincts pour hiérarchiser les dépenses consacrées à la correction des failles.

‍

Principaux acronymes liés à la sécurité

Le CVE (Common Vulnerabilities and Exposures) est le répertoire mondial des vulnérabilités rendues publiques, géré par MITRE sous l’égide du gouvernement américain (cve.org). Une fiche CVE établit une identité unique : un identifiant, une vulnérabilité, afin que chaque outil, avis de sécurité et discussion fasse référence à la même faille. Les identifiants CVE sont attribués par les autorités de numérotation CVE (CNA), un ensemble fédéré de fournisseurs, de projets open source, d'entreprises de sécurité et de coordinateurs autorisés à attribuer des identifiants dans leur domaine de compétence. HeroDevs est une CNA.

‍

La NVD (National Vulnerability Database) est la couche d'enrichissement du NIST qui vient s'ajouter au CVE (nvd.nist.gov). La NVD ajoute des scores CVSS, des correspondances avec le CWE et des données sur les produits concernés (CPE). Ces dernières années, la NVD a accumulé d'importants retards dans l'enrichissement de ses données, ce qui explique en partie pourquoi de nombreux programmes ne la considèrent plus comme leur seule source de référence.

‍

L'EUVD (base de données sur les vulnérabilités de l'Union européenne) est une plateforme centralisée gérée par l'Agence de l'Union européenne chargée de la cybersécurité (ENISA) afin de recenser, de classer et de traiter les vulnérabilités logicielles et matérielles présentant un intérêt pour l'UE. Créée pour soutenir la directive NIS2 et la loi sur la cyber-résilience, elle regroupe des flux d’informations mondiaux (tels que CVE et NVD) tout en intégrant directement les rapports des CSIRT (équipes nationales d’intervention en cas d’incident de sécurité informatique) et les divulgations régionales des éditeurs de logiciels. 

‍

Le CVSS (Common Vulnerability Scoring System), géré par FIRST, évalue la gravité technique d'une vulnérabilité sur une échelle de 0 à 10 en fonction de critères liés à l'exploitabilité et à l'impact (first.org/cvss). La notation diffère entre les versions v3.1 et v4.0 du CVSS. Elle ne fournit aucune indication quant à savoir si quelqu'un exploite réellement cette faille ou si votre déploiement est accessible.

‍

L'EPSS (Exploit Prediction Scoring System), également développé par FIRST, estime la probabilité qu'une vulnérabilité soit exploitée en conditions réelles au cours des 30 prochains jours (first.org/epss). L'EPSS est un indicateur de probabilité, et non de gravité. Une faille de faible gravité peut ainsi obtenir un score EPSS élevé, et inversement.

‍

Le KEV (Known Exploited Vulnerabilities Catalog, ou catalogue des vulnérabilités connues et exploitées) est la liste officielle de la CISA répertoriant les vulnérabilités dont l’exploitation a été confirmée dans la nature, chacune étant assortie d’une date limite de correction obligatoire pour les agences fédérales américaines (catalogue KEV sur cisa.gov). Le KEV constitue le seuil minimal de tout système de hiérarchisation : si une vulnérabilité figure dans le KEV et est présente dans votre environnement, elle doit être traitée en priorité.

‍

Une SBOM (Software Bill of Materials, ou nomenclature logicielle) est un inventaire lisible par machine des composants d'un logiciel, généralement au format SPDX ou CycloneDX. La CISA gère la base centrale regroupant les recommandations relatives aux SBOM et les ressources de la communauté (cisa.gov/sbom).

‍

VEX (Vulnerability Exploitability eXchange) est le format complémentaire qui permet à un fournisseur d'indiquer si un produit est réellement concerné par un CVE donné au niveau de ses composants. Le format VEX a été créé car les SBOM génèrent un nombre considérable de correspondances théoriques, et il faut bien que quelqu'un précise lesquelles sont pertinentes.

‍

Le paysage du conseil

Les fiches CVE et les entrées du NVD ne constituent qu'une partie du tableau. Les avis des éditeurs fournissent souvent les informations les plus précoces et les plus précises concernant les versions concernées. Les écosystèmes open source gèrent leurs propres bases de données d'avis, notamment la GitHub Advisory Database et la couche d'agrégation OSV.dev, dont les informations divergent fréquemment de celles du NVD en ce qui concerne les plages de versions et les niveaux de gravité.

‍

Vulnérabilités « zero-day » et « forever-day »

Une faille « zero-day » désigne une vulnérabilité pour laquelle un exploit est disponible avant que l'éditeur ou le responsable de la maintenance n'en ait connaissance ou n'ait publié de correctif. Certaines vulnérabilités ont eu un tel impact qu'elles ont donné lieu à des noms spécifiques : Spring4Shell, Dirty Pipe, Log4Shell, Shellshock, Heartbleed, même si pour plusieurs d'entre elles, des correctifs ont été mis à disposition quelques jours seulement après leur divulgation publique.

‍

Une « forever-day » est une vulnérabilité présente dans un logiciel ayant atteint sa fin de vie (EOL). Les logiciels abandonnés, non pris en charge et en fin de vie ne bénéficiant plus de correctifs de sécurité, de nouvelles versions ni de correctifs, une « forever-day » présente un risque d'exploitation plus élevé. Elle reste exploitable dans chaque déploiement, indéfiniment, à moins que l'opérateur ne prenne d'autres mesures que d'attendre un correctif.  Déterminer quels composants d’un inventaire ont effectivement franchi cette ligne n’est pas une mince affaire, car la plupart des paquets open source n’annoncent jamais officiellement leur fin de vie.

‍

Causes profondes : comment les vulnérabilités s'introduisent dans le code

Les vulnérabilités s'introduisent rarement dans le code par malveillance ; la complexité des logiciels, les dépendances héritées et les rythmes de déploiement actuels entraînent inévitablement des risques systémiques. La grande majorité des vulnérabilités relève d'un petit nombre de catégories récurrentes qui sont comprises, documentées et enseignées depuis longtemps.

‍

Corruption de mémoire. Débordements de tampon, utilisation après libération, double libération, ainsi que lectures et écritures hors limites, principalement présents dans les bases de code C et C++. Ces failles restent les plus courantes dans les systèmes d'exploitation, les navigateurs et les bibliothèques natives, et constituent la cible principale de la campagne en faveur de la sécurité mémoire menée par le secteur, qui prône l'adoption de langages tels que Rust (soutenue par la CISA, la NSA et d'autres organismes).

‍

Injection. L'injection SQL, l'injection de commandes, l'injection LDAP et l'injection XML ont toutes une cause commune : l'introduction de données contrôlées par un attaquant dans un interpréteur, en l'absence de séparation adéquate entre les données et le code. L'injection figure dans toutes les éditions du Top 10 de l'OWASP depuis la création de cette liste, il y a plus de 20 ans.

‍

Cross-site scripting (XSS). À lui seul, le XSS a donné lieu à plus de 8 000 CVE rien qu’en 2025. Trois décennies après sa découverte, le XSS persiste car il est facile de commettre des erreurs d’encodage de sortie à n’importe lequel des milliers d’endroits où une application web écrit les données utilisateur dans une page, et parce que les écosystèmes présentant de faibles barrières à l’entrée continuent de produire du nouveau code qui reproduit les mêmes erreurs.

‍

Désérialisation. Une désérialisation non sécurisée de données fournies par un attaquant entraîne certaines des vulnérabilités d'exécution de code à distance les plus graves jamais recensées, en particulier dans les écosystèmes Java et .NET , où des graphes d'objets complexes peuvent être transformés en chaînes de gadgets.

‍

Défaillances en matière d'authentification et de contrôle d'accès. Les failles de contrôle d'accès constituent la première catégorie du classement actuel « OWASP Top 10 ». L'absence de limites de confiance, une conception incomplète du système d'autorisation, des paramètres par défaut non sécurisés et une utilisation non sécurisée des API génèrent des vulnérabilités qu'aucun langage garantissant la sécurité de la mémoire ne pourra jamais empêcher, car il s'agit de défauts de conception et non de défauts d'implémentation.

‍

Mauvaise utilisation de la cryptographie. Il s'agit rarement d'un algorithme défaillant ; il s'agit presque toujours d'un algorithme correct utilisé de manière incorrecte : clés codées en dur, validation des certificats désactivée, solutions maison, générateurs aléatoires peu fiables.

‍

Profils de risque liés à la langue et à l'écosystème

Chaque écosystème majeur présente des défaillances qui lui sont propres et facilement identifiables. Les bases de code en C et C++ sont connues pour générer des corruptions de mémoire : débordements de tampon et vulnérabilités liées à des accès hors limites.

Les vulnérabilités de Java se caractérisent par une désérialisation non sécurisée et des failles complexes au niveau des frameworks, et l'écosystème Spring en illustre l'ampleur : rien qu'en juin 2026 , 67 CVE ont été répertoriés sur Spring , dont 27 de gravité élevée.

‍

Bon nombre des vulnérabilités touchant JavaScript et l’écosystème npm trouvent leur origine dans l’exposition de la chaîne d’approvisionnement et la contamination des prototypes, amplifiées par une profondeur extrême des dépendances. La campagne « Mini Shai-Hulud » de mai 2026 en est l’exemple récent le plus marquant : en l’espace de six minutes, des attaquants ont publié 84 versions malveillantes réparties dans 42 paquets TanStack en corrompant le cache de GitHub Actions.

‍

Le code PHP est susceptible de générer des failles d'injection et d'inclusion de fichiers, notamment dans les écosystèmes de plugins de WordPress et d'Drupal. Python génère des failles de désérialisation (pickle), de confusion des dépendances et, de plus en plus, des vulnérabilités dans les outils d'IA et d'apprentissage automatique.

‍

Connaître les vulnérabilités caractéristiques de votre pile vous permet de concentrer vos efforts de vérification sur les points faibles de votre écosystème ; cela dit, n'importe quel type de vulnérabilité peut être détecté à tout moment, quel que soit le langage ou le framework utilisé.

‍

Pour aller plus loin

Deux références traitent de l'aspect « prévention » de ce chapitre de manière bien plus approfondie qu'un livre numérique ne pourrait le faire. La norme ASVS (Application Security Verification Standard) de l'OWASP constitue une liste de contrôle pratique permettant de vérifier les contrôles au niveau des applications. Le cadre de développement logiciel sécurisé du NIST, SP 800-218, définit les pratiques relatives au cycle de vie du développement auxquelles les régulateurs font de plus en plus souvent référence en les citant nommément. 

‍

Le cycle de vie complet d'une vulnérabilité

Chaque vulnérabilité suit un cycle de vie, depuis sa création et sa découverte jusqu'à sa divulgation et, dans l'idéal, à sa correction. Comprendre ce parcours, y compris les points où il peut s'enliser ou échouer, constitue un aspect fondamental des connaissances en matière de sécurité des applications.

Parcours de découverte

Les vulnérabilités se manifestent par quatre voies principales, chacune présentant des caractéristiques différentes.

‍

Recherche interne. Les équipes de sécurité des éditeurs et des projets open source examinent leur propre code, effectuent des analyses statiques et soumettent leurs propres cibles à des tests de fuzzing. C'est là que l'on détecte les signaux les plus significatifs, dès les premières étapes du cycle de vie.

‍

Programmes de prime aux bogues et chercheurs externes. Il s’agit de chercheurs indépendants qui signalent des failles via des programmes sur des plateformes telles que HackerOne, ou directement aux responsables de maintenance. La qualité varie énormément ; par exemple, des rapports de mauvaise qualité générés par l’IA ont récemment mis ce canal à rude épreuve pour certains projets open source, notamment Node.js. Ce sujet a été abordé lors d’un récent webinaire organisé par HeroDevs.

‍

Le fuzzing à grande échelle. Les infrastructures de fuzzing guidées par la couverture, telles que l'OSS-Fuzz de Google, testent en continu des centaines de projets open source critiques et ont généré des dizaines de milliers de résultats depuis leur mise en service.

‍

Analyse assistée par l'IA. Il s'agit du canal le plus récent et de celui qui connaît la croissance la plus rapide. Les modèles linguistiques de pointe sont désormais capables de lire une base de code, d'émettre des hypothèses sur les points où elle pourrait présenter des défaillances, de valider ces hypothèses de manière expérimentale par rapport au logiciel en exécution, et de produire des résultats confirmés et reproductibles. L'évaluation « Mythos Preview » d'Anthropic fournit des preuves détaillées issues d'un seul de ces modèles linguistiques de grande envergure (LLM).

‍

Validation et rapports

Une découverte ne constitue pas une vulnérabilité tant qu'elle n'a pas été validée : c'est-à-dire reproduite sur le logiciel concerné, avec une description claire de son impact et des versions touchées. C'est dans l'écart entre « mon outil a signalé cela » et « voici un problème de sécurité reproductible dont l'impact a été démontré » que la plupart des rapports de mauvaise qualité sont écartés, et que le rapporteur gagne en crédibilité. 

‍

Un rapport de qualité doit inclure le composant concerné et la plage de versions, les étapes de reproduction ou une démonstration de principe, une évaluation de l’impact, ainsi qu’une proposition de niveau de gravité accompagnée d’une justification. Les principes de fonctionnement publiés par Anthropic concernant les vulnérabilités détectées par l’IA constituent un modèle moderne et utile : chaque rapport fait l’objet d’un examen et d’une confirmation par des humains, les résultats issus de l’IA sont clairement identifiés comme tels, et des correctifs potentiels sont inclus dans la mesure du possible (Anthropic, « Coordinated Vulnerability Disclosure »).

‍

Divulgation coordonnée, embargos et calendriers

La divulgation coordonnée des vulnérabilités (CVD) est le processus négocié par lequel un signalant accorde à un éditeur ou à un responsable de maintenance le temps nécessaire pour développer et publier un correctif avant que les détails ne soient rendus publics. La référence officielle de ce processus est le « Guide du CERT/CC sur la divulgation coordonnée des vulnérabilités », et les normes sous-jacentes sont les normes ISO/IEC 29147 (divulgation) et ISO/IEC 30111 (processus de traitement).

‍

La norme de facto dans le secteur est un délai de divulgation de 90 jours : le divulgateur publie l'information au bout de 90 jours ou dès la mise à disposition d'un correctif, selon la première de ces deux échéances, les prolongations et les anticipations étant négociées au cas par cas. Les périodes d'embargo ont pour but de coordonner les correctifs entre plusieurs éditeurs, en particulier pour les vulnérabilités touchant des composants partagés, où des dizaines de produits en aval doivent être corrigés simultanément.

‍

Les normes de divulgation partent du principe qu’il y a quelqu’un à l’autre bout, capable de mettre au point un correctif. Pour un projet sain et actif, le cycle de vie suit son cours : signalement, délai de divulgation, correctif, avis de sécurité, adoption. Pour un projet open source en fin de vie, ce cycle s’interrompt prématurément. Il n’y a personne à qui signaler le problème, ou bien les responsables de maintenance qui reçoivent le signalement indiqueront, à juste titre, que la version concernée n’est plus prise en charge. La divulgation est achevée ; la correction ne commence jamais. C’est la raison technique pour laquelle les logiciels non pris en charge et en fin de vie accumulent des vulnérabilités qui restent indéfiniment non corrigées et documentées publiquement : les divulgations se poursuivent, mais les corrections ont cessé. 

‍

Une visibilité claire sur le support à long terme et les dates de fin de vie (EOL) est une bonne pratique recommandée pour offrir une visibilité aux développeurs de logiciels. Le cadre publié par HeroDevs pour les projets open source via son « Open Source Sustainability Fund » aborde cette question du point de vue des responsables de maintenance : communiquer les événements liés à la fin de vie par les canaux officiels, indiquer clairement quelles versions sont prises en charge et lesquelles ne le sont pas, et orienter les utilisateurs vers une migration ou une solution de support avant que la date de fin de vie n’arrive.

‍

Publication d'un correctif et divulgation publique

Lorsque le cycle de vie fonctionne correctement, la phase finale consiste en la publication d’un correctif accompagnée d’un avis de sécurité : le correctif, les versions concernées, le niveau de gravité et la mention du nom de la personne ayant signalé la faille. Malheureusement, dès cette divulgation, les attaquants peuvent cibler les environnements non mis à jour et les exploiter. Selon la CSA, le délai médian de cinq jours entre la divulgation et l’exploitation ouvre une brèche pour tout déploiement qui n’a pas encore été mis à jour. Et pour les logiciels open source en fin de vie, ce correctif n’arrive jamais, à moins d’opter pour une option commerciale de support étendu.

‍

Vulnérabilités des logiciels libres en fin de vie

La gestion des vulnérabilités, telle qu'elle est mise en œuvre et réglementée, repose sur une hypothèse implicite : pour toute vulnérabilité donnée, un correctif existe ou existera bientôt, et le rôle de l'opérateur est de l'appliquer rapidement. Les logiciels en fin de vie remettent complètement en cause cette hypothèse.

‍

Les logiciels open source abandonnés, sans support ou en fin de vie (EOL) désignent des projets qui ne font plus l'objet d'une maintenance active ni d'un support de la part de leurs développeurs d'origine ou de leur communauté. Ces projets ne bénéficient plus de correctifs de sécurité, de corrections de bogues ni de mises à jour de compatibilité, ce qui expose les organisations à des vulnérabilités connues et accroît le risque de problèmes de sécurité et d'exploitation. Chaque vulnérabilité CVE publiée à leur sujet reste définitivement non corrigée par les voies habituelles. 

‍

Identifier les composants en fin de vie dans votre propre stock

Il est impossible de gérer cette catégorie de risques sans savoir où elle se situe, et la plupart des scanners de vulnérabilité ne permettent pas de répondre à cette question, car ils s'appuient sur les données CVE plutôt que sur le statut du cycle de vie. Un composant ne présentant aucune vulnérabilité CVE connue et n'ayant plus aucun responsable de maintenance apparaît comme sûr aux yeux d'un scanner de sécurité, alors qu'il s'agit en réalité d'une bombe à retardement.

‍

Il existe des outils tenant compte du cycle de vie pour combler cette lacune. Le jeu de données EOL de HeroDevs compare les paquets à un ensemble de données répertoriant plus de 19 millions de versions de paquets dans tous les principaux écosystèmes (npm, Maven, etc.), et renvoie une détermination de fin de vie pour chaque composant. Et pour une fonctionnalité complète de la plateforme, HeroDevs Evergreen remplace automatiquement toutes les dépendances en fin de vie dans les applications par des solutions de remplacement sécurisées et développées par des ingénieurs. Ces solutions de remplacement sont fournies sous forme de pull requests à examiner et à fusionner. La couverture ne cesse de s'étendre à mesure que de nouvelles dépendances perdent leur support et sont ajoutées au système.

‍

L'arbre de décision : migrer, atténuer les risques, accepter ou souscrire à une extension de support

Une fois qu'un composant en fin de vie (EOL) a été identifié, il existe exactement quatre options.

‍

• Migrer. Passer à une version prise en charge ou à une technologie de remplacement. Il s’agit là d’une solution définitive et de la bonne réponse à long terme, mais les migrations concrètes des dépendances au niveau du framework se mesurent en sprints d’ingénieurs, et les imposer dans l’urgence après la découverte d’une vulnérabilité CVE critique constitue la méthode la plus coûteuse qui soit. Le fonctionnement de l’organisation ou de l’entreprise est également affecté par ces migrations forcées.

‍

• Atténuer les risques. Mettre en place des mesures de contrôle compensatoires : règles WAF, segmentation du réseau, désactivation de fonctionnalités, voire isolation de l'environnement. Une solution valable à titre provisoire, mais risquée à long terme, car chaque mesure de contrôle traite des vecteurs d'exploitation connus associés à des vulnérabilités CVE identifiées, tandis que la faille sous-jacente, ainsi que toutes les failles non encore découvertes, persistent.

‍

• Accepter. Recenser le risque et l'assumer en toute connaissance de cause. Cette approche peut parfois se justifier pour des systèmes véritablement isolés et de faible valeur. Elle est rarement justifiable pour tout ce qui est connecté à Internet ou relève d'un secteur réglementé. Plusieurs régimes réglementaires excluent de fait cette option.

‍

• Support étendu par des tiers. Maintenance commerciale des logiciels open source en fin de vie (EOL) grâce à une équipe d’ingénieurs spécialisés en sécurité. HeroDevs emploie des experts en open source et des contributeurs clés qui surveillent en permanence les avis de sécurité en amont et évaluent les CVE par rapport aux versions EOL de ses clients. Ils développent, testent et fournissent des correctifs rétroportés sous forme de remplacements prêts à l’emploi, sans nécessiter de modifications du code de l’application. Cette même expertise s’avère également utile lorsqu’un CVE très médiatisé ne s’applique pas à un logiciel en fin de vie. Lorsque le noyau d’ Drupal a révélé une faille d’injection SQL hautement critique en 2026, l’avis en amont n’évaluait tout simplement pas Drupal 7, et il a fallu un audit réalisé par un expert de HeroDevs sur le noyau et les modules contribués pour confirmer que les déploiements d’ Drupal 7 n’étaient pas exposés (blog HeroDevs, « Drupal 7 est-il affecté par le CVE-2026-9082 ? »).

‍

Ces quatre options ne s'excluent pas mutuellement ; le modèle courant et éprouvé consiste à utiliser la poursuite du support ou l'atténuation des risques comme solution transitoire, la migration comme objectif final, et l'acceptation uniquement pour des exceptions explicitement délimitées et assorties d'une date d'expiration.

‍

Risques liés à la conformité

Une analyse spécifique de la conformité s’impose. Le livre blanc de HeroDevs, « Le guide du développeur sur la conformité en matière de sécurité », passe en revue les normes, les cadres réglementaires et les réglementations mondiaux, et conclut que les logiciels en fin de vie (EOL) ne répondent pas, par nature, à leurs exigences fondamentales sur trois points principaux :

• Délais de correction : les délais de mise en conformité standard (tels que les délais de correction obligatoires de 30 jours pour les vulnérabilités critiques) supposent qu'un correctif existe.
• Visibilité des stocks et des actifs : la création d'une nomenclature logicielle (SBOM) met immédiatement en évidence les composants actifs et non pris en charge, qui font alors l'objet d'un examen réglementaire.
• Gouvernance documentée : les processus obligatoires de gestion des risques ne peuvent pas être respectés pour les vulnérabilités pour lesquelles aucune procédure de correction n'a été définie.

Par conséquent, un auditeur qui détecte un composant en fin de vie (EOL) présentant une vulnérabilité CVE critique non corrigée et entrant dans le champ d'application de l'audit est susceptible de consigner un constat de non-conformité.

‍

Détection et exploitation des vulnérabilités à l'aide de l'IA

Les preuves publiques les plus solides proviennent de l’équipe de recherche en sécurité d’Anthropic, qui a publié en avril 2026 une évaluation technique de son modèle « Claude Mythos Preview », après environ un mois de tests internes. Le modèle analyse du code pour formuler des hypothèses, exécute le logiciel pour les confirmer ou les infirmer, utilise des débogueurs si nécessaire et fournit des résultats validés. Grâce à cette approche, le modèle a découvert de véritables vulnérabilités « zero-day », principalement des failles de sécurité liées à la mémoire, dans des logiciels open source largement utilisés, et a démontré sa capacité à créer des exploits fonctionnels, notamment en enchaînant plusieurs vulnérabilités de navigateurs (Anthropic, « Assessing Claude Mythos Preview's cybersecurity capabilities »).

‍

L'échelle est le point essentiel. Claude Mythos et les grands modèles de langage (LLM) similaires développés par OpenAI, Google et d'autres acteurs sont capables d'analyser rapidement des bases de code et d'identifier les vulnérabilités. Parallèlement, les outils assistés par l'IA peuvent aider les chercheurs à accélérer la correction des failles, mais pas au même rythme. Et cela ne concerne que la partie « codage » du processus. Les correctifs doivent encore être triés, regroupés, documentés, testés et, enfin, déployés.

‍

Exploits de vulnérabilités

L'analyse des résultats de Mythos réalisée par Wiz montre que le modèle peut, à partir d'un identifiant CVE et d'un hachage de commit, produire de manière autonome et à moindre coût un exploit fonctionnel en quelques heures, alors que ce travail prenait auparavant plusieurs jours, voire plusieurs semaines, à des chercheurs expérimentés. Conséquence pratique : davantage de CVE sont divulguées et exploitées plus rapidement. Grâce à l'aide de l'IA, chaque correctif publié pour une vulnérabilité peut devenir un point de départ pour le développement d'un exploit.

‍

Or, si l'on applique ce raisonnement aux logiciels abandonnés, non pris en charge ou en fin de vie, l'asymétrie devient flagrante. Pour les logiciels pris en charge, l'accélération des attaques est contrée par une mise à jour plus rapide ; la marge de manœuvre du défenseur se réduit, mais elle subsiste. Pour les logiciels abandonnés, non pris en charge et en fin de vie, il n'y a aucune marge de manœuvre pour le défenseur, car il n'y a pas de correctif vers lequel tendre. 

‍

L'IA a définitivement renversé l'avantage dont bénéficiait jusqu'alors le défenseur. Les modèles de pointe effectuent désormais de manière autonome la recherche de vulnérabilités et la génération d'exploits à la vitesse de la machine et à un coût marginal. Pour les logiciels actifs, cela réduit la fenêtre de correction ; pour les logiciels en fin de vie (EOL) et ceux qui ne font plus l'objet d'une maintenance, cela élimine complètement toute défense, transformant la dette technique héritée en un risque réel de violation.

‍

Si le taux de détection du secteur est sur le point d'être multiplié par l'analyse à l'échelle des machines, c'est au sein du parc de logiciels qui, de par leur structure, ne peuvent pas bénéficier de correctifs que cette multiplication causera le plus de dégâts. C'est là l'argument le plus convaincant en faveur d'un traitement du parc de logiciels en fin de vie (EOL) comme un sujet urgent relevant du conseil d'administration, plutôt que comme une dette technique secondaire.

‍

Réflexions finales

L'ancienne stratégie de gestion des vulnérabilités reposait sur trois hypothèses : les divulgations se succèdent à un rythme gérable, un correctif existe ou sera bientôt disponible, et les responsables de la sécurité ont le temps de l'appliquer. Ces trois hypothèses sont désormais fausses. Dans le nouveau contexte des vulnérabilités, le volume des divulgations dépasse les 66 000 selon les prévisions semestrielles de FIRST, la détection assistée par l'IA transforme les bases de code en résultats à la vitesse de l'ordinateur, et la durée médiane d'exploitation est tombée en dessous de tous les délais de conformité.

‍

Pour les logiciels pris en charge, il s’agit d’un problème opérationnel complexe. Pour les logiciels en fin de vie, la situation est bien pire : il s’agit d’une catégorie croissante de vulnérabilités documentées publiquement, pour lesquelles aucun correctif n’est jamais publié, et qui sont de plus en plus souvent détectées par l’IA. Chaque accélération décrite dans cet ebook – augmentation du nombre de CNA, de découvertes et d’exploits plus rapides – touche le plus durement les logiciels qui, de par leur nature même, ne peuvent pas bénéficier d’un correctif.

‍

La réponse ne réside pas dans la panique, mais dans l'inventaire et la hiérarchisation. Identifiez les composants de votre pile qui ont dépassé la date de fin de vie (la plupart ne l'annoncent jamais). Affichez le statut du cycle de vie à côté du statut de vulnérabilité dans la même vue. Appliquez ensuite l'arbre de décision de manière réfléchie : optez pour la migration comme solution finale, le support prolongé ou les mesures d'atténuation comme solution intermédiaire, et n'acceptez les exceptions que si elles sont limitées et assorties d'une date d'expiration.

‍

La fréquence des vulnérabilités détectées par l'IA multiplie les risques liés aux logiciels en fin de vie (EOL). Les « Forever-days » ne durent « pour toujours » que si personne ne publie de correctifs. Le service « HeroDevs Never-Ending Support » rétablit l'application des correctifs de sécurité pour plus de 40 frameworks, environnements d'exécution et bibliothèques open source en fin de vie, fournis sous forme de remplacements prêts à l'emploi dans le cadre d'un contrat de niveau de service (SLA). Si l'un des composants de votre inventaire a atteint sa fin de vie, contactez notre équipe avant que le prochain cycle de divulgation ne le repère en premier.

‍