Threat modeling em Go: como mapear cadeias de exploração antes do atacante

De uma senha vazada a admin em quatro horas

A descrição de um workshop na agenda oficial da GopherCon 2026 resume bem o problema que muita equipe de backend prefere não encarar: "uma senha de banco vazada. Quatro horas depois, acesso admin completo." O workshop "Security Threat Modeling for Go Developers", conduzido por Benji Vesterby (CodePros), propõe pegar uma aplicação web Go realista e percorrer o caminho do atacante, do primeiro credencial roubado até o comprometimento do sistema inteiro.

Vale separar o que é o evento do que é o tema. O iMasters não esteve na sala e este texto não fala sobre o que foi apresentado, mas sim sobre o problema que a ementa se propõe a atacar, e que interessa a qualquer pessoa que mantém serviço em produção, seja em Go, PHP, Ruby ou Java.

O que threat modeling resolve (e o que não)

Threat modeling é o exercício de olhar para um sistema e perguntar, de forma sistemática, o que pode dar errado antes que dê. A ementa faz uma distinção que costuma se perder no dia a dia: vulnerabilidade, ameaça e risco não são a mesma coisa. Vulnerabilidade é a falha técnica; ameaça é o agente ou evento que pode explorá-la; risco é a combinação de probabilidade e impacto. Priorizar sem essa separação leva à armadilha clássica: corrigir o que é fácil em vez do que é perigoso.

O framework central proposto é o STRIDE, acrônimo para as seis categorias de ameaça:

• Spoofing (falsificação de identidade)
• Tampering (adulteração de dados)
• Repudiation (negar uma ação sem rastro)
• Information Disclosure (vazamento de dados)
• Denial of Service (indisponibilidade)
• Elevation of Privilege (escalada de privilégio)

A ideia é passar cada componente do sistema por essas seis lentes, em vez de confiar na intuição de quem já viu muito incidente. STRIDE dá cobertura; ele não garante profundidade sozinho.

Diagramas de fluxo, fronteiras de confiança e árvores de ataque

O ponto de partida prático é o data flow diagram (DFD): onde os dados entram, onde ficam parados, quem fala com quem. Sobre esse desenho marcam-se as trust boundaries, os pontos onde o dado cruza de uma zona de confiança para outra (do navegador para a API, da aplicação para o banco, do seu serviço para uma API externa). É nessas fronteiras que a maioria dos ataques acontece.

À frente do STRIDE, a ementa combina árvores de ataque para visualizar como uma ameaça vira exploração real: qual o objetivo do atacante, quais pré-requisitos ele precisa encadear, que dependências existem entre os passos. STRIDE responde "o que pode dar errado"; a árvore de ataque responde "em que ordem e com o quê".

Assumed breach: partir de dentro

O diferencial do exercício descrito é o cenário de assumed breach: em vez de perguntar se o atacante entra, assume-se que ele já entrou com uma credencial roubada e mapeia-se o blast radius dela. Que movimento lateral aquele token permite? Que escalada de privilégio está a um passo de distância? Quais dados sensíveis ficam expostos a partir dali?

Essa mudança de ângulo tende a ser mais honesta que o pentest tradicional, porque credencial vaza o tempo todo, por commit acidental, log verboso ou phishing. A pergunta útil não é "e se", é "quando".

A ementa também insiste num ponto que backends modernos ignoram: aplicações Go em produção carregam muitas dependências, e a superfície de ataque só cresce com o tempo. Some a isso os serviços externos fora do controle da equipe, o que força o chamado black-box threat modeling, modelar o que você não controla e desenhar controles compensatórios em torno.

As mitigações previsíveis, e por que ainda importam

O fim do caminho é priorização com matriz de risco e mitigações concretas: princípio do menor privilégio de verdade (não só no papel), gestão e rotação de segredos, defesa em profundidade para o caso do credential comprometido. Nada disso é novidade conceitual. O valor está em conectar cada mitigação a uma cadeia de ataque específica que o modelo revelou, em vez de aplicar checklist genérico.

Trade-offs que a ementa não esconde

Threat modeling tem custo. É trabalho de gente sênior, consome tempo e envelhece: um DFD feito hoje mente sobre o sistema daqui a três meses se ninguém atualizar. Para um projeto pequeno e estável, o retorno pode não justificar o ritual completo; um checklist de OWASP e boas práticas de segredo já cobrem muito. O exercício rende mais em sistemas com várias fronteiras de confiança, integrações externas e dados sensíveis, exatamente o perfil que a ementa usa como exemplo.

Para quem quer experimentar, o caminho independe de linguagem: desenhe o DFD do seu serviço, marque as trust boundaries, rode STRIDE em cada uma e monte uma árvore de ataque partindo de uma credencial vazada. O framework é o mesmo em Go, Rails ou Laravel; muda só a ferramenta.

Fonte: Agenda oficial — Meeting Room 433, Level 4, SCC | Summit