Análise código estático: 13 ferramentas para 2025

Análise estática de código é a inspeção do código-fonte sem executá-lo, usada para encontrar bugs, vulnerabilidades e violações de estilo. As ferramentas vão de linters gratuitos a plataformas SAST corporativas. A escolha certa depende da linguagem, do orçamento e da profundidade de segurança exigida. Abaixo, 13 opções testadas no mercado, da mais abrangente à mais específica.

1. SonarQube

Plataforma de análise contínua que cobre bugs, vulnerabilidades, code smells e dívida técnica em mais de 25 linguagens. Roda em servidor próprio ou na nuvem e se integra a pipelines de CI/CD.

O critério que a coloca no topo é a cobertura de linguagens combinada com o modelo de qualidade: o Quality Gate reprova o merge se o código novo não atingir padrões definidos. Empresas que adotam o gate costumam reduzir retrabalho, mas a configuração inicial exige tempo. Para projetos pequenos, a versão Community é gratuita.

2. Snyk Code

Focada em segurança, usa análise semântica para rastrear fluxos de dados entre entrada e saída, apontando injeções e exposição de dados sensíveis. A base de conhecimento é atualizada com frequência.

O diferencial é a integração nativa com IDEs e repositórios, sugerindo correções no próprio pull request. Em times que já usam Snyk para dependências, a adoção é quase imediata. O plano gratuito limita o número de testes por mês.

3. Checkmarx

Suíte SAST corporativa com foco em conformidade. Cobre mais de 30 linguagens e gera relatórios prontos para auditorias.

A justificativa da posição é o suporte a ambientes regulados: bancos e seguradoras costumam exigir rastreabilidade de cada achado. O custo é proporcional ao tamanho do time, e a curva de aprendizado é maior que a de ferramentas open source.

4. Semgrep

Ferramenta de análise por padrões, com regras simples de escrever. Roda localmente e em CI, com foco em velocidade.

O ponto forte é a customização: times de segurança criam regras próprias para padrões internos. A versão open source é gratuita; a paga adiciona gestão centralizada de regras. Em projetos grandes, a análise incremental reduz o tempo de execução.

5. ESLint

Linter para JavaScript e TypeScript, configurável e amplamente adotado. Detecta erros de sintaxe, más práticas e padrões inconsistentes.

A força está no ecossistema: milhares de plugins prontos, incluindo regras de acessibilidade e de frameworks como React. É a primeira linha de defesa em projetos front-end. A configuração exige curadoria para não gerar ruído excessivo.

6. Pylint

Linter para Python que verifica estilo, erros lógicos e complexidade. Segue as convenções da PEP 8.

O critério é a maturidade: existe há mais de duas décadas e é padrão em projetos Python. A pontuação de qualidade que gera ajuda a acompanhar a evolução do código. Pode ser integrado a editores como VS Code.

7. PMD

Analisador para Java, Apex e outras linguagens da JVM. Foca em código morto, complexidade e más práticas.

O diferencial é o conjunto de regras pronto para Java corporativo, com foco em performance. Roda via Maven ou Gradle. A documentação é extensa, mas a configuração inicial pede atenção.

8. Checkstyle

Ferramenta para Java que verifica padrões de codificação e formatação. Muito usada em projetos que exigem estilo uniforme.

A justificativa é a padronização: em times grandes, evita discussões de formatação em code review. Integra-se a IDEs e pipelines. Não substitui um SAST, mas complementa.

9. Bandit

Analisador de segurança para Python, focado em vulnerabilidades comuns como injeção de comandos e uso inseguro de bibliotecas.

O ponto forte é a simplicidade: roda com um comando e já aponta problemas relevantes. É mantido pela comunidade OpenStack. Cobre menos linguagens que um SAST completo, mas é eficaz para o ecossistema Python.

10. Brakeman

Ferramenta de segurança para Ruby on Rails. Analisa o código em busca de vulnerabilidades específicas do framework.

O critério é a especialização: entende o fluxo do Rails e reduz falsos positivos. É gratuito e open source. Para projetos Ruby, é praticamente obrigatório.

11. Gosec

Analisador de segurança para Go, integrado ao ecossistema da linguagem.

A justificativa é a cobertura de padrões de concorrência e tratamento de erros. Roda como parte do go vet. A comunidade mantém regras atualizadas.

12. Infer

Ferramenta do Facebook (Meta) para Java, C, C++ e Objective-C. Usa análise incremental para rodar em grandes bases de código.

O diferencial é a capacidade de analisar milhões de linhas sem travar o desenvolvimento. É open source. A configuração é mais complexa que a de linters simples.

13. Clang Static Analyzer

Analisador para C, C++ e Objective-C, integrado ao compilador Clang. Encontra bugs de memória e lógica.

O critério é a precisão: por ser parte do compilador, entende o código em profundidade. É gratuito e usado em projetos de sistemas. A saída pode ser verbosa, exigindo filtros.

Qual escolher

Se o objetivo é qualidade geral e integração com CI, SonarQube é o ponto de partida. Para segurança em Python, Bandit ou Snyk Code. Em JavaScript, ESLint resolve a maior parte. Times corporativos com exigência de auditoria tendem a Checkmarx ou Snyk. A recomendação prática é começar com uma ferramenta gratuita da sua linguagem principal, medir o ruído e só então avaliar uma suíte paga. O importante é rodar a análise a cada commit, não uma vez por trimestre.

FAQ

O que é análise estática de código?

É a inspeção do código-fonte sem executá-lo. Ferramentas leem o texto do programa e apontam bugs, vulnerabilidades e violações de estilo. Diferente de testes dinâmicos, não precisa rodar a aplicação, o que permite detectar problemas cedo, antes mesmo do merge.

Qual a diferença entre SAST e linter?

Linters focam estilo e erros simples, com regras leves. SAST (Static Application Security Testing) analisa fluxos de dados e busca vulnerabilidades exploráveis, como injeção de SQL. Um não substitui o outro: o linter pega formatação, o SAST pega falhas de segurança.

Análise estática substitui code review?

Não. A ferramenta encontra padrões repetíveis e falhas conhecidas, mas não avalia intenção, arquitetura ou regras de negócio. O code review humano complementa, focando no que a máquina não vê. O ideal é usar a análise para filtrar o óbvio e reservar o review para o que exige julgamento.

Ferramentas gratuitas são suficientes?

Para muitos projetos, sim. ESLint, Pylint, Bandit e SonarQube Community cobrem o essencial. A limitação aparece em ambientes regulados, que exigem relatórios de conformidade e suporte. Nesses casos, a versão paga se justifica pelo custo de uma auditoria.

Como reduzir falsos positivos?

Comece com regras padrão e ajuste gradualmente. Ignore alertas irrelevantes com comentários no código ou configuração. Meça a taxa de falsos positivos por sprint; acima de 20% costuma desmotivar o time. Ferramentas com análise semântica, como Snyk Code, tendem a errar menos que as baseadas em padrões simples.

Análise estática funciona para todas as linguagens?

Não. A cobertura varia: Java e JavaScript têm ecossistema maduro; linguagens menos populares podem ter suporte limitado. Verifique a lista de linguagens suportadas antes de adotar. Em projetos poliglotas, é comum combinar duas ou três ferramentas.