Code Vulnerability

No post anterior falamos de Hotspots — código que merece revisão. Vulnerability é o passo seguinte: bug de segurança que análise estática consegue confirmar.

A diferença operacional é grande. Hotspot abre a pergunta "isto é seguro neste contexto?". Vulnerability afirma "existe um caminho de exploração — corrija ou aceite o risco com justificativa".

What this article explores:

• A diferença entre suspeito e confirmado — Hotspot vs Vulnerability lado a lado
• Como análise estática detecta vulnerabilities — taint analysis (sources, sinks, sanitizers)
• As 6 famílias mais frequentes em produção — Injection, XSS, Path Traversal, Deserialization, SSRF, IDOR
• CWE — o vocabulário que falta nas reuniões com CTO/CISO
• O impacto da IA generativa: por que ela escreve vulnerabilities por padrão estatístico
• Plano operacional em 4 passos para começar hoje
• Cinco pontos-chave para levar embora

A diferença entre suspeito e confirmado

A diferença mais clara aparece no código. Veja Hotspot e Vulnerability lado a lado:

// Pode ser OK se for ID de log
const id = Math.random()
                .toString(36);

app.get('/user', (req, res) => {
  const id = req.query.id;        // taint source
  db.query(`SELECT * FROM users WHERE id=${id}`,
           callback);                    // taint sink
});

A segunda função tem um caminho rastreável do input do usuário até a execução de SQL. Análise estática moderna marca isso como vulnerability — não hotspot, não warning, não suggestion. Bug com payload.

Como análise estática detecta vulnerabilities

A técnica chama taint analysis (análise de contaminação). O analisador rastreia:

• Sources — pontos onde dados externos entram (request params, body, headers, env vars, file reads)
• Sinks — pontos perigosos onde dados externos não deveriam chegar sem sanitização (SQL execution, shell commands, HTML render, file paths, deserialização)
• Sanitizers — funções que neutralizam o risco (parameterized queries, HTML escape, path validation)

Se existe um caminho do source ao sink sem passar por sanitizer, a ferramenta marca vulnerability. Se passa por sanitizer reconhecido, OK. Se passa por função custom desconhecida, fica como hotspot — depende da ferramenta saber se a função sanitiza de fato.

As 6 famílias mais frequentes em produção

A OWASP Top 10 muda a cada 4 anos, mas as famílias que análise estática captura bem são consistentes:

A boa notícia: ferramentas modernas detectam todas as 6 com taxa de falso positivo aceitável. A má notícia: detecção depende de a ferramenta entender seu framework. ORMs custom, frameworks proprietários, DSLs internos — tudo isso reduz cobertura.

CWE — o vocabulário que falta nas reuniões

CWE (Common Weakness Enumeration) é a taxonomia formal. Cada padrão tem um número (CWE-89 SQL injection, CWE-79 XSS, CWE-22 Path traversal, CWE-78 OS command injection, CWE-502 Insecure deserialization, CWE-918 SSRF).

Por que isso importa? Porque tira a discussão do achismo. "Achei um bug" vira "detectamos CWE-89 em 12 endpoints, todos eles em código que muda toda semana". CWE é defensível em reunião com CTO/CISO. "Bug" não é.

“

A maturidade do time aparece quando uma reunião de incidente termina com CWE number e contagem por categoria, não com "alguns bugs de segurança encontrados".

O impacto das Vulnerabilities no uso de IA

A IA generativa escreve vulnerabilities por padrão estatístico. Não porque o modelo seja malicioso — porque o corpus de treinamento tem milhões de exemplos de SQL com string interpolation, fs.readFile com path do usuário, eval() de JSON externo. O LLM aprende padrões frequentes; padrões frequentes incluem padrões inseguros.

O que acontece em código gerado por IA sem análise de vulnerability

• Padrões inseguros se naturalizam. SQL com template literal vira default. Cada prompt similar reforça o padrão.
• Sanitizers viram opcional. A IA gera o código que funciona; sanitização vira "feature". Sem prompt explícito pedindo, fica de fora.
• Taint flow fica invisível. Reviewer humano lê linha-a-linha, não rastreia caminho de dados. O bug passa porque "parece ok aqui".
• Testes refletem o bug. A IA gera teste com input válido; vulnerability só aparece com input adversário. Teste verde, bug ativo.

Quando análise estática de vulnerability roda no commit (não no CI tardio), o feedback chega ao LLM via erro: "this code has CWE-89, suggest parameterized query". A próxima geração corrige. Vulnerability scanning vira pré-condição para extrair valor real de IA generativa em código com qualquer superfície externa.

How Codurance can help

A Codurance acompanha times de engenharia que querem instrumentar a saúde de segurança do código sem virar AppSec. Ajudamos Tech Leads e Staff Engineers a integrar SAST em pipelines de PR, alinhar regras a CWE, e estabelecer baseline para conversas com CTO/CISO baseadas em fato — não em achismo.

Se você quer aplicar essas práticas no seu time, entre em contato hoje.

About the Author

[PARÁGRAFO_BIOGRAFICO_AUTOR]