Cycle de vie : les fins de support de vos composants
Mis à jour le
Une échéance, pas une faille
Une faille est un défaut connu qu’un correctif répare. Une fin de support est une date : passé ce jour, l’éditeur ne publie plus de correctif de sécurité. Les failles à venir ne seront donc plus corrigées. C’est grave, mais ça se planifie : une montée de version majeure ne se fait pas dans l’heure.
StatHall suit les deux sur deux échelles séparées. Une fin de support n’est jamais une alerte critique : elle ne compte pas sur la pastille de l’icône du téléphone, et elle ne vous réveille pas la nuit.
Ce qui est daté
| Composant | D’où vient la version |
|---|---|
| Distribution (Debian, Ubuntu, RHEL, Alpine…) | l’agent StatHall |
| Paquets d’un dépôt tiers (PostgreSQL du dépôt PGDG, Node.js de NodeSource, PHP de sury, Docker…) | l’inventaire de l’agent, avec l’origine de chaque paquet (agent 1.3.16 ou plus) |
Images Docker en service (postgres:13, node:20, redis:7…) | la photo des conteneurs prise par l’agent |
| Langage et framework d’une image construite sur votre machine (PHP, Node.js, Python, Go, Ruby ; Laravel, Symfony, Drupal, CakePHP) | la photo des conteneurs : la version du langage héritée de l’image de base, et le composer.lock du dossier de travail du conteneur (agent 1.3.19 ou plus) |
| Frameworks et bibliothèques (Django, React, Angular, Spring…) | les SBOM poussées par votre CI |
| Exigences des stores (targetSdk Google Play, SDK iOS) | la configuration de l’application, à renseigner |
| Agent StatHall | la version rapportée par l’agent |
| Base d’un projet Supabase | le connecteur Supabase |
Les dates viennent du calendrier public endoflife.date, synchronisé chaque jour. Le cockpit télécharge le calendrier entier : aucune information sur votre parc ne lui est envoyée.
Pourquoi un paquet de la distribution n’est pas daté
Un paquet fourni par votre distribution suit la distribution. Debian corrige
son python3 jusqu’à la fin de Debian, même quand python.org a abandonné cette
version. Seul un paquet venu d’un dépôt tiers suit le calendrier de son éditeur.
Le support étendu
Si un support étendu est actif (Ubuntu Pro ESM, Debian ELTS), l’échéance de la distribution devient celle du support étendu. StatHall le détecte à l’origine des paquets installés, sans rien configurer.
Les niveaux de la puce
| Niveau | Quand | Alerte |
|---|---|---|
| Supporté | échéance lointaine, ou pas encore annoncée | — |
| Fin annoncée | moins de 12 mois (distribution, base) ou 6 mois (le reste) | — |
| À planifier | moins de 6 mois (distribution, base) ou 3 mois | P2 |
| Imminent | moins de 3 mois (distribution, base) ou 1 mois | P2 |
| Hors support | échéance passée depuis moins de 6 mois | P1 |
| Hors support de longue date | de 6 à 18 mois après | P1 |
| Abandonné | plus de 18 mois après | P1 |
| Non couvert | date inconnue | — |
Une migration de distribution ou de base de données se prépare plus tôt qu’une montée de bibliothèque : c’est pourquoi les seuils d’avant l’échéance sont plus larges pour elles.
Non couvert veut dire que StatHall ne sait pas dater le composant : une image construite sur votre machine dont rien ne dit ce qu’elle contient, un produit sans calendrier public, une version illisible, ou des exigences de store pas encore renseignées. Ce n’est jamais présenté comme « à jour » : une cible dont un composant n’est pas couvert voit son score de santé plafonné à 90, et la carte dit lequel.
Où la voir
- Liste des cibles, vue d’ensemble, en-tête d’une cible : la puce donne le composant le plus en retard.
- Onglet Sécurité d’un serveur : la section « Cycle de vie » liste tous ses composants, datés ou non.
- Écran Cycle de vie : toutes les échéances du parc, triées par gravité puis par date, filtrables par niveau et par origine.
- Boîte de réception : une seule alerte « Fin de support » par cible, qui nomme le composant le plus en retard et liste les autres.
- Téléphone : la même puce sur vos cibles, et le même écran Cycle de vie.
Les notifications
L’alerte s’ouvre en P2 quand une échéance approche, et passe en P1 le jour où un composant sort du support. C’est à ce moment qu’elle vous notifie. Un passage d’un niveau à l’autre à l’intérieur de la même gravité n’envoie rien : la puce et la boîte de réception suffisent.
Si vous prenez l’alerte en charge (« Je m’en occupe ») ou la fermez, elle reste fermée jusqu’au prochain changement de niveau : pas de rappel quotidien pour un chantier que vous connaissez. Dès que le composant est monté de version, l’alerte se ferme d’elle-même.
Les applications : exigences des stores
Google Play refuse une mise à jour dont le targetSdk est trop ancien. L’App Store refuse un binaire construit avec un SDK iOS dépassé. Aucune de leurs API ne donne ces valeurs : renseignez-les dans la configuration de l’application, onglet Général (la carte « Support » de son tableau de bord y mène quand elles manquent). StatHall vous prévient avant l’échéance publiée par chaque store.