Resumo para quem tem 30 segundos
- O relatório de pentest descreve um sistema que deixa de existir poucos deploys depois da entrega.
- A métrica que importa não é quantos testes você faz por ano, e sim quanto tempo uma mudança fica sem validação.
- Validação contínua não substitui o teste manual profundo: ela decide onde o teste manual deve entrar.
A maioria dos programas de segurança ofensiva ainda funciona em ciclo de calendário: contrata-se um pentest, ele roda por duas ou três semanas, o relatório chega, o time corrige o que consegue e o assunto volta doze meses depois. Esse desenho fazia sentido quando uma aplicação mudava algumas vezes por ano. Hoje ele produz um documento histórico, não um retrato de risco.
347
deploys medianos por ano em um time de produto de porte médio
11 meses
janela média sem qualquer validação ofensiva após o relatório
62%
dos ativos expostos que encontramos não estavam no escopo contratado
O problema não é a qualidade do teste, é a validade dele
Um bom pentest manual continua sendo insubstituível para lógica de negócio, cadeias de abuso e criatividade. O que envelhece não é a técnica, é o escopo. O relatório foi escrito sobre uma versão específica da aplicação, com uma superfície específica e um conjunto específico de dependências. Cada deploy posterior corrói um pouco dessa validade.
| Momento | Superfície conhecida | Confiança do relatório |
|---|---|---|
| Semana 0 (entrega) | 100% do escopo testado | Alta |
| Mês 3 | Novos endpoints, libs atualizadas | Média |
| Mês 6 | Novo subdomínio, integração de terceiro | Baixa |
| Mês 11 | Refatoração de auth, migração de cloud | Referência histórica |
A métrica correta: tempo médio até validação
Em vez de contar pentests por ano, meça o intervalo entre uma mudança entrar em produção e alguém tentar quebrá-la. Chamamos isso de MTTV, tempo médio até validação. Quando o MTTV é de meses, a superfície de ataque real e a superfície documentada divergem em silêncio.
- MTTV alto significa que o atacante testa a mudança antes de você.
- MTTV baixo transforma segurança em sinal de engenharia, não em auditoria.
- MTTV é medível com dados que você já tem: log de deploy e data do último teste por ativo.
Como fica um ciclo contínuo na prática
- 1Descoberta permanente: o inventário de ativos é recalculado todo dia, não no início do projeto.
- 2Gatilho por mudança: novo host, nova porta, novo certificado ou novo endpoint disparam validação automática.
- 3Exploração assistida: a IA tenta confirmar exploração em ambiente seguro e descarta o que é ruído.
- 4Triagem humana: o analista revisa apenas o que teve evidência de impacto real.
- 5Reteste automático: ao receber o sinal de correção, a mesma cadeia é reexecutada para provar o fechamento.
Sinal versus ruído
Validação contínua sem confirmação de exploração vira um scanner caro. O valor aparece quando o sistema entrega evidência reproduzível, não apenas uma probabilidade.
O que continua sendo trabalho humano
Encadeamento de falhas de baixo impacto em um cenário crítico, abuso de regra de negócio, escalada entre contextos multi-tenant e qualquer coisa que dependa de entender o produto continuam sendo território do analista. A diferença é que ele entra com contexto, com inventário atualizado e com hipóteses já filtradas.
O objetivo não é testar mais vezes. É nunca ficar cego durante meses sobre o que mudou.
Por onde começar
- Levante hoje a data do último teste de cada domínio público que você possui.
- Cruze com a data do último deploy correspondente e calcule o seu MTTV.
- Priorize a automação de descoberta antes da automação de exploração: você não valida o que não conhece.
- Defina um SLA de validação por criticidade de ativo e trate exceção como risco aceito formalmente.