O que é SAST: guia completo de análise estática de código

SAST, sigla para Static Application Security Testing, é a técnica de analisar o código fonte de uma aplicação sem executá-la, procurando padrões que levam a vulnerabilidades de segurança. É a mais antiga das ferramentas de segurança de aplicações e, bem configurada, continua sendo uma das mais eficientes: ela encontra o problema antes do deploy, aponta a linha exata e explica como corrigir.

Neste guia você vai entender como o SAST funciona por dentro, o que ele encontra e o que ele não encontra, por que ele tem fama de gerar ruído e como adotar a técnica de um jeito que o time de engenharia realmente use.

Como a análise estática funciona

Uma ferramenta de SAST lê o código da mesma forma que um compilador. Ela transforma os arquivos numa representação estruturada, normalmente uma árvore sintática abstrata (AST) e um grafo de fluxo de controle, e aplica regras sobre essa representação. Existem três níveis de sofisticação:

1. Busca por padrões. A regra procura construções perigosas, como eval() com uma variável ou uma consulta SQL montada com concatenação. É rápida, mas gera muitos alertas sem contexto.
2. Análise de fluxo de dados (taint analysis). A ferramenta marca as fontes de dados não confiáveis, como parâmetros de requisição, cabeçalhos e corpo de formulário, e os sorvedouros sensíveis, como execução de SQL, comandos do sistema e escrita de HTML. Um alerta só é gerado quando existe um caminho da fonte até o sorvedouro sem passar por um sanitizador.
3. Análise entre arquivos e funções (interprocedural). O caminho do dado é rastreado mesmo quando atravessa serviços, repositórios e camadas de abstração. É o que separa um SAST útil de um gerador de ruído.

Veja um exemplo clássico em Node.js:

// Vulnerável: a entrada do usuário vira parte da consulta
app.get('/pedidos', async (req, res) => {
  const sql = `SELECT * FROM pedidos WHERE cliente = '${req.query.cliente}'`;
  res.json(await db.query(sql));
});

A fonte é req.query.cliente, o sorvedouro é db.query e não existe sanitização no meio. Um SAST com análise de fluxo aponta a injeção de SQL (CWE 89) e sugere a correção com parâmetros:

app.get('/pedidos', async (req, res) => {
  const sql = 'SELECT * FROM pedidos WHERE cliente = $1';
  res.json(await db.query(sql, [req.query.cliente]));
});

O que o SAST encontra bem

O SAST é excelente para falhas que têm assinatura no código, ou seja, que dependem de como o código foi escrito:

• Injeções: SQL, NoSQL, comando do sistema operacional, LDAP e templates
• Cross site scripting (XSS) refletido e armazenado
• Travessia de diretório e inclusão de arquivos
• Desserialização insegura
• SSRF, quando a URL de destino vem da entrada do usuário
• Criptografia fraca, como MD5 para senhas ou geradores de números previsíveis
• Configurações inseguras declaradas no código, como CORS aberto ou cookies sem Secure

Essas classes cobrem boa parte do OWASP Top 10 2025, especialmente injeção e falhas criptográficas.

O que o SAST não encontra

Conhecer os limites é o que evita a falsa sensação de segurança. O SAST tem dificuldade com:

• Falhas de lógica de negócio. Um endpoint que deixa um usuário ver o pedido de outro (IDOR) pode estar escrito de forma perfeitamente "limpa". Falta uma verificação, e ausência é difícil de detectar por padrão.
• Configuração do ambiente. O código pode estar correto e o servidor, mal configurado. Isso é trabalho de DAST e CSPM.
• Vulnerabilidades em dependências. O SAST analisa o seu código; as bibliotecas de terceiros são cobertas pelo SCA.
• Credenciais expostas. Chaves de API no repositório são responsabilidade da detecção de secrets.

É por isso que programas maduros combinam várias técnicas. Explicamos a diferença entre elas em SAST, DAST, IAST e SCA: quando usar cada um.

O problema do falso positivo

A reclamação número um sobre SAST é o ruído. A história se repete em muitos times: a ferramenta é instalada, gera 3 mil alertas no primeiro dia, ninguém consegue avaliar todos, o time passa a ignorar os comentários no pull request e, seis meses depois, a ferramenta é desligada.

Os falsos positivos aparecem por três motivos principais:

Na TransiTax Security, cada achado passa por análise de fluxo entre arquivos e, depois, por uma etapa de revisão por IA que lê o contexto do repositório. Em média, 83,6% dos achados brutos são descartados antes de chegar ao time, e todos continuam registrados para auditoria.

Como adotar SAST sem travar o time

A diferença entre um SAST que funciona e um que é desligado está no processo, não só na ferramenta.

Comece pelo pull request, não pelo backlog

Analisar o repositório inteiro no primeiro dia produz uma lista impossível. Em vez disso, ative a análise incremental no pull request: o desenvolvedor só vê os problemas do código que ele mesmo está alterando, no momento em que está com o contexto na cabeça. O backlog histórico é tratado em paralelo, priorizado por risco.

Bloqueie pouco, informe muito

Configure a política para bloquear o merge só em severidade crítica com alta confiança. O resto aparece como comentário informativo. Bloquear tudo transforma segurança em obstáculo e incentiva exceções em massa.

Entregue a correção junto com o problema

Um alerta que diz "injeção de SQL na linha 42" é útil. Um alerta que já traz o diff da correção, pronto para aceitar, é muito mais. Ferramentas com correção automática reduzem o tempo médio de correção de semanas para minutos.

Meça o que importa

Acompanhe três números: tempo médio de correção por severidade, taxa de descarte (quantos achados são marcados como falso positivo) e cobertura (quantos repositórios estão com análise ativa). Uma taxa de descarte acima de 30% indica que a configuração precisa de ajuste.

SAST e inteligência artificial

Dois movimentos mudaram o SAST nos últimos anos. O primeiro é o uso de modelos de linguagem para triagem: em vez de substituir as regras, o modelo revisa cada achado com o contexto do código e responde se ele é explorável. O segundo é a revisão de pull request com IA, que encontra falhas de lógica, como verificações de permissão ausentes, que regras estáticas não conseguem expressar. Falamos mais sobre isso na página de revisão de pull request.

Um cuidado importante: com assistentes de código gerando uma parte crescente do código que vai para produção, a análise estática no pull request virou ainda mais necessária. Código gerado por IA reproduz padrões inseguros com a mesma confiança com que reproduz os seguros.

Checklist para escolher uma ferramenta de SAST

• Suporta todas as linguagens e frameworks do seu stack?
• Faz análise de fluxo de dados entre arquivos, ou só busca padrões?
• Roda de forma incremental no pull request em menos de um minuto?
• Permite declarar sanitizadores e exceções com trilha de auditoria?
• Oferece sugestão de correção aplicável?
• Integra com o seu provedor Git, CI e ferramenta de tarefas?
• Deixa claro onde o código é processado e se ele é armazenado?