Our organization requires us to patch all High/Critical vulnerabilities in our docker images, before we could deploy them to production. Currently our build of discourse, which is based on discourse/base:2.0.20251008-0017-web-only, has a few of them which we are trying to patch if possible. Below is the list of vulnerabilities we need to patch.
Could you give me any guidance on whether updating any of these blindly to versions which have fixed these vulnerabilities, will cause any issues ? If yes, how can we find out if an upgrade is causing an issue ?
Also, I notice that there are lots of golang related vulnerabilities. Does discourse use golang in any way during the runtime, or can we just completely purge it from the final image ? Same goes for python too.
I think you could just give it a try and see what happens. A bunch of people have a full time job of managing security and library versions.
But wait. If you’re looking at the base Docker image (oh, maybe you do mean the image that you built; I can’t quite tell), then I’d think that your job is impossible, since lots of that stuff gets managed in the Discourse source. For example, this commit upgrades Rack to 2.2.20. The version in the base docker image doesn’t matter. You probably want to build your image with launcher and then see what versions of stuff you have. You could then add some yaml to remove go and python, for example.
Also, there are a bunch of security issues that are issues only when there are other users on the system, so having those in your Docker container doesn’t really matter, so it’s not likely to be a priority for the Discourse team.
Our current build process starts with the discourse base image mentioned in the previous message, and then runs a script, which is just the bootstrap step of the supported installation process ( the launcher script ), but without running the steps which require an active redis/db connection.
So the bootstrap step, I assume, installs all the ruby dependencies and the npm dependencies of discourse. The versions which are showing up in the vulnerability list, are the dependencies of the discourse application itself mostly.
I also did some digging and found out that the golang dependencies it is tagging is from a npm dependency called esbuild, which is built using golang. The version of go it uses has a standard library vulnerability, which is getting tagged. So I think solving this would require a recompilation of that library, so I am not sure if it is even worth the effort.
But the other vulnerabilities are either direct ruby/npm dependencies or transitive dependencies of discourse. My question was mainly about updating the versions of those, just before installing them. I understand it would be difficult for developers of discourse to work on fixing those. I was just trying to understand if there was a way to check if the “upgrade” causes an issue or not, as my guess was that some dependencies might actually cause issues only in certain code paths.