A remediação de vulnerabilidades é o trabalho de corrigir a causa de uma falha de segurança para que ela não possa mais ser explorada, e depois provar que a correção funcionou. É uma das três opções de tratamento, ao lado da mitigação e da aceitação, e a única que elimina a fraqueza em vez de administrá-la.
A segunda metade dessa definição é onde os programas quebram. No Relatório de ataques 2026 da Fluid Attacks, a taxa de remediação dos sistemas avaliados fechou 2025 em 62,2 %, e os sistemas cujos desenvolvedores usaram os plugins de IDE da Fluid Attacks alcançaram uma taxa média de remediação de 55,4 %, contra 28,1 % dos sistemas que não os usaram. Onde a correção é escrita muda se ela chega a ser escrita.
Esta página cobre o que é e o que não é a remediação de vulnerabilidades, como ela se diferencia da mitigação e da aceitação, como as correções são construídas para o código, as vulnerabilidades em dependências e a infraestrutura, como verificar se uma falha realmente desapareceu, o que fazer quando não há patch e quais métricas mostram se o processo de remediação de vulnerabilidades funciona.
O que é remediação de vulnerabilidades?
A remediação de vulnerabilidades é a correção de uma fraqueza de segurança na sua origem, confirmada com um novo teste. Ela abrange três tipos de mudança: corrigir seu próprio código-fonte, atualizar ou substituir um componente de terceiros vulnerável e corrigir uma configuração insegura na infraestrutura ou em serviços de nuvem.
Não é um status em um ticket. Um issue fechado registra que alguém acreditou que o problema estava resolvido; não é evidência de que a fraqueza desapareceu. Também não é sinônimo de aplicar patch. Aplicar patch é um caminho para a correção, e a Publicação Especial 800-40 Revisão 4 do NIST, Guide to Enterprise Patch Management Planning (2022), define o patch management empresarial como identificar, priorizar, adquirir, instalar e verificar a instalação de patches, e o apresenta sobretudo como manutenção preventiva, não como reação a cada aviso.
A remediação de vulnerabilidades vive dentro do ciclo mais amplo da gestão de vulnerabilidades. A detecção, a triagem e a priorização decidem o que corrigir e em que ordem. O processo de remediação de vulnerabilidades é o que vem depois, e a verificação da correção é o que o encerra.
Por que a remediação de vulnerabilidades importa
A remediação de vulnerabilidades importa porque a exposição dura exatamente o que dura a fraqueza. A detecção sozinha não muda nada: uma falha reportada que ninguém corrige é a mesma rota de ataque que era antes da varredura, agora documentada em dois lugares.
Nossos dados de remediação de vulnerabilidades de 2025 mostram o quanto o trabalho é desigual. No Relatório de ataques 2026, a mediana do tempo de remediação foi de 14 dias para as vulnerabilidades de severidade crítica, mas de 40 dias para as de severidade alta, enquanto o tempo médio de remediação chegou a 36 dias para as críticas e 60 dias para as altas. As falhas críticas recebem atenção; o nível logo abaixo espera mais do que qualquer outro na fila, incluindo os achados de severidade baixa, com mediana de 28 dias.
A remediação de vulnerabilidades também é o que os auditores pedem, porque uma lista de achados não é um controle. A Fluid Attacks define seus próprios prazos de remediação por severidade por essa razão, seguindo as recomendações de marcos como PCI DSS e NIST.
A remediação de vulnerabilidades na Fluid Attacks
A Fluid Attacks opera a remediação de vulnerabilidades como um ciclo fechado. A IA, os scanners próprios e os pentesters reportam uma vulnerabilidade com sua localização exata e sua evidência de exploração; a plataforma oferece uma rota de correção dentro do editor do desenvolvedor; e um novo teste confirma se a correção funcionou antes de o achado poder ser fechado.
O que corrigimos e sob quais regras
Nosso suporte de remediação de vulnerabilidades cobre os três alvos que avaliamos. Para o código-fonte, a plataforma mostra as linhas vulneráveis e o padrão seguro daquela linguagem. Para os componentes, Software Composition Analysis (SCA) devolve rotas de atualização para dependências diretas e transitivas. Para a infraestrutura, os achados chegam com a configuração corrigida do provedor de nuvem ou da plataforma de contêineres envolvida.
Nada é fechado por afirmação. Um desenvolvedor marca o trabalho como concluído ao solicitar um novo teste, não ao mudar um status. Nosso motor ou nossos pentesters decidem o resultado.
Como isso funciona na prática
Cada rota de remediação de vulnerabilidades deixa um tipo diferente de evidência:
Rota de correção | O que o desenvolvedor recebe | O que fecha o achado |
|---|---|---|
Custom Fix | Um guia passo a passo gerado para o código vulnerável no IDE | Novo teste |
Autofix | Uma mudança sugerida aplicada diretamente no arquivo | Novo teste |
Atualização de dependência | Três versões para escolher: correção mínima, atualização segura, correção completa | Novo teste depois que o scanner roda de novo |
Sessão com pentester | Uma chamada de 30 minutos com o pentester que reportou o problema | Novo teste manual |
O catálogo público de soluções da Fluid Attacks: 2.044 correções documentadas que cobrem 326 fraquezas em 23 linguagens de programação.
Onde a remediação acontece muda se ela acontece
O padrão mais forte dos nossos dados de 2025 não é sobre a qualidade das ferramentas. É sobre a distância entre um achado e a pessoa que pode corrigi-lo. Estas comparações são observacionais, então mostram associação, não causa:
Prática em 2025 | Sistemas ou clientes que a usaram | Os que não usaram |
|---|---|---|
Plugins de IDE | 55,4 % de taxa média de remediação | 28,1 % |
Servidor MCP | 49,7 % de taxa média de remediação | 24,1 % |
CI Gate | 72,2 % de taxa de remediação; mediana de 22 dias | 58 %; mediana de 30 dias |
Fonte: Fluid Attacks, Relatório de ataques 2026. Os números dos plugins de IDE cobrem os 23 % de clientes que os usaram desde março de 2025; os do servidor MCP, os 41 % que o usaram desde junho de 2025.
O que a remediação com GenAI faz bem
A IA generativa ganha seu lugar na metade rotineira do trabalho. No Relatório de ataques 2026, Autofix e Custom Fix foram usados em 53,6 % dos sistemas, e o Custom Fix respondeu por 93 % desses sistemas. O padrão é claro: as equipes recorrem muito mais a um guia que explica a correção do que a um patch aplicado em seu nome.
Essa preferência está bem colocada, e nossa própria documentação diz o motivo sem rodeios: a IA generativa pode produzir código vulnerável, então cada passo gerado precisa ser examinado antes de ser aceito. A remediação assistida por IA encurta a distância entre um achado e uma correção que funciona. Ela não elimina a revisão, os testes nem o novo teste.
As regras que aplicamos ao nosso próprio código
A Fluid Attacks aplica sua solução completa ao seu próprio stack tecnológico, sob prazos publicados de remediação de vulnerabilidades por severidade:
Pontuação CVSS v4.0 | Tempo de remediação |
|---|---|
9.0 – 10.0 (Crítica) | ≤ 7 dias |
7.0 – 8.9 (Alta) | ≤ 15 dias |
4.0 – 6.9 (Média) | ≤ 30 dias |
0.1 – 3.9 (Baixa) | ≤ 60 dias ou conforme a prioridade |
Nosso time de engenharia pode aceitar uma vulnerabilidade temporariamente enquanto constrói o patch: no máximo duas vezes, 30 dias cada uma, 60 dias no total. A meta de percentual de remediação está acima de 99 %. Este é nosso acordo de nível de serviço interno de remediação, publicado na nossa documentação de transparência, não um padrão que toda organização deva copiar.
Remediação, mitigação e aceitação do risco não são alternativas
A remediação de vulnerabilidades, a mitigação e a aceitação do risco respondem perguntas diferentes, e tratá-las como um cardápio é como o risco residual se acumula em silêncio. A remediação elimina a fraqueza. A mitigação de vulnerabilidades reduz a probabilidade ou o impacto da exploração enquanto a fraqueza continua ali. A aceitação é uma decisão documentada de conviver com ela.
Tratamento | O que muda | O que permanece | Quando se aplica |
|---|---|---|---|
Remediação de vulnerabilidades | A fraqueza é corrigida na sua origem | Nada, depois de verificada | Sempre a opção padrão |
Mitigação | A exposição ou o impacto são reduzidos por um controle compensatório | A falha de fundo e o custo do próprio controle | Ainda não há correção, ou a correção precisa de uma janela de implantação |
Aceitação | Nada técnico | A exposição completa, agora documentada e com dono | Risco baixo, ou custo de remediação maior que a perda esperada |
Duas regras mantêm isso honesto. A mitigação precisa de data de validade, porque um controle temporário que ninguém revisa vira arquitetura permanente. A aceitação precisa de dono e data de revisão, porque uma aceitação sem nenhum dos dois é uma vulnerabilidade sem correção com papelada melhor. Nos sistemas que avaliamos em 2025, a aceitação permanente cobriu 0,1 % das vulnerabilidades de severidade alta e 0,3 % das críticas: em um processo maduro de remediação de vulnerabilidades ela continua sendo exceção, não válvula de escape.
Como as correções de vulnerabilidades são realmente feitas
A remediação de vulnerabilidades assume três formas diferentes conforme onde a fraqueza vive, e confundi-las é a razão pela qual os planos de remediação atrasam.
Seu próprio código. A remediação de vulnerabilidades aqui muda a lógica da aplicação: adicionar a verificação de autorização, parametrizar a consulta, substituir o algoritmo fraco. Essas correções estão totalmente sob seu controle, e são as que um security champion ou um assistente de IA pode entregar a um desenvolvedor como um diff concreto.
Suas dependências. Você raramente aplica patch em código de terceiros; você troca versões. Nossa plataforma devolve três opções para cada componente vulnerável, para que as equipes possam escolher entre segurança e estabilidade. Cada opção é um equilíbrio diferente de remediação de vulnerabilidades, e a plataforma diz qual é:
Opção | O que faz | Custo |
|---|---|---|
Correção mínima | Corrige a vulnerabilidade reportada | Pode introduzir novas |
Atualização segura | Corrige a vulnerabilidade reportada sem adicionar novas | Costuma ser um salto de versão maior |
Correção completa | Atualiza para a última versão livre de vulnerabilidades conhecidas | Maior chance de mudanças que quebram |
As dependências transitivas são o caso difícil do trabalho com vulnerabilidades em dependências, porque você não controla a versão delas diretamente. A plataforma identifica o pacote direto que traz o código vulnerável e entrega as três versões de remediação para ele, assim a equipe pode confirmar a compatibilidade ou levar o pacote pai à sua versão mínima suportada.
Sua infraestrutura. Aqui a remediação de vulnerabilidades significa corrigir uma configuração: fechar um bucket público, forçar TLS, remover uma política de IAM com permissões demais. Essas correções costumam ser as mais rápidas de aplicar e as mais fáceis de regredir, e por isso pertencem à infraestrutura como código e não a um console.
Corrija a fraqueza, não o CVE
Um CVE é uma instância de uma falha em um produto; uma fraqueza é a classe por trás de muitas instâncias. A Fluid Attacks escreve suas orientações de remediação de vulnerabilidades para a classe, e por isso um único padrão de correção serve a cada CVE que a compartilha, em diferentes linguagens e frameworks.
Nosso catálogo público de soluções tem 2.044 correções documentadas que cobrem 326 fraquezas em 23 linguagens de programação, mapeadas a partir de mais de 340.000 registros de vulnerabilidades. Cada entrada apresenta o código não conforme ao lado do código seguro e nomeia o requisito de segurança que a mudança satisfaz, como explica em detalhe nosso artigo sobre a base de dados. Esse mapeamento é o que torna a remediação de vulnerabilidades reutilizável entre tecnologias e frameworks.
Cada entrada de fraqueza também traz um tempo estimado de remediação, o que transforma a remediação de vulnerabilidades em algo que uma equipe pode planejar em um sprint em vez de estimar no olho. A fraqueza 022, uso de um canal inseguro, indica 15 minutos e se associa ao requisito 181, transmitir dados usando protocolos seguros; a fraqueza 005, escalonamento de privilégios, indica 60 minutos e se associa ao requisito 035.
Entrada 022 do catálogo da Fluid Attacks: impacto, recomendação, requisito associado e tempo estimado de remediação.
Como verificar se uma vulnerabilidade foi remediada
A verificação da correção é o passo que separa a remediação de vulnerabilidades de uma mudança de status, e existe porque uma correção pode falhar de duas maneiras: ela pode não resolver a fraqueza original, ou pode introduzir uma nova. Nossa documentação diz exatamente isso, e é a razão pela qual nenhuma remediação de vulnerabilidades é fechada sem um novo teste.
Na Fluid Attacks, a reavaliação da remediação de vulnerabilidades se chama reattack. Depois de sincronizar o repositório corrigido, o desenvolvedor seleciona a localização onde aplicou a correção e a solicita. Os novos testes automatizados são rodados pela ferramenta; os manuais, pelo pentester que reportou o achado. Se a fraqueza sobrevive, a coluna Reattack da vulnerabilidade mostra Verified (vulnerable) e um comentário explica o que ainda funciona.
A resposta é limitada por um acordo de nível de serviço: pelo menos 90 % dessas solicitações recebem uma primeira resposta em uma mediana de menos de oito horas de expediente. Um desenvolvedor que pede um novo teste pela manhã costuma saber antes do fim do dia se a correção aguentou.
Os novos testes confirmam a remediação de vulnerabilidades depois do fato. O CI Gate opera na direção contrária: quebra a build quando uma implantação carrega vulnerabilidades que violam a política da organização. Os dois controles servem à mesma regra: nenhum achado é fechado por uma afirmação que ninguém testou. Uma correção que passa em um novo teste vira um padrão de remediação de vulnerabilidades que a equipe pode reutilizar; uma que falha vira uma lição antes de chegar à produção.
Quando não há patch disponível
Às vezes a remediação de vulnerabilidades não está disponível no prazo que o risco exige: o fornecedor não publicou uma correção, o componente está sem manutenção ou a atualização quebra uma dependência em produção. A resposta é uma mitigação documentada com data de encerramento, tratada como uma etapa da remediação de vulnerabilidades e não como substituta dela.
Situação | Medida provisória | O que ainda precisa acontecer |
|---|---|---|
Ainda não há patch do fornecedor | Restringir o acesso de rede, desativar a funcionalidade afetada | Acompanhar o aviso e aplicar a correção quando sair |
A correção quebra a compatibilidade | Isolar o componente, adicionar validação de entrada a montante | Agendar a atualização em uma janela de implantação |
Componente sem manutenção | Substituí-lo, ou bifurcá-lo e corrigi-lo | Tratar a substituição como a remediação |
Risco menor que o custo de corrigir | Documentar a aceitação com dono e data de revisão | Reavaliar quando a exposição ou os dados de exploração mudarem |
Os dados de exploração decidem o prazo. O catálogo KEV da CISA lista falhas com exploração confirmada no mundo real, e a Diretiva Operacional Vinculante 26-04 da CISA, Prioritizing Security Updates Based on Risk, emitida em junho de 2026, exige que as agências civis federais dos Estados Unidos ajam sobre as entradas do catálogo dentro dos prazos que cada entrada traz, alguns deles de poucos dias. Aparecer no catálogo KEV da CISA move um achado para a frente da fila de remediação de vulnerabilidades, diga o que disser sua pontuação base.
Como medir a remediação de vulnerabilidades
Um programa de remediação de vulnerabilidades é medido pelo que foi fechado e por quanto tempo ficou aberto, não por quantos achados foram reportados. Quatro métricas dão conta disso.
Taxa de remediação de vulnerabilidades. A proporção de vulnerabilidades reportadas que foram corrigidas. A nossa, nos sistemas avaliados, chegou a 62,2 % no fim de 2025.
Tempo médio e mediana de remediação. Reporte os dois e separe por severidade, porque uma média esconde a cauda longa e um agregado esconde qual nível está sendo negligenciado:
Severidade | Tempo médio de remediação | Mediana de remediação |
|---|---|---|
Crítica | 36 dias | 14 dias |
Alta | 60 dias | 40 dias |
Média | 51 dias | 30 dias |
Baixa | 56 dias | 28 dias |
Fonte: Fluid Attacks, Relatório de ataques 2026, sobre vulnerabilidades remediadas durante 2025.
Novos testes que falham. A proporção de correções que não sobreviveram à verificação. É a única métrica desta lista que mede a qualidade da remediação de vulnerabilidades e não sua velocidade, e um número em alta é razão para revisar como as correções são revisadas antes de serem enviadas.
Exposição ao risco residual. Ponderada por severidade em vez de contada, para que um achado crítico não desapareça atrás de cem baixos. Para isso usamos o CVSSF.
Conclusões
A remediação de vulnerabilidades é o único tratamento que elimina uma fraqueza, e ela termina quando alguém diferente do autor confirma que a fraqueza desapareceu. A mitigação e a aceitação são escolhas legítimas, mas as duas deixam um risco residual que precisa de dono e de data.
As alavancas que movem o processo de remediação de vulnerabilidades nos nossos dados não são vistosas: coloque a correção onde o código é escrito, dê ao desenvolvedor um guia em vez de um patch opaco e faça da verificação um novo teste em vez de uma caixa marcada. Os sistemas cujos desenvolvedores usaram nossos plugins de IDE remediaram quase o dobro da taxa dos que não usaram, e os sistemas que quebraram a build fecharam achados oito dias mais rápido na mediana. Toda outra métrica de um programa de remediação de vulnerabilidades depende desse hábito.
Perguntas frequentes
Qual é a diferença entre remediação e mitigação de vulnerabilidades?
A remediação de vulnerabilidades corrige a fraqueza na sua origem, então a rota de ataque desaparece. A mitigação de vulnerabilidades deixa a fraqueza no lugar e reduz a probabilidade ou o impacto da exploração com um controle compensatório, como restringir o acesso de rede ou desativar uma funcionalidade. A remediação é a meta; a mitigação é o que compra tempo até a correção ficar disponível, e precisa de data de validade.
Como se verifica se uma vulnerabilidade foi corrigida?
Testando de novo a localização específica com a mesma técnica que a encontrou, não fechando o ticket. Na Fluid Attacks esse novo teste se chama reattack, e é rodado pela ferramenta de forma automática ou pelo pentester que reportou o achado de forma manual. Se a fraqueza sobrevive, a plataforma a marca como Verified (vulnerable). Pelo menos 90 % das solicitações recebem uma primeira resposta em uma mediana de menos de oito horas de expediente.
Quanto tempo deve levar a remediação de vulnerabilidades?
Depende da severidade e dos prazos que seu acordo de nível de serviço de remediação define. A Fluid Attacks aplica ≤7 dias para crítica, ≤15 para alta, ≤30 para média e ≤60 para baixa no seu próprio código. Na prática, nos sistemas que avaliamos em 2025, a mediana do tempo de remediação foi de 14 dias para as vulnerabilidades críticas e de 40 dias para as de severidade alta.
A IA pode corrigir vulnerabilidades de software com segurança?
Com revisão, sim, e o padrão de uso reflete essa cautela. Autofix e Custom Fix foram usados em 53,6 % dos sistemas que avaliamos em 2025, e 93 % desses sistemas usaram o Custom Fix, o guia passo a passo, em vez do patch automático. A IA generativa pode produzir código vulnerável, então a remediação assistida por IA ainda precisa de testes e de um novo teste antes de contar como concluída.
A Fluid Attacks verifica se suas correções funcionaram?
Sim. A remediação de vulnerabilidades só é fechada na nossa plataforma depois que um novo teste confirma, solicitado a partir da plataforma, do IDE ou do seu sistema de tickets. Os clientes do plano Advanced recebem reattacks manuais do pentester que reportou a vulnerabilidade, com evidência em qualquer um dos dois sentidos.
Feche o ciclo em cada correção
Os pentesters e os scanners da Fluid Attacks testam de novo cada correção que você reporta, para que a remediação de vulnerabilidades termine com evidência e não com uma suposição. Teste gratuito · Fale conosco.
Comece a usar a solução ASPM da Fluid Attacks agora mesmo
