SAST: como comparar ferramentas de análise estática

Premissa deste post

Este artigo foi escrito sem uma base de pesquisa com dados verificáveis sobre ferramentas específicas de SAST (Static Application Security Testing). Não há aqui benchmarks, números de falsos positivos, comparativos de cobertura de linguagem ou testes de desempenho validados para produtos como Semgrep, SonarQube, CodeQL, Checkmarx, Snyk Code ou qualquer outro. Citar esses números sem fonte seria inventar dado, e isso não entra.

O que você vai encontrar abaixo é um framework de critérios técnicos para você mesmo avaliar e comparar ferramentas de SAST no seu contexto -- com base em como esse tipo de ferramenta funciona e no que a documentação oficial da OWASP recomenda observar. Se você já tem um resumo de pesquisa com dados reais de produtos, use os critérios daqui para organizar essa comparação; não os use como se fossem o veredito final.

Cenário: por que "qual é a melhor SAST" é a pergunta errada

Times de DevSecOps costumam chegar à escolha de SAST depois de um gatilho concreto: uma auditoria de compliance, um incidente de injeção de SQL que passou direto pelo code review, ou a exigência de um cliente enterprise por "scan estático no pipeline". Nesse momento, é tentador buscar um ranking pronto e escolher a ferramenta "número um".

O problema é que SAST não é uma categoria homogênea. Existem analisadores baseados em regras (pattern matching sobre AST), engines baseadas em fluxo de dados (taint analysis) e ferramentas que combinam SAST com SCA (análise de dependências) no mesmo produto. Cada abordagem tem um perfil diferente de cobertura, ruído e custo operacional. A pergunta útil não é "qual ferramenta é melhor", e sim "qual conjunto de trade-offs eu consigo sustentar na minha stack e no meu time".

Critérios para comparar

Ao avaliar candidatas, estruture a comparação nesses eixos. A OWASP Cheat Sheet Series tem uma seção dedicada a isso, vale ler antes de montar sua matriz de decisão: Static Code Analysis Cheat Sheet.

Cobertura de linguagem e framework. Não basta a linguagem estar "suportada" -- verifique se o suporte cobre os frameworks que você usa (ORM, templating, serialização). Uma ferramenta pode ter excelente cobertura de Java puro e cobertura fraca de Spring Security, por exemplo. Teste com código real do seu repositório, não com o sample da ferramenta.

Taxa de falsos positivos e falsos negativos. Isso varia conforme a engine (regras vs. taint analysis) e conforme o quão bem ela entende o seu código. Não existe número universal -- o único jeito confiável de medir é rodar a ferramenta contra um repositório seu com vulnerabilidades conhecidas (inclusive injetadas de propósito) e contar manualmente os resultados.

Integração em CI/CD. Pergunte: a ferramenta roda via CLI/container (fácil de plugar em GitHub Actions, GitLab CI, Jenkins) ou depende de um agente proprietário? Ela suporta scan incremental (só o diff do PR) ou sempre escaneia o repositório inteiro? Scan completo em todo PR vira gargalo de pipeline rapidamente em bases de código grandes.

Formato de saída e triagem. SARIF é o formato que mais ferramentas de SAST e plataformas de CI/CD leem nativamente -- facilita centralizar achados de múltiplas fontes num mesmo painel. Verifique se a ferramenta exporta SARIF e se dá para suprimir falsos positivos de forma auditável (comentário no código, baseline file), sem apagar o histórico de decisão.

Capacidade de regra customizada. Em ambientes com padrões internos de segurança (ex: proibir uso de uma lib interna insegura, ou um padrão de serialização específico), a ferramenta precisa permitir escrever regras próprias sem depender do vendor. Isso separa ferramentas extensíveis de ferramentas "caixa-preta".

Modelo de licenciamento e dados. Open source self-hosted, SaaS comercial ou híbrido -- cada modelo implica onde o código-fonte trafega. Para código proprietário ou regulado, isso pode ser critério eliminatório antes mesmo de avaliar qualidade de detecção.

Custo de manutenção. Quem vai atualizar regras, triar falsos positivos recorrentes e manter a integração funcionando quando o pipeline mudar? Ferramenta com melhor detecção teórica, mas que exige um analista dedicado full-time para triagem, pode custar mais caro no total do que uma opção mais simples e bem integrada.

Diferenças práticas entre as abordagens

Sem citar produtos específicos, dá para generalizar por tipo de engine:

• Baseada em regras/padrões (pattern matching sobre AST): mais rápida, mais fácil de customizar, tende a gerar mais falsos positivos em código complexo e menos falsos negativos "óbvios". Boa candidata para linting de segurança contínuo no PR.
• Baseada em análise de fluxo de dados (taint analysis): entende melhor caminhos reais de entrada-até-sink (ex: input do usuário chegando numa query SQL), tende a ter menos ruído em vulnerabilidades de injeção, mas é mais lenta e mais sensível a mudanças de versão de linguagem/framework.
• Plataformas combinadas (SAST + SCA + secrets scanning): reduzem número de ferramentas no pipeline e centralizam triagem, ao custo de acoplamento a um único vendor e, às vezes, profundidade menor em cada frente isolada comparado a uma ferramenta especializada.

Essas são tendências gerais do tipo de engine, não uma avaliação de produto específico -- a implementação de cada vendor varia e só teste real no seu código tira a dúvida.

Como montar sua própria comparação

1. Defina 3 a 5 repositórios representativos da sua stack (inclua pelo menos um com vulnerabilidade conhecida, histórica ou injetada de propósito).
2. Rode as candidatas nesses repositórios com a configuração padrão -- não comece ajustando regras, isso mascara o comportamento "de fábrica".
3. Registre: tempo de scan, nº de achados, nº de falsos positivos manualmente confirmados, nº de falsos negativos conhecidos que a ferramenta não pegou.
4. Avalie o esforço de integrar no pipeline existente -- cronometrado, não estimado de memória.
5. Só depois disso, compare custo de licença contra o resultado dos passos 3 e 4. Custo sem dado de qualidade de detecção é decisão no escuro.

Recomendação condicionada

Não há como recomendar uma ferramenta específica aqui sem inventar dado. O que dá para afirmar com segurança:

• Se o time é pequeno e o pipeline já é simples (GitHub Actions, poucos repositórios), priorize ferramentas com CLI leve, scan incremental e saída SARIF -- o custo de manutenção pesa mais que a profundidade de detecção nesse estágio.
• Se há exigência regulatória de manter código-fonte fora de serviços de terceiros, elimine SaaS puro da lista antes de avaliar qualquer outro critério.
• Se o objetivo é reduzir ruído em vulnerabilidades de injeção (SQL, command, path traversal), dê peso maior a engines com taint analysis, mesmo que o scan seja mais lento -- rode em pipeline assíncrono ou noturno se o tempo de PR for crítico.

Próximo passo prático: antes de assinar qualquer contrato ou adotar qualquer ferramenta open source em produção, rode o teste dos 5 passos acima contra o seu próprio código. Um resumo de pesquisa com dados reais de produtos, quando você tiver, encaixa direto nesses critérios para virar decisão -- e não em promessa de página de vendas.