PR review. O autor escreve const token = Math.random().toString(36). Você sabe que aquilo pode virar problema — Math.random() não é criptograficamente seguro, e tokens precisam ser. Mas você não sabe se aquele token vai ser usado em autenticação, em ID de log, em chave de cache, ou em nome de arquivo temporário.
Sem saber o uso, você não sabe se é bug. Você comenta "considera usar crypto.randomInt?". O autor responde "é só ID de log, tá ok". Você concorda. Aprova. Três meses depois, o "ID de log" virou ID de sessão em outro contexto. Vulnerability ativa. Investigação de incident.
Security Hotspot é código que não é vulnerável por si só, mas tem padrão suspeito o suficiente para exigir revisão humana antes de virar produção. Diferente de Vulnerability (bug confirmado), Hotspot é decisão pendente. Tratar Hotspots como categoria separada filtra ruído, força conversa explícita, e tira segurança da pilha de "achismo".
O que esse artigo explora:
- A pergunta que reviewers experientes evitam — e por que ela existe
- A distinção crítica entre Hotspot e Vulnerability — bug suspeito vs. bug confirmado
- Os 5 padrões de Hotspot mais comuns — e por que todos são contexto-dependentes
- O ritual operacional que separa time que usa Hotspots de time que mistura tudo
- Por que Hotspot vai dentro do PR review — não em ticket separado
- O impacto da IA generativa: por que ela cria Hotspots por design
- Plano operacional em 4 passos para começar hoje
- Cinco pontos-chave para levar embora
A pergunta que reviewers experientes evitam
Security Hotspot é o nome dessa zona cinza. Código que isolado parece OK, mas merece revisão humana explícita antes de qualquer commit. Não é bug confirmado — é decisão pendente.
Hotspot vs Vulnerability — a distinção que importa
A separação resolve um problema operacional crônico: ferramentas que listam tudo como "vulnerability" geram backlog inutilizável. Time aprende a ignorar. Quando aparece uma vulnerability real, está enterrada em ruído.
| Hotspot | Vulnerability | |
|---|---|---|
| Natureza | Código que merece revisão | Bug de segurança confirmado |
| Detecção automática | Padrão suspeito por análise estática | Taint analysis confirma exploit possível |
| Ação | "Você revisou? Considera safe?" | "Corrija ou justifique exceção" |
| Falsos positivos | Aceitos por design | Inadmissíveis |
| Exemplo | Math.random() em código de produção |
SELECT * FROM users WHERE id=" + userId |
Hotspot tem um critério explícito: decisão humana foi tomada? Se sim, marca como reviewed. Se não, fica visível. Isso reduz 1.200 issues a 40 que precisam de olho humano agora.
Os 5 padrões de Hotspot mais comuns
A maioria das ferramentas modernas de análise estática usa essas 5 famílias como base:
MD5, SHA-1, Math.random(). Não é bug se for hash não-criptográfico (deduplicação, fingerprint). É bug se for senha ou token.*. Cookie sem Secure/HttpOnly. CSP frouxo. Pode ser intencional em dev/staging mas perigoso em produção.fs.readFile(userPath). Path traversal possível, mas pode ser que o caller já validou.child_process.exec(cmd). Injection possível, mas se cmd é construído com inputs validados é seguro.A lista não é exaustiva — cada linguagem tem seus padrões. O ponto é que todos esses casos são contexto-dependentes. Análise estática sozinha não consegue decidir. Por isso vira Hotspot, não Vulnerability.
O ritual operacional do Hotspot
A diferença prática entre time que usa Hotspots como categoria e time que mistura tudo em "vulnerabilities":
Backlog: 1.200 issues marcados "security". Triagem mensal de 4 horas. Time desenvolve aversão. Issues novos são auto-arquivados. Quando vulnerability real aparece, mistura com o ruído.
Backlog separado em duas colunas: Vulnerabilities (bloqueia merge — corrigir ou justificar exceção rastreada) e Hotspots (marca review-required — autor + reviewer registram decisão no PR). Hotspots viram parte de PR review normal, não tarefa separada de "tempo livre".
A distinção parece administrativa. Não é. Tira a discussão de segurança do tempo livre e coloca dentro do PR, onde o contexto está fresco e a decisão fica registrada com link pro código.
O impacto dos Hotspots no uso de IA
A IA generativa gera Hotspots por design. Quando você pede "função para gerar ID único", o LLM frequentemente entrega Math.random() ou Date.now() + Math.random(). É código que compila, parece razoável, e o linter padrão não acusa. Vira commit. Vira produção.
O que acontece em código com Hotspots não-revisados + IA
- Padrões suspeitos se multiplicam. A IA replica
Math.random()em mais lugares porque viu funcionar. Cada prompt amplifica. - Decisões implícitas viram default. Se o time não força revisão de Hotspot, a primeira ocorrência vira padrão arquitetural. "É assim que a gente faz aqui".
- Reviewer humano perde foco. Em PRs gerados por IA, o reviewer foca na lógica de negócio. Padrões de segurança subliminares passam.
- Hotspot revela uso. Quando a ferramenta marca o código como "review-required", força o autor (humano ou prompted-by-AI) a justificar — o que reintroduz a decisão consciente.
A maioria das ferramentas modernas de análise estática (incluindo a plataforma SQA da Codurance, que integra Hotspots com os outros 2 sinais do pilar Code Security em um diagnóstico unificado) já vem com a separação Vulnerability vs Hotspot out-of-the-box.
- 1 Configure separação explícita. Ferramentas modernas de SAST e a plataforma SQA têm Hotspots como categoria distinta de Vulnerabilities. Ative.
- 2 Defina o gate diferente. Vulnerability bloqueia merge. Hotspot exige resolved/approved no PR — não bloqueia se reviewer marcar como reviewed.
- 3 Estabeleça baseline. Marque os Hotspots existentes como "to review" (não "approved by default"). Force o time a passar uma vez por cada um.
- 4 Ritualize no PR review. Adicione checkbox: "Hotspots desta mudança foram revisados conscientemente". Tira do tempo livre, coloca no fluxo.
- →Hotspot é decisão pendente, não bug confirmado. Resolve o problema do "1.200 issues, time desistiu".
- →A decisão é contextual. Mesma linha pode ser segura num lugar e perigosa em outro — depende de quem chama.
- →Hotspot vai dentro do PR, não em ticket separado. Reviewer registra decisão com contexto fresco.
- →IA generativa cria Hotspots por design. Sem gate explícito, padrões suspeitos viram default arquitetural.
- →Comece pela separação Vulnerability vs Hotspot na ferramenta. O resto é processo.
Hotspot é "código que merece revisão". Mas e quando o código já é, comprovadamente, bug de segurança? Quando análise estática consegue confirmar via taint analysis que existe um caminho de exploração — daí não é mais Hotspot, é Vulnerability. O próximo post fala dos catálogos formais (CWE, OWASP) e de como ferramentas detectam SQL injection, XSS, path traversal e os outros suspeitos usuais.
Post 02 Code Vulnerabilities →Como a Codurance pode ajudar
A Codurance acompanha times de engenharia que querem instrumentar a saúde de segurança do código sem virar AppSec ou CISO. Ajudamos Tech Leads e Staff Engineers a configurar gates explícitos para Hotspots, ritualizar revisão dentro do PR e estabelecer baseline rastreável — para que segurança saia da pilha de "achismo" e vire conversa baseada em fato.
Se você quer aplicar essas práticas no seu time, entre em contato hoje.
