SAST e DAST: Diferenças, O Que Cada Um Detecta e Como Combinar

SAST (static application security testing) lê o seu código fonte sem executá-lo. DAST (dynamic application security testing) ataca a sua aplicação rodando, de fora. Essa única diferença, código parado versus app em movimento, explica quase todo o resto: o que cada um encontra, quando roda, quanto ruído gera e quanto custa.

A resposta curta para "SAST e DAST, qual usar?" é: os dois, em momentos diferentes do ciclo de vida. A resposta longa, abaixo, é qual adotar primeiro, o que cada um nunca vai detectar e onde entram IAST, SCA e o SAST baseado em IA.

Definições: SAST, DAST, IAST e SCA

SAST: teste estático de segurança

O SAST analisa código fonte, bytecode ou binários procurando padrões e fluxos de dados que levam a vulnerabilidades. Ele monta um modelo do programa (árvore sintática, fluxo de controle, fluxo de dados) e segue a entrada não confiável ("sources") até operações perigosas ("sinks"): queries SQL, comandos de shell, saída HTML. Como trabalha sobre o código, pode rodar a cada commit e apontar o arquivo e a linha exatos. É o núcleo da análise estática de código voltada para segurança.

DAST: teste dinâmico de segurança

O DAST é uma abordagem de caixa preta. Um scanner percorre uma aplicação implantada (web ou API), envia requisições montadas de propósito e analisa as respostas procurando sinais de vulnerabilidade: payloads refletidos, mensagens de erro de SQL, headers de segurança ausentes, open redirects, TLS fraco. Não precisa do código fonte e não se importa com a linguagem. Ele vê a aplicação exatamente como um atacante na internet vê.

IAST: teste interativo

O IAST coloca um agente dentro da aplicação em execução (por exemplo, um agente para JVM ou .NET). Enquanto testes funcionais ou tráfego real exercitam o app, o agente observa em tempo real como os dados vão do input HTTP até os sinks. Ele combina a precisão do SAST (sabe a linha de código) com a verdade de runtime do DAST (só reporta caminhos que realmente executaram). O custo: suporte limitado de linguagens e a necessidade de boa cobertura de testes.

SCA: análise de composição de software

A maior parte de uma aplicação moderna é código de terceiros. O software composition analysis monta um inventário das suas dependências diretas e transitivas a partir de lockfiles e manifestos e cruza as versões com bases de vulnerabilidades (CVEs, GitHub Security Advisories), além de checar licenças. O SCA não olha a lógica do seu código; ele avisa quando uma biblioteca que você entrega tem uma vulnerabilidade conhecida.

Tabela comparativa: SAST e DAST

O que cada um encontra e o que deixa passar

Um bug que o SAST encontra e o DAST pode perder

Veja esta SQL injection clássica, escondida atrás de um endpoint de relatórios só para admins:

// reports.js
app.get('/admin/reports', requireAdmin, async (req, res) => {
  const sort = req.query.sort;
  const rows = await db.query(
    `SELECT * FROM invoices ORDER BY ${sort}`
  );
  res.json(rows);
});

Um scanner DAST que não está logado como admin nunca chega nessa rota, então não reporta nada. Mesmo com credenciais, muitas ferramentas DAST não fazem um bom fuzzing de cláusulas ORDER BY. Um SAST segue req.query.sort até uma query montada por concatenação e aponta reports.js na linha exata, antes do merge.

Um bug que o DAST encontra e o SAST não

Agora imagine que o código está correto, mas a produção roda atrás de um reverse proxy que remove o header Strict-Transport-Security, o cookie de sessão sai sem a flag Secure por causa de uma configuração do load balancer e um endpoint de debug ficou habilitado por uma variável de ambiente. Nada disso aparece no código da aplicação. O DAST vê na hora porque analisa respostas reais do deploy real.

O bug que os dois costumam perder: autorização quebrada

// invoices.js
app.get('/api/invoices/:id', requireLogin, async (req, res) => {
  const invoice = await Invoice.findById(req.params.id);
  res.json(invoice); // não verifica se invoice.ownerId === req.user.id
});

Isso é um IDOR, parte do broken access control que lidera o OWASP Top 10. Não existe nenhum sink perigoso: nem SQL montado na mão, nem shell, nem HTML. Uma regra de SAST por padrões não tem o que casar. Um DAST precisaria de duas contas e entender que a fatura 42 pertence a outra pessoa. É aqui que a revisão manual, o pentest ou a análise que raciocina fazem diferença.

Resumo dos achados típicos

• O SAST é forte em: injeções (SQL, comandos, templates), sinks de XSS, path traversal, desserialização insegura, credenciais hardcoded, criptografia fraca, funções perigosas.
• O SAST é fraco em: configuração do deploy, comportamento em runtime, problemas que dependem de dados no banco e lógica de negócio que nenhuma regra descreve.
• O DAST é forte em: headers de segurança, TLS, flags de cookies, painéis de admin expostos, erros verbosos, XSS refletido, servidor mal configurado.
• O DAST é fraco em: tudo que está atrás de fluxos de autenticação complexos, rotas não linkadas na UI e dizer qual linha corrigir.

Como SAST, DAST, IAST e SCA se complementam

Pense neles como camadas que se sobrepõem de propósito:

1. SCA e SAST em cada pull request. Baratos, rápidos e precisos. Barram dependências vulneráveis e falhas óbvias antes do merge.
2. Varredura de segredos em todo o histórico do git. Uma chave commitada e depois apagada continua vivendo no histórico.
3. Checagens de IaC e de CI. GitHub Actions, Dockerfiles, Terraform e manifestos de Kubernetes também são código, e um erro ali costuma ser mais grave que um bug no app.
4. DAST contra staging periodicamente. Confirma que o sistema implantado se comporta como o código sugere e detecta drift de configuração.
5. IAST onde você tiver boas suítes de testes e um runtime suportado, tipicamente em ambientes grandes de Java ou .NET.
6. Pentests manuais periódicos para lógica de negócio, ataques encadeados e tudo que exige criatividade humana.

Essa estrutura em camadas é o que "shift left" significa na prática dentro de DevSecOps: empurrar o máximo de detecção para as camadas baratas e cedo, e reservar as caras e tardias para o que só elas conseguem ver.

Onde entra o SAST com IA

Os motores SAST tradicionais rodam regras: "se o input do usuário chega em db.query sem passar por um sanitizador, reporte". Funciona bem para tipos de sink conhecidos, mas tem dois problemas estruturais. Primeiro, as regras não conhecem cada sanitizador próprio, cada wrapper de ORM ou cada convenção de framework, então reportam demais (ruído) ou de menos (lacunas). Segundo, regras não expressam intenção. "Cada usuário só pode ler as próprias faturas" não é um padrão; é lógica de negócio.

Um SAST com IA usa um modelo de linguagem para ler o código como um revisor faria. Em vez de só casar sintaxe, ele consegue:

• Seguir o fluxo de dados entre arquivos e através de helpers, middlewares e wrappers que um motor de regras não modela.
• Raciocinar sobre autorização: perceber que um handler checa o dono do recurso e o vizinho não.
• Avaliar alcançabilidade e contexto, descartando uma chamada "perigosa" cujo input na verdade é uma constante, o que reduz falsos positivos.
• Explicar o achado em linguagem simples e propor uma correção, acelerando o triage para devs que não são especialistas em segurança.

Não é mágica. Modelos também erram com toda a confiança, então um bom SAST com IA ancora cada achado em um arquivo e uma linha concretos e descreve o caminho de exploração para que uma pessoa possa verificar. Veja como o AI SAST funciona na prática e como ele se compara ao code review com IA em pull requests.

Um ponto prático: um SAST com IA que envia seu código fonte para a API de um provedor de IA genérico é uma decisão sobre o tratamento dos seus dados, não só sobre ferramentas. Se isso importa para você, leia nosso guia sobre IA self-hosted para segurança de código.

Stack recomendado: startup vs empresa regulada

Startup em estágio inicial

Você tem um time pequeno, um ou dois repositórios, ninguém dedicado a segurança e pouca paciência para ruído. Otimize sinal por minuto:

• SAST + SCA + segredos + IaC em uma só passada por repositório, com achados ordenados por explorabilidade e não só por rótulo de severidade.
• Rode nos pull requests para que quem escreveu o problema o corrija, com o contexto fresco.
• Uma checagem DAST leve do seu domínio de produção: headers, TLS e endpoints expostos.
• Um pentest externo quando um cliente ou investidor pedir, não antes de corrigir o que é fácil.

Por exemplo, com a Nurbak você conecta o GitHub e escaneia um repositório: o próprio modelo de IA self-hosted da Nurbak analisa o código (a análise não envia seu código para a OpenAI nem para a Anthropic), reporta vulnerabilidades exploráveis com arquivo e linha, cruza as dependências com CVEs conhecidos, aponta configurações inseguras de GitHub Actions, Docker, Terraform e Kubernetes e segredos no histórico do git, e resume tudo em um score de segurança de 0 a 100 com explicações em linguagem simples. O scan grátis mostra completos os 3 achados mais importantes, e na página de AI SAST você encontra mais detalhes da abordagem.

Empresa regulada (fintech, saúde, setor público)

Aqui o que pesa é evidência, repetibilidade e controle dos dados, tanto quanto a detecção:

• SAST e SCA como gates obrigatórios nos pull requests, com limites de severidade documentados e processo de exceções.
• DAST autenticado contra staging com contas de teste realistas, incluindo checagens multi-perfil para controle de acesso.
• IAST em serviços críticos se seus runtimes forem suportados e a cobertura de testes for alta.
• Geração de SBOM a partir da sua ferramenta de SCA para auditorias e questionários de clientes.
• Pentests manuais anuais ou por release, complementados se quiser com pentest assistido por IA entre eles.
• Controle estrito de onde o código é processado. Se uma ferramenta de IA analisa seu código, você precisa saber onde o modelo roda, o que é retido e como é o registro de auditoria.

Erros comuns ao escolher entre SAST e DAST

• Comprar DAST primeiro porque não exige integração. É fácil de começar, mas só vê a superfície e não diz ao dev onde corrigir.
• Ligar todas as regras do SAST. Devs aprendem a ignorar uma ferramenta que despeja centenas de achados de baixa confiança. Comece pelo que é explorável e de alta confiança.
• Ignorar dependências e configuração. Um código de aplicação perfeito ainda entrega bibliotecas vulneráveis e um workflow de CI com tokens amplos demais.
• Tratar um scan limpo como "seguro". Scanners reduzem risco; não provam que ele não existe. Falhas de lógica continuam exigindo raciocínio, revisão e testes.

Resumo

SAST e DAST não são uma escolha de "um ou outro". O SAST dá detecção cedo, precisa e barata no código; o DAST dá a verdade sobre o sistema implantado; o SCA cobre o código que você não escreveu; IAST e pentests preenchem as lacunas. Se só puder começar com uma camada, comece com SAST mais SCA nos pull requests, porque é ali que corrigir custa menos. Depois some DAST e testes humanos conforme o produto e o que está em jogo crescem. Um bom próximo passo é rodar um scanner de segurança de código no seu repositório principal e ver o que ele realmente encontra.

Leituras relacionadas

• OWASP Top 10 2025
• O que é DevSecOps
• O que é pentest
• SQL injection