Tu ne peux pas t'amuser à tout remettre en chantier à chaque fois qu'une dépendance évolue, sinon ton projet ne sortira jamais.

Certes, mais Rust et Go sont tous les deux, depuis des années, dans une phase où l'utilisation d'une nouvelle release ne remet pas tout en chantier. Et c'est heureux. Les grosses casses de compatibilité seraient pour des versions 2 des langages.

Si Rust et Go veulent percer dans ces milieux, il faudra qu'ils arrivent à être matures et stables, il n'y a pas d'autres solutions.

Peut-être que des entités prendront, pour ces langages, le rôle qu'ont Redhat, SUSE et quelques autres pour les distributions Linux, ou maintenant même Java pour RedHat puisqu'Oracle veut passer à des mises à jour rapides pour Java, comme le dont déjà la plupart des autres langages: figer une release pour un temps certain, en n'y appliquant qu'un sous-ensemble des mises à jour de sécurité. Ca pourrait être une solution pour contenter à peu près à la fois:
* ceux qui veulent et peuvent développer plus rapidement du code qui aura moins de bugs, quitte à traiter des casses de compatibilité antérieures sur des éléments mal faits de la toolchain, de la lib standard ou de certaines dépendances (l'écosystème Go a des soucis avec les modules, ça n'a pas été bien fait au départ, le passage aux modules est apparemment un mauvais moment à passer mais après, ça va plutôt mieux à long terme), et des obsolescences logicielles au fil de l'eau: ils resteront sur les versions à évolution rapide;
* ceux qui veulent rester sur une base qui n'évolue que rarement, avec des releases rares, une faible mise à jour des dépendances, et donc en général un déploiement en rares big bangs coûteux. Les projets avec un certain niveau de criticité seront en général dans cette catégorie, nous sommes d'accord

Sur RHEL 7.5, 7.6 et 7.7, Redhat a fait un travail moins limité que précédemment d'upgrade de packages user-space, pour des raisons à la fois de sécurité et de fonctionnalité. Peu d'upstreams fournissent un support sécurité sur 5 ans, c'est à la fois un principe de réalité (la maintenance des versions anciennes, et le packaging desdites versions, ont un coût, alors que beaucoup de projets et distributions ont déjà du mal à vivre...) et une bonne chose pour inciter à / forcer des upgrades vers des versions développées selon des standards et méthodes plus modernes. Ce travail d'upgrade réduit un peu la dangerosité de l'assemblage RHEL 7.x causée par les toolchains par défaut qui ne changent pas (GCC 4.8, donc absence ou faible diffusion des mitigations un tant soit peu récentes, PIE / relro / bindnow / etc.), les packages qui n'ont pas été mis à jour alors que des versions plus récentes contiennent des mises à jour de sécurité qui ne sont pas toujours clairement labelisées comme telles, la mauvaise car difficile maintenance du fork d'une version vraiment antique du kernel (les travaux de spender indiquent qu'il manque des centaines de patches de sécurité dans tous les kernels LTS, mainline comme vendor), etc..

J'ai l'impression à te lire que si on n'applique pas une politique de sécurité extrême avec des mises à jour aussi souvent que possible, alors c'est qu'on ne fait rien du tout et qu'on court un très gros risque.

Ca dépend sur quoi. Pour certains composants très largement répandus, une surface d'attaque élevée, avec un niveau de privilège élevé, des moyens d'accès à distance et/ou des PoC publics d'attaque, c'est un fait qu'on peut courir de gros risques si on ne fait pas les mises à jour de manière assidue. Pour des packages que presque personne n'utilise, même s'il y a de très gros problèmes, le risque qu'on prend à ne pas faire des mises à jour tout de suite est beaucoup plus faible, bien sûr.

Sur toutes mes machines perso, et la plupart des machines pro que j'administre (la plupart des machines Debian, et encore une fois, en environnement spécial où on est censés faire les mises à jour), unattended-upgrades est installé. Mes machines perso, et une machine pro, utilisent Debian sid, parce que dans les Debian, c'est ça qui permet d'avoir accès à des versions plus récentes qui ont en moyenne moins de vulnérabilités, à davantage de mitigations, etc. Il n'y a pas de support sécurité sur testing, et le support sécurité de stable - comme celui de toutes les distributions stables - laisse à désirer.
Ce n'est pas parce que les diverses équipes sécurité font mal leur travail que les distributions stables ont un support de sécurité loin d'être parfait. C'est parce qu'ils n'ont pas assez de moyens et que les informations dont ces équipes disposent sont très partielles: beaucoup de mises à jour de sécurité, y compris pour des packages largement utilisés, ne sont pas annoncées comme telles, pour quantité de raisons (à une époque, difficulté d'obtenir des assignations de CVE IDs; difficulté de se rendre compte que certains changements sont des mises à jour de sécurité; autre chose à faire que de détailler les problèmes et corrections; volonté de cacher les problèmes de sécurité; j'en passe). Même pour des packages populaires, presque toutes les mises à jour de sécurité issues de mes jobs de fuzzing ont été assez silencieuses, sans CVE IDs, donc elles ont été peu backportées vers les distros stables. Il y avait probablement peu d'ACE dans le lot, c'est vrai, mais énormément de DoS.