Processo de remediação de vulnerabilidades

AppSec orientada por provas é um processo de remediação de vulnerabilidades que fecha o ciclo do alerta ao fix de uma vez, com evidência reproduzível: detectar, verificar, corrigir, auditar.

Um processo de remediação de vulnerabilidades é a sequência de etapas que leva um achado de segurança da detecção até uma correção verificada e implantada: detectar, verificar, corrigir e auditar. AppSec orientada por provas é a nossa versão desse processo, com uma regra: cada etapa precisa produzir evidência que um desenvolvedor, um auditor ou um gate de CI consiga executar novamente.

A maioria dos programas de AppSec parece igual. Um scanner encontra uma vulnerabilidade. O achado cai em uma fila. Um humano faz a triagem, eventualmente. Um ticket é aberto. Um desenvolvedor pega o ticket — quando dá. O desenvolvedor abre um PR. O PR fica em revisão. A revisão leva uma semana porque o diff é grande e o desenvolvedor é o único que entende o arquivo. O PR é mergeado. O gate do CI passa. O achado é fechado.

Enquanto isso, os atacantes ficam mais rápidos e mais baratos. O agente de pesquisa RapidPen obteve acesso a uma shell em um alvo vulnerável em 200–400 segundos, por bem menos de um dólar por execução. Do lado da defesa, o Vulnerability Statistics Report 2026 da Edgescan aponta um tempo médio de remediação (MTTR) de 54,81 dias para vulnerabilidades altas e críticas de aplicações e APIs. Um tempo de correção de várias semanas não é uma métrica de segurança. É um argumento de venda para os atacantes.

AppSec orientada por provas é a disciplina operacional que fecha o ciclo de uma vez, torna cada etapa demonstrável e baixa a mediana de correção de semanas para dias. Esta é a definição canônica.

O que é AppSec orientada por provas

AppSec orientada por provas é a disciplina de executar programas de segurança de aplicações onde cada afirmação se apoia em evidência que um auditor, um desenvolvedor ou um gate de CI pode re-executar. Não pontuações CVSS. Não etiquetas de severidade. Não “alto/médio/baixo”. Um artefato reproduzível anexado ao achado.

Três propriedades definem a prática:

Cada achado tem um caminho. Não um match de regex. Não um match de padrão. Um caminho de alcançabilidade de uma fonte de entrada real até um sink com capacidade real, vinculado a um arquivo e número de linha concretos.
Cada achado tem evidência. Uma requisição que pode ser re-executada, um job de CI que pode ser reproduzido, um estado de sandbox que pode ser retomado. Se um achado não pode ser reproduzido, não é um achado — é uma hipótese.
Cada correção tem uma cadeia de evidência. O patch veio do mesmo achado. O patch fecha o exploit original. O patch foi revisado com a evidência original anexada. O teste de regressão do patch é o exploit original, invertido.

Essa é a prática. Qualquer coisa que não cumpra as três propriedades é uma captura de tela de um programa de AppSec, não um programa de AppSec.

O processo de remediação de vulnerabilidades em quatro ciclos

O padrão operacional tem quatro ciclos. Cada ciclo tem um trabalho. Cada transferência preserva a evidência.

Ciclo 1 — Detectar

A primeira passagem escaneia a base de código (e o IaC que define o runtime) e produz um grafo de hosts, endpoints, parâmetros e capacidades. Achados são posições no grafo, não linhas em um arquivo.

É isso que o Deep Code Analysis faz (o raciocínio completo está em O que é Deep Code Analysis?). A saída é um conjunto de achados propostos, cada um vinculado a um nó do grafo, um caminho de alcançabilidade, uma classe de capacidade e um número de linha.

Ciclo 2 — Verificar

A segunda passagem pega cada achado proposto e tenta reproduzi-lo. O agente que executa essa passagem não é o agente que propôs o achado. Este é o passo crítico. Autoconsistência não é verificação.

A saída do Ciclo 2 é um conjunto menor de achados verificados, cada um com a evidência anexada. Achados que não se reproduzem são descartados com um motivo documentado. Os códigos de motivo importam — é assim que sua equipe depura o pipeline depois. Os motivos comuns incluem: não há caminho real de um endpoint público até o sink, uma verificação anterior torna o achado inerte, um controle de runtime neutraliza-o, ou o segundo agente não conseguiu reproduzir o resultado.

Ciclo 3 — Corrigir

A terceira passagem pega cada achado verificado e redige um patch pronto para revisão. O patch não é uma correção genérica. É a mudança mínima que elimina o caminho de alcançabilidade preservando a lógica de negócio. O patch inclui testes de regressão (o exploit original vira um teste). O patch inclui atualizações de documentação.

É isso que faz um fluxo estruturado de remediação de segurança como o Plexicus Remediation. A saída é um pull request, não um trecho de código. Para ver como essa etapa roda de ponta a ponta sem passagens manuais, veja o playbook de remediação autônoma (em inglês).

Ciclo 4 — Auditar

A quarta passagem garante que o patch fecha o achado original. O verificador re-executa o exploit original contra a branch com patch. Se o exploit se reproduz, o patch é revertido. Se o exploit fica mitigado, o patch é assinado e o achado é fechado.

A saída do Ciclo 4 é um registro de auditoria: achado original, nó do grafo, referência à evidência, diff do patch, resultado do teste de regressão, aprovação do revisor, timestamp do deploy. Um registro por achado. Assinado. Reproduzível.

Por que isso não é “AppSec nativo de IA” com marketing melhor

O termo “AppSec nativo de IA” foi útil quando significava “os scanners usam modelos de machine learning”. Hoje todos os scanners usam modelos de machine learning. O diferenciador não é se a IA está envolvida. É se a IA está fundamentada.

Três modos de falha da era nativa de IA:

IA que resume achados sem fundamentá-los. O modelo lê a saída do SAST e produz um PDF mais legível. O auditor não consegue re-executar nada.
IA que propõe correções sem verificação. O modelo escreve um patch. O patch compila. O patch muda o significado do código. Espera-se que um revisor humano detecte isso. Não conseguem, em escala, ainda mais quando, segundo nossa análise, 78% dos PRs gerados por IA continham uma vulnerabilidade (em inglês).
IA que roda sem evidência. O modelo explora a aplicação. Encontra algo interessante. Reporta como achado. O relatório não é reproduzível.

AppSec orientada por provas é a resposta aos três. A estrutura é o padrão:

A detecção deve produzir um caminho, não um padrão.
A verificação deve ser independente, não autoconsistente.
A correção deve estar fundamentada na mesma evidência, não em uma sugestão genérica.
A auditoria deve ser reproduzível, não narrativa.

Qualquer coisa que não cumpra as quatro é o mesmo programa de AppSec com um logo diferente.

A remediação de vulnerabilidades na prática

Na base de clientes Plexicus que executam o padrão completo de quatro ciclos, o efeito prático tem a mesma forma: o tempo de triagem se comprime de dias para minutos, os falsos positivos caem após a verificação e o tempo até o merge cai porque o revisor lê um diff pequeno e respaldado por evidência em vez de uma lista não verificada.

Dois números definem se a prática está funcionando: com que frequência o auditor consegue re-executar a evidência e confirmar o achado, e com que frequência o auditor aceita que o patch corrige o que o achado afirmava. Todo o resto é vazão.

As medianas exatas variam conforme a base de código, a mistura de linguagens e a maturidade do CI. O padrão é o que escala.

O que o cenário de ameaças exige

O cenário de ameaças em 2026 é estruturalmente mais rápido que o ciclo do defensor:

O tempo até o exploit continua caindo. A Mandiant mediu um tempo médio até o exploit de cinco dias em 2023, ante 63 dias em 2018–2019.
A maior parte da exploração começa antes de existir uma correção: 70% das vulnerabilidades desse conjunto de dados da Mandiant foram exploradas como zero-days.
Agentes ofensivos com IA são baratos de rodar. O RapidPen obteve acesso a uma shell em 200–400 segundos por cerca de US$ 0,30–0,60 por execução.
A IA reduz a barreira de habilidade. A Amazon Threat Intelligence documentou um único agente com pouca habilidade técnica que, usando IA generativa comercial, comprometeu mais de 600 dispositivos FortiGate em 55 países em cerca de cinco semanas.

O pipeline do atacante já é orientado por provas. Eles verificam seus exploits antes de enviá-los. Reproduzem seus payloads. Auditam seus resultados. A assimetria não é “atacantes usam IA e defensores não”. A assimetria é “atacantes usam um ciclo fechado e defensores uma série de filas abertas”.

AppSec orientada por provas é o padrão operacional que fecha o ciclo do defensor.

Como montar um fluxo de remediação de segurança com as ferramentas que você já tem

A estrutura de quatro ciclos não é específica de um fornecedor. O padrão pode ser implementado com as ferramentas que sua equipe já tem:

Ciclo 1 (Detectar) — análise estática que produz caminhos de alcançabilidade. Plexicus Deep Code Analysis, ou qualquer scanner que vincule os achados ao grafo de chamadas em vez do número de linha.
Ciclo 2 (Verificar) — um engajamento de pentest com escopo assinado. Plexicus AI Swarm Pentest, ou um engajamento de pentest manual com captura de evidência (veja nossa comparação de ferramentas de pentest com IA).
Ciclo 3 (Corrigir) — um gerador de patches com testes de regressão. Qualquer fluxo de codificação com IA com instruções explícitas de fundamentar os patches no achado original.
Ciclo 4 (Auditar) — um hook de CI de re-teste que executa o exploit original contra a branch com patch. É também a evidência que o Secure Software Development Framework (SP 800-218) do NIST espera em suas práticas de “Respond to Vulnerabilities”.

Os quatro ciclos precisam estar conectados. A evidência do Ciclo 2 precisa chegar ao Ciclo 3. O patch do Ciclo 3 precisa ser re-verificado pelo Ciclo 2. O registro de auditoria do Ciclo 4 precisa incluir as referências de evidência dos Ciclos 1, 2 e 3.

Se alguma dessas transferências perder a evidência, o ciclo está quebrado. A prática deixa de ser orientada por provas.

O padrão para 2026

Três perguntas para fazer ao seu programa de segurança:

Seu scanner consegue produzir um caminho de alcançabilidade para cada achado? Se a resposta é “não, só um número de linha”, sua fila de triagem vai continuar crescendo.
Seu pentester consegue re-executar o achado contra um build limpo? Se a resposta é “teríamos que montar um novo engajamento”, sua trilha de evidência não é reproduzível.
Seu desenvolvedor consegue abrir o PR com o exploit original anexado? Se a resposta é “teria que pedir ao time de segurança para reencontrar”, sua trilha de auditoria não é contínua.

Se as três respostas forem “sim”, você está executando AppSec orientada por provas. Se alguma for “não” ou “mais ou menos”, a lacuna está na transferência de evidência, não nas ferramentas.

Perguntas frequentes

O que é o processo de remediação de vulnerabilidades?

O processo de remediação de vulnerabilidades é o conjunto de etapas que leva um achado de segurança da detecção até uma correção verificada em produção. Na AppSec orientada por provas ele tem quatro ciclos: detectar a falha com um caminho de alcançabilidade, verificá-la de forma independente, corrigi-la com um patch mínimo e um teste de regressão, e auditar o resultado executando novamente o exploit original contra o código corrigido.

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

A remediação elimina a vulnerabilidade em si, normalmente com uma mudança de código, atualização de dependência ou correção de configuração. A mitigação reduz o risco sem eliminar a falha, por exemplo com uma regra de WAF, um feature flag ou isolamento de rede. A mitigação ganha tempo; a remediação fecha o achado. Um bom processo registra qual foi aplicada e testa as duas novamente.

O que é AppSec orientada por provas?

AppSec orientada por provas é uma forma de conduzir a segurança de aplicações em que cada afirmação é sustentada por evidência que outra pessoa consegue executar novamente. Achados precisam de um caminho de alcançabilidade e de um exploit reproduzível, correções precisam de um teste de regressão criado a partir desse exploit, e o registro de auditoria liga tudo. Um achado que não se reproduz é uma hipótese.

Como verificar se uma remediação de segurança funcionou?

Execute novamente o exploit original contra o build com patch. Se o exploit não funciona mais e o teste de regressão derivado dele passa no CI, a correção está verificada. Se ainda se reproduz, o patch está incompleto e deve ser revertido. Mantenha o exploit, o diff do patch e o resultado do teste juntos em um único registro de auditoria.

Como as equipes devem priorizar vulnerabilidades para remediação?

Priorize achados verificados e alcançáveis a partir de uma entrada real em vez de pontuações de severidade brutas. Uma falha de severidade média com caminho confirmado a partir de um endpoint público costuma ser mais urgente que uma crítica inalcançável. Alcançabilidade, evidência de exploit e a capacidade que um atacante ganharia são sinais melhores que o CVSS sozinho.

Para onde isso vai

Nos próximos dois anos, todo regulador vai fazer a mesma pergunta: você consegue re-executar a evidência que provou que este controle estava funcionando quando o incidente aconteceu? Equipes que executam AppSec orientada por provas vão responder “sim” com o artefato original. Equipes com o padrão antigo vão responder “temos um PDF”.

O investimento para fechar a lacuna não é grande. A disciplina para mantê-la fechada, sim.

Leitura relacionada:

O que é Deep Code Analysis? — Ciclo 1
78% dos PRs gerados por IA contêm uma vulnerabilidade — por que a verificação é o novo gargalo
O playbook de remediação autônoma — Ciclo 3 em detalhe
Guia de campo OWASP MAESTRO para modeladores de ameaças — a arquitetura de referência para os agentes que executam os ciclos

Do alerta à correção: um processo de remediação de vulnerabilidades com AppSec orientada por provas

AppSec orientada por provas para equipes que desenvolvem com IA