--- title: "SAMM 0→3 em PME: 12 meses, cinco práticas e a ordem que importa - OkamiOps Insights" description: "O OWASP SAMM tem 90 atividades e uma escala de 0 a 3 por prática. No benchmark oficial, dominado por multinacionais, a média é 1,44 — e Verification fica" url: https://okamiops.com/pt/insights/appsec-maturity-smb-2026/ lang: pt-BR alternates: en: https://okamiops.com/insights/appsec-maturity-smb-2026/ pt-BR: https://okamiops.com/pt/insights/appsec-maturity-smb-2026/ de: https://okamiops.com/de/insights/appsec-maturity-smb-2026/ x-default: https://okamiops.com/insights/appsec-maturity-smb-2026/ lastmod: 2026-09-10 --- # SAMM 0→3 em PME: 12 meses, cinco práticas e a ordem que importa APPSEC · FEV · 2026 · 8 min O OWASP SAMM tem 90 atividades e uma escala de 0 a 3 por prática. No benchmark oficial, dominado por multinacionais, a média é 1,44 — e Verification fica em 1,12. A barra do maduro é mais baixa do que a palavra sugere. Com escopo apertado e a ordem certa, uma PME chega ao nível 3 nas práticas críticas em quatro trimestres. - **Categoria**: AppSec - **Data**: FEV · 2026 - **Leitura**: 8 min - **Fontes**: 8 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 roteiro em três números** - **9–12 meses** — até nível 3 nas práticas críticas - **5 práticas** — concentram a queda de risco por real investido - **8h + 2h /semana** — um sênior responsável + 2h por squad, sem contratação ## 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. **O que nível 1, 2 e 3 significam nas cinco práticas** (OWASP SAMM v2 · escala 0–3 por stream) | | 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. **O plano, trimestre a trimestre** - **Q1** — Secure Build nível 2 + Defect Management nível 1 — só medir, nada bloqueia - **Q2** — Secure Build nível 3 + Security Testing nível 1 — gate obrigatório só para achado novo - **Q3** — Threat Assessment níveis 1–2 + Secure Deployment nível 2 — segredos saem do .env para o cofre - **Q4** — Security 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. **Quatro medidas que resistem à manipulação** 1. **% 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. 2. **Tempo mediano de detecção até correção** — Por severidade, medido na fila de defeitos e comparado ao SLA publicado. 3. **Idade do achado crítico mais antigo em aberto** — O único número que denuncia dívida escondida. 4. **Proporçã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. **SAMM nas práticas críticas · PME · mês 0 vs mês 12** (nível 3 = máximo do modelo) | Item | Valor | | --- | --- | | secure build · M0 | 0 | | secure build · M12 | 3 | | security testing · M0 | 0 | | security testing · M12 | 2 | | threat assessment · M0 | 0 | | threat assessment · M12 | 2 | | defect management · M0 | 1 | | defect management · M12 | 2 | > **O que fazer amanhã**: Comece por Secure Build: gate obrigatório que bloqueia só achado novo, com o passivo antigo indo para uma fila com SLA. É a única mudança que impede regressão enquanto o resto sobe. ## Fontes desta análise - **01**: [OWASP SAMM · The Model (v2)](https://owaspsamm.org/model/) - **02**: [OWASP SAMM · The SAMM Benchmark Report](https://owaspsamm.org/benchmark/benchmark-report/) - **03**: [OWASP SAMM · Quick Start Guide](https://owaspsamm.org/docs/getting-started/) - **04**: [Veracode · 2026 State of Software Security](https://www.veracode.com/blog/2026-state-of-software-security-report-risky-security-debt/) - **05**: [Veracode · 2026 GenAI Code Security Report](https://www.veracode.com/blog/2026-genai-code-security-report-ai-risk/) - **06**: [Sonatype · 2026 State of the Software Supply Chain](https://www.sonatype.com/state-of-the-software-supply-chain/2026/open-source-malware) - **07**: [NIST · SP 800-218 Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final) - **08**: [ENISA · Cybersecurity guide for SMEs: 12 steps](https://www.enisa.europa.eu/publications/cybersecurity-guide-for-smes) ## Continue lendo - **CONSULTORIA · AGO · 2026**: [Quanto custa implementar IA em 2026: as três faixas, com as contas abertas](https://okamiops.com/pt/insights/quanto-custa-implementar-ia-2026/) (6 min) - **GATEWAY · JUL · 2026**: [Output de LLM varia 106× entre fornecedores. Sua PME paga o teto.](https://okamiops.com/pt/insights/llm-cost-spread-2026/) (6 min) - **APPSEC · ABR · 2026**: [OWASP LLM Top 10 (2025): cinco riscos que já viraram incidente — e como cobrir cada um](https://okamiops.com/pt/insights/owasp-llm-top-10-2025/) (8 min) ## Sem opinião solta. Cada número tem fonte, cada artigo termina com o que fazer. Escrevemos o que aprendemos resolvendo o problema em cliente. Se o seu caso parece com algum destes, a conversa começa por aqui.