SAST (Static Application Security Testing) é um método de teste que analisa o código-fonte, o bytecode ou os binários de uma aplicação em busca de fraquezas de segurança, sem executá-la. A ferramenta converte o código em uma árvore de sintaxe abstrata e segue o fluxo de controle e de dados para encontrar onde uma entrada não confiável chega a uma operação sensível. Como lê o próprio código, pode rodar desde o primeiro commit, antes de existir algo implantado.
A ficha da MITRE sobre injeção de SQL diz que a análise estática automatizada detecta muitas instâncias dessa fraqueza e, na mesma seção, que "100% accuracy and coverage are not feasible". As duas metades dessa frase podem ser medidas. O scanner da Fluid Attacks alcança uma taxa de verdadeiros positivos de 100 % e uma taxa de falsos positivos de 0 % no conjunto de testes OWASP Benchmark v1.2, um resultado que qualquer pessoa pode reproduzir com um único comando do Docker. Contra uma aplicação real com 1.201 vulnerabilidades, esse mesmo scanner relatou 22,7 %.
Esta página cobre como a análise estática lê o código, quais fraquezas ela alcança e quais não, como o SAST funciona na Fluid Attacks, em que difere de DAST e SCA, e o que uma varredura limpa não prova.
O que é SAST?
SAST, também chamado de análise estática e Teste Estático de Segurança de Aplicações, é um método de teste de caixa branca: a ferramenta tem acesso completo à estrutura interna e à lógica da aplicação, e nunca executa o programa. Examina código-fonte, bytecode ou binários compilados e relata o arquivo e a linha onde cada fraqueza está.
O SAST trabalha em três etapas. O parsing transforma o código em uma árvore de sintaxe abstrata que representa funções, variáveis e estruturas de controle. A análise de fluxo de controle mapeia os caminhos que a execução pode tomar. A análise de fluxo de dados rastreia os valores enquanto se movem por esses caminhos, que é como a análise de código-fonte conecta uma entrada controlada por um atacante à operação que confia nela.
As regras de detecção ficam sobre esse modelo. As ferramentas SAST codificam padrões associados a classes de fraqueza conhecidas, mapeadas para catálogos como o OWASP Top 10 e a CWE, de modo que uma correspondência produz um achado com categoria, severidade e localização.
O que o SAST não é
Três técnicas são agrupadas sob "varredura de código". Elas respondem perguntas diferentes, e a distinção importa quando um relatório volta limpo.
Técnica | O que lê | O que responde | O que não pode dizer |
Teste estático de segurança de aplicações | Seu próprio código-fonte, bytecode ou binários | Onde a lógica insegura foi escrita | Se a falha é explorável no ambiente implantado |
Análise de composição de software | Dependências de terceiros e suas versões | Quais CVEs conhecidas você herdou | Nada sobre o código que sua equipe escreveu |
Varredura de segredos | Arquivos e histórico de commits | Quais credenciais foram enviadas | Se essas credenciais continuam válidas |
Três varreduras, três perguntas. Um resultado limpo em uma não diz nada sobre as outras duas.
Por que o SAST importa
A maior parte do risco de uma aplicação sob medida está no código que a equipe escreveu, e o SAST é a única técnica que o lê antes de a aplicação existir. Esse é o argumento prático para rodá-lo.
A maioria das vulnerabilidades está no código que você escreveu
No benchmark da Fluid Attacks com 36 ferramentas AppSec de terceiros contra uma aplicação com 1.201 vulnerabilidades em 105 categorias CWE, 80 % delas estavam no código, 13 % no backend e o restante em dependências e no frontend. O relatório State of Attacks 2026, que cobre 1.119.396 vulnerabilidades relatadas entre 1º de janeiro e 31 de dezembro de 2025, mostra o mesmo formato: 978.820 delas foram encontradas em código-fonte.
Volume não é severidade
A automação encontra quase tudo o que existe, e a parte menor do que importa. No mesmo relatório, as técnicas automatizadas detectaram 88,4 % de todas as vulnerabilidades, mas apenas 73,4 % das altas e críticas, e a exposição média ao risco por achado automatizado foi de 15,5 CVSSF contra 93,2 CVSSF por achado relatado por um pentester.
Esses dois números definem a expectativa para qualquer programa de SAST: cobertura ampla do código e um perfil de severidade que ainda precisa de testes de segurança de outros tipos por cima.
O retorno chega onde o código é escrito
Um achado de SAST entregue na IDE ou em um pull request é lido por quem escreveu a linha, minutos depois de escrevê-la. Esse momento é o que faz da técnica parte do DevSecOps e não de uma auditoria: as correções acontecem enquanto o contexto ainda está fresco, e o mesmo ciclo melhora a qualidade geral da aplicação, não só a sua segurança.
Os hábitos de programação segura se formam do mesmo jeito. Quem vê a mesma regra de SAST disparar três vezes para de escrever o padrão.
SAST na Fluid Attacks
A Fluid Attacks roda o SAST como um scanner que você mesmo pode executar, com resultados entregues na plataforma, na IDE e no pipeline de CI. O que segue é o alcance do nosso SAST, a evidência que ele produz e os limites que medimos.
O que varremos, e sob quais regras
O scanner cobre 15 linguagens de programação, seis protocolos de API, oito formatos de infraestrutura como código e 19 ferramentas de CI/CD. Ele também lê arquivos de configuração e sinaliza credenciais enviadas ao repositório.
As regras são públicas. A Fluid Attacks Database tem 2.200 regras de segurança em 45 alvos, mapeadas para 173 padrões, que cobrem código, nuvem, aplicações e binários. Cada regra remete a uma entrada de fraqueza com sua descrição, impacto, orientação de remediação e os requisitos que impõe.
A fraqueza 146, injeção de SQL, é um exemplo concreto: uma fraqueza, 35 regras de detecção escritas para Java, C#, PHP, Python, Dart, TypeScript, Rust, Swift, Go, JavaScript, Elixir, Ruby, Scala e Kotlin, com exemplos de remediação em 11 linguagens. A fraqueza 009 cobre credenciais e outros dados sensíveis deixados no código-fonte.
Uma fraqueza, 35 regras de detecção em quatorze linguagens e frameworks.
Como isso aparece na prática
Onde roda | Como é disparado | O que você recebe |
CLI em um contêiner Docker | Um único comando | Um arquivo de achados em CSV |
Um push na branch padrão roda uma varredura completa; branches de trabalho e pull requests rodam uma varredura diferencial | Um arquivo SARIF, pronto para subir na aba Security do GitHub | |
Extensões de IDE | Abrir um arquivo no editor | O achado ao lado da linha que o causou |
Plataforma de gestão de vulnerabilidades | Cada varredura | Severidade, exposição ao risco, localização e orientação de remediação |
CI Gate | Execução do pipeline | Um build quebrado quando um achado viola a política que você definiu |
O mesmo scanner, cinco pontos de entrada. O modo diferencial é o que mantém rápido o retorno nos pull requests.
Um benchmark perfeito não é uma aplicação segura
O scanner da Fluid Attacks atinge 100 % no OWASP Benchmark: uma taxa de verdadeiros positivos de 100 % e uma taxa de falsos positivos de 0 % na versão 1.2 do conjunto de testes, quase três vezes a pontuação média das ferramentas comerciais de detecção e mais de 1,5 vez a da melhor ferramenta gratuita. A documentação publica os comandos para reproduzir isso: clonar o repositório do benchmark, rodar o contêiner do scanner e gerar o scorecard com o plugin da OWASP.
O scanner alcança uma taxa de verdadeiros positivos de 100 % e uma taxa de falsos positivos de 0 % no conjunto v1.2. Fluid Attacks, 2026.
Esse número descreve um conjunto de testes sintético em Java, construído para ser mensurável. Ele não descreve a sua aplicação. No benchmark contra uma aplicação real, o mesmo scanner relatou 273 de 1.201 vulnerabilidades — 22,7 % de recall com 99 % de precisão —, enquanto um pentester no mesmo alvo relatou 1.076 delas, 89,6 % de recall com 100 % de precisão.
Avaliador e alvo | Recall | Precisão | O que é o alvo |
Scanner da Fluid Attacks no OWASP Benchmark v1.2 | 100 % | 100 % | Um conjunto de testes sintético em Java |
Scanner da Fluid Attacks em uma aplicação real | 22,7 % | 99 % | 1.201 vulnerabilidades reais, 105 categorias CWE |
Um pentester da Fluid Attacks na mesma aplicação | 89,6 % | 100 % | O mesmo alvo, 49 dias de trabalho |
Média das outras 34 ferramentas de terceiros | 1,7 % | Varia | O mesmo alvo |
Os dois resultados são do mesmo scanner. A distância entre eles é a distância entre um conjunto de testes e um código real.
Uma pontuação perfeita é evidência sobre o motor, não uma afirmação sobre o seu risco.
De um achado estático a uma CVE
Um achado é uma pista. A pesquisa da Fluid Attacks sobre os resultados do AI SAST descreve o que acontece no meio: de 1.006 achados gerados e revisados, 163 sobreviveram à triagem manual como verdadeiros positivos, 118 permaneceram após a consolidação de duplicatas e 28 chegaram à avaliação como candidatos a CVE. As etapas intermediárias: análise contextual, revisão de fonte a sumidouro, reprodução, deduplicação e divulgação.
Esse processo termina nas nossas Advisories, onde as entradas detectadas pelo scanner de AI SAST trazem um identificador CVE e o nome do pesquisador que as divulgou.
Um achado estático vira uma CVE só depois da triagem manual, da reprodução e da divulgação.
A prática que decide o resto
Varrer por calendário produz relatórios. Varrer a cada mudança, com um portão, produz correções. Os sistemas que usam nosso CI Gate alcançaram uma taxa de remediação de 72,2 % contra 58 % dos que não o usam, com uma mediana de remediação de 22 dias contra 30, no período de 2025 coberto pelo relatório State of Attacks 2026.
Para se aprofundar: o AI SAST explica como o aprendizado de máquina amplia o conjunto de regras, e nosso benchmark contra agentes de codificação mediu o AI SAST encontrando 72 de 100 vulnerabilidades reais em 52 bases de código, contra 9 do Codex e 8 do Claude Code com o mesmo prompt de auditoria.
Como o SAST lê o código
O SAST responde a uma pergunta, repetidamente: um valor que um atacante controla consegue chegar a uma operação que confia nele? Tudo na análise serve a essa pergunta.
O parsing transforma texto em estrutura. A árvore de sintaxe abstrata dá à ferramenta funções, parâmetros, atribuições e ramos, em vez de caracteres.
A análise de fluxo de controle mapeia a ordem em que as instruções podem ser executadas, incluindo os ramos que só rodam sob certas condições.
A análise de fluxo de dados segue os valores por esse mapa, das fontes — parâmetros de requisição, cabeçalhos, conteúdo de arquivos, leituras de banco de dados — até os sumidouros, que são as operações onde um valor não confiável causa dano: uma consulta, um comando de shell, uma resposta HTML, um caminho de arquivo.
A correspondência de regras decide o que o SAST relata. Uma regra de injeção de SQL dispara quando um valor contaminado chega à construção da consulta sem parametrização, e fica em silêncio quando uma instrução parametrizada ou uma lista de permissões validada quebra o caminho.
Parsing, fluxo de controle, fluxo de dados, correspondência de regras: de onde vem um achado e onde a análise para. Elaboração própria.
A cadeia também explica o ponto cego. Tudo o que o SAST sabe vem de código presente e analisável. A configuração aplicada na implantação, um sanitizador implementado em um serviço que ele não vê, um controle de autorização imposto por um gateway: nada disso está na árvore.
O que o SAST encontra, e o que lhe escapa
O SAST é mais forte com fraquezas visíveis como padrão no código: um valor que viaja de uma fonte não confiável até uma operação perigosa, uma chamada criptográfica com um parâmetro fraco, uma credencial escrita como literal. A análise de código-fonte as alcança porque a evidência está no arquivo.
Classe de fraqueza | Por que a análise estática a alcança | O que ainda não consegue confirmar |
O valor contaminado e a construção da consulta estão no código | Se os privilégios da conta limitam o impacto | |
Dados não confiáveis chegam ao conteúdo web gerado sem validação | Se um cabeçalho de resposta ou uma CSP bloqueia a execução | |
Comandos do sistema são construídos com entradas manipuláveis de fora | Se o usuário em execução consegue executar algo útil | |
A configuração do parser e a resolução de entidades são declaradas no código | Se o parser implantado usa essa configuração | |
As credenciais aparecem como literais em arquivos e no histórico | Se a credencial continua válida |
Cada linha é uma entrada da Fluid Attacks Database, com suas regras e sua orientação de remediação.
A técnica traz dois modos de falha, e a MITRE documenta os dois para injeção de SQL. Os falsos positivos aparecem quando a ferramenta não reconhece que há validação, o que produz alertas sem consequência de segurança. Os falsos negativos aparecem quando ela não consegue analisar funções de API próprias ou bibliotecas de terceiros, "especially if the API/library code is not available for analysis". A conclusão da MITRE sobre a análise estática automatizada é a frase que vale guardar: "100% accuracy and coverage are not feasible".
Os falsos negativos são o problema silencioso. Um relatório limpo é lido como boa notícia, e nada nele distingue "aqui não há fraqueza" de "não há regra para isso". Por isso combinamos o SAST com revisões manuais de código no plano Advanced, e por isso a cobertura ponderada por severidade, e não a contagem de achados, é a métrica que vale acompanhar.
SAST, DAST e SCA não são alternativas
Eles leem material diferente em momentos diferentes, e as lacunas de um são a cobertura do outro. As diferenças entre os três se resumem ao que cada um consegue observar.
Os Testes Dinâmicos de Segurança de Aplicações (DAST) atacam uma aplicação em execução a partir de fora, sem acesso ao código. A Análise de Composição de Software (SCA) inventaria os componentes de terceiros e os compara com vulnerabilidades conhecidas. O SAST lê o código que sua equipe escreveu, que nenhuma das outras duas jamais vê.
Característica | SAST | DAST |
Método de teste | Caixa branca, de dentro para fora | Caixa preta, de fora para dentro |
Análise | Lê o código sem executar a aplicação | Simula ataques contra uma aplicação em execução |
Quando se aplica | Desde o primeiro commit | Quando há uma aplicação implantada e funcionando |
Achados típicos | Injeção, tratamento inseguro de dados, criptografia fraca, segredos no código | Configuração em execução, falhas de autenticação, problemas do lado do servidor |
Depende da linguagem | Sim: a ferramenta precisa suportar a linguagem e o framework | Não: interage de fora |
Detalhe de remediação | Arquivo e número da linha | A requisição que o disparou, não a linha |
Principal modo de falha | Falsos positivos por falta de contexto de execução | Falsos negativos em caminhos de código que nunca alcança |
SAST e DAST discordam sobre onde olhar, e é justamente por isso que rodar os dois cobre mais do que rodar um deles duas vezes.
A Fluid Attacks combina os dois em uma única solução, junto com Secure Code Review (SCR), Pentesting as a Service (PTaaS) e Reverse Engineering (RE), de modo que os achados de cada técnica chegam à mesma fila e com a mesma escala de severidade.
Como rodar SAST com eficácia
Comprar um scanner é a menor decisão de um programa de SAST. Cinco práticas decidem se ele produz correções.
Escolha para a sua stack, não para uma lista de funções: a ferramenta SAST precisa suportar as linguagens e os frameworks que suas equipes realmente usam, e publicar como sua precisão foi medida. Um fornecedor que não consegue dizer como reproduzir os próprios números deu a você uma afirmação, não uma medição.
Configure antes de escalar: ajuste o conjunto de regras, delimite a varredura ao código que é seu e registre as exclusões de forma explícita, para que um achado suprimido seja uma decisão documentada e não uma lacuna silenciosa.
Integre onde o trabalho acontece: extensões de IDE para o minuto em que o código é escrito, varreduras diferenciais nos pull requests para o minuto em que ele é proposto, varreduras completas na branch padrão para todo o resto. A orientação de programação segura cai melhor nesse momento.
Priorize por exposição, não por contagem: faça a triagem por severidade e explorabilidade. Nos nossos dados de 2025, 4,5 % das vulnerabilidades relatadas carregavam 79,9 % da exposição total ao risco, que é a razão pela qual uma contagem de achados é uma fila de trabalho ruim.
Verifique a correção e mantenha o portão: varra de novo depois de remediar e mantenha o portão do pipeline impondo a política. A alternativa é um relatório que documenta a mesma vulnerabilidade por um ano.
Conclusões
O SAST lê o código que sua equipe escreveu, antes de existir algo para atacar, e aponta a linha exata. É uma capacidade estreita e valiosa: a maior parte das vulnerabilidades de uma aplicação sob medida vive nesse código, e nenhuma outra técnica o vê tão cedo.
Os limites do SAST são tão específicos quanto suas forças. Ele não consegue confirmar a explorabilidade em um ambiente implantado, não consegue raciocinar sobre código que não consegue analisar, e um relatório limpo não é uma aplicação segura. Trate uma varredura de SAST como a primeira camada de evidência, meça-a pelo risco que cobre e não pelos achados que imprime, e coloque por cima as técnicas que veem execução, dependências e lógica de negócio.
Perguntas frequentes
Qual é a diferença entre SAST e DAST?
O SAST lê código-fonte, bytecode ou binários sem executar a aplicação e relata a linha exata. Ele pode rodar desde o primeiro commit. O DAST ataca uma aplicação em execução a partir de fora, sem acesso ao código, então encontra problemas de execução e de configuração que são invisíveis no código-fonte. Eles falham em direções opostas: o SAST produz falsos positivos por falta de contexto de execução, e os testes dinâmicos perdem os caminhos de código que nunca alcançam.
O SAST precisa que a aplicação esteja rodando?
Não. Essa é a propriedade que define a técnica: ela analisa código em repouso, por isso pode ser usada antes de a aplicação compilar ou ser implantada, e por isso não consegue observar o comportamento em execução.
O SAST pode encontrar todas as vulnerabilidades do meu código?
Não. A MITRE afirma que, para a análise estática automatizada, "100% accuracy and coverage are not feasible". No benchmark da Fluid Attacks contra uma aplicação com 1.201 vulnerabilidades, nosso scanner relatou 22,7 % delas com 99 % de precisão, enquanto um pentester no mesmo alvo relatou 89,6 % com 100 % de precisão.
Qual é a diferença entre SAST e AI SAST?
O SAST tradicional compara o código com regras escritas por pessoas, então encontra os padrões que essas regras antecipam. O AI SAST acrescenta aprendizado de máquina para gerar candidatos e agentes para rastrear contexto entre arquivos, o que amplia a cobertura de fluxos que cruzam módulos. No nosso benchmark sobre 52 bases de código, ele encontrou 72 de 100 vulnerabilidades reais contra 9 de um agente de codificação de propósito geral com o mesmo prompt.
Um relatório limpo de SAST significa que minha aplicação está segura?
Não. Significa que nenhuma regra correspondeu ao código varrido. O código não analisado, as bibliotecas de terceiros, a configuração aplicada na implantação e as falhas de lógica de negócio ficam fora da análise, e um falso negativo se parece exatamente com um resultado limpo.
Qual é a precisão do scanner SAST da Fluid Attacks?
No conjunto de testes OWASP Benchmark v1.2 ele alcança uma taxa de verdadeiros positivos de 100 % e uma taxa de falsos positivos de 0 %, para uma pontuação de 100 %, e a documentação publica os comandos para reproduzir isso. Contra uma aplicação real com 1.201 vulnerabilidades, relatou 22,7 % delas com 99 % de precisão. Os dois números descrevem o mesmo scanner contra alvos diferentes.
Leia o erro antes que alguém o execute
Nossos scanners e pentesters revisam seu código-fonte desde o primeiro commit, para que as vulnerabilidades sejam corrigidas enquanto ainda são baratas.Teste gratuito · Fale conosco.
Rode o SAST sobre o que mudou em cada pull request
