Remediação de CVE: do aviso de segurança a um build corrigido e distribuído

O processo de remediação de CVE

A remediação de CVE remove uma vulnerabilidade divulgada publicamente do software que executa ou distribui. No seu próprio código, isso significa um patch. Nas dependências open source, de onde vem a maioria das CVE num produto típico, significa chegar a uma versão em que a vulnerabilidade esteja corrigida. Em qualquer dos casos, os passos são os mesmos:

1. Encontrar todos os produtos, builds e versões que contêm o pacote e a versão afetados.
2. Avaliar se a vulnerabilidade o afeta e com que gravidade.
3. Priorizar face a tudo o resto que está em aberto.
4. Corrigir atualizando, aplicando um patch, substituindo ou, se não existir correção, mitigando.
5. Verificar que a versão corrigida é a que o novo build realmente contém.
6. Registar o que foi afetado, o que decidiu e quando a correção foi distribuída.

Passo 1: encontrar todos os builds afetados

A primeira pergunta após um aviso de segurança é onde está o pacote. Responder a partir dos repositórios de código-fonte é lento e muitas vezes errado: a versão num lockfile, a versão resolvida por um build e a versão numa imagem de contentor lançada podem ser todas diferentes. As dependências transitivas e os pacotes que um build descarrega fora do gestor de pacotes nem sequer aparecem nos manifestos.

A resposta fiável vem de uma SBOM de cada versão, comparada continuamente com os avisos de segurança. Se essa SBOM for registada durante o build, enumera o que o build realmente usou, pelo que a correspondência lhe indica que builds distribuídos contêm a versão vulnerável, e não que repositórios a mencionam.

Passo 2: priorizar com gravidade e exploração

A gravidade, por si só, classifica demasiadas vulnerabilidades como urgentes. A maioria das equipas combina três sinais:

Sinal	O que indica	Publicado por
CVSS	A gravidade da vulnerabilidade se for explorada, numa escala de 0 a 10	FIRST (a norma); o NVD e os fornecedores publicam pontuações
EPSS	A probabilidade estimada de exploração nos próximos 30 dias	FIRST
KEV	Se se sabe que a vulnerabilidade está a ser explorada no terreno	Catálogo Known Exploited Vulnerabilities da CISA

Depois, acrescente o seu próprio contexto: se o pacote afetado é distribuído aos clientes ou apenas executado num job de testes, e se a função vulnerável chega a ser usada. Uma vulnerabilidade comprovadamente explorada num pacote distribuído vai para o topo da lista. A priorização de vulnerabilidades transforma estes sinais num método.

Prazos de remediação

• CISA BOD 26-04. Desde 10 de junho de 2026, as agências federais dos EUA definem cada prazo a partir de quatro perguntas: o ativo está exposto publicamente, a vulnerabilidade está no catálogo KEV, a exploração pode ser automatizada e esta dá controlo parcial ou total. As respostas vão de 3 dias, com triagem forense nos piores casos, até à correção na próxima atualização do sistema. Substituiu a BOD 22-01, que dava duas semanas para a maioria das entradas do KEV.
• EU Cyber Resilience Act. Os fabricantes têm de tratar e corrigir vulnerabilidades sem demora, nomeadamente através de atualizações de segurança (Anexo I, parte II). Desde 11 de setembro de 2026, uma vulnerabilidade ativamente explorada num produto dá também início a um prazo de reporte: um alerta precoce no prazo de 24 horas, uma notificação no prazo de 72 horas e um relatório final no prazo de 14 dias após a disponibilização de uma correção.
• A sua própria política. A maioria dos programas de segurança define objetivos internos por gravidade. Sejam quais forem, só os poderá cumprir se o passo 1 for rápido.

Passo 3: escolher a correção

Opção	Quando a usar
Atualizar	Existe uma versão corrigida. Prefira a atualização mais pequena que inclua a correção, para limitar alterações incompatíveis.
Atualizar a dependência pai	O pacote vulnerável é transitivo. Uma versão mais recente da dependência direta traz muitas vezes a correção.
Forçar a versão	A dependência pai ainda não lançou uma correção. Force a versão transitiva com overrides do npm, resolutions do Yarn ou pnpm.overrides, e teste-a.
Patch ou backport	Ainda não pode passar para a versão principal corrigida. Aplique a correção upstream à versão que utiliza.
Substituir	O pacote deixou de ter manutenção ou continua a gerar CVE. Mude para uma alternativa.
Mitigar e documentar	Ainda não existe correção, ou o seu produto não é afetado. Reduza a exposição e registe a avaliação, por exemplo como declaração VEX.

A maior parte deste passo pode ser automatizada, desde a escolha da versão até à abertura do pull request. A remediação automatizada de vulnerabilidades explica o que automatizar e o que deixar para uma pessoa.

Passo 4: uma correção integrada não é uma correção distribuída

O pull request foi integrado, logo a CVE está encerrada. Não necessariamente. A correção está no repositório, mas um build restaura uma cache desatualizada, uma imagem base ainda contém o pacote antigo ou um ramo de lançamento nunca recebeu a alteração. O ticket diz «corrigido» enquanto o produto continua a distribuir a versão vulnerável.

Feche o ciclo pela outra ponta: verifique a SBOM do build seguinte e confirme que a versão vulnerável desapareceu. Quando essa SBOM regista o que o build realmente obteve, incluindo pacotes restaurados de caches, a verificação responde à pergunta que o cliente, o auditor e o regulador estão realmente a fazer.

Como o CRACI apoia a remediação de CVE

• Encontrar. O CRACI regista os pacotes que cada job de GitHub Actions obteve, incluindo dependências transitivas e pacotes restaurados de caches, e reavalia continuamente as SBOM monitorizadas. As vistas da organização agregam as conclusões de todos os builds e repositórios, para que veja que builds uma nova CVE afeta.
• Atribuir. As equipas de segurança fazem a triagem de cada conclusão e enviam-na à equipa responsável pela correção. O CRACI suporta VEX para registar como uma vulnerabilidade afeta o seu produto.
• Verificar. Cada novo build tem a sua própria SBOM com um estado de completude, para que possa confirmar que a versão corrigida é a que o build usou.
• Reportar. Para vulnerabilidades ativamente exploradas ao abrigo do CRA, o CRACI submete as notificações às autoridades em nome do fabricante.

Consulte acompanhamento de vulnerabilidades para conhecer a capacidade completa.

Remediação de CVE: perguntas frequentes

O que é a remediação de CVE?

A remediação de CVE consiste em remover uma vulnerabilidade divulgada publicamente, identificada pelo seu identificador CVE, do software que executa ou distribui. Numa dependência, isso significa normalmente atualizar para uma versão em que a vulnerabilidade esteja corrigida. No seu próprio código, significa aplicar-lhe um patch.

Como priorizo as CVE a corrigir primeiro?

Combine a gravidade com provas de exploração. O CVSS descreve quão grave é uma vulnerabilidade, o EPSS estima a probabilidade de ser explorada nos próximos 30 dias e o catálogo Known Exploited Vulnerabilities da CISA enumera as que já são exploradas. Uma vulnerabilidade comprovadamente explorada num pacote que distribui vai para o topo.

Com que rapidez têm as CVE de ser remediadas?

Depende de quem pergunta. A Binding Operational Directive 26-04 da CISA dá às agências federais dos EUA entre 3 dias e a próxima atualização do sistema, consoante a vulnerabilidade esteja no catálogo KEV, o ativo esteja exposto publicamente, a exploração possa ser automatizada e o grau de controlo que dá a um atacante. O EU Cyber Resilience Act pede aos fabricantes que corrijam vulnerabilidades sem demora e, desde 11 de setembro de 2026, uma vulnerabilidade ativamente explorada num produto dá início a um prazo de reporte de 24 horas.

E se ainda não existir uma versão corrigida?

Mitigue e documente. Desative a funcionalidade afetada, bloqueie o caminho de ataque ou troque o componente, se puder, e registe a sua avaliação, por exemplo como declaração VEX. Depois, fique atento à versão corrigida e faça a remediação quando surgir.

Como corrijo uma CVE numa dependência transitiva?

Tente primeiro atualizar a dependência direta que a traz, uma vez que uma versão mais recente inclui muitas vezes a correção. Se ainda não existir nenhuma, a maioria dos gestores de pacotes permite forçar a versão de um pacote transitivo: overrides no npm, resolutions no Yarn, pnpm.overrides no pnpm. Teste o resultado, porque o pacote pai não foi construído com essa versão.