A correção de vulnerabilidades é o processo de resolver falhas de segurança, quer estas se encontrem no código escrito pela sua equipa, nos pacotes de código aberto dos quais depende, nos contentores que distribui ou nas contas na nuvem que utiliza. As vulnerabilidades tornaram-se a forma mais comum de os atacantes conseguirem aceder aos sistemas. O Relatório de Investigações sobre Violações de Dados da Verizon de 2026 revelou que, pela primeira vez, a exploração de vulnerabilidades ultrapassou as credenciais roubadas como o principal vetor de acesso inicial, representando 31% das violações, um aumento em relação aos 20% registados no ano anterior.
A maioria das equipas já tem conhecimento de mais vulnerabilidades no seu código do que aquelas que consegue corrigir. O mesmo relatório revelou que apenas 26 % das vulnerabilidades incluídas no catálogo «Known Exploited Vuln» (KEV) da CISA foram totalmente corrigidas em 2025, e que o tempo médio necessário para aplicar uma correção ascendeu a 43 dias.
Este guia aborda, passo a passo, o processo de correção de vulnerabilidades, como estabelecer prioridades para decidir o que corrigir primeiro e como corrigir cada tipo de vulnerabilidade, bem como o que fazer quando não é possível atualizar uma dependência. Se estiver à procura de ferramentas que facilitem este trabalho, consulte a nossa seleção de ferramentas de correção de vulnerabilidades.
{{cta}}
Onde estão as vulnerabilidades
O teu próprio código
As vulnerabilidades no código escrito pela vossa equipa dividem-se em dois grupos, que requerem dois segmentos diferentes da pilha de segurança. As falhas baseadas em padrões são aquelas que o SAST deteta de forma determinística em cada commit.
SAST é um motor determinístico, baseado em regras, que funciona através da correspondência de padrões. Funciona bem para falhas com um padrão reconhecível, como «se a entrada do utilizador chegar a esta função sem passar por um sanitizador, assinalá-la como injeção de SQL». As falhas lógicas não têm esse padrão. Não existe um padrão para um endpoint que deva verificar se o utilizador é proprietário de um recurso e não o é; por isso, detetar estas falhas implica raciocinar sobre o que o código deve fazer. Essa é a função da revisão de código por IA, que analisa o código com essa intenção em mente, e do « pentest de IA », que examina a aplicação em execução para comprovar se uma falha pode realmente ser explorada.
Ambos os tipos de correção de vulnerabilidades exigem alterações no código por parte de quem for o responsável pelo mesmo. As correções baseadas em padrões seguem procedimentos bem conhecidos, como a parametrização de uma consulta ou a codificação da saída. As falhas lógicas dependem do que o código deveria fazer; por isso, corrigir uma delas requer o mesmo conhecimento da aplicação que foi necessário para a detetar. Quando uma ferramenta de IA já identificou como uma verificação de autorização em falta pode ser explorada, pode propor uma correção baseada nessa análise, e o revisor recebe uma explicação juntamente com a alteração.
Dependências open source
A maior parte do código de uma aplicação moderna provém de pacotes de código aberto, e a maioria destes são dependências transitivas introduzidas pelos pacotes que escolheu. Por isso, a maioria das vulnerabilidades aqui presentes reside em código que ninguém da sua equipa escreveu, nem sequer escolheu.
análise de composição de software (SCA) lê os seus ficheiros de bloqueio para construir a árvore completa de dependências e, em seguida, verifica a versão de cada pacote em relação a uma fonte de dados sobre vulnerabilidades. É essa fonte que determina o que deteta. As ferramentas que dependem apenas de bases de dados CVE públicas não detetam as falhas de código aberto que são corrigidas numa versão sem que lhes tenha sido atribuído um CVE; é por isso que algumas ferramentas SCA , incluindo a Aikido, recorrem a feedsThreat Intelligence , como oAikido da Intel.
Uma descoberta não indica se a vulnerabilidade é relevante para si. Um CVE numa função que o seu código nunca chama não é acessível e representa um risco real reduzido, enquanto o mesmo CVE numa função que utiliza em todo o lado justifica que se deixe de lado outro trabalho. Uma pontuação CVSS não permite distinguir entre os dois casos, uma vez que avalia a falha de forma abstrata, e não o grau de exposição da sua aplicação.
SCA As verificações têm de continuar a ser executadas após a fusão. As versões dos pacotes no seu ficheiro de bloqueio permanecem fixas, enquanto continuam a ser divulgadas novas vulnerabilidades relacionadas com elas; por isso, uma árvore de dependências que foi aprovada no mês passado pode falhar hoje, sem que ninguém a tenha alterado. Quando surge uma vulnerabilidade, a solução padrão consiste em atualizar para uma versão que a corrija, e a secção seguinte explica por que razão essa atualização se torna, muitas vezes, um trabalho mais complexo do que parece.
Imagens de Container
A maior parte das vulnerabilidades numa imagem do container provém da imagem base sobre a qual foi construída. Uma imagem base típica inclui dezenas de bibliotecas e ferramentas do sistema, como um shell e um gestor de pacotes, e a análise de imagens do container é o que verifica esses pacotes ao nível do sistema operativo. As imagens também sofrem alterações que são fáceis de passar despercebidas. Um container em execução mantém os pacotes com os quais foi construído até que alguém o reconstrua e volte a implementar; por isso, um container em execução em produção pode não receber uma correção que já existe no upstream há meses.
A correção de uma imagem depende do quanto dessa base está disposto a alterar. Remover pacotes que o seu ambiente de execução nunca utiliza reduz o problema. Para tudo o que permanecer, atualizar para uma tag de base mais recente ou migrar para uma distribuição reforçada de outro fornecedor implica testar a sua aplicação numa base diferente, enquanto uma compilação corrigida da mesma versão de base corrige as vulnerabilidades (CVEs) e mantém tudo o resto tal como está.
Infraestrutura como código (IaC)
A IaC transfere a configuração da nuvem para ficheiros como os modelos do Terraform e do CloudFormation, os gráficos do Helm e os manifestos do Kubernetes, pelo que a maior parte da sua configuração na nuvem pode ser revista tal como qualquer outro código. As vulnerabilidades mais comuns incluem:
- Um bucket de armazenamento aberto à Internet
- Um grupo de segurança que aceita tráfego proveniente de qualquer local
- Um « container » a funcionar como root
- Uma instância EC2 que ainda utiliza o IMDSv1, a versão mais antiga do serviço de metadados da AWS, da qual dependem os ataques SSRF para roubar credenciais
O IaC é o local mais fácil para corrigir uma configuração incorreta na nuvem, porque ainda não foi aplicado nada. As verificações do IaC são executadas no seu pipeline de CI/CD e assinalam esses problemas no pedido de integração, e a correção consiste num modelo corrigido — muitas vezes, uma alteração de apenas uma linha — que nunca chega a um ambiente de produção. O problema é que as verificações do IaC apenas detetam o que está escrito nos seus modelos.
Cloud configuração
Numa organização de engenharia madura, a maior parte da infraestrutura na nuvem é definida em IaC, pelo que muitas descobertas relacionadas com a nuvem são, na verdade, descobertas de IaC que acabaram por ser implementadas. O resto resulta de alterações que ninguém registou. Alguém clica na consola para abrir uma porta ou alargar uma função, e não há nenhum modelo nem pedido de integração que registe essa ação.
Cloud gestão da postura de segurança (CSPM) acede diretamente à conta ativa, pelo que deteta essas alterações, bem como tudo o que tenha escapado à revisão. A correção consiste numa alteração de configuração ou numa política mais rigorosa, e tem de ser incorporada de novo na IaC. Se o recurso já for gerido por um modelo, uma correção efetuada apenas na consola será revertida na próxima implementação. Se tiver sido criado manualmente, integrá-lo na IaC significa que a próxima alteração a ele será submetida a revisão.
Algumas das descobertas mais graves abrangem várias camadas, e a falha SSRF do MLflow (CVE-2026-64849) ilustra bem como isso acontece. Poucas horas após ter-lhe sido atribuído um CVE, em agosto de 2026, os atacantes já a estavam a explorar para fazer com que os servidores do MLflow solicitassem ao serviço de metadados do fornecedor de serviços na nuvem as suas próprias credenciais. Na AWS, o IMDSv1 fornece essas credenciais em resposta a um simples pedido. O IMDSv2 exige primeiro um token de sessão, um passo adicional que a maioria dos bugs SSRF não consegue executar, pelo que a aplicação desta medida provavelmente teria impedido o roubo.
Quaisquer que fossem as credenciais que os atacantes conseguissem obter, estas teriam apenas o poder da função IAM associada ao servidor e, uma vez que essas funções também se encontram normalmente no Terraform ou no CloudFormation, as verificações de IaC podem detetar uma política excessivamente abrangente antes de esta ser implementada. Ambas as medidas de proteção encontram-se nos mesmos modelos que as verificações de IaC já analisam, o que torna a IaC a forma mais económica de impedir um ataque como este.
Secrets
Secrets acabam frequentemente por aparecer no código por acidente. Uma chave de API pode ser codificada de forma rígida num teste, ou uma palavra-passe de base de dados pode acabar num ficheiro de configuração que é submetido juntamente com todo o resto. O código escrito por IA tende a apresentar este problema em particular. A deteção do Secrets verifica os novos commits e todo o histórico do Git em busca destes elementos, e um hook de pré-submissão pode bloquear um antes mesmo de ser submetido. As imagens do Container necessitam da mesma verificação, uma vez que um segredo copiado para uma camada permanece na imagem, mesmo que uma camada posterior o elimine.
Apagar o segredo do código não resolve o problema, porque este continua no histórico do Git. A solução consiste em alternar a credencial e, em seguida, verificar os registos de acesso para ver se alguém utilizou a credencial antiga antes da alternância. Se os registos revelarem que outra pessoa a utilizou, é necessário determinar a que informações o atacante teve acesso e se os dados em causa desencadeiam quaisquer requisitos de notificação de violação. Assim que a credencial antiga estiver desativada, eliminá-la do histórico é uma boa prática de manutenção, mas já não é urgente. Para evitar que isto volte a acontecer, transfira o segredo para um gestor de credenciais ( secrets ) ou para uma variável de ambiente que o código leia em tempo de execução.
Quando não é possível atualizar uma dependência
A maioria das ferramentas de « SCA » e dos avisos de segurança dão o mesmo conselho para um pacote vulnerável: atualizar para a versão que inclui a correção. No caso de um aumento do nível do patch, isso é normalmente tudo o que é necessário. O problema começa quando a correção não chega de forma tão simples e, na prática, isso acontece frequentemente.
O problema começa quando a correção só existe numa nova versão principal com alterações de API incompatíveis, ou quando o pacote vulnerável é transitivo e a atualização depende de um mantenedor três níveis acima na árvore. Os pacotes abandonados e as versões fora de suporte nunca recebem uma versão corrigida, e é precisamente por se atualizar por reflexo que as versões comprometidas do chalk e do debug chegaram aos pipelines em poucos minutos. Assim, as equipas adiam a atualização, e o CVE vai para uma lista de ignorados que não para de crescer.
A vulnerabilidade CVE-2026-48937 no Node.js ilustra bem como isto se passa. A correção foi lançada juntamente com uma atualização de versão principal (semver) do nghttp2 que removeu completamente a sinalização de prioridade HTTP/2, uma vez que o comportamento vulnerável e a funcionalidade removida provinham do mesmo código subjacente. Para uma equipa que gere um serviço HTTP/2, um aumento de versão de apenas uma linha transformou-se numa busca por todas as chamadas a `setPriority` e `.priority()`, tanto no seu próprio código como em qualquer dependência que utilizasse as mesmas APIs, enquanto o CVE permanecia aberto.
O backporting é a solução mais direta, consistindo na aplicação da correção à versão que já está a utilizar. Pode criar um fork do pacote e fazê-lo por conta própria, embora fique então responsável por esse fork, ou utilizar uma compilação corrigida de um fornecedor que mantenha backports, algo que o Aikido Security oferece para pacotes de código aberto e imagens do container . Pode encerrar o CVE e atualizar quando a sua equipa tiver tempo para testar devidamente.
Melhores práticas para a correção de vulnerabilidades
Definir SLAs por nível de risco
Depois de classificar os resultados por explorabilidade e exposição, atribua a cada nível de risco um prazo que a sua equipa consiga cumprir. Um acordo de nível de serviço (SLA), medido em dias para uma vulnerabilidade incluída na lista KEV num serviço exposto à Internet e em semanas para um meio acessível numa ferramenta interna, define a ordem da fila. Acompanhe também os incumprimentos desses SLAs, uma vez que um padrão de incumprimentos numa equipa ou numa camada geralmente aponta para um problema de processo que vale a pena corrigir.
Implementar correções nos locais onde os programadores já trabalham
Uma descoberta que fica confinada a um painel de segurança acaba por competir com todas as outras tarefas do programador e, normalmente, sai a perder. Apresentá-la no IDE enquanto o código está a ser escrito, ou no pedido de integração antes da fusão, significa que o programador a vê enquanto a alteração ainda está fresca na sua mente. É nesse momento que tem mais contexto sobre o que o código se destina a fazer e quando corrigi-la custa menos, antes de ser lançada. Isso também resolve a questão da responsabilidade, porque quem abriu o pedido de integração é, obviamente, a pessoa indicada para a corrigir.
Automatizar correções que não alteram o comportamento
Os patches retroativos e as atualizações de nível de patch que passam nos seus testes podem ser incorporados após uma revisão superficial, uma vez que resolvem um CVE sem alterar o comportamento do seu código. As correções de falhas lógicas, como um IDOR ou uma verificação de autorização em falta, alteram o comportamento; por isso, são mais úteis quando vêm acompanhadas do raciocínio subjacente, mostrando como a falha poderia ser explorada e o que a correção impõe, o que agiliza a revisão. As atualizações que envolvem uma mudança de versão principal são aquelas em que a automatização ajuda menos, e a secção sobre «armadilhas de atualização» acima aborda as melhores opções para esses casos.
Repita o teste antes de encerrar
Execute novamente o teste que detetou a vulnerabilidade na versão corrigida e só feche o relatório quando esta deixar de aparecer. No caso de detetados numa aplicação em execução, isso significa voltar a testar o ambiente implementado, uma vez que uma correção que passe num ramo pode ainda falhar devido a um proxy mal configurado ou a uma compilação antiga que nunca tenha sido reimplementada.
Como a Segurança d Aikido a lida com a correção de vulnerabilidades
Aikido A segurança abrange o processo de correção desde o primeiro indício de uma vulnerabilidade até ao pedido de integração (pull request) que a corrige. Começa com o «Aikido » da Intel, que monitoriza vulnerabilidades em pacotes de código aberto antes de lhes ser atribuído um CVE, incluindo muitas que nunca o terão, para que a correção possa começar antes mesmo de as bases de dados públicas as registarem.
Cada resultado passa então por duas fases de triagem. O Reachability analysis verifica se o seu código tem algum caminho de execução para a função vulnerável, o que elimina os CVEs em pacotes que você importa, mas nunca utiliza. O que resta é encaminhado para o CVE análise de explorabilidade, um agente que analisa a forma como o seu código utiliza efetivamente o pacote e, em seguida, toma medidas relativamente a cada descoberta: aumenta o nível de gravidade quando um CVE é mais perigoso na sua configuração do que a pontuação base sugere, diminui-o quando é menos perigoso, adia as descobertas para revisão posterior ou ignora aquelas que não são de todo exploráveis. Juntos, reduzem o ruído em até 95%.
As correções chegam sob a forma de pedidos de integração (pull requests) do AutoFix. No caso de detecções relacionadas com código e IaC, o próprio AutoFix cria a alteração. No que diz respeito a dependências e contentores, a correção consiste num backport. Aikido O Libraries produz compilações corrigidas das versões dos pacotes que já utiliza no npm, PyPI, Maven e Go, pelo que o CVE é encerrado sem necessidade de aumentar a versão ou alterar a API, mesmo quando não existe uma versão corrigida no upstream. Aikido O Images faz o mesmo na camada « container », com mais de 2 000 imagens de substituição imediata que eliminam CVEs de gravidade elevada e crítica, de acordo com um SLA definido para a versão do SO e a distribuição que já utiliza.
Ambos são enviados como pull requests diários do AutoFix no fluxo de trabalho que a sua equipa já utiliza. Um pull request ainda tem de ser testado e implementado antes de a vulnerabilidade ser efetivamente eliminada, e é essa a etapa de que o AutoShip se encarrega. Basta adicionar uma etiqueta a um pull request do AutoFix e o AutoShip encarrega-se de o levar da CI, passando pelo ambiente de teste, até à produção, executando testes de verificação e monitorizando eventuais regressões ao longo do processo, para que a correção chegue à produção sem que seja necessário afastar um programador do que está a desenvolver.
Aikido contribui também com correções retroativas para vulnerabilidades listadas no KEV para a comunidade de código aberto, de forma gratuita, para que as falhas que os atacantes estão a explorar ativamente sejam corrigidas para todos, sejam ou não clientes. E como todas as correções passam pela mesma plataforma, cada uma delas é registada como prova de conformidade com a norma SOC 2 e com as normas ISO que a « Aikido » apoia, incluindo a ISO 27001 e a ISO 42001.
{{walkthrough}}
