SAST, DAST, IAST e SCA: diferenças e quando usar cada um

Quem começa a montar um programa de segurança de aplicações esbarra rapidamente numa sopa de siglas: SAST, DAST, IAST, SCA, RASP, ASPM. Todas prometem encontrar vulnerabilidades, mas cada uma olha para um pedaço diferente do problema. Escolher errado significa pagar por cobertura duplicada e, pior, deixar buracos sem ninguém olhando.

Este guia compara as quatro técnicas principais, mostra onde cada uma entra no ciclo de desenvolvimento e sugere combinações para empresas de tamanhos diferentes.

Resumo em uma tabela

SAST: o código parado

O SAST lê o código sem executá-lo e procura caminhos entre entradas não confiáveis e operações sensíveis. A grande vantagem é o momento: ele roda no pull request, quando corrigir custa minutos. A desvantagem clássica é o falso positivo, que ferramentas modernas atacam com análise de fluxo entre arquivos e triagem por IA. Detalhamos a técnica em O que é SAST.

Use quando: você escreve código próprio (ou seja, sempre).

SCA: o código dos outros

Entre 70% e 90% do código de uma aplicação moderna vem de bibliotecas de código aberto. O SCA monta o inventário dessas dependências, diretas e transitivas, e cruza com bases de vulnerabilidades conhecidas. Ferramentas atuais vão além da lista e verificam alcançabilidade, isto é, se o seu código chama a função vulnerável, o que elimina a maior parte do ruído. Explicamos isso em SCA com alcançabilidade.

O SCA também é a base para SBOM, conformidade de licenças e detecção de pacotes maliciosos.

Use quando: você usa npm, PyPI, Maven ou qualquer gerenciador de pacotes (ou seja, sempre).

DAST: a aplicação rodando, vista de fora

O DAST se comporta como um visitante mal intencionado: navega pela aplicação, preenche formulários e envia requisições modificadas, observando as respostas. Como não depende da linguagem nem do código, ele encontra problemas que só existem com a aplicação montada: servidor mal configurado, cabeçalhos de segurança ausentes, TLS fraco e injeções que atravessam camadas.

A limitação é a falta de contexto: o DAST diz que o parâmetro busca é vulnerável, mas não diz em qual arquivo. E ele só testa o que consegue alcançar, por isso autenticação é um requisito: um DAST sem login testa apenas a página inicial.

Use quando: você tem aplicações web ou APIs expostas, em homologação ou produção.

IAST: a aplicação rodando, vista de dentro

O IAST (Interactive Application Security Testing) instala um agente dentro da aplicação durante os testes. Quando um teste automatizado ou manual exercita uma rota, o agente observa o dado percorrendo o código e reporta a vulnerabilidade com a linha exata e a requisição que a disparou. É preciso e com pouco falso positivo.

A limitação é a cobertura: o IAST só vê o que os testes exercitam. Se a sua suíte cobre 40% das rotas, o IAST cobre 40% das rotas. Na prática, muitas empresas obtêm o mesmo benefício combinando SAST com análise de fluxo e DAST autenticado, com menos atrito de instalação.

Um parente próximo do IAST é a proteção em runtime (RASP), que usa a mesma visão de dentro da aplicação para bloquear ataques em produção, e não só detectar.

Use quando: você tem boa cobertura de testes automatizados e quer precisão máxima.

Pentest: o atacante

O pentest é a única técnica que tenta encadear falhas como um atacante real faria, e a única que encontra com consistência falhas de lógica de negócio e autorização, como um usuário acessando dados de outro. Tradicionalmente era caro e anual. Com pentest por agentes de IA, passou a caber em cada release. Falamos disso em detalhe no guia de pentest com IA.

Use quando: você lida com dados pessoais, dinheiro ou clientes que exigem relatório de teste de intrusão.

Onde cada técnica entra no ciclo

IDE / pre commit  →  Pull request      →  CI / build        →  Homologação     →  Produção
secrets              SAST, SCA,            SCA, containers,     DAST, pentest,     RASP, bots,
                     secrets, IaC,         IaC, SBOM            IAST               superfície de
                     revisão com IA                                                ataque, pentest
                                                                                   contínuo

A regra prática: quanto mais à esquerda, mais barato corrigir; quanto mais à direita, mais realista o teste. Um bom programa tem as duas pontas.

Combinações recomendadas por estágio

Startup ou time pequeno (até 30 desenvolvedores)

SAST, SCA e secrets no pull request, CSPM na conta de nuvem e um pentest com IA antes de cada grande lançamento ou contrato enterprise. Veja a página para startups.

Empresa em crescimento (30 a 300 desenvolvedores)

Tudo acima, mais IaC e containers no CI, DAST autenticado contínuo, SBOM por release e políticas de bloqueio por severidade. É o ponto em que consolidar ferramentas numa plataforma única começa a economizar dinheiro e tempo de triagem.

Empresa regulada ou grande

Tudo acima, mais pentest contínuo, proteção em runtime, gestão de superfície de ataque e relatórios mapeados para normas como ISO 27001, PCI DSS e Resolução CMN 4.893.

O valor está na correlação

Rodar quatro técnicas separadas gera quatro listas. O ganho real aparece quando os resultados são correlacionados: uma CVE encontrada pelo SCA, numa função que o SAST confirma ser alcançável, num container que o CSPM mostra exposto à internet, é prioridade máxima. A mesma CVE num serviço interno sem caminho de chamada pode esperar. É esse cruzamento que transforma milhares de alertas em uma fila curta, e é a razão de existir das plataformas que unificam as técnicas.