Times maduros já têm SAST, DAST, pipeline bem definida, às vezes até SCA rodando com política de bloqueio. O código passa, os testes passam e o deploy acontece sem atrito. Mesmo assim, o incidente ocorre. Muitas vezes porque a lógica não foi questionada.
SAST e DAST encontram padrões conhecidos. Injection, dependência vulnerável, uso incorreto de API. Isso cobre uma parte importante do risco. Mas não cobre o fluxo de negócio. Uma feature que permite exportar dados pode estar tecnicamente correta e, ainda assim, permitir que um usuário acesse informações de outra conta só alterando um ID. Decisão de produto que passou sem modelagem.
Threat Modeling entra nesse ponto. Antes de escrever código, alguém do time olha para a feature e tenta quebrar a ideia, não a sintaxe. Essa mudança desloca a discussão de “esse código está seguro?” para “essa funcionalidade pode ser abusada?”
A lacuna entre código e contexto
Ferramentas automatizadas não têm contexto. Elas não sabem quais dados são sensíveis para o negócio, quais fluxos já causaram incidente, nem quais atalhos o time costuma tomar sob pressão. Quem sabe isso é o time.
E, na prática, uma pessoa costuma concentrar esse tipo de percepção: o Security Champion. Porque é o time que costuma fazer a pergunta que importa na hora certa. No refinamento, ele puxa o fio: esse dado deveria circular assim? No code review, muda o foco: esse endpoint valida só autenticação ou também autorização? No incidente, conecta os pontos: esse fluxo já falhou antes?
E assim, não deixa o contexto escapar.
STRIDE não é teoria quando cabe no tempo do time
Quando Threat Modeling vira workshop longo, ele morre na próxima sprint. O que funciona no dia a dia é um roteiro curto que cabe dentro do refinamento. Algo que o time consegue repetir toda semana, sem depender de agenda extra.
O STRIDE acaba sendo adotado por isso. São seis ângulos para olhar uma mesma feature. Se alguém pode se passar por outro, alterar dados, negar ações, acessar informação indevida, abusar volume ou escalar privilégio.
Se existe dúvida, já existe risco.
A maior parte dos problemas aparece aí, antes da primeira linha de código. Porque ninguém tinha parado para enxergar o fluxo inteiro.
30 minutos que evitam retrabalho real
Como já se sabe em desenvolvimento, quanto mais tarde um problema de segurança aparece, mais caro ele fica. Não só pelo esforço técnico de corrigir. Mas pelo impacto em arquitetura, backlog e, em alguns casos, reputação.
Inserir uma análise rápida no início muda essa curva.
Em vez de descobrir um IDOR depois que a API está publicada, o time percebe durante o desenho que a autorização ainda não está definida. Em vez de discutir rate limit em produção, já decide se aquilo é necessário na primeira versão.
Torna o risco visível. E visibilidade já resolve metade do problema.
O efeito colateral do “Vibe Coding”
A adoção de IA no desenvolvimento trouxe velocidade. Também trouxe um tipo novo de erro. Código gerado compila, passa nos testes e não acende alerta no SAST. Tudo parece correto.
Só que a IA não conhece o seu contexto. Ela não sabe que aquele endpoint precisa validar ownership do recurso. Não sabe que determinados campos carregam informação sensível, nem quais integrações têm restrição contratual. O padrão começa a aparecer nos incidentes recentes, como autenticação presente, autorização ausente. Fluxo funcionando, regra de negócio quebrada.
Sem modelagem, o time passa a revisar código sintaticamente correto e logicamente vulnerável.
IA ajuda, mas não substitui a pergunta certa
Dá para usar IA no próprio Threat Modeling. Gerar rascunho de análise, sugerir ameaças comuns, levantar controles iniciais. Funciona bem para cobrir o básico. Mas o que realmente importa continua dependendo de alguém que conhece o sistema de verdade.
O risco relevante nasce da forma como o produto foi desenhado, das decisões feitas ao longo do tempo, das exceções que viraram regra. IA acelera. Contexto decide.
Segurança como fluxo, não como etapa
O efeito mais interessante de colocar Threat Modeling no dia a dia é cultural. O time começa a tomar decisões com mais consciência. Risco deixa de ser algo que aparece em relatório e passa a fazer parte da conversa de produto. Nem tudo será corrigido na hora. Mas quando um risco é aceito, ele é aceito de forma explícita.
Isso muda a relação com incidentes. Eles deixam de ser surpresa e começam a ser consequência de escolhas feitas sabendo o custo.
