Chaque version que vous exécutez, et jusqu’à quand elle est corrigée
Chaque version que vos sites clients exécutent, chaque version qu’ils publient, et combien de temps chacune reçoit encore des correctifs de sécurité.
Demandez à une agence lesquels de ses sites clients tournent encore sur un PHP supporté et vous obtiendrez un silence, puis une estimation, puis quelqu’un qui ouvre les serveurs un par un. L’information existe. Elle est simplement répartie sur onze comptes d’hébergement et n’est le travail de personne.
L’espace Versions d’Unolia y répond en un seul endroit.
Il suit ce qu’un projet exécute, relevé sur les sites eux-mêmes, et ce qu’un projet publie, lu dans ses propres releases et tags. L’historique des dépendances sort de vos fichiers de verrouillage, parcourus commit par commit dans le dépôt plutôt qu’échantillonnés au sommet, sur GitHub comme sur GitLab. Cela se produit dès qu’un compte git est connecté, donc un projet a sa chronologie avant que quiconque pense à pousser.
Unolia synchronise ensuite chaque jour les fenêtres de support publiées pour PHP, Laravel, Symfony et les autres depuis endoflife.date, et chaque version se lit de trois façons : support actif, correctifs de sécurité seulement, ou fin de vie dépassée. Une version morte arrive avec la date où c’est arrivé et les versions encore vivantes vers lesquelles aller. Un cycle a sa propre page, dans les mots de l’éditeur, et l’historique d’un paquet hachure les séries déjà disparues, donc il se lit tout seul.
Un runtime en fin de vie ouvre ensuite un vrai problème sur le projet, donc il arrive dans la liste du matin et dans la vue sécurité à côté des CVE, au lieu de rester un badge sur une page que vous n’ouvrez jamais. Il s’ouvre qu’il y ait eu un déploiement ou non, parce que la synchronisation quotidienne des cycles voit une date passer toute seule, et il se referme quand la version change.
Je gardais un onglet ouvert sur endoflife.date. Maintenant, c’est le projet qui sait.