Criador de Regras Semgrep

Crie regras Semgrep de qualidade de produção com testes e validação adequados.

Quando Usar

Cenários ideais:

• Escrever regras Semgrep para padrões de bugs específicos
• Escrever regras para detectar vulnerabilidades de segurança em seu código
• Escrever regras de modo taint para vulnerabilidades de fluxo de dados
• Escrever regras para impor padrões de codificação

Quando NÃO Usar

NÃO use esta habilidade para:

• Executar conjuntos de regras Semgrep existentes
• Análise estática geral sem regras personalizadas (use a habilidade static-analysis)

Racionalizações para Rejeitar

Ao escrever regras Semgrep, rejeite estes atalhos comuns:

• "O padrão parece completo" → Ainda execute semgrep --test --config <rule-id>.yaml <rule-id>.<ext> para verificar. Regras não testadas têm falsos positivos/negativos ocultos.
• "Corresponde ao caso vulnerável" → Corresponder a vulnerabilidades é metade do trabalho. Verifique se os casos seguros não correspondem (falsos positivos quebram a confiança).
• "O modo taint é exagero para isso" → Se os dados fluem da entrada do usuário para um sink perigoso, o modo taint oferece melhor precisão do que a correspondência de padrões.
• "Um teste é suficiente" → Inclua casos extremos: diferentes estilos de codificação, entradas sanitizadas, alternativas seguras e condições de limite.
• "Vou otimizar os padrões primeiro" → Escreva padrões corretos primeiro, otimize depois que todos os testes passarem. Otimização prematura causa regressões.
• "O dump da AST é muito complexo" → A AST revela exatamente como o Semgrep vê o código. Ignorá-la leva a padrões que perdem variações sintáticas.

Anti-Padrões

Muito amplo - corresponde a tudo, inútil para detecção:

# BAD: Matches any function call
pattern: $FUNC(...)

# GOOD: Specific dangerous function
pattern: eval(...) # security-allowlist: Semgrep sink pattern

Casos seguros ausentes nos testes - leva a falsos positivos não detectados:

# BAD: Only tests vulnerable case
# ruleid: my-rule
dangerous(user_input)

# GOOD: Include safe cases to verify no false positives
# ruleid: my-rule
dangerous(user_input)

# ok: my-rule
dangerous(sanitize(user_input))

# ok: my-rule
dangerous("hardcoded_safe_value")

Padrões excessivamente específicos - perde variações:

# BAD: Only matches exact format
pattern: os.system("rm " + $VAR)

# GOOD: Matches all os.system calls with taint tracking
mode: taint
pattern-sinks:
  - pattern: os.system(...)

Nível de Rigor

Este fluxo de trabalho é rigoroso - não pule etapas:

• Leia a documentação primeiro: Veja Documentação antes de escrever regras Semgrep
• Teste primeiro é obrigatório: Nunca escreva uma regra sem testes
• 100% de testes aprovados é necessário: "A maioria dos testes aprovados" não é aceitável
• A otimização vem por último: Simplifique os padrões apenas depois que todos os testes passarem
• Evite padrões genéricos: As regras devem ser específicas, não corresponder a padrões amplos
• Priorize o modo taint: Para vulnerabilidades de fluxo de dados
• Um arquivo YAML - uma regra Semgrep: Cada arquivo YAML deve conter apenas uma regra Semgrep; não combine várias regras em um único arquivo
• Sem regras genéricas: Ao segmentar uma linguagem específica para regras Semgrep - evite a correspondência de padrões genéricos (languages: generic)
• Anotações de teste todook e todoruleid proibidas: Anotações todoruleid: <rule-id> e todook: <rule-id> em arquivos de teste para futuras melhorias de regras são proibidas

Visão Geral

Esta habilidade orienta a criação de regras Semgrep que detectam vulnerabilidades de segurança e padrões de código. As regras são criadas iterativamente: analise o problema, escreva os testes primeiro, analise a estrutura da AST, escreva a regra, itere até que todos os testes passem, otimize a regra.

Seleção de abordagem:

• Modo Taint (priorizar): Problemas de fluxo de dados onde a entrada não confiável atinge sinks perigosos
• Correspondência de padrões: Padrões sintáticos simples sem requisitos de fluxo de dados

Por que priorizar o modo taint? A correspondência de padrões encontra a sintaxe, mas perde o contexto. Um padrão eval($X) corresponde tanto a eval(user_input) (vulnerável) quanto a eval("safe_literal") (seguro). O modo taint rastreia o fluxo de dados, portanto, ele só alerta quando os dados não confiáveis realmente atingem o sink — reduzindo drasticamente os falsos positivos para vulnerabilidades de injeção. <!-- security-allowlist: Semgrep taint-mode explanation -->

…