Software house média no Brasil entrega 30 a 50 releases por semana em pipelines que raramente foram desenhados com segurança em mente. O modelo abaixo é uma adaptação enxuta do OWASP SAMM e do BSIMM para o contexto de fábrica de software brasileira: quem atende cliente terceiro, quem tem dezenas de repositórios ativos e um time de segurança que, na melhor das hipóteses, cabe em uma mesa.

Por que um modelo de maturidade?

Sem baseline, todo investimento em AppSec parece ad-hoc. O board pergunta "estamos seguros?" e o CTO responde com adjetivos. Um modelo de maturidade converte a conversa em uma coordenada: hoje estamos no nível 2, meta é nível 3 até o Q3, e o custo/benefício de cada salto é previsível.

Os 5 níveis

Nível 0 — Reativo

Segurança só entra em pauta depois de incidente. Não existe inventário de aplicações, dependências vêm do "npm install" mais recente e o pipeline não bloqueia nada.

• Características: sem OWASP na conversa, sem SAST/DAST, secrets em .env versionado, releases sem revisão de segurança.
• Indicadores: MTTD > 30 dias, backlog de CVEs desconhecido, 100% dos pentests contratados sob pressão de cliente.
• Próximo passo: inventário de ativos e política mínima. Ligue um scanner externo contínuo — apenas medir já move a agulha.

Nível 1 — Consciente

Existe pentest anual, alguém do time leu o OWASP Top 10 e há uma planilha de "coisas a arrumar". Vulnerabilidades são tratadas quando o cliente cobra.

• Características: pentest 1x/ano, dependabot ligado mas ignorado, revisão de PR informal.
• Indicadores: MTTR de crítico > 30 dias, 60% das vulnerabilidades vazam para produção.
• Próximo passo: definir SLA por severidade (crítico 7 dias, alto 30 dias) e ligar DAST contínuo. Veja o OWASP Top 10 2026 com exemplos para calibrar a régua.

Nível 2 — Repetível

Segurança tem um dono (mesmo que part-time). SAST no CI, dependência escaneada, política de secrets. O pipeline quebra em crítico.

• Características: gate no CI para severidade alta, threat modeling em features novas de risco, revisão de PR com checklist.
• Indicadores: MTTR de crítico entre 7 e 15 dias, cobertura SAST > 80% do código de produção.
• Próximo passo: DAST contínuo em ambientes de staging e produção, treinamento anual dos devs, formalização do processo de resposta a incidente.

Nível 3 — Gerenciado

Segurança é parte do SDLC, não um estágio no final. Métricas circulam mensalmente no comitê executivo. Testes automatizados cobrem OWASP Top 10 e camadas específicas do negócio (LGPD, PCI se aplicável).

• Características: threat modeling obrigatório para features de risco, red-team interno trimestral, SBOM gerado a cada build, resposta a incidente ensaiada.
• Indicadores: MTTR de crítico < 7 dias, MTTD < 24h, 0 secrets em código, taxa de escape < 5%.
• Próximo passo: métricas DORA cruzadas com métricas de segurança, program de bug bounty privado, automação de compliance LGPD.

Nível 4 — Preditivo

Segurança é uma propriedade emergente do sistema. Detecção comportamental, análise de risco por feature, threat intel alimentando o pipeline. AppSec influencia arquitetura desde o RFC.

• Características: detecção baseada em anomalia, chaos engineering de segurança, atualização de dependência automatizada com testes, program de bug bounty público.
• Indicadores: MTTR de crítico < 24h, MTTD < 15 min, taxa de escape < 1%, ROI de segurança auditável.
• Próximo passo: aqui é evolução contínua. Foco em reduzir toil e integrar segurança à experiência do desenvolvedor.

Tabela-resumo

| Nível | Nome | MTTD | MTTR crítico | Escape rate | Investimento típico (% eng) | |-------|------|------|--------------|-------------|-----------------------------| | 0 | Reativo | > 30 dias | Ad-hoc | > 40% | 0-1% | | 1 | Consciente | 7-30 dias | > 30 dias | 30-40% | 1-3% | | 2 | Repetível | 3-7 dias | 7-15 dias | 10-20% | 3-6% | | 3 | Gerenciado | < 24h | < 7 dias | < 5% | 6-10% | | 4 | Preditivo | < 15 min | < 24h | < 1% | 10-15% |

Como usar em uma software house brasileira

Três recomendações práticas:

1. Meça antes de investir. Rode um scanner externo em toda a base por 30 dias. O relatório inicial define o nível real, não a autoavaliação.
2. Suba um nível por semestre. Pular níveis quebra cultura. Nível 0 para 2 em três meses tende a virar teatro de compliance.
3. Amarr metas de segurança a métricas DORA. Deploy frequency e change failure rate ficam mais confiáveis com AppSec maduro — é o discurso que o board entende.

Empresas que querem começar pelo nível 1 ou 2 sem contratar analistas dedicados usam DAST contínuo como base. A Varredura monitora sua superfície 24/7, testa OWASP e devolve findings priorizados por severidade, sem tocar em código-fonte. Rode agora e descubra seu nível real.