Nossa organização exige que corrijamos todas as vulnerabilidades de Alto/Crítico em nossas imagens Docker antes de podermos implantá-las em produção. Atualmente, nossa compilação do Discourse, que é baseada em discourse/base:2.0.20251008-0017-web-only, tem algumas delas que estamos tentando corrigir, se possível. Abaixo está a lista de vulnerabilidades que precisamos corrigir.
Você poderia me dar alguma orientação sobre se atualizar cegamente alguma delas para versões que corrigiram essas vulnerabilidades causará algum problema? Se sim, como podemos descobrir se uma atualização está causando um problema?
Além disso, notei que há muitas vulnerabilidades relacionadas ao Golang. O Discourse usa Golang de alguma forma durante o tempo de execução, ou podemos simplesmente removê-lo completamente da imagem final? O mesmo vale para o python.
Eu acho que você poderia simplesmente tentar e ver o que acontece. Um monte de gente tem um trabalho em tempo integral gerenciando segurança e versões de bibliotecas.
Mas espere. Se você está olhando para a imagem Docker base (ah, talvez você queira dizer a imagem que você construiu; não consigo dizer ao certo), então eu acho que seu trabalho é impossível, já que muitas dessas coisas são gerenciadas no código-fonte do Discourse. Por exemplo, este commit atualiza o Rack para 2.2.20. A versão na imagem Docker base não importa. Você provavelmente quer construir sua imagem com o launcher e então ver quais versões de coisas você tem. Você poderia então adicionar algum yaml para remover go e python, por exemplo.
Além disso, há um monte de problemas de segurança que são problemas apenas quando há outros usuários no sistema, então tê-los em seu contêiner Docker realmente não importa, então não é provável que seja uma prioridade para a equipe do Discourse.
Nosso processo de build atual começa com a imagem base do discourse mencionada na mensagem anterior e, em seguida, executa um script, que é apenas a etapa de bootstrap do processo de instalação suportado (o script do launcher), mas sem executar as etapas que exigem uma conexão ativa com o redis/db.
Portanto, a etapa de bootstrap, presumo, instala todas as dependências ruby e as dependências npm do discourse. As versões que aparecem na lista de vulnerabilidades são, em sua maioria, dependências do próprio aplicativo discourse.
Também investiguei um pouco e descobri que as dependências do golang que ele está marcando vêm de uma dependência npm chamada esbuild, que é construída usando golang. A versão do go que ele usa tem uma vulnerabilidade na biblioteca padrão, que está sendo marcada. Portanto, acho que resolver isso exigiria uma recompilação dessa biblioteca, então não tenho certeza se vale a pena o esforço.
Mas as outras vulnerabilidades são dependências ruby/npm diretas ou dependências transitivas do discourse. Minha pergunta era principalmente sobre a atualização das versões dessas dependências, pouco antes de instalá-las. Entendo que seria difícil para os desenvolvedores do discourse trabalhar na correção delas. Eu estava apenas tentando entender se havia uma maneira de verificar se o “upgrade” causa algum problema ou não, pois minha suposição era que algumas dependências poderiam causar problemas apenas em certos caminhos de código.