Au sein de nos data center nous n’effectuons jamais de mise à jour automatique, c’est la porte ouverte à n’importe quoi, y compris avec les dépôts de sécurité.
De façon personnel par contre je me casse moins la tête il est vrai, mais en environnement entreprise (surtout dans le monde de l’infogérance) le contrôle maximale des paquets et de la sécurité est primordiale.
Autant c’est extrêmement rare de voir un patch foireux chez Debian, autant c’est déjà arrivé un nombre de fois incroyable sur des produits proprio.
La sécurité informatique est une spécialité à part entière tout la gestion des base de donnée ou la gestion des stockage de donnée ou la sauvegarde.
Par contre je plussoie sur le fait que debscan n’est clairement pas l’outil ultime sur lequel se reposer, mais rudement pratique pour dégrossir le travail lorsque l’on n’a pas la possibilité de profiter de serveur de scanne de sécurité comme peuvent offrir OpenVAS et Lynis (pour ceux que je connais).
Il existe des scanners de sécurité assez spécialisé comme pour les Wordpress, attention tout de même à la pertinence des failles relevés, en bref c’est tout un métier 
Un paquet qui peux être utile dans le cas de déploiement de mise à jour est checkrestart, qui permettra aussi de tester l’utilité d’un redémarrage d’un service afin de prendre en compte la mise à jour déployé … la mise à jour de OpenSSL ou de la libC requiert parfois de redémarrer des services pas évident à deviner lorsque l’on n’a pas le nez régulièrement dedans par exemple.
Enfin car beaucoup de monde utilise du MySQL ou affiliée, l’utilisation régulière de MySQLtunner, permet de relever des problèmes d’optimisation et de sécurité dans de rare cas (qui oserai de nos jours ne pas protéger un utilisateur MySQL avec un mot de passe).
En dernier lieu pour une sécurité maximum, le cloisonnement et le durcissement d’une Debian est parfois une nécessité.
Ce ne sont que des pistes à explorer pour compléter debsecan …
