Vérifier le cycle de vie du support d'un système d'exploitation avant d'automatiser des opérations sur celui-ci

Objectif

Avant qu'un agent n'automatise l'application de correctifs, des mises à niveau ou un contrôle de conformité sur un hôte, il doit confirmer que la version du système d'exploitation de cet hôte se trouve encore dans la période de support de l'éditeur, et le signaler clairement dans le cas contraire.

Prérequis

Pouvoir identifier le système d'exploitation et sa version (voir l'article complémentaire sur la détection de l'OS depuis un script) et disposer d'un accès réseau à la page de cycle de vie publiée par l'éditeur, ou d'une copie locale en cache des dates concernées.

Étapes

1. Identifier d'abord la famille du système d'exploitation et sa version ou release exacte (nom de la distribution, version majeure et, pour les systèmes qui suivent les point releases, la version mineure également).
2. Prendre comme source primaire la déclaration de cycle de vie de l'éditeur lui-même, et non celle d'un tiers :
   • RHEL : la page de Red Hat sur la politique de support des mises à jour de paquets et des errata décrit les phases de chaque version majeure et leur durée.
   • Ubuntu : la page du cycle de publication d'Ubuntu distingue les versions standard (9 mois) des versions LTS (5 ans de support standard, prolongeable).
   • Debian : la page des versions stable indique quelle version est la version courante et à partir de quand une version cesse de recevoir des mises à jour ; le projet distinct Debian LTS prolonge le support de sécurité pour certaines architectures.
   • Windows / Windows Server : le site Microsoft Lifecycle Policy donne les dates des cycles de vie fixe et moderne, par produit et par canal de maintenance.
   • AIX : les pages de support d'IBM publient les dates du cycle de vie de support des Technology Levels (TL) d'AIX.
   • FreeBSD : la page Security Information indique quelles branches reçoivent actuellement des correctifs de sécurité.
   • macOS : Apple ne publie pas de calendrier de fin de vie fixe ; en pratique, Apple fournit généralement des mises à jour de sécurité pour la version courante et les deux précédentes — les deux plus anciennes ne recevant souvent qu'une partie des correctifs. Ce suivi est assuré par des agrégateurs tiers tels que endoflife.date, et non par un calendrier officiel.
3. Comparer la version de l'hôte aux dates trouvées ; considérer « impossible à déterminer, aucune date publiée trouvée » comme équivalent à « à signaler pour examen », et non comme « supposé pris en charge ».
4. Consigner la date de la vérification, la source consultée et le statut obtenu (pris en charge / fin de vie proche / fin de vie dépassée) dans la fiche d'inventaire de l'hôte.
5. Pour un hôte dont la fin de vie est dépassée, empêcher les workflows automatisés de correctifs ou de conformité de le déclarer en bon état ; le faire apparaître plutôt comme un constat nécessitant une décision (mettre à niveau, remplacer ou accepter un risque documenté).

Résultat attendu

Chaque hôte concerné dispose d'un statut de cycle de vie enregistré, daté et rattaché à une source nommée ; les hôtes dont la fin de vie est dépassée sont signalés de façon visible au lieu d'être inclus silencieusement dans des synthèses « tout est corrigé ».

Limites et base de vérification

Les pages de cycle de vie des éditeurs évoluent ; une date mise en cache doit être revérifiée périodiquement et non considérée comme définitive. L'absence de politique de fin de vie publiée chez Apple signifie que le statut d'un macOS relève nécessairement de l'inférence et non d'un fait documenté, et doit être présenté comme tel dans tout rapport. Cette méthodologie ne détermine pas si un hôte en fin de vie fait actuellement l'objet d'une exploitation : elle établit seulement qu'il ne recevra plus de correctifs, ce qui est une question distincte et préalable que l'automatisation ne doit pas escamoter.