Maintenir le logiciel pendant toute sa durée d’utilisation

Attribuer la maintenance à un responsable de service

Un logiciel utile continue de changer après sa première livraison. Les dépendances reçoivent des correctifs. Les environnements d’exécution perdent leur support. Les certificats expirent. Les règles métier changent. Les accès accordés pendant la configuration peuvent durer plus longtemps que prévu.

Tenez un inventaire des services, des responsables, des versions déployées, des dépendances et des dates de support. Incluez le travail planifié et celui déclenché par un nouveau problème. Réservez de la capacité pour les deux. Un backlog de maintenance sans responsable ne protège pas le service.

Séparez la maintenance de la réponse immédiate aux incidents. Un identifiant exposé ou des preuves de compromission active peuvent exiger un confinement avant la fin d’un cycle de développement normal. Orientez ces cas vers la procédure de réponse de sécurité.

Prioriser l’exposition réelle

La gravité décrit les conséquences possibles. La priorité dépend aussi de l’exploitation effective, de la possibilité d’atteindre le code vulnérable, des données, des contrôles existants et du coût du délai. Un service interne peu utilisé peut malgré tout détenir des identifiants importants.

Le catalogue Known Exploited Vulnerabilities de la CISA répertorie les vulnérabilités dont l’exploitation est étayée par des preuves. Utilisez-le pour prioriser. L’absence d’une vulnérabilité dans ce catalogue ne prouve pas son innocuité. Catalogue CISA.

Considérez ces problèmes fictifs. Les délais appartiennent à l’organisation de l’exemple ; ce ne sont pas des échéances universelles.

Ne transformez pas automatiquement chaque problème en mise à niveau majeure. Choisissez une correction prise en charge, examinez la compatibilité et testez le comportement important. Consignez les atténuations temporaires avec un responsable et une condition d’expiration.

Suivre la correction jusqu’en production

Utilisez une séquence traçable : problème, décision, modification, revue, déploiement et vérification. Consignez l’identifiant de l’artefact réellement utilisé en production. Analysez de nouveau l’artefact ou l’environnement pertinent après le changement.

Pour un package PDF vulnérable fictif, l’équipe merge une mise à niveau à 10:00. À 11:00, la production utilise encore l’image d’hier. La correction du dépôt est terminée. La remédiation en production ne l’est pas.

Après le déploiement, vérifiez à la fois la version du package et la génération de PDF. Une analyse de vulnérabilités ne prouve pas que l’export fonctionne encore. Un test fonctionnel ne prouve pas que le composant vulnérable a été retiré.

Le SSDF du NIST inclut l’identification continue des vulnérabilités et la réponse associée. Appliquez ces pratiques sur tout le cycle de vie, y compris aux logiciels qui reçoivent peu de demandes de fonctionnalités. NIST SSDF.

Automatiser avec des limites visibles

Taiga Maintaining analyse les dépôts liés et peut transformer les problèmes détectés en initiatives de remédiation. Vérifiez la dernière analyse réussie, la version touchée et la modification produite. L’analyse du dépôt ne permet pas de déterminer si le code vulnérable est atteignable en production. Maintaining.

L’automatisation peut réduire le travail répété, mais le service a toujours besoin d’un responsable du déploiement et de vérifications. Gardez explicites les décisions de livraison, les accès d’urgence et l’expiration des exceptions.

La maintenance comprend aussi le retrait. Supprimez les routes, identifiants, intégrations et infrastructures inutilisés par une procédure contrôlée. Vérifiez les exigences de conservation et les services dépendants avant la suppression. Retirez le service en cours d’exécution et attribuez les obligations restantes de conservation ou d’audit.

La leçon suivante détaille l’analyse continue des vulnérabilités et leur remédiation.