SAST (Static Application Security Testing) é a análise de segurança realizada diretamente no código-fonte, bytecode ou binário de uma aplicação, sem executá-la. DAST (Dynamic Application Security Testing) testa a aplicação enquanto ela está em execução, simulando ataques externos como um agente malicioso faria. A diferença fundamental: SAST enxerga o que está escrito no código; DAST enxerga o que acontece quando a aplicação responde a entradas maliciosas. Juntos, SAST e DAST formam a espinha dorsal de um programa de Application Security (AppSec) moderno, cobrindo etapas distintas e complementares do ciclo de desenvolvimento seguro.

O que é SAST — Análise Estática de Segurança

SAST examina artefatos de código sem execução. A ferramenta percorre o código em busca de padrões associados a vulnerabilidades: chamadas inseguras de API, concatenação de strings em queries SQL (possível SQL Injection), uso de funções criptográficas obsoletas, ausência de validação de entrada, controle de acesso falho em nível de função, entre outros. Por operar sobre o código-fonte, SAST pode ser executado desde o primeiro commit, tornando-se a principal ferramenta da abordagem shift-left — mover a segurança para o início do ciclo de vida do software, onde o custo de correção é exponencialmente menor.

As técnicas empregadas por ferramentas SAST variam em profundidade e precisão:

  • Correspondência de padrões (pattern matching): localiza construções de código conhecidamente perigosas por expressões regulares ou assinaturas. É rápida, mas gera mais falsos positivos.
  • Análise de fluxo de dados (data-flow analysis / taint analysis): rastreia o caminho de dados não confiáveis desde a entrada (source) até pontos sensíveis (sink), como gravação em banco de dados, renderização em HTML ou execução de comandos. Reduz falsos positivos significativamente.
  • Análise de fluxo de controle (control-flow analysis): modela todos os caminhos de execução possíveis e verifica condições de erro, race conditions e comportamentos inesperados.
  • Análise semântica: interpreta o significado do código no contexto do framework utilizado, permitindo regras específicas para Django, Spring, React, Laravel, entre outros.

SAST é especialmente eficaz para detectar as categorias do OWASP Top 10 que têm origem em falhas de codificação: A03 (Injection), A02 (Cryptographic Failures), A04 (Insecure Design) e A05 (Security Misconfiguration). O NIST SP 800-218 (Secure Software Development Framework — SSDF) recomenda explicitamente a automação de análise estática como controle fundamental do desenvolvimento seguro.

O que é DAST — Análise Dinâmica de Segurança

DAST trata a aplicação como uma caixa preta. A ferramenta envia requisições HTTP maliciosas, payloads de fuzzing, inputs inesperados e sequências de ações que simulam ataques reais — e analisa as respostas para identificar comportamentos vulneráveis. Por não ter acesso ao código, DAST encontra vulnerabilidades que só se manifestam em tempo de execução: falhas de autenticação e gerenciamento de sessão, cabeçalhos de segurança ausentes (HSTS, CSP, X-Frame-Options), exposição acidental de dados em respostas de API, Server-Side Request Forgery (SSRF), redirecionamentos abertos e configurações incorretas de servidor.

Entre os vetores tipicamente cobertos por DAST estão:

  • Cross-Site Scripting (XSS) refletido, armazenado e baseado em DOM
  • SQL Injection, NoSQL Injection, LDAP Injection e similares
  • Quebras de controle de acesso (IDOR, privilege escalation)
  • Falhas de autenticação (tokens fracos, exposição de credenciais em URLs)
  • Configurações inseguras de CORS
  • Enumeração de usuários e caminhos sensíveis
  • Problemas em implementações de OAuth 2.0 e OpenID Connect

Para APIs REST e GraphQL, ferramentas DAST especializadas importam especificações OpenAPI/Swagger para gerar casos de teste automaticamente. Isso permite cobertura abrangente de endpoints, incluindo aqueles que exigem autenticação via Bearer token, Basic Auth ou cookies de sessão.

IAST — Interactive Application Security Testing

IAST representa uma evolução que combina o melhor dos dois mundos. Um agente de instrumentação é inserido dentro do runtime da aplicação (JVM, CLR, Node.js runtime). Enquanto a aplicação executa — seja por testes automatizados, uso manual ou varredura DAST — o agente monitora internamente o fluxo de dados, chamadas de sistema e comportamentos suspeitos. O resultado é uma precisão muito maior: o IAST sabe exatamente qual linha de código processou um dado não sanitizado que chegou a um sink vulnerável.

A grande vantagem do IAST é a integração orgânica com suítes de testes de integração e end-to-end existentes: a segurança é verificada como efeito colateral dos testes funcionais, sem varredura adicional. A desvantagem é a necessidade de instrumentação por linguagem e a possível sobrecarga de desempenho no ambiente de testes.

SCA — Software Composition Analysis

Estudos recentes indicam que entre 70% e 90% do código de uma aplicação moderna provém de bibliotecas e frameworks de terceiros — open source ou comerciais. SCA audita essas dependências em busca de vulnerabilidades conhecidas (CVEs catalogados no NVD/NIST), licenças incompatíveis com o modelo de negócio e versões que não recebem mais suporte de segurança.

SCA é distinto de SAST: enquanto SAST analisa o código que a equipe escreve, SCA examina o código que a equipe reutiliza. Incidentes como Log4Shell (CVE-2021-44228) — que afetou dezenas de milhares de sistemas por uma biblioteca Java amplamente utilizada — illustram o risco de ignorar a superfície de ataque nas dependências. A integração de SCA no pipeline CI/CD, com bloqueio de builds quando CVEs críticos são detectados em dependências diretas, é hoje uma prática essencial de AppSec.

Comparativo: SAST vs DAST vs IAST vs SCA

Critério SAST DAST IAST SCA
O que analisa Código-fonte / bytecode Aplicação em execução (caixa preta) Fluxo interno durante execução Dependências de terceiros
Exige app em execução Não Sim Sim Não
Falsos positivos Alto (sem tuning) Médio Baixo Baixo
Fase ideal no SDLC Desenvolvimento / PR Staging / pré-produção Testes de integração Qualquer (build time)
Tipo de vulnerabilidade Falhas de codificação Falhas de runtime e config Falhas de fluxo de dados CVEs em dependências
Integração CI/CD Nativa (sem ambiente) Requer ambiente funcional Requer agente instrumentado Nativa (manifest scan)
Cobertura de código proprietário Alta Indireta Alta Nenhuma
Cobertura de dependências Baixa Indireta Parcial Alta

Integração no SDLC e Pipelines CI/CD

A abordagem shift-left preconiza que a segurança deve ser incorporada o mais cedo possível no ciclo de vida do software — idealmente no momento em que o desenvolvedor escreve o código, não semanas depois em uma revisão de segurança manual. Na prática, isso se traduz em:

  1. IDE plugins: extensões que executam análise SAST em tempo real enquanto o desenvolvedor digita, fornecendo feedback imediato (semelhante ao spellchecker para segurança).
  2. Pre-commit hooks: verificações leves de SAST e secrets scanning executadas localmente antes de cada commit.
  3. Pull Request checks: SAST e SCA completos executados no servidor de CI ao abrir um PR, com resultados exibidos inline nos comentários do código.
  4. Pipeline de build: quality gates que bloqueiam o avanço de builds com vulnerabilidades críticas não triadas.
  5. Deploy em staging: acionamento automático de DAST após deploy em ambiente de homologação.
  6. Monitoramento contínuo: SCA executado periodicamente para capturar CVEs publicados em dependências já presentes na codebase, mesmo sem novo código.

O OWASP Application Security Verification Standard (ASVS) nível 2 e 3 define controles verificáveis que podem ser mapeados diretamente para regras SAST e casos de teste DAST, criando uma ponte entre conformidade e automação de segurança.

Falsos Positivos e Falsos Negativos

Toda ferramenta de análise automatizada enfrenta dois problemas opostos: falsos positivos (alertas incorretos que desperdiçam tempo do time) e falsos negativos (vulnerabilidades reais não detectadas). O equilíbrio entre precisão e recall determina a utilidade prática de uma ferramenta.

Ferramentas SAST baseadas apenas em pattern matching costumam gerar taxas elevadas de falsos positivos — às vezes acima de 50% — tornando o processo insustentável sem triagem. Ferramentas com data-flow analysis reduzem esse índice, mas aumentam o tempo de execução. Para DAST, falsos negativos são o maior risco: uma varredura que não autentica corretamente na aplicação pode deixar de testar 80% da superfície de ataque real.

Boas práticas para gerenciar esse equilíbrio incluem:

  • Calibrar as regras SAST para o stack tecnológico específico do projeto
  • Usar supressões documentadas, auditadas e com prazo de validade
  • Complementar SAST com pentest manual para validar os achados de maior severidade
  • Configurar DAST com credenciais de autenticação e scripts de login para cobertura completa
  • Adotar métricas de eficácia (ex.: % de vulnerabilidades reais detectadas em testes controlados)

Categorias de Ferramentas

O mercado de AppSec oferece três categorias de soluções, sem ordem de preferência:

  • Ferramentas open source: projetos mantidos por comunidades (ex.: OWASP oferece referências de ferramentas em seu site oficial). Exigem maior esforço de configuração e integração, mas oferecem transparência e custo zero de licença.
  • Ferramentas comerciais SaaS: plataformas com interfaces web, integrações nativas com GitHub, GitLab, Azure DevOps e Jira, suporte a múltiplas linguagens e painel centralizado de gestão de vulnerabilidades. Geralmente incluem funcionalidades de triagem assistida por IA.
  • Ferramentas de plataforma unificada (ASPM — Application Security Posture Management): consolidam SAST, DAST, SCA, secrets scanning e IAST em uma única plataforma, com deduplicação de findings, priorização por risco e integração com processos de desenvolvimento.

A seleção deve considerar: linguagens e frameworks suportados, integração com o stack CI/CD existente, precisão das regras (taxa de falsos positivos), cobertura de CVEs para SCA, modelo de licenciamento e suporte a regulamentações aplicáveis (LGPD, PCI DSS, SOC 2).

Referências Normativas e Técnicas

  • OWASP Top 10: catálogo das dez categorias de vulnerabilidades mais críticas em aplicações web, base para regras SAST e casos de teste DAST. Disponível em owasp.org.
  • OWASP ASVS (Application Security Verification Standard): framework de controles verificáveis em três níveis de maturidade, mapeáveis para automação AppSec.
  • OWASP SAMM (Software Assurance Maturity Model): modelo de maturidade para programas de AppSec organizacionais, cobrindo governança, design, implementação, verificação e operações.
  • NIST SP 800-218 (SSDF — Secure Software Development Framework): diretrizes do NIST para desenvolvimento seguro de software, incluindo análise estática como controle obrigatório.
  • NIST NVD (National Vulnerability Database): repositório oficial de CVEs utilizado por ferramentas SCA para identificar vulnerabilidades em dependências.
  • CWE (Common Weakness Enumeration): taxonomia de fraquezas de software mantida pelo MITRE, referência para classificação de findings SAST.

Perguntas frequentes

Qual a diferença entre SAST e DAST?

SAST analisa o código-fonte sem executar a aplicação — identifica falhas de codificação como injeções, uso de criptografia fraca e controle de acesso falho diretamente no repositório. DAST testa a aplicação em execução, simulando ataques externos — encontra vulnerabilidades de runtime como cabeçalhos de segurança ausentes, falhas de autenticação e exposição de dados em respostas. São complementares: SAST encontra o 'onde no código', DAST confirma o 'se é explorável em produção'.

Quando usar SAST e quando usar DAST no ciclo de desenvolvimento?

SAST deve rodar a cada commit e pull request, pois não exige ambiente de execução — é a ferramenta de shift-left por excelência. DAST exige a aplicação rodando em staging ou QA, sendo executado após o deploy em homologação e antes de qualquer liberação para produção. Em pipelines maduros, ambos rodam automaticamente: SAST no servidor de CI ao abrir PR, DAST no pipeline de deploy em staging.

O que é IAST e como ele difere de SAST e DAST?

IAST usa agentes instrumentados dentro do runtime da aplicação para monitorar o fluxo de dados internamente durante a execução — seja por testes automatizados ou uso manual. Ao contrário do DAST (caixa preta externa), o IAST vê o fluxo interno e gera muito menos falsos positivos. Ao contrário do SAST (análise offline), precisa da aplicação rodando. É ideal para integrar segurança em suítes de testes de integração existentes.

O que é SCA e por que complementa SAST e DAST?

SCA audita as dependências de terceiros (bibliotecas open source e pacotes) em busca de CVEs conhecidos, licenças problemáticas e versões sem suporte. Enquanto SAST cobre o código que a equipe escreve, SCA cobre o código que a equipe reutiliza — hoje 70–90% do software moderno. Incidentes como Log4Shell ilustram o risco de ignorar dependências. Um programa AppSec completo combina SAST + SCA + DAST + IAST.

Como lidar com falsos positivos em ferramentas SAST?

Falsos positivos são o principal obstáculo à adoção de SAST. Para gerenciá-los: configure regras específicas para o stack tecnológico do projeto; prefira ferramentas com data-flow analysis a simples pattern matching; documente e revise periodicamente as supressões; priorize findings por severidade e contexto real de exploração; e complemente com pentest manual para validar achados críticos. Ferramentas modernas usam IA para ranquear e filtrar resultados, reduzindo ruído significativamente.

A Decripte realiza testes SAST e DAST para empresas?

Sim. A Decripte oferece serviços completos de Application Security — análise estática (SAST), testes dinâmicos (DAST), análise de composição de software (SCA), pentest de aplicações web e mobile, e integração de segurança em pipelines CI/CD — para empresas de todos os portes, do MEI ao Enterprise com mais de 100.000 colaboradores. Os resultados são entregues em relatórios executivos e técnicos, com roadmap de remediação priorizado por risco de negócio.

AppSec profissional para empresas de todos os portes

A Decripte atua em segurança de aplicações para organizações de todos os tamanhos — do MEI ao Enterprise com mais de 100.000 colaboradores. Nossa equipe integra SAST, DAST, SCA e pentest manual em programas de AppSec estruturados, alinhados ao OWASP SAMM e ao NIST SSDF. Combinamos automação no pipeline de desenvolvimento com revisão técnica especializada, garantindo que vulnerabilidades sejam encontradas antes de chegar à produção — não depois de um incidente. Se sua empresa desenvolve ou utiliza software e precisa evoluir a maturidade de segurança de aplicações, entre em contato pela página de planos da Decripte.