📬 Toda semana, um resumo de segurança, Clean Code e IA no seu e-mail Inscreva-se →

SAMM: o que é e como aplicar o Software Assurance Maturity Model

Uma pergunta que aparece direto quando o assunto é maturidade de segurança: “a gente tá bem ou tá mal?”. Sem um framework de referência, essa pergunta não tem resposta objetiva — vira opinião de quem tá mais estressado no dia. O SAMM existe pra tirar essa pergunta do campo da opinião e colocar num critério mensurável.

O que é o SAMM

SAMM é sigla de Software Assurance Maturity Model, mantido pela OWASP. É um framework organizacional — não uma ferramenta que você instala, mas um modelo de avaliação que te diz onde sua empresa está em termos de maturidade de segurança de software, e principalmente, o que fazer pra melhorar de forma incremental. Ele foi desenhado pra times medirem continuamente a segurança dos próprios sistemas, identificarem lacunas de implementação e alinharem prática de segurança com objetivo de negócio — não segurança pela segurança, segurança que faz sentido pro contexto da empresa.

A diferença prática do SAMM pra “vamos rodar um scanner e ver no que dá” é que ele olha o processo como um todo, não só o código. Você pode ter o melhor SAST do mercado rodando e ainda assim ser imaturo em SAMM, porque falta governança, falta processo de resposta a incidente, falta treinamento de time.

As cinco funções de negócio

O SAMM v2 organiza a avaliação em cinco domínios:

1. Governança — estratégia organizacional de segurança: política, cultura, métrica, gestão de compliance, programa de conscientização do time. Se ninguém sabe qual é a política de segurança da empresa, você está aqui na base.

2. Design — segurança incorporada na fase de planejamento: modelagem de ameaça (threat modeling), definição de requisito de segurança, planejamento de arquitetura segura.

3. Implementação — segurança durante o desenvolvimento de fato: processo de build seguro, procedimento de deploy seguro, rastreamento de vulnerabilidade encontrada.

4. Verificação — validação de que a segurança realmente funciona: revisão de arquitetura, teste baseado em requisito, atividade de pentest.

5. Operações — segurança em produção: monitoramento de incidente, hardening de sistema, gestão de patch, proteção de dado.

Repare que isso cobre o ciclo inteiro, não só o código — é por isso que o SAMM funciona bem como complemento do que eu já falei sobre segurança integrada ao SDLC. O SDLC te diz onde inserir segurança em cada fase; o SAMM te diz o quão maduro você está em cada uma dessas frentes.

Os três níveis de maturidade

Para cada uma das cinco funções, o SAMM define três níveis:

  • Nível 1 (Básico): prática ad hoc, não estruturada, documentação mínima ou inexistente. Segurança acontece quando alguém lembra.
  • Nível 2 (Gerenciado): processo formalizado, com monitoramento, métrica definida e treinamento consistente incorporado à rotina.
  • Nível 3 (Avançado): melhoria contínua, segurança automatizada, cultura organizacional incorporada, inovação constante.

Na prática, a maioria das empresas que eu vejo está em nível 1 em Governança e Operações, e talvez nível 2 em Implementação (porque já tem CI/CD com algum scanner rodando). Isso não é vergonha nenhuma — é o ponto de partida real da maioria dos times, e é exatamente pra isso que o modelo serve: te mostrar onde investir primeiro em vez de tentar melhorar tudo ao mesmo tempo.

Como aplicar o SAMM na prática

Passo a passo que funciona sem precisar contratar consultoria cara pra começar:

1. Faça a autoavaliação. A OWASP disponibiliza planilhas e questionários de autoavaliação gratuitos para cada função de negócio. Reserve um dia com as lideranças técnicas e responda com honestidade — o valor do exercício desaparece se você responder o que “deveria ser” em vez do que realmente é.

2. Defina objetivos realistas com prazo. Não tente ir de nível 1 pra nível 3 em Governança em um trimestre. Escolha uma ou duas funções prioritárias (normalmente Implementação e Verificação, que têm impacto mais direto e visível) e trace metas de 90 dias.

3. Invista em treinamento do time. Boa parte da evolução de nível 1 pra nível 2 não é ferramenta, é conhecimento — dev que entende o OWASP Top 10, que sabe o que é threat modeling básico, que sabe revisar um PR pensando em segurança.

4. Use os recursos abertos da comunidade. A própria OWASP mantém ferramentas, guias e comunidade ativa que complementam o SAMM — não precisa reinventar processo do zero.

5. Implemente monitoramento contínuo. KPI de segurança, auditoria periódica, simulação de incidente. Sem medir de novo depois de um tempo, você não sabe se a mudança realmente pegou ou se foi só um esforço de curto prazo que esfriou.

Exemplo de autoavaliação simplificada

Pra dar uma ideia concreta de como isso fica na prática, uma versão resumida de como pontuar a função de Implementação:

PráticaNível 1Nível 2Nível 3
Build seguroSem processo definidoPipeline com SAST/SCA obrigatórioPipeline com gate automático + métricas de tendência
DeployManual, sem checklistChecklist documentado seguidoDeploy automatizado com rollback e auditoria
Rastreamento de vulnerabilidadePlanilha informal ou nadaTicket no sistema de issue trackingDashboard com SLA de correção por severidade

Se sua empresa está na coluna do meio na maioria das linhas, você já está em nível 2 de Implementação — não é pouco, é razoavelmente maduro pra maioria dos times de mercado.

O que o SAMM não resolve sozinho

Vale ser honesto: o SAMM te dá o mapa, não a viagem. Ele não escreve o threat model pra você, não configura o SAST, não treina seu time. É um framework de diagnóstico e direcionamento — o trabalho de execução continua sendo seu. E como qualquer framework de maturidade, o risco real é usar ele como exercício de auditoria única (“fizemos a avaliação em janeiro”) em vez de prática recorrente. Maturidade que não é revisitada periodicamente regride sozinha, porque time muda, prioridade muda, e segurança é a primeira coisa que a pressão de prazo tende a cortar se ninguém está olhando o indicador.

Se você quer ver como cada uma dessas cinco funções se encaixa nas fases específicas do ciclo de desenvolvimento, o artigo sobre segurança em cada fase do SDLC aqui no blog complementa bem esse.

Leandro Rosendo Candido

Leandro Rosendo Candido

Engenheiro de Computação, mestre pela USP, 10+ anos com Embedded Linux. Escreve e grava sobre segurança, Clean Code e IA aplicada à programação.

Rolar para cima