Remediação automatizada de vulnerabilidades, da conclusão à correção

O que significa remediação automatizada de vulnerabilidades

A remediação de vulnerabilidades consiste em remover uma vulnerabilidade conhecida do seu software: atualizar o pacote afetado, aplicar um patch ou substituir o componente. A remediação automatizada entrega a parte mecânica desse trabalho ao software. Lê uma conclusão, apura que versão a corrige, altera o manifesto, o lockfile ou o código e propõe a alteração, na maioria das vezes como pull request.

Nas dependências de terceiros, onde reside a maioria das vulnerabilidades conhecidas de uma base de código moderna, o ciclo é igual em todas as ferramentas:

1. Inventariar. Saiba que pacotes, em que versões, estão em cada coisa que distribui.
2. Comparar. Compare esse inventário com os avisos de segurança e continue a fazê-lo à medida que são publicados novos.
3. Priorizar. Decida o que corrigir primeiro, por gravidade, exploração e exposição.
4. Corrigir. Escolha a versão corrigida, atualize-a e adapte o código se a atualização partir algo.
5. Verificar. Faça o build e teste a alteração e, depois, confirme que a versão corrigida é a que foi realmente distribuída.
6. Registar. Mantenha um rasto do que foi afetado, de quando foi corrigido e em que versão.

A automatização é mais forte nos passos 2, 4 e 6, onde o trabalho é repetitivo. É mais fraca onde as entradas estão erradas, e a entrada de tudo o resto é o passo 1.

Quatro tipos de remediação automatizada

Abordagem	O que faz	Exemplos	Onde termina
Bots de atualização de dependências	Abrem pull requests que atualizam uma dependência vulnerável para uma versão corrigida	Dependabot security updates, Renovate	Trabalham a partir dos manifestos e lockfiles do repositório; uma atualização incompatível continua a exigir que uma pessoa adapte o código
Pull requests de correção de SCA	Abrem pull requests de atualização para as conclusões de uma ferramenta comercial de SCA	Snyk, Black Duck, Aikido, Endor Labs	A cobertura varia: algumas ferramentas corrigem apenas dependências diretas, outras acrescentam patches ou backports
Correções de código com IA	Geram uma alteração de código para uma conclusão, muitas vezes um alerta de análise estática	GitHub Copilot Autofix	Sugestões não determinísticas que exigem revisão; consulte remediação com IA
Remediação automática de infraestrutura	Reverte uma configuração incorreta ou aplica um patch a um host quando uma regra é acionada	Ferramentas de postura de segurança na nuvem e de endpoints	Abrange a infraestrutura em execução, não as dependências dentro do software que distribui

As três primeiras corrigem código que distribui e partilham um pressuposto: que a lista de pacotes vulneráveis que estão a corrigir é a lista certa.

Todas as correções dependem do inventário

Uma ferramenta de remediação só pode corrigir as vulnerabilidades que conhece, e conhece as que o seu inventário contém. A maioria dos inventários é reconstruída a partir de ficheiros: manifestos, lockfiles, pacotes instalados ou uma imagem de contentor final. Essa reconstrução deixa escapar coisas de formas previsíveis.

• Pacotes que os ficheiros não declaram. As ferramentas que o build descarrega, as imagens base, os plugins e tudo o que seja instalado por um script nunca aparecem num lockfile, pelo que nunca se abre um pull request de correção para eles.
• Versões diferentes das do lockfile. O build pode resolver uma versão diferente da que um scanner lê, sobretudo sem um lockfile no repositório. Uma correção baseada na versão errada é uma resposta errada dada com confiança.
• Pacotes restaurados de caches. Uma dependência em cache nunca mais volta a tocar no registo, pelo que aquilo que o build usou pode ficar atrás do que o repositório diz.

A solução é partir do que o build realmente usou. Uma SBOM de build é registada enquanto o build decorre, pelo que enumera os pacotes que o job obteve, incluindo os transitivos, e não aquilo de que um manifesto diz precisar. A remediação que parte daí corrige o que é distribuído.

O que automatizar e o que manter

A maioria das equipas em que a remediação funciona divide-a assim:

• Automatize a deteção e a correspondência. Todos os dias são publicados novos avisos de segurança. Voltar a verificar manualmente todos os builds distribuídos face a esses avisos não escala, e é exatamente o tipo de trabalho que o software faz bem.
• Automatize a proposta. Escolher a versão corrigida e abrir a alteração é mecânico. Agrupe atualizações relacionadas para que quem revê veja um pull request em vez de vinte.
• Condicione a integração aos testes. Faça automerge das atualizações de segurança ao nível de patch que o conjunto de testes abrange. Deixe para uma pessoa as atualizações incompatíveis e tudo o que não tenha cobertura de testes.
• Deixe às pessoas as decisões que exigem julgamento. Saber se uma vulnerabilidade afeta sequer o seu produto, e se uma atualização arriscada vale a pena esta semana, são decisões. Registe-as, por exemplo como declaração VEX, para que a mesma pergunta não seja feita duas vezes.

Como avaliar uma ferramenta de remediação

Antes de confiar a uma ferramenta a abertura de pull requests nos seus repositórios, pergunte:

1. De onde vem a lista de vulnerabilidades da ferramenta: de ficheiros no repositório, de uma imagem analisada ou do próprio build?
2. Corrige dependências transitivas ou apenas as diretas declaradas por si?
3. Como escolhe a versão corrigida: a versão mínima com patch, a mais recente ou uma versão fixada por si?
4. A correção é compilada e testada antes de a ver, ou o pull request é a primeira vez que é executada?
5. Consegue agrupar e agendar atualizações, para não inundar quem revê?
6. Regista que versões foram afetadas e quando cada correção foi distribuída?

Onde entra o CRACI hoje

O CRACI executa os seus jobs de GitHub Actions nos runners do CRACI e regista os pacotes que cada job realmente obteve, incluindo dependências transitivas e pacotes restaurados de caches, com um estado de completude para cada job. Esse registo é o inventário de que um workflow de remediação deve partir.

O CRACI reavalia continuamente as SBOM monitorizadas, pelo que, quando é publicado um novo aviso de segurança, vê que builds distribuídos este afeta nos seus repositórios. As equipas de segurança fazem a triagem de cada conclusão e enviam-na à equipa responsável pela correção, e o CRACI suporta VEX para registar como uma vulnerabilidade afeta o seu produto. A SBOM do build seguinte mostra depois se a versão corrigida é a que o build realmente usou. A página de acompanhamento de vulnerabilidades aborda a capacidade completa.

Ao abrigo do EU Cyber Resilience Act, os fabricantes têm de tratar e corrigir vulnerabilidades sem demora, nomeadamente através de atualizações de segurança. Um registo do que cada build continha e de quando cada correção foi distribuída é a evidência de que esse processo precisa.

Remediação automatizada de vulnerabilidades: perguntas frequentes

O que é a remediação automatizada de vulnerabilidades?

A remediação automatizada de vulnerabilidades é software que transforma uma conclusão sobre uma vulnerabilidade numa correção sem que uma pessoa faça o trabalho braçal: apura a versão corrigida, altera o manifesto, o lockfile ou o código e propõe a alteração, normalmente como pull request. Uma pessoa, ou uma política em que a equipa confia, continua a decidir o que é integrado.

Qual é a diferença entre remediação e mitigação de vulnerabilidades?

A remediação remove a vulnerabilidade, por exemplo atualizando para uma versão corrigida ou aplicando um patch. A mitigação reduz o risco enquanto a vulnerabilidade continua presente, por exemplo desativando a funcionalidade afetada ou bloqueando o caminho de ataque. A mitigação ganha tempo; a remediação encerra a conclusão.

A remediação de vulnerabilidades pode ser totalmente automatizada?

Em parte. Encontrar os builds afetados, comparar avisos de segurança e propor uma atualização de versão são tarefas mecânicas que se automatizam bem. Decidir se uma atualização incompatível é segura, ou se uma vulnerabilidade afeta sequer o seu produto, continua a exigir julgamento. A maioria das equipas automatiza a proposta e mantém uma pessoa, apoiada por testes, na integração.

O Dependabot faz remediação automatizada de vulnerabilidades?

Os Dependabot security updates abrem pull requests que atualizam uma dependência vulnerável para a versão mínima com patch, para os alertas que o GitHub gera sobre o grafo de dependências do seu repositório. É remediação automatizada para aquilo que os manifestos e lockfiles declaram. CRACI vs Dependabot explica onde o declarado e o distribuído diferem.

O que devo procurar numa ferramenta de remediação de vulnerabilidades?

De onde vem a lista de vulnerabilidades da ferramenta, se trata dependências transitivas, como escolhe a versão da correção, se a correção é compilada e testada antes de a ver e se regista o que foi corrigido e quando. Este último ponto é importante para as auditorias e para o CRA, que pede aos fabricantes que corrijam vulnerabilidades sem demora.