SAST analisa o código-fonte sem executá-lo. DAST testa a aplicação rodando, simulando ataques de fora. A diferença fundamental está no ponto de vista: o SAST enxerga o código, o DAST enxerga o comportamento.
Essa distinção parece simples, mas tem consequência prática direta. As duas abordagens encontram tipos diferentes de falha, e nenhuma delas cobre o que a outra deixa passar. Escolher uma e considerar o problema resolvido é o erro mais comum em segurança de aplicações.
Este artigo compara as duas em detalhe, mostra o que cada uma não encontra, explica onde entra o SCA e propõe como combinar as três. Se você quer o contexto mais amplo antes, veja nosso guia sobre [o que é AppSec].
O que é SAST
SAST é a sigla de Static Application Security Testing, ou teste estático de segurança de aplicação. A ferramenta lê o código-fonte como texto estruturado, sem executá-lo, e procura padrões associados a vulnerabilidades conhecidas.
Na prática, ela rastreia o caminho que um dado percorre dentro do programa. Quando identifica que uma entrada controlada pelo usuário chega a um ponto sensível sem passar por validação ou tratamento adequado, sinaliza o problema.
Exemplos típicos de achados de SAST:
- Consulta a banco de dados montada por concatenação de texto, abrindo caminho para injeção de SQL
- Entrada de usuário exibida na tela sem sanitização, permitindo execução de script no navegador
- Credenciais, chaves de API ou tokens escritos diretamente no código
- Uso de funções criptográficas obsoletas ou com parâmetros inseguros
- Tratamento de erro que expõe detalhes internos da aplicação
A grande vantagem do SAST é o momento em que ele atua. Como funciona sobre o código, pode rodar enquanto o desenvolvedor ainda está escrevendo, muitas vezes integrado ao próprio editor. Nesse ponto do ciclo, corrigir custa quase nada: o contexto está fresco e não há nada construído em cima.
O que é DAST
DAST é a sigla de Dynamic Application Security Testing, ou teste dinâmico de segurança de aplicação. Diferente do SAST, ele não olha o código: interage com a aplicação em execução, enviando requisições e analisando as respostas.
É uma abordagem de caixa preta. A ferramenta se comporta como um atacante externo que não conhece a implementação interna e precisa descobrir o comportamento do sistema testando.
Exemplos típicos de achados de DAST:
- Falhas de autenticação e de gestão de sessão
- Controle de acesso quebrado, quando um usuário alcança dados de outro
- Configuração insegura de servidor ou de cabeçalhos de segurança
- Exposição de informação sensível em respostas ou mensagens de erro
- Comportamentos inseguros que só aparecem com o sistema integrado ao ambiente real
A vantagem do DAST é testar o sistema como ele realmente existe, com servidor configurado, integrações ativas e dependências carregadas. Muita falha só se manifesta nessa condição, e o SAST jamais a veria olhando código isolado.
SAST e DAST lado a lado
| Critério | SAST | DAST |
| O que analisa | Código-fonte, sem executar | Aplicação em execução |
| Precisa do código | Sim | Não |
| Momento no ciclo | Escrita do código e integração contínua | Homologação e produção |
| Perspectiva | Interna, de quem vê a implementação | Externa, de quem ataca sem conhecer |
| Encontra bem | Injeção, segredos no código, criptografia fraca | Autenticação, sessão, controle de acesso, configuração |
| Não encontra | Falhas de ambiente, configuração e integração | Código que o teste não alcança |
| Falsos positivos | Frequentes, exige calibragem | Menos frequentes |
| Custo de correção do achado | Baixo, código recém-escrito | Maior, aplicação já construída |
As limitações que ninguém conta
Materiais produzidos por fabricantes de ferramenta costumam listar apenas as capacidades. Na prática, entender as limitações é o que permite montar uma estratégia sem lacunas.
Limitações do SAST
- Falsos positivos em volume. O SAST trabalha com padrões, e padrão sem contexto erra. Uma ferramenta mal calibrada pode gerar centenas de alertas em uma base de código média, e o efeito colateral é grave: o time aprende a ignorar os avisos, inclusive os corretos.
- Cegueira para o ambiente. O código pode estar impecável e a aplicação continuar vulnerável por causa de uma permissão excessiva na nuvem, um cabeçalho de segurança ausente ou um serviço exposto indevidamente. Nada disso está no código.
- Dificuldade com código dinâmico. Construções que só se resolvem em tempo de execução, como reflexão ou geração dinâmica de consultas, escapam da análise estática.
Limitações do DAST
- Só testa o que alcança. Se uma funcionalidade está atrás de um fluxo que a ferramenta não percorre, ela simplesmente não é avaliada. Áreas autenticadas, formulários com etapas múltiplas e funcionalidades acessíveis apenas a determinados perfis frequentemente ficam de fora.
- Não indica onde corrigir. O DAST aponta que a aplicação respondeu de forma insegura, mas não diz qual trecho de código causou aquilo. A investigação fica por conta do time.
- Entra tarde. Quando o DAST encontra a falha, a aplicação já está construída. A correção custa mais do que se tivesse sido pega no código.
O PONTO CENTRAL
SAST e DAST não são alternativas concorrentes: são perspectivas complementares sobre o mesmo sistema.
Uma organização que usa apenas SAST tem código revisado rodando em ambiente possivelmente mal configurado. Uma que usa apenas DAST descobre problemas tarde e sem saber onde corrigi-los.
E nenhuma das duas cobre o risco que vem das dependências de terceiros.
Onde entra o SCA
SCA é a sigla de Software Composition Analysis, ou análise de composição de software. A ferramenta inventaria todas as bibliotecas e dependências que a aplicação utiliza e verifica se alguma delas tem vulnerabilidade conhecida publicada.
A necessidade dessa camada vem de uma característica do desenvolvimento moderno: a maior parte do código que roda em uma aplicação não foi escrita pela equipe que a mantém. São bibliotecas de terceiros, muitas delas com suas próprias dependências, formando cadeias com dezenas ou centenas de componentes.
O reconhecimento desse risco é recente e explícito. A edição 2025 do OWASP Top 10 incluiu Software Supply Chain Failures como categoria nova, posicionada em terceiro lugar entre os riscos mais críticos em aplicações web.
O SCA responde a duas perguntas que nem SAST nem DAST conseguem responder: quais componentes de terceiros existem na minha aplicação, e algum deles tem falha conhecida agora? A segunda pergunta precisa ser refeita continuamente, porque uma biblioteca considerada segura hoje pode ter vulnerabilidade crítica publicada na semana que vem.
Como combinar as três abordagens
A defesa eficaz distribui as verificações ao longo do ciclo, cada uma no momento em que é mais eficiente:
- SCA no build. Inventário e verificação de dependências a cada construção. Costuma ser o primeiro a implantar, por ter baixa taxa de falso positivo e retorno imediato.
- SAST na escrita e na integração contínua. Análise de código a cada alteração, com regras calibradas para o contexto do time.
- DAST em homologação. Teste da aplicação em execução antes de subir para produção, priorizando os fluxos críticos.
- Pentest periodicamente. Avaliação manual conduzida por especialistas, que encontra o que automação não encontra: encadeamento de falhas menores e problemas de lógica de negócio.
- Monitoramento em produção. Detecção contínua de tentativas de exploração no ambiente real, função de um [SOC gerenciado].
Essa sequência não precisa ser implantada de uma vez. O caminho descrito no nosso artigo sobre [DevSecOps] mostra como avançar por estágios de maturidade sem sobrecarregar o time.
E o IAST, onde entra?
Vale mencionar uma quarta sigla que aparece nessa discussão. O IAST (Interactive Application Security Testing) trabalha de dentro da aplicação enquanto ela executa, através de instrumentação. Isso lhe dá simultaneamente a visão de código do SAST e a observação de comportamento do DAST.
Na teoria, resolve as limitações das duas abordagens. Na prática, exige instrumentar a aplicação, o que adiciona complexidade e pode impactar desempenho em alguns cenários. Por isso costuma ser adotado por organizações que já têm as camadas anteriores maduras e calibradas, não como ponto de partida.
A recomendação prática é não se preocupar com IAST antes de ter SCA, SAST e DAST funcionando com taxa de falso positivo controlada e processo de correção estabelecido.
Quer implementar SAST, DAST e SCA sem afogar seu time em alertas?
A Viwsec ajuda a escolher as ferramentas adequadas ao seu estágio de maturidade e a calibrar as regras para o que realmente importa.
Em resumo
SAST analisa código sem executá-lo e atua cedo, quando corrigir é barato, mas gera falsos positivos e não enxerga o ambiente. DAST testa a aplicação rodando e encontra falhas de configuração e autenticação, mas só avalia o que alcança e entra tarde no ciclo. SCA cobre o risco das dependências de terceiros, que nenhum dos dois cobre.
A pergunta correta não é qual escolher, e sim em que ordem implantar e como calibrar cada uma. Começar pelo SCA, avançar para SAST com regras ajustadas, incluir DAST em homologação e complementar com avaliação manual periódica é uma sequência que funciona na maioria dos contextos.
Perguntas frequentes
Qual a diferença entre SAST e DAST?
SAST analisa o código-fonte sem executar a aplicação, encontrando falhas cedo no desenvolvimento. DAST testa a aplicação em execução, simulando ataques externos. O SAST enxerga o código, o DAST enxerga o comportamento. São complementares.
SAST ou DAST: qual devo implantar primeiro?
Se está começando do zero, o SCA costuma dar o retorno mais rápido, com baixa taxa de falso positivo. Entre SAST e DAST, o SAST atua mais cedo e evita que a falha chegue à produção, mas exige calibragem das regras para não gerar ruído excessivo.
SAST substitui o pentest?
Não. O SAST é automatizado e encontra padrões conhecidos no código. O pentest é conduzido por especialistas que exploram falhas de forma criativa, encadeiam problemas menores e avaliam impacto real de negócio. São complementares.
O que é SCA?
SCA (Software Composition Analysis) analisa as bibliotecas e dependências de terceiros usadas na aplicação, identificando vulnerabilidades conhecidas nelas. Como software moderno é majoritariamente montado com componentes externos, é uma camada essencial.
Por que o SAST gera tantos falsos positivos?
Porque trabalha com padrões e nem sempre tem contexto suficiente para saber se o padrão detectado é realmente explorável no seu ambiente. A calibragem das regras é parte obrigatória da implantação, não um detalhe opcional.
Preciso das três ferramentas?
Cada uma cobre um risco diferente, e usar apenas uma deixa lacunas. Mas a implantação pode ser gradual: começar pela que dá mais retorno com menos atrito e evoluir conforme o processo amadurece.
Fontes
OWASP. OWASP Top 10:2025, Open Worldwide Application Security Project: inclusão da categoria Software Supply Chain Failures entre os riscos mais críticos.
OWASP. Application Security Verification Standard (ASVS): referência de requisitos de verificação de segurança em aplicações.
