Vous allez me dire : "il y a vraiment besoin d'un mot pour ça ? Il y a des mises à jour, on les applique et c'est réglé. Gestion c'est peut être un peu grandiloquent pour décrire ça non ?".
Tendre naïveté. La gestion des mises à jour ...

C'est en fait un des sujets les plus critiques et les plus difficile à traiter.

En fait, une mise à jour publiée par un éditeur ne sert pas uniquement à corriger des vulnérabilités.
Le but premier est généralement de fournir de nouvelles fonctionnalités ou bien d'améliorer les fonctionnalités existantes. Le but secondaire est de corriger les bugs (et certains de ces bugs sont des vulnérabilités).

Le contenu d'une mise à jour est généralement décrit dans ce que l'on nomme un « changelog ».
Voici par exemple le changelog de la version 2.4.62 du logiciel Apache :

On peut y voir que deux vulnérabilités ont été corrigées (CVE-2024-40725 et CVE-2024-40898), 4 bugs ont été corrigés (là où il y a marqué Fix ... et Avoid ...) et 2 fonctionnalités mineures ont été ajoutées.

Le problème est qu'en installant une mise à jour pour corriger une vulnérabilité, vous installez aussi tout le reste qu'il y a dans la mise à jour, dont des modifications de fonctionnalités. Et si votre outil ne fonctionne plus exactement comme avant, cela peut entraîner des « régressions », aussi appelées des « ruptures fonctionnelles » (il ne délivre plus le service attendu comme souhaité). C'est notamment très fréquent lorsque cet outil s'interface avec d'autres et qu'il y a un changement dans le format de ce qu'il communique.
Par exemple, si votre outil inscrivait les dates au format 20/12/25 et que, dans la dernière mise à jour, l'éditeur a fait un changement pour que maintenant ce soit 20/12/2025 ... vous pourriez avoir un bug car l'outil qui utilise ces dates était configuré pour lire 8 caractères (donc si on lui donne 20/12/2025 il ne lira que 20/12/20 et pensera qu'il s'agit d'une date en 2020).

Donc, dans une entreprise, appliquer aveuglément les mises à jour des éditeurs c'est être à peu près sûr que plus rien ne marche comme prévu d'ici 1 ou 2 ans.
Alors comment fait-on ?
L'approche la plus commune est d'appliquer les mises à jour sur un échantillon du parc informatique seulement (20 machines par exemple), d'observer le comportement quelques jours/semaines, et si rien n'a l'air de bugger, on applique la mise à jour partout.
Dans les entreprises les plus grosses, on dédie même des machines uniquement au fait de tester que les mises à jour n'entraînent pas de bug. Ces machines sont appelées un « environnement de pré-production »(stagging en anglais). Et on n'attend pas passivement de voir s'il y a des bugs, on reteste activement toutes les fonctions pour s'assurer qu'elles marchent comme prévu (on nomme ceci des « tests de non-régression »).

Le problème que cela engendre est que si l'équipe informatique n'a pas assez de temps pour tester les mises à jour, elle préfèrera souvent de rien installer du tout, plutôt qu'installer aveuglément (c'est-à-dire sans certitude qu'il n'y aura pas de régressions).
D'où le nombre stratosphérique d'entreprises où 90% du parc n'est pas à jour et où il est donc assez facile pour un pirate de pénétrer car il y a plein vulnérabilités connues.