我们的组织要求我们在将 Docker 镜像部署到生产环境之前，修补所有高危/严重漏洞。目前我们基于 discourse/base:2.0.20251008-0017-web-only 构建的 discourse 存在一些漏洞，我们正在尝试修复它们。以下是我们需要的漏洞列表。
vuln-report-opencves.txt (2.3 KB)
您能否就盲目更新这些漏洞到已修复这些漏洞的版本是否会导致任何问题提供指导？如果会，我们如何才能发现升级是否会导致问题？
另外，我注意到有很多与 golang 相关的漏洞。Discourse 在运行时是否以任何方式使用 golang，或者我们是否可以完全将其从最终镜像中删除？Python 也是如此。
我认为你可以试试看会发生什么。很多人全职负责管理安全和库版本。
但等等。如果你查看的是基础 Docker 镜像（哦，也许你确实是指你构建的镜像；我不太确定），那么我认为你的工作是不可能的，因为其中很多东西都是在 Discourse 源代码中管理的。例如，这个提交将 Rack 升级到了 2.2.20。基础 Docker 镜像中的版本无关紧要。你可能想使用 launcher 构建你的镜像，然后查看你拥有哪些版本的软件。然后你可以添加一些 yaml 来移除 go 和 python 等。
此外，还有很多安全问题只有在系统中有其他用户时才是问题，因此在 Docker 容器中拥有这些问题并不重要，所以这不太可能是 Discourse 团队的优先事项。
抱歉，我之前没有说清楚。
我们当前的构建过程以先前消息中提到的 discourse 基础镜像开始，然后运行一个脚本，该脚本只是支持的安装过程（启动器脚本）的引导程序步骤，但没有运行需要活动 redis/db 连接的步骤。
因此，我假设引导程序步骤会安装 discourse 的所有 ruby 依赖项和 npm 依赖项。漏洞列表中显示的许多版本主要是 discourse 应用程序本身的依赖项。
我还进行了一些挖掘，发现它标记的 golang 依赖项来自一个名为 esbuild 的 npm 依赖项，该依赖项是使用 golang 构建的。它使用的 go 版本有一个标准库漏洞，该漏洞正在被标记。因此，我认为解决这个问题需要重新编译该库，所以我也不确定这是否值得付出努力。
但是，其他漏洞要么是直接的 ruby/npm 依赖项，要么是 discourse 的传递依赖项。我的问题主要是关于在安装这些依赖项之前更新它们的版本。我明白修复这些问题对于 discourse 的开发者来说会很困难。我只是想了解是否有办法检查“升级”是否会导致问题，因为我猜测某些依赖项实际上只在某些代码路径中引起问题。