Nível 0 no OWASP SAMM não quer dizer time ruim. Quer dizer que a prática não existe de forma reconhecível: ninguém escreveu, ninguém repete, ninguém mede. É onde começa quase toda empresa de 20 a 200 pessoas, inclusive as que rodam CI/CD há anos e têm um scanner ligado em algum lugar.
A pergunta que o cliente faz não é quanto vale o SAMM. É quanto tempo até isso parar de doer. A resposta honesta: nas práticas que importam, de nove a doze meses. O que segura não é a complexidade do modelo. É a ordem em que você ataca.
O modelo é menor do que parece
O SAMM v2 tem cinco funções de negócio: Governance, Design, Implementation, Verification e Operations. Cada função tem três práticas de segurança, o que dá quinze. Cada prática se divide em dois streams e cada stream tem três níveis. Cinco vezes três vezes dois vezes três: noventa atividades. É o modelo inteiro, e ele cabe numa planilha.
O nível 0 é implícito — a atividade não acontece. O nível 1 costuma ser faça de forma consciente, ainda que ad hoc. O nível 2 é padronize e automatize. O nível 3 é aplique como regra e otimize com dados. A progressão é a mesma nas quinze práticas, o que torna o modelo previsível de planejar.
O próprio guia do SAMM diz que preparar, avaliar, definir o alvo e montar o plano — os quatro primeiros passos — levam de um a dois dias de uma pessoa. Os passos 5 e 6, executar e distribuir, é que consomem meses. O diagnóstico nunca foi o gargalo.
O benchmark oficial calibra a expectativa. São 30 avaliações, mais de 80% conduzidas por avaliadores externos e cerca de 60% vindas de multinacionais. A média geral é 1,44 de 3,0. Por função: Operations 1,81, Design 1,50, Implementation 1,46, Governance 1,35 e Verification 1,12. O relatório reconhece que empresas menores estão sub-representadas.
Leia de novo o número mais baixo. Verification — teste de segurança, revisão de requisitos, avaliação de arquitetura — fica em 1,12 num conjunto dominado por empresas grandes. Maturidade de AppSec não é privilégio de orçamento. É consequência de método.
As cinco práticas que movem o risco primeiro
Nem toda prática rende igual. Cinco delas concentram a queda de risco por real investido, e a ordem entre elas importa mais do que a escolha de ferramenta.
Secure Build. Nível 1: o processo de build está escrito e é repetível, e você mantém um bill of materials das dependências. Nível 2: pipeline automatizado, ferramental do build protegido, checagens de segurança rodando. Nível 3: as checagens são obrigatórias e o build de um artefato não conforme falha. É o salto mais barato do conjunto, porque é configuração de pipeline e não reorganização de time. E é o único que impede regressão.
Secure Deployment. Nível 1: deploy formalizado, ferramental protegido, acesso a segredos de produção restrito. Nível 2: deploy automatizado em todos os estágios, com testes de verificação de segurança, e segredos injetados dinamicamente a partir de cofre, com auditoria de acesso humano. Nível 3: integridade de todo software implantado verificada automaticamente. Barato até o nível 2. Caro no 3, porque exige assinatura e proveniência.
Defect Management. Nível 1: rastreio estruturado dos defeitos de segurança. Nível 2: severidade avaliada de forma consistente e SLA por classe. Nível 3: SLA aplicado e sistema de defeitos integrado ao resto do ferramental. Custo quase zero em licença, alto em disciplina. É aqui que a maioria trava, e a leitura do benchmark aponta exatamente a falta de métricas úteis como ponto fraco.
Security Testing. Nível 1: ferramentas automatizadas rodando, mais teste manual dos componentes de maior risco. Nível 2: automação específica da aplicação e pentest manual. Nível 3: teste de segurança integrado ao build, ao deploy e ao processo de desenvolvimento. O nível 1 é uma tarde de trabalho. O nível 2 exige escrever casos de abuso para as suas regras de negócio, e é aí que o benchmark mostra a maioria parando.
Threat Assessment. Nível 1: perfil de risco básico da aplicação e threat modeling de melhor esforço, com brainstorming, os diagramas que já existem e um checklist simples. Nível 2: treinamento, processo e ferramentas padronizados. Nível 3: metodologia otimizada e automatizada de forma contínua. Threat modeling está entre as práticas de menor nota no benchmark, e a leitura dos avaliadores é direta: as empresas tratam a prática como esotérica. A versão pragmática cabe numa sessão de duas horas por serviço.
| Nível 1 | Nível 2 | Nível 3 | |
|---|---|---|---|
| Secure Build | Processo de build documentado e repetível, com SBOM das dependências | Pipeline automatizado, ferramental protegido, checagens rodando | Checagens obrigatórias — build de artefato não conforme falha |
| Secure Deployment | Deploy formalizado, ferramental protegido, acesso a segredo restrito | Deploy automatizado com testes de verificação; segredos via cofre | Integridade de todo software implantado verificada automaticamente |
| Defect Management | Rastreio estruturado dos defeitos de segurança | Severidade avaliada de forma consistente + SLA por classe | SLA aplicado e sistema integrado ao resto do ferramental |
| Security Testing | Ferramentas automatizadas + teste manual do maior risco | Automação específica da aplicação + pentest manual | Teste integrado ao build, ao deploy e ao desenvolvimento |
| Threat Assessment | Perfil de risco básico + threat modeling de melhor esforço | Treinamento, processo e ferramentas padronizados | Metodologia otimizada e automatizada de forma contínua |
A IA escreve metade do código; a revisão não acompanhou
O relatório GenAI Code Security 2026 da Veracode testou mais de 100 modelos em tarefas de geração de código. A taxa média de aprovação em segurança é de 56%, contra 55% no primeiro relatório. Cerca de 44% das tarefas produziram uma vulnerabilidade. O melhor modelo do conjunto, GPT-5.5, chega a 68% e ainda falha em quase uma tarefa de segurança a cada três.
A distribuição é mais útil que a média. Criptografia passa em 87% dos casos e SQL injection em 83%. XSS passa em 15%. Log injection, em 12%. Traduzindo: o modelo aprendeu a usar consulta parametrizada e continua concatenando saída para o usuário. E a Veracode estima que a IA já escreve cerca de metade do código commitado nas organizações que usam essas ferramentas.
O volume de dependência acompanha. A Sonatype identificou mais de 454.600 novos pacotes maliciosos em 2025, num acumulado de 1,233 milhão de pacotes bloqueados. Em 55,9% dos casos, o vetor é abuso do próprio repositório público.
O efeito aparece no passivo. No State of Software Security 2026 da Veracode, dívida de segurança atinge 82% das organizações, contra 74% em 2025 e 71% em 2024. Dívida crítica — falha grave aberta há mais de um ano — sobe para 60%. Vulnerabilidades de alto risco crescem 36% em doze meses.
A conclusão prática não é parar de usar IA. É que o gargalo saiu da escrita e foi para a revisão. Gate no build e teste automatizado deixaram de ser boa prática e viraram condição de operação. Nenhum time de PME revisa manualmente o dobro de código com o mesmo número de pessoas.
O plano, trimestre a trimestre
As premissas mudam o prazo, então valem explícitas: 15 a 40 pessoas em engenharia, 3 a 8 serviços em produção, um único provedor de CI, um engenheiro sênior como responsável técnico com 8 horas por semana, mais 2 horas semanais de cada squad, e ferramenta aberta — SAST, scanner de dependência e de imagem, DAST e um cofre de segredos. Sem contratação dedicada. Com 40 repositórios e três provedores de CI, some um trimestre.
Trimestre 1 — Secure Build ao nível 2, Defect Management ao nível 1. Um pipeline de referência, SBOM gerado em todo build, scanner de dependência e de segredo em modo aviso, e uma fila única de defeitos de segurança. Nada bloqueia ainda. O objetivo do trimestre é ter número, não ter gate.
Trimestre 2 — Secure Build ao nível 3, Security Testing ao nível 1. As checagens viram obrigatórias e o build falha em achado crítico novo. A regra que salva o cronograma: bloqueie só o que é novo. O passivo antigo entra pela fila com SLA, não pelo gate. Caso contrário o time desliga o gate na primeira sexta-feira.
Trimestre 3 — Threat Assessment aos níveis 1 e 2, Secure Deployment ao nível 2. Perfil de risco por serviço, uma sessão de threat modeling por serviço com checklist, e segredos saindo de variável de ambiente para cofre com injeção dinâmica e auditoria de acesso humano. É o trimestre com mais conversa e menos ferramenta.
Trimestre 4 — Security Testing ao nível 2, Defect Management aos níveis 2 e 3. Casos de abuso escritos para as regras de negócio críticas, um pentest externo contratado, SLA por severidade publicado e aplicado. No fim do quarto trimestre há nível 3 onde ele muda o risco e nível 2 no resto do núcleo. Governance e Operations sobem de carona: política versionada e resposta a incidente viram consequência do que foi construído.
- Q1Secure Build nível 2 + Defect Management nível 1 — só medir, nada bloqueia
- Q2Secure Build nível 3 + Security Testing nível 1 — gate obrigatório só para achado novo
- Q3Threat Assessment níveis 1–2 + Secure Deployment nível 2 — segredos saem do .env para o cofre
- Q4Security Testing nível 2 + Defect Management níveis 2–3 — pentest externo e SLA publicado
Medir sem fraudar o placar
A nota do SAMM é subproduto. Se ela virar meta, o time aprende a marcar caixinha. Quatro medidas resistem melhor à manipulação.
Percentual de builds que passaram pelo gate obrigatório, não percentual de repositórios com scanner instalado. Tempo mediano entre detecção e correção por severidade, medido na fila de defeitos e comparado ao SLA publicado. Idade do achado crítico mais antigo em aberto, que é o único número que denuncia dívida escondida. E proporção de achados vindos do pipeline em vez de auditoria externa: se o pentest continua encontrando o que o pipeline deveria pegar, o pipeline é decorativo.
- 01% de builds pelo gate obrigatório
Não percentual de repositórios com scanner instalado — mede o que de fato bloqueia, não o que só está ligado.
- 02Tempo mediano de detecção até correção
Por severidade, medido na fila de defeitos e comparado ao SLA publicado.
- 03Idade do achado crítico mais antigo em aberto
O único número que denuncia dívida escondida.
- 04Proporção de achados vindos do pipeline
Em vez de auditoria externa: se o pentest ainda encontra o que o pipeline deveria pegar, o pipeline é decorativo.
Duas regras de higiene. Congele o escopo da avaliação, com o mesmo conjunto de serviços em cada rodada, senão a média sobe sem nada mudar. E exija evidência: artefato, log, configuração versionada. No benchmark do SAMM, mais de 80% das avaliações foram feitas por terceiros, e isso não é acaso.
Se for preciso traduzir para outro vocabulário, o NIST SSDF (SP 800-218) traz 19 práticas e 42 tarefas em quatro grupos e funciona bem como linguagem comum com cliente e auditoria. O OWASP DSOMM desce ao nível da atividade técnica de pipeline. E o guia de 12 passos da ENISA cobre o que fica fora do código.