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".
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.
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.
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.
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.
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.
Math.random() em mais lugares porque viu funcionar. Cada prompt amplifica.Code Security com Hotspots configurados como gate explícito faz a IA gerar com mais cautela — porque feedback do scanner volta pro próximo prompt, e o LLM aprende padrões mais seguros pra aquela base. Sem instrumentação, IA acelera a degradação silenciosa de superfície de risco.
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.
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 →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.