Notre organisation nous oblige à corriger toutes les vulnérabilités Hautes/Critiques dans nos images Docker avant de pouvoir les déployer en production. Actuellement, notre build de Discourse, qui est basé sur discourse/base:2.0.20251008-0017-web-only, en a quelques-unes que nous essayons de corriger si possible. Ci-dessous la liste des vulnérabilités que nous devons corriger.
Pourriez-vous me donner des conseils sur la question de savoir si la mise à jour aveugle de certaines de ces versions vers des versions qui ont corrigé ces vulnérabilités pourrait causer des problèmes ? Si oui, comment pouvons-nous savoir si une mise à niveau cause un problème ?
De plus, je remarque qu’il y a beaucoup de vulnérabilités liées à Golang. Discourse utilise-t-il Golang d’une manière ou d’une autre pendant l’exécution, ou pouvons-nous simplement le supprimer complètement de l’image finale ? Il en va de même pour python.
Je pense que vous pourriez simplement essayer et voir ce qui se passe. Un tas de gens ont un emploi à temps plein pour gérer la sécurité et les versions des bibliothèques.
Mais attendez. Si vous regardez l’image Docker de base (oh, peut-être que vous parlez de l’image que vous avez construite ; je ne peux pas vraiment dire), alors je pense que votre travail est impossible, car une grande partie de ces éléments sont gérés dans le code source de Discourse. Par exemple, ce commit met à jour Rack vers 2.2.20. La version de l’image Docker de base n’a pas d’importance. Vous voudrez probablement construire votre image avec launcher, puis voir quelles versions des éléments vous avez. Vous pourriez alors ajouter un fichier yaml pour supprimer go et python, par exemple.
De plus, il y a un tas de problèmes de sécurité qui ne sont des problèmes que lorsqu’il y a d’autres utilisateurs sur le système, donc les avoir dans votre conteneur Docker n’a pas vraiment d’importance, donc ce n’est probablement pas une priorité pour l’équipe Discourse.
Notre processus de build actuel commence par l’image de base discourse mentionnée dans le message précédent, puis exécute un script, qui est simplement l’étape d’amorçage du processus d’installation pris en charge (le script de lancement), mais sans exécuter les étapes qui nécessitent une connexion active à redis/db.
Donc, l’étape d’amorçage, je suppose, installe toutes les dépendances ruby et les dépendances npm de discourse. Les versions qui apparaissent dans la liste des vulnérabilités sont principalement les dépendances de l’application discourse elle-même.
J’ai également fait quelques recherches et découvert que les dépendances golang qu’il identifie proviennent d’une dépendance npm appelée esbuild, qui est construite à l’aide de golang. La version de go qu’elle utilise a une vulnérabilité dans sa bibliothèque standard, qui est identifiée. Je pense donc que résoudre ce problème nécessiterait une recompilation de cette bibliothèque, je ne suis donc pas sûr que cela vaille la peine.
Mais les autres vulnérabilités sont soit des dépendances ruby/npm directes, soit des dépendances transitives de discourse. Ma question portait principalement sur la mise à jour des versions de celles-ci, juste avant de les installer. Je comprends qu’il serait difficile pour les développeurs de discourse de travailler à la correction de celles-ci. J’essayais juste de comprendre s’il existait un moyen de vérifier si la « mise à niveau » provoque un problème ou non, car je suppose que certaines dépendances pourraient en fait ne causer des problèmes que dans certains chemins de code.