--- title: "O que é SAST: guia completo de análise estática de código" description: "Entenda o que é SAST, como a análise estática de código encontra vulnerabilidades, quais são os limites da técnica e como adotar sem afogar o time em falsos…" url: "https://security.transitax.com/blog/o-que-e-sast" --- Fundamentos # O que é SAST: guia completo de análise estática de código Entenda o que é SAST, como a análise estática de código encontra vulnerabilidades, quais são os limites da técnica e como adotar sem afogar o time em falsos positivos. [Equipe de Pesquisa TransiTax Security](https://security.transitax.com/sobre#pesquisa)Publicado em 16 de setembro de 2026Atualizado em 22 de setembro de 20266 min de leitura Resumo - SAST é a análise do código fonte sem executá-lo, em busca de padrões que levam a vulnerabilidades. - Ele encontra falhas cedo, no pull request, e aponta a linha exata do problema. - O maior problema do SAST tradicional é o falso positivo; análise de fluxo de dados e triagem por IA resolvem boa parte disso. - SAST não substitui DAST, SCA nem pentest: cada técnica enxerga um tipo diferente de falha. Neste artigo 1. [Como a análise estática funciona](#como-a-analise-estatica-funciona) 2. [O que o SAST encontra bem](#o-que-o-sast-encontra-bem) 3. [O que o SAST não encontra](#o-que-o-sast-nao-encontra) 4. [O problema do falso positivo](#o-problema-do-falso-positivo) 5. [Como adotar SAST sem travar o time](#como-adotar-sast-sem-travar-o-time) 6. [SAST e inteligência artificial](#sast-e-inteligencia-artificial) 7. [Checklist para escolher uma ferramenta de SAST](#checklist-para-escolher-uma-ferramenta-de-sast) 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](#como-a-analise-estatica-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: ```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: ```js 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-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](https://security.transitax.com/blog/owasp-top-10-2025), especialmente injeção e falhas criptográficas. ## [O que o SAST não encontra](#o-que-o-sast-nao-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](https://security.transitax.com/funcionalidades/dast) e [CSPM](https://security.transitax.com/funcionalidades/cspm). - **Vulnerabilidades em dependências.** O SAST analisa o seu código; as bibliotecas de terceiros são cobertas pelo [SCA](https://security.transitax.com/funcionalidades/sca). - **Credenciais expostas.** Chaves de API no repositório são responsabilidade da [detecção de secrets](https://security.transitax.com/funcionalidades/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](https://security.transitax.com/blog/sast-dast-iast-sca-diferencas). ## [O problema do falso positivo](#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: | Causa | Exemplo | Como resolver | | --- | --- | --- | | Sanitizador não reconhecido | Uma função interna `escapeHtml()` que a ferramenta não conhece | Declarar sanitizadores customizados ou usar triagem com contexto | | Código que não roda em produção | Testes, scripts de migração, exemplos | Excluir por caminho e classificar automaticamente código de teste | | Fluxo impossível | Um valor que já foi validado por tipo em outra camada | Análise interprocedural e revisão por IA | Na [TransiTax Security](https://security.transitax.com/funcionalidades/sast), 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](#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](#comece-pelo-pull-request-nao-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](#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](#entregue-a-correcao-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](https://security.transitax.com/funcionalidades/autofix) reduzem o tempo médio de correção de semanas para minutos. ### [Meça o que importa](#meca-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](#sast-e-inteligencia-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](https://security.transitax.com/funcionalidades/revisao-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](#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? Quer ver isso rodando no seu código? Em 30 minutos mostramos a TransiTax Security num repositório seu, separando o que é explorável do que é ruído. [Falar com um especialista](https://security.transitax.com/contato) Escrito por Equipe de Pesquisa TransiTax Security Engenheiros de segurança de aplicações e de nuvem que acompanham registros de pacotes, bases de vulnerabilidades e técnicas de ataque. [Conheça a equipe](https://security.transitax.com/sobre#pesquisa). Neste artigo 1. [Como a análise estática funciona](#como-a-analise-estatica-funciona) 2. [O que o SAST encontra bem](#o-que-o-sast-encontra-bem) 3. [O que o SAST não encontra](#o-que-o-sast-nao-encontra) 4. [O problema do falso positivo](#o-problema-do-falso-positivo) 5. [Como adotar SAST sem travar o time](#como-adotar-sast-sem-travar-o-time) 6. [SAST e inteligência artificial](#sast-e-inteligencia-artificial) 7. [Checklist para escolher uma ferramenta de SAST](#checklist-para-escolher-uma-ferramenta-de-sast) 8. [Perguntas frequentes](#perguntas-frequentes) ## Perguntas frequentes Respostas diretas às dúvidas mais comuns sobre o tema. ### O que significa SAST? SAST significa Static Application Security Testing, ou teste estático de segurança de aplicações. É a análise do código fonte sem executá-lo, em busca de vulnerabilidades. ### Qual a diferença entre SAST e DAST? O SAST analisa o código antes de ele rodar e aponta a linha do problema. O DAST testa a aplicação em execução, de fora, sem acesso ao código. Eles encontram tipos diferentes de falhas e se complementam. ### SAST encontra vulnerabilidades em bibliotecas de terceiros? Não. Vulnerabilidades conhecidas em dependências são encontradas pela análise de composição de software (SCA). O SAST analisa o código escrito pelo seu time. ### Quanto tempo leva uma análise SAST? Depende do tamanho do repositório e da profundidade da análise. Análises incrementais de pull request costumam levar menos de um minuto; análises completas de repositórios grandes podem levar alguns minutos. ### SAST gera muitos falsos positivos? Ferramentas baseadas só em padrões, sim. Ferramentas com análise de fluxo de dados entre arquivos e triagem por IA reduzem o ruído de forma significativa, a ponto de a maioria dos alertas exibidos ser acionável. ## Continue lendo - [SAST, DAST, IAST e SCA: diferenças e quando usar cada um2 de setembro de 2026Fundamentos](https://security.transitax.com/blog/sast-dast-iast-sca-diferencas) - [OWASP Top 10 2025: o que mudou e como se proteger de cada risco26 de agosto de 2026Vulnerabilidades](https://security.transitax.com/blog/owasp-top-10-2025) - [DevSecOps na prática: segurança no CI/CD sem travar o time6 de maio de 2026DevSecOps](https://security.transitax.com/blog/devsecops-pipeline-ci-cd) ## Veja o que é explorável no seu código Em 30 minutos mostramos a plataforma num repositório seu, separamos o risco real do ruído e montamos uma proposta em reais. [Falar com um especialista](https://security.transitax.com/contato) Resposta em até 1 dia útil.