Sorry for being unclear.
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.