SAST vs DAST vs IAST: Escolhendo as Ferramentas Certas

Quando um time decide levar segurança a sério no pipeline, a primeira pergunta costuma ser qual ferramenta adotar. A sigla escolhida (SAST, DAST ou IAST) define quando a análise acontece, o que ela consegue enxergar e quanto ruído o time vai precisar triar. As três resolvem problemas diferentes, e tratá-las como alternativas excludentes é o erro mais comum.

Este post explica o que cada técnica observa, onde ela encaixa no ciclo de desenvolvimento e como combiná-las de forma que uma cubra o ponto cego da outra.

SAST: lê o código sem executá-lo

Static Application Security Testing analisa o código-fonte (ou o bytecode) parado, sem rodar a aplicação. Ele percorre a estrutura do programa procurando padrões perigosos: concatenação de SQL que vira injeção, uso inseguro de funções de criptografia, dados de entrada que chegam a uma operação sensível sem validação, segredos escritos direto no código.

A grande vantagem é o timing: o SAST roda no editor do desenvolvedor ou no primeiro passo da CI, antes de qualquer deploy, e aponta o arquivo e a linha exata do problema. Como olha o código inteiro, alcança caminhos que nenhum teste chegaria a executar.

O custo disso é a taxa de falsos positivos. Sem executar a aplicação, o SAST não sabe se aquele trecho realmente é alcançável em produção ou se há uma proteção mais adiante que ele não enxergou. Ele também é cego a tudo que só existe em tempo de execução: configuração de servidor, comportamento de autenticação, falhas de ambiente.

Ferramentas comuns: Semgrep, SonarQube, CodeQL, Snyk Code.

DAST: ataca a aplicação rodando

Dynamic Application Security Testing faz o oposto. Ele ignora o código e testa a aplicação em execução, de fora, como um atacante faria: envia requisições, manipula parâmetros e observa as respostas. É uma abordagem black-box: não precisa saber em que linguagem o sistema foi escrito.

Por validar comportamento real, o DAST tem baixa taxa de falso positivo: se ele reporta um XSS, é porque conseguiu dispará-lo. Encontra classes de problema que o SAST não vê, como falhas de configuração expostas, gestão frágil de sessão e cabeçalhos de segurança ausentes.

As limitações são igualmente claras. O DAST só roda quando há uma aplicação de pé, ou seja, tarde no ciclo. Ele não aponta a linha de código culpada: diz que existe um problema na rota, não onde corrigir. E a cobertura depende de quão bem a ferramenta consegue navegar pela aplicação; telas atrás de autenticação ou fluxos complexos podem passar despercebidos sem configuração cuidadosa.

Ferramentas comuns: OWASP ZAP, Burp Suite, Nuclei.

IAST: observa de dentro enquanto a aplicação roda

Interactive Application Security Testing fica no meio. Ele instrumenta a aplicação com um agente e acompanha o fluxo de dados de dentro, enquanto os testes funcionais ou um DAST exercitam o sistema. Quando uma entrada maliciosa percorre o caminho até uma operação perigosa, o agente registra exatamente onde isso acontece.

O resultado combina o melhor dos dois mundos: a precisão do runtime (poucos falsos positivos, porque a falha foi de fato percorrida) com a localização no código (o agente sabe qual método tratou o dado). Como roda junto com a suíte de testes existente, integra-se bem a um pipeline já automatizado.

Em troca, o IAST exige instrumentação, o que significa suporte específico por linguagem e runtime e algum overhead de desempenho. E ele só enxerga o que os testes efetivamente executam: sem boa cobertura de testes, o IAST tem pouco a observar.

Ferramentas comuns: Contrast Security, Seeker.

Comparação rápida

Não esqueça das dependências

Nenhuma das três cobre bem o código que você não escreveu. A maior parte de uma aplicação moderna são bibliotecas de terceiros, e é aí que mora boa parte das vulnerabilidades conhecidas. Para isso existe o SCA (Software Composition Analysis), que cruza suas dependências com bases de CVEs. Ele é complemento obrigatório, não substituto, e roda barato junto do SAST na CI.

Onde cada uma entra no pipeline

A forma produtiva de pensar não é "qual escolher", e sim em que camada cada uma atua:

• No editor e no pre-commit: SAST leve e rápido (regras do Semgrep, por exemplo) e varredura de segredos. Feedback em segundos, antes do commit.
• No pull request / CI: SAST completo e SCA das dependências. É o portão que impede regressões de entrarem na main.
• Em staging, com a aplicação no ar: DAST e, se houver instrumentação, IAST acoplado aos testes de integração e end-to-end.
• Em produção: DAST agendado e monitoramento contínuo, para pegar o que mudou no ambiente.

Como começar

Se o programa de AppSec ainda está no começo, a sequência que entrega valor mais rápido é clara: comece por SAST e SCA na CI. São baratos, rodam cedo e não dependem de infraestrutura extra. O risco aqui é o volume de alertas: vale calibrar as regras e tratar os achados como parte do fluxo de revisão, não como uma fila paralela que ninguém olha.

Com isso estável, adicione DAST em staging para validar o que só aparece em runtime. O IAST faz sentido quando já existe uma suíte de testes sólida e o time precisa reduzir o ruído do SAST sem perder a localização no código; costuma ser um passo de maturidade, não o ponto de partida.

No fim, SAST, DAST e IAST não competem: cada um cobre uma parte diferente do problema. A decisão real é por onde começar e em que ritmo somar as camadas. E essa resposta depende menos da ferramenta do que de quanto do seu pipeline já está automatizado.