As vulnerabilidades detectadas em confirmações antigas devem ser corrigidas?

Um dos meus projetos no GitHub recebeu um alerta de vulnerabilidade, neste caso de gravidade moderada.

A vulnerabilidade foi detectada na dependência de uma versão antiga do código. As versões atuais não usam mais essa dependência. No entanto, confirmações antigas podem potencialmente ser retiradas e executadas e abrir o aplicativo para explorações da vulnerabilidade.

Do ponto de vista da engenharia de software, é aconselhável voltar e alterar as confirmações antigas, ou seja, atualizar a dependência agora não utilizada para uma versão mais recente que contém a correção da vulnerabilidade? Ou melhor, para manter intacto o histórico de confirmação?

Eu vejo duas opções viáveis ​​aqui.

Primeiro, libere uma versão de patch da versão problemática. Por exemplo, se a versão problemática for a versão 3.3 e você estiver na versão 5.1, poderá lançar um 3.3.1 que resolva a vulnerabilidade. Isso permitiria que os usuários que não podem atualizar para as principais versões (por várias razões) obtenham a correção da vulnerabilidade.

Segundo, não faça nada. É uma versão antiga do software e você tem versões mais novas que não possuem a vulnerabilidade. Os usuários que se preocupam com a segurança devem estar executando uma versão mais recente.

Qual opção é a melhor? Depende. No entanto, voltar e revisar confirmações antigas (reescrever o histórico) não faz muito sentido. E para alguns usuários (especialmente em um ambiente regulamentado) teria muitos problemas com isso. Para uso generalizado do seu software, o histórico de reescrições deve ser evitado.

Considerar:

• Quão grave é a vulnerabilidade?
• Quão difundida é a versão da vulnerabilidade?
• Você tem a capacidade de continuar a oferecer suporte a versões antigas - você gerenciará isso como um precedente?

Normalmente, um sistema de controle de versão é usado para registrar o histórico; forneça uma visão precisa do estado do código em um determinado momento. O resultado do check-out e da construção de uma versão antiga deve ser essa versão, bugs e tudo. Alguns sistemas fornecem construções reproduzíveis : deve ser possível gerar um binário exatamente idêntico a uma construção antiga.

A maioria dos sistemas de controle de versão não permite reescrever o histórico, exceto em circunstâncias extremas, como apagar informações que podem causar responsabilidades se registradas. É incomum e um pouco "herético" que o git permita que você faça isso.

A documentação admite que há riscos de reescrever o histórico .

Além disso, é um sistema de controle de versão distribuído - reescrevê-lo não afeta nenhum repositório já clonado!

Eu sugeriria nunca fazer isso, a menos que seja para remover algo que foi recentemente confirmado que deveria ter sido mantido em sigilo - dados pessoais, chaves de criptografia, esse tipo de coisa.

Parece que até a resposta atualmente aceita realmente não aborda a parte da sua pergunta, como evitar que alguém acesse acidentalmente um commit antigo, use esse estado mais antigo da base de código em uma nova ramificação e introduza uma vulnerabilidade antiga novamente.

IMHO a única maneira certa de abordar isso é:

• documentando as correções de erros e as vulnerabilidades rigidamente no documento "notas de versão" (ou "log de alterações") do sistema

• certificando-se de que todos os desenvolvedores que acessam versões mais antigas do código leiam as notas de versão, verifique quais problemas foram resolvidos na versão do código que veio depois da versão que eles usarão

Ao reutilizar uma versão mais antiga ou ramificar de uma versão mais antiga da base de código, é claramente a responsabilidade dos desenvolvedores não fazer isso cegamente. É claro que eles devem checar os bugs e vulnerabilidades já corrigidos, para não apresentá-los novamente. O registro VCS, no entanto, não é realmente um bom lugar para encontrar esse tipo de informação, porque geralmente existem todos os tipos de alterações mencionados, em um nível de abstração muito baixo.

As notas de versão, no entanto, devem conter uma seção "novos recursos" e uma seção "problemas resolvidos". E o último deve ser o primeiro local a verificar antes de ramificar de uma versão mais antiga.

Digamos que 3.5 esteja vulnerável, mas 3.6 não. Você pode produzir 3.5.1 sem a vulnerabilidade. Mas isso é trabalho e não é muito útil, porque as pessoas atualizam sua versão ou não, por isso é improvável que alguém use o 3.5.1.