Segurança e Qualidade na Prática: O Papel do SAST, DAST e Testes Automatizados no Ciclo de Vida do Software Moderno

Maksuel — Sun, 28 Jun 2026 18:27:58 +0000

Imagine o seguinte cenário: uma startup em hipercrescimento acaba de fechar uma rodada Série A. O produto cresce 40% ao mês, o time de engenharia dobra de tamanho em seis meses, e o CTO acorda às 3h da manhã com uma notificação: dados de clientes foram expostos por uma falha de SQL Injection em um endpoint que "ninguém lembrava que existia". O custo? Não é só o dinheiro gasto em resposta ao incidente — é a confiança perdida, a mancha na marca e, dependendo da jurisdição, as multas da LGPD que podem chegar a 2% do faturamento bruto, limitadas a R$ 50 milhões por infração.

Este cenário é mais comum do que parece. E a raiz do problema raramente é falta de talento. É falta de processo.

Neste artigo, vamos dissecar as ferramentas e práticas que formam a espinha dorsal de um ciclo de desenvolvimento seguro: SAST, DAST e testes automatizados. Mais do que definir conceitos, queremos entregar um mapa de decisões que um time real pode usar amanhã.

Fundamentação: SAST e DAST — Dois Olhares sobre o Mesmo Problema

Static Application Security Testing (SAST)

O SAST analisa o código-fonte, bytecode ou binário da aplicação sem executá-la. Pense nele como um revisor de código extremamente pedante que conhece de memória todos os CVEs e padrões de vulnerabilidade catalogados pelo OWASP.

Ferramentas como SonarQube, Semgrep, Checkmarx e Snyk Code varreram o repositório à procura de padrões conhecidos: injeções, secrets hardcoded, uso de funções inseguras, criptografia fraca, entre outros. O SonarQube, por exemplo, mapeia issues diretamente às categorias do OWASP Top 10 e ao CWE (Common Weakness Enumeration), oferecendo não apenas o problema, mas o contexto educacional do "por quê isso é perigoso".

Quando aplicar no CI/CD:

Commit → [SAST scan] → Build → Testes → Deploy

O SAST deve rodar o mais cedo possível na esteira — idealmente como um passo de pré-build ou integrado ao pull request review. A filosofia aqui é o chamado "shift left": empurrar a verificação de segurança para a esquerda do ciclo de vida, onde o custo de correção é menor. Segundo o NIST, corrigir uma vulnerabilidade em produção custa até 30 vezes mais do que corrigi-la durante o desenvolvimento.

Limitações: O SAST não tem contexto de runtime. Ele não sabe como variáveis de ambiente serão configuradas, como a rede estará exposta ou como os dados realmente fluirão entre componentes. Daí a necessidade do seu complemento.

Dynamic Application Security Testing (DAST)

O DAST testa a aplicação em execução, simulando o comportamento de um atacante externo. Ferramentas como OWASP ZAP (Zed Attack Proxy), Burp Suite e Invicti (antigo Netsparker) enviam requisições HTTP reais à aplicação, injetam payloads maliciosos e analisam as respostas em busca de comportamentos anômalos.

Enquanto o SAST pergunta "esse código pode ser vulnerável?", o DAST pergunta "essa aplicação, tal como está rodando agora, é vulnerável?".

Quando aplicar no CI/CD:

Build → Testes Unitários → Deploy (Staging) → [DAST scan] → Deploy (Produção)

O DAST precisa de uma aplicação em execução, então ele se encaixa após o deploy em staging. Pipelines modernos usam abordagens como DAST incremental — varrendo apenas endpoints modificados por uma PR — para reduzir o tempo de execução de horas para minutos.

O OWASP ZAP, em sua modalidade de API scan, consegue ser integrado ao GitHub Actions ou GitLab CI com configuração mínima, varrendo automaticamente o contrato OpenAPI/Swagger de uma API REST.

Limitações: O DAST tem cobertura limitada a superfícies acessíveis externamente. Lógica de negócio, validações internas e falhas que só aparecem com dados muito específicos podem escapar.

A Complementaridade é Obrigatória

DimensãoSASTDASTQuando rodaPré-build / na PRPós-deploy em ambiente de testeO que analisaCódigo-fonteAplicação em execuçãoTipo de vulnerabilidadeCode-level (ex: XSS no código)Runtime (ex: header misconfiguration)Falsos positivosAlto (varia por ferramenta)ModeradoCusto de integraçãoBaixoMédioContexto de runtimeNãoSim

A combinação dos dois — junto com o SCA (Software Composition Analysis) para dependências de terceiros, como faz o Snyk — forma uma camada de segurança que nenhuma das abordagens entrega sozinha. O OWASP recomenda explicitamente o uso combinado no seu Application Security Verification Standard (ASVS).

Sinergia: Testes Automatizados como Primeira Linha de Defesa

Antes que qualquer scanner de segurança entre em ação, existe uma camada que muitos times subestimam: a suíte de testes automatizados. E aqui está um insight que vale repetir: um teste unitário bem escrito é uma afirmação sobre o comportamento esperado do sistema — e comportamentos inesperados são onde as vulnerabilidades vivem.

Testes Unitários: Contratos de Comportamento

Um teste unitário que verifica se uma função de autenticação rejeita tokens expirados não é apenas garantia funcional — é uma especificação de segurança executável. Quando esse teste quebra, o CI para antes mesmo do SAST rodar.

Métricas como cobertura de código (code coverage) importam aqui, mas com nuances. Uma cobertura de 80% não significa que os 20% descobertos são inofensivos — frequentemente são os caminhos de erro, os edge cases e os fluxos de autenticação que ficam de fora. Ferramentas como Jest (para JavaScript), JUnit + JaCoCo (para Java) ou pytest-cov (para Python) permitem não só medir cobertura, mas identificar exatamente quais branches e linhas críticas ainda estão sem cobertura.

javascript// Exemplo: teste unitário como defesa de segurança
describe('AuthService.validateToken', () => {
it('deve rejeitar tokens com assinatura inválida', () => {
const tamperedToken = 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.TAMPERED.signature';
expect(() => authService.validateToken(tamperedToken))
.toThrow(InvalidTokenError);
});

it('deve rejeitar tokens expirados mesmo com assinatura válida', () => {
const expiredToken = generateToken({ exp: Date.now() - 3600 });
expect(() => authService.validateToken(expiredToken))
.toThrow(TokenExpiredError);
});
});

Esses testes não passam pelo SAST (o código já estava lá). O DAST também não vai testar esse fluxo com a mesma profundidade. São os testes unitários que garantem que a lógica de segurança foi implementada corretamente.

Testes de Integração: Detectando Vulnerabilidades Sistêmicas

Vulnerabilidades como IDOR (Insecure Direct Object Reference) — onde um usuário acessa o recurso de outro apenas mudando um ID na URL — raramente são capturadas por análise estática, porque o código individualmente pode estar correto. O problema está na interação entre o controller, o service e o banco de dados.

Testes de integração que verificam regras de autorização em nível de API são uma defesa direta contra esse tipo de falha:

python# Teste de integração: proteção contra IDOR
def test_usuario_nao_acessa_dados_de_outro_usuario(client, usuario_a, usuario_b):
client.login(usuario_b)
response = client.get(f'/api/pedidos/{pedido_do_usuario_a.id}')
assert response.status_code == 403 # Forbidden, não 200

Testes E2E: O Smoke Test de Segurança

Testes end-to-end com ferramentas como Playwright ou Cypress podem incluir cenários de segurança básica: tentar acessar rotas protegidas sem autenticação, verificar se cookies têm os atributos HttpOnly e Secure, checar se headers como Content-Security-Policy e X-Frame-Options estão presentes nas respostas.

javascript// Cypress: verificando headers de segurança
cy.request('/').then((response) => {
expect(response.headers).to.have.property('x-frame-options');
expect(response.headers).to.have.property('content-security-policy');
expect(response.headers['strict-transport-security']).to.include('max-age=');
});

A Pirâmide de Testes com Camada de Segurança

    ┌─────────────┐
    │   E2E (10%) │  ← Smoke tests de segurança
    │  + DAST     │
   ┌┴─────────────┴┐
   │Integração (20%)│  ← Testes de autorização, IDOR
   │  + SAST       │
  ┌┴───────────────┴┐
  │  Unitários (70%) │  ← Contratos de comportamento seguro
  └──────────────────┘

A lição: as ferramentas de segurança são mais efetivas quando trabalham sobre uma base sólida de testes. O SAST encontra menos falsos positivos quando o código está bem estruturado. O DAST encontra menos superfície de ataque quando a lógica foi validada por testes de integração.

Análise Crítica: Velocidade vs. Segurança — Uma Falsa Dicotomia

Esta seção representa nossa opinião formada, baseada em pesquisa e prática.

A pergunta que mais ouvimos de times de startups é direta: "Estamos com pressão para entregar. Podemos 'pular' o SAST e o DAST por enquanto?"

Nossa resposta, sem rodeios: não existe "pular" — existe "adiar o custo com juros". Mas a resposta completa é mais nuançada.

O Problema dos Falsos Positivos: Real, mas Gerenciável

Uma das razões mais citadas para desativar scanners de segurança em esteiras de CI é a fadiga por falsos positivos. O SAST, em especial, é notório por gerar alertas sobre código que é perfeitamente seguro em contexto — como uma consulta SQL parametrizada que a ferramenta não consegue distinguir de uma concatenação insegura.

O SonarQube, em seus próprios guias de boas práticas, recomenda uma estratégia de onboarding gradual:

Fase 1 (semanas 1-2): Rodar o scanner em modo de observação, sem quebrar o build. Catalogar os alertas.
Fase 2 (semanas 3-4): Triagem colaborativa. O time de desenvolvimento e o responsável por segurança revisam juntos, marcando o que é falso positivo com justificativa documentada.
Fase 3 (mês 2+): Apenas issues de severidade Alta e Crítica quebram o build. Médias viram tech debt gerenciado no backlog.

Essa abordagem resolve 80% da resistência dos times. O problema não é o scanner — é a falta de um processo de triagem.

O Snyk vai além: seu modelo de "fixable vulnerabilities" prioriza automaticamente vulnerabilidades para as quais existe uma versão corrigida da dependência disponível. Isso transforma uma lista de 200 alertas em 15 ações concretas que o desenvolvedor pode executar com um npm update.

Existe um Cenário Aceitável para Pular?

Aqui, vamos ser diretos com nossa opinião: não existe cenário tecnicamente justificável para remover completamente SAST e DAST de uma esteira de produção. Mas existem estratégias de redução de atrito que são racionais:

O que É aceitável:

Configurar thresholds que apenas bloqueiem vulnerabilidades de severidade Crítica no início.
Usar DAST em modo "passivo" (apenas observação, sem ataques ativos) em um primeiro momento.
Criar uma whitelist temporária para falsos positivos confirmados, com revisão quinzenal.
Executar o DAST completo apenas em deploys para produção, não em cada PR.

O que NÃO é aceitável:

Desativar o SAST "até ter mais tempo" — esse tempo nunca chega.
Ignorar vulnerabilidades de severidade Alta em bibliotecas de terceiros com CVE publicado.
Não ter nenhum processo de verificação de segurança em código que lida com dados pessoais ou financeiros.

O Argumento Econômico que os CEOs Entendem

Para times que precisam vender segurança internamente, o argumento técnico muitas vezes não é suficiente. Use o argumento econômico:

O Ponemon Institute Cost of a Data Breach Report (2024) aponta que o custo médio de uma violação de dados no Brasil é de R$ 6,75 milhões — e esse número sobe exponencialmente quando há dados regulados (saúde, financeiro). O custo de configurar e manter SAST + DAST em uma startup de 20 pessoas? Estimamos entre R$ 2.000 a R$ 8.000/mês em ferramentas (SonarQube Community é gratuito; OWASP ZAP é gratuito; Snyk tem tier gratuito) mais 4-8 horas/semana de um desenvolvedor sênior para triagem.

O ROI é absurdo. Uma única vulnerabilidade evitada paga anos de ferramenta.

DevSecOps: A Cultura que Sustenta a Tecnologia

A lição mais importante que tiramos desta pesquisa não é técnica — é cultural. As empresas que conseguem velocidade E segurança não tratam essas duas coisas como opostos. Elas adotam DevSecOps não como um conjunto de ferramentas, mas como uma mentalidade onde segurança é responsabilidade de todo o time, não apenas do "cara de segurança".

Práticas concretas que vimos funcionar:

Security Champions: um desenvolvedor de cada squad que se aprofunda em segurança e faz a ponte com a equipe dedicada.
Threat Modeling em refinamentos: antes de estimar uma história de usuário, perguntar "o que pode dar errado em termos de segurança nesse fluxo?"
Métricas de segurança no dashboard do time: tempo médio para fechar uma vuln crítica, número de issues abertos por severidade — visíveis para todos, não só para o CISO.

Conclusão

Bugs em produção e vazamentos de dados não são problemas de ferramentas — são problemas de processo. SAST e DAST são aliados poderosos, mas funcionam melhor quando a fundação já está sólida: código testado, times alinhados e uma cultura onde segurança não é uma fase do projeto, mas uma propriedade contínua do produto.

Para a nossa startup hipotética em hipercrescimento, a recomendação prática é:

Esta semana: Integrar SonarQube (ou Semgrep, gratuito) na pipeline de CI. Modo observação, sem quebrar builds.
Este mês: Configurar OWASP ZAP API scan no ambiente de staging. Criar processo de triagem semanal.
Este trimestre: Estabelecer thresholds que bloqueiam Crítico/Alto. Treinar o time em OWASP Top 10. Criar o papel de Security Champion.

A startup que faz isso não está "sacrificando velocidade por segurança". Está construindo a fundação que permite continuar crescendo sem travar em crises de incidente que drenam energia e confiança do mercado.

Segurança não é um feature. É a ausência de bugs com consequências catastróficas.

Referências

OWASP. OWASP Top Ten. https://owasp.org/www-project-top-ten/
OWASP. Application Security Verification Standard (ASVS). https://owasp.org/www-project-application-security-verification-standard/
OWASP. ZAP – Zed Attack Proxy Project. https://www.zaproxy.org/docs/
SonarSource. SonarQube Documentation. https://docs.sonarsource.com/sonarqube/
Snyk. Snyk Developer Security Platform. https://docs.snyk.io/
NIST. The Economic Impacts of Inadequate Infrastructure for Software Testing (2002). Estudo referência sobre custo de bugs por fase.
Ponemon Institute. Cost of a Data Breach Report 2024. IBM Security.
Kim, G.; Humble, J.; Debois, P.; Willis, J. The DevOps Handbook. IT Revolution, 2016.
Forsgren, N.; Humble, J.; Kim, G. Accelerate: The Science of Lean Software and DevOps. IT Revolution, 2018.
LGPD – Lei Geral de Proteção de Dados Pessoais. Lei nº 13.709/2018.

DEV Community: Maksuel

Segurança e Qualidade na Prática: O Papel do SAST, DAST e Testes Automatizados no Ciclo de Vida do Software Moderno