30/03/2025

Administration SystèmesCybersécurité

Anticipez l’obsolescence de vos logiciels avec endoflife.date

I. Présentation

Au sein d’un système d’information composé de nombreux systèmes d’exploitation et applications différentes, le suivi des versions des composants et surtout de l’obsolescence peut être une tâche difficile.

Comment savoir si la version d’un service, d’une application ou d’un OS est toujours maintenue ? Jusqu’à quand les mises à jour sont-elles prévues ? À partir de quelle date le composant devient-il obsolète ?

Est généralement décrit comme obsolète un composant qui est dans une version qui n’est plus maintenue par l’éditeur. Ce dernier ne publiera donc plus de mise à jour, notamment en cas de vulnérabilité impactant cette version.

Ces questions sont importantes, puisqu’elles permettent de prévoir quand devront être mis à jour, voire remplacés les systèmes et applications d’un SI. Pour ne rien arranger, trouver les informations concernant la fin de maintenance d’une version ou la parution d’une nouvelle version peut parfois être un vrai casse-tête selon les technologies et éditeurs.

Dans cet article, nous allons présenter endoflife.date, un site web, mais aussi un dépôt et une API qui facilitent le suivi des versions des principaux composants d’un SI et de leurs obsolescences.

II. Présentation et utilisation de endoflife.date

A. Le site web

Le site endoflife.date propose une interface simple pour rechercher un produit et consulter les versions supportées et obsolètes, les dates de début et fin de support, y compris pour les LTS (Long-Term Support) et enfin les types de mises à jour encore disponibles (correctifs de sécurité, mises à jour majeures, etc.).

Voyons un exemple avec la page endoflife.date concernant Apache Tomcat :

Page Apache Tomcat de endoflife.date.
Page Apache Tomcat de endoflife.date. Source : endoflife.date - Tomcat

Le résultat est plutôt clair, par exemple, si vous disposez d’une version 10.0.13 de Tomcat. Celle-ci n’est plus maintenue depuis le 31 octobre 2022 (dernière version de cette branche : 10.0.27). Conclusion : il vaut mieux passer à une version majeure plus récente. Par contre, si vous disposez d’une version 11.0.1. Celle-ci est toujours maintenue, mais n’est pas la dernière version à jour.

Pensez à vérifier la dernière mise à jour de la page (en dessous du titre) pour s’assurer d’avoir les bonnes informations. La base de connaissance de endoflife.date est maintenue par la communauté via un dépôt GitHub que nous verrons un peu plus bas.

Voyons un autre exemple avec quelque chose de plus utilisé, comme Windows Server : 

Page Microsoft Windows Server de endoflife.date.
Page Microsoft Windows Server de endoflife.date. Source : endoflife.date - Windows Server

Ce second exemple est intéressant puisqu’il permet de voir une information complémentaire (lorsque l’éditeur l'a fourni) : le temps restant jusqu’à la fin du support. Pour un Windows Server 2022, nous savons donc qu’il nous reste encore 6 ans et 8 mois avant de ne plus pouvoir disposer des mises à jour de sécurité de l’éditeur. Cela facilite l’anticipation des fins de vie et la planification des migrations.

La plupart du temps, la page correspondant à un produit va aussi contenir des informations supplémentaires, comme la source d’information (page web du changelog officiel ou équivalent) ou des précisions concernant le modèle de support, voici un exemple, toujours avec la page Microsoft Windows Server :

Détails concernant le modèle de support de Microsoft sur endoflife.date.
Détails concernant le modèle de support de Microsoft sur endoflife.date.

En date d’écriture de cet article, le site endoflife.date contient des informations sur près de 360 produits, ce qui en fait une très bonne source d’information, rapide d’utilisation et fiable.

B. Utilisation de l'API endoflife.date

Si vous souhaitez intégrer ces données dans vos scripts ou tableaux de bord, endoflife.date propose une API REST. Elle permet de récupérer les informations sur les cycles de vie des logiciels de manière automatisée.

Celle-ci est plutôt simple d’utilisation et permet de récupérer des informations directement au format JSON. Nous allons ici voir les 3 points d’entrés existants (l’API est encore en version beta).

Exemple d’appel API pour vérifier le cycle de vie de Zabbix :

# Récupérer l’ensemble des technologies référencées
$ curl https://endoflife.date/api/all.json
["akeneo-pim","alibaba-dragonwell","almalinux","alpine","amazon-cdk","amazon-corretto","amazon-eks","amazon-glue","amazon-linux","amazon-neptune","amazon-rds-mariadb","amazon-rds-mysql","amazon-rds-postgresql","android","angular","angularjs","ansible","ansible-core","antix","apache","apache-activemq","apache-airflow","apache-apisix","apache-camel","apache-cassandra","apache-couchdb","apache-flink","apache-groovy","apache-hadoop","apache-hop",[...]

# Récupérer l’ensemble des cycles d’une techno (zabbix)
$ curl https://endoflife.date/api/zabbix.json                                                                                                                                              
[{"cycle":"7.2","releaseDate":"2024-12-10","eol":"2025-12-31","latest":"7.2.3","latestReleaseDate":"2025-01-28","lts":false,"support":"2025-06-30"},{"cycle":"7.0","lts":true,"releaseDate":"2024-06-04","eol":"2029-06-30","latest":"7.0.9","latestReleaseDate":"2025-01-28","support":"2027-06-30"}[...]

# Récupérer les détails d’une version particulière (zabbix 7.2)
$ curl https://endoflife.date/api/zabbix/7.2.json
{"releaseDate":"2024-12-10","eol":"2025-12-31","latest":"7.2.3","latestReleaseDate":"2025-01-28","lts":false,"support":"2025-06-30"}

Avec cela, il devient envisageable de très facilement automatiser une analyse hebdomadaire des versions de vos services et OS. Notamment pour être averti des éventuelles fin de support à venir. Des langages comme PowerShell, Python ou même bash pourront facilement traiter ce format JSON et faire des requêtes HTTP.

C. Le dépôt Github

Le projet est open source et disponible sur GitHub. Il fonctionne grâce à des contributions de la communauté. Plus de 100 contributeurs enrichissent régulièrement la base de données avec de nouvelles applications et versions.

Cela vous permet donc, si vous souhaitez travailler avec ce contenu plus profondément, récupérer toutes les informations pour ensuite les traiter en local :

Tous les fichiers JSON contenant les détails techniques de chaque technologie sont présents ici.

Attention toutefois, une fois ces données récupérées en local, elles ne seront plus mises à jour, ce qui perd un peu de son intérêt.

III. Un composant de mon SI est obsolète, que faire ?

Profitons de cet article pour rappeler ce qu’il est recommandé de faire lorsqu’un composant de votre SI est ou va bientôt devenir obsolète.

La première recommandation est bien sûr de mettre à jour ce composant vers une version supérieure, qui sera, elle, encore maintenue. Pour être plus complet, on peut s’aider de la directive n°34 du guide d’hygiène de l’ANSSI : Définir une politique de mise à jour des composants du système d’information :

Extrait du guide d’hygiène de l’ANSSI - directive n°34

Il faut néanmoins garder en tête que les mises à jour majeures sont souvent synonymes de breaking change, c'est-à-dire d’incompatibilités ou de changement dans le fonctionnement qui nécessitent des tests et adaptations.

Cette directive nous mène tout droit au deuxième point : l’isolation. Les composants qui ne peuvent être mis à jour, souvent pour des raisons métier, parfois de budget, doivent être isolés, entre eux, et du reste du système d’information. Ils doivent être considérés comme non sécurisés, potentiellement déjà infectés et l’objectif va alors être de réduire la surface d’attaque à laquelle ils sont accès au niveau de notre système d’information : 

Cette isolation, système et réseau, doit passer par le positionnement dans un VLAN ou sous-réseau dédié, une restriction au strict minimum des connexions réseau autorisées (entrantes comme sortantes), la limitation des données accessibles, l’utilisation de secrets d’authentification dédiés, etc. Il est aussi recommandé de mettre en place une surveillance accrue de ces composants et d’ajouter des mesures de sécurité complémentaires (pare-feu applicatif, sonde réseau, etc.) pour détecter toute activité anormale.

Toujours concernant le guide d’hygiène de l’ANSSI, sa directive n°35 concerne justement l’anticipation de l’obsolescence des logiciels et systèmes : 

Extrait du guide d’hygiène de l’ANSSI - directive n°35

Pour plus de détails, je vous invite à consulter ce guide : 

Plus globalement, il est recommandé de maintenir aussi fréquemment que possible les composants de votre SI à jour. Il s’agit là des systèmes d’exploitations et applications installées dessus, mais également des frameworks, des modules et bibliothèques tierces, des équipements réseau, etc.

IV. Conclusion

Grâce à endoflife.date, le suivi des versions et des dates d’obsolescence des logiciels devient plus simple et accessible. Via l’accès à son site web, son API ou son dépôt GitHub, ce projet permet de plus facilement anticiper les mises à jour et d’éviter les risques liés aux composants obsolètes.

N’hésitez pas à partager avec nous dans les commentaires votre retour d’expérience concernant l’utilisation de cette source d’information pour améliorer la sécurité et la stabilité de votre système d’information.

author avatar
Mickael Dorigny Co-founder
Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense.
Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Envoyer par mail

1 commentaire sur “Anticipez l’obsolescence de vos logiciels avec endoflife.date

  • Bonjour
    Merci pour cet article intéressant. Sait on si enoflife indique aussi les mises à jour possibles dans le cas de dépendances d’un logiciel à un autre?

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.