Do alerta à correção: fechando o ciclo com AppSec orientada por provas

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, atacantes executam exploração automatizada por centavos por tentativa e comprometem um novo dispositivo a cada poucos minutos. A mediana de várias semanas para corrigir 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:

1. 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.
2. 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.
3. 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.

A estrutura de 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 Deep Code Analysis faz. 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 de remediação estruturado. A saída é um pull request, não um trecho de código.

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:

1. 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.
2. 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.
3. 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.

O ciclo operacional 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 de vulnerabilidades recém-publicadas se comprimiu de anos para horas. Sub-dia é agora a norma para alvos de alto perfil.
• O arsenal ofensivo open-source com IA se multiplicou. A emergência de classe de ferramenta mais rápida da história da segurança ofensiva.
• Grupos de ransomware com um único operador comprometeram centenas de dispositivos em dezenas de países em uma única campanha.
• Uma parcela significativa das vulnerabilidades exploradas estava ativa antes da publicação de um CVE.

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 isso se parece para uma equipe de engenharia real

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.
• 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.

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:

1. 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.
2. 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.
3. 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.

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