Automatiser la détection des fins de vie à partir des SBOM, des images de conteneurs et des inventaires logiciels

Objectif

État au 25 octobre 2026 : ce protocole proposé détecte de manière récurrente les risques liés au cycle de vie dans un parc, y compris pour les environnements d'exécution applicatifs, les paquets des distributions et le contenu des conteneurs. Il produit une file d'actions correctives attribuées à des responsables et une file distincte pour les preuves incertaines. Vérifier de nouveau le schéma de l'API, les pages de cycle de vie des fournisseurs et les droits de support locaux à chaque actualisation des preuves. Aucun déploiement réussi ni aucune mesure de détection n'est revendiqué.

Prérequis

Utiliser un inventaire des actifs dont l'accès est autorisé, les relevés de déploiement, les identifiants d'images, les nomenclatures logicielles disponibles et des responsables capables de confirmer les dispositifs de support. Définir l'ancienneté acceptable de l'inventaire, la fréquence d'actualisation des sources, le délai nécessaire à la migration et un circuit d'escalade. Conserver avec les décisions les URL des fournisseurs, les dates et heures de récupération et les éventuelles dates de révision publiées.

Le projet endoflife.date documente sa propre API ; il agrège les cycles de vie d'autres produits. Utiliser son flux comme source de repérage, le fournisseur restant la référence pour les décisions relatives aux échéances. Son schéma distingue la fin du support actif, la fin de vie et la fin du support étendu. Définition de l'API.

Étapes

1. Collecter les versions observées dans les charges de travail déployées et les associer à un responsable et à un identifiant de déploiement. Inclure les modèles inactifs et les étapes de construction. Pour chaque composant, conserver l'écosystème, le produit, l'édition, la branche de version, le distributeur et l'origine du paquet. Exiger un examen manuel des noms ambigus au lieu d'établir une correspondance à partir de la seule chaîne de version.
2. Associer chaque empreinte d'image déployée à sa SBOM et aux informations de provenance de son image de base. Là où Docker Scout est déjà disponible, docker scout sbom --format spdx local://IMAGE génère une SBOM à partir d'une image locale ; remplacer IMAGE par la référence de l'image locale visée. Consigner la plateforme analysée et l'empreinte. Ne pas analyser sans le signaler la dernière image construite, quelle qu'elle soit. Commande SBOM.
3. Associer les composants à des identifiants de produit et de cycle de version préalablement examinés. Interroger le point de terminaison documenté /api/v1/products/{product} ou son point de terminaison de cycle de version. Mettre les réponses en cache, respecter les redirections et gérer les limites de débit. Conserver isEol, eolFrom, eoasFrom et eoesFrom lorsqu'ils sont fournis. Une valeur nulle de eolFrom signifie que la date est inconnue ; l'absence de champs de support étendu peut signifier que cette phase ne s'applique pas. Aucune de ces situations n'accorde un support indéfini.
4. Confirmer les échéances déterminantes sur les pages des fournisseurs et consigner la phase de support et les droits applicables. Séparer les décisions du projet amont de celles du distributeur. Le cycle de vie d'Ubuntu distingue la maintenance standard des paquets Main de la couverture liée à un abonnement et des autres catégories de paquets ; ne pas déduire une couverture identique pour tous les paquets du seul nom du système d'exploitation. Couverture de la distribution.
5. Évaluer séparément le cycle de vie et l'actualité de l'image. La politique de Docker concernant les images de base obsolètes compare l'empreinte actuelle de l'étiquette de base à celle utilisée pour construire l'image et exige des informations de provenance. Une comparaison réussie n'établit pas que la version sous-jacente est encore prise en charge. Conserver explicitement un état inconnu lorsque les preuves de cycle de vie, la correspondance des paquets ou la provenance font défaut. Sémantique des politiques d'image.
6. Définir les seuils d'alerte à partir du travail nécessaire : lancer la migration lorsque le temps restant est inférieur ou égal au délai de migration convenu, augmenté de la marge prévue pour l'approbation et la reprise. Déclencher une escalade lorsqu'il ne reste que la fenêtre de bascule et de reprise testée en répétition ; signaler immédiatement toute couverture expirée. Il s'agit de propositions de règles de politique locale, pas d'échéances de fournisseurs. Dédupliquer les alertes par responsable et composant, et faire expirer automatiquement les exceptions pour qu'elles soient réexaminées.
7. Tester le processus de décision avec des cas de versions prises en charge, de support expiré ou inconnu, de flux de données périmé et de support étendu documenté. Inclure une image dont l'empreinte est à jour mais dont la version n'est plus prise en charge. Actualiser à la fois l'observation de l'actif et les preuves de cycle de vie avant de clore un constat après correction.

Résultat attendu

Chaque constat identifie la charge de travail concernée, le composant, la phase de support, les preuves du fournisseur, le responsable et l'action suivante. Les données manquantes restent visibles au lieu d'être comptabilisées comme une prise en charge confirmée.

Limites et base de vérification

Une SBOM ne peut pas, à elle seule, prouver une couverture contractuelle ni rendre compte de toutes les modifications effectuées en cours d'exécution. Il s'agit d'une synthèse d'interfaces documentées et d'une proposition de protocole d'évaluation ; ses tests sont des critères de recette, pas des résultats rapportés. La surveillance du cycle de vie complète la détection des vulnérabilités et des compromissions sans établir elle-même l'un ou l'autre de ces constats.