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

Matheus Armando — Mon, 06 Jul 2026 02:16:16 +0000

DevSecOps · Qualidade · Segurança

Se o seu processo de release é "deu build, sobe", este artigo é para você. Principalmente se você não gostou de ler essa frase.

Julho de 2025 🏷 DevSecOps · SAST · DAST · CI/CD · Testes

Você acaba de ser contratado como Consultor de Qualidade e Segurança em uma startup que cresce 30% ao mês. O produto está em produção, o time faz deploy toda semana, e a rotina é sempre a mesma: sobe o código, cruza os dedos, torce para não cair. Compila e reza. Enquanto isso, os alertas chegam antes do café: mais um bug crítico, mais um vazamento de dados. A pressão por features novas não diminui — aumenta. Este artigo é o documento que você entregaria no seu primeiro mês, sem rodeios.

1. Fundamentação: O que são SAST e DAST — e por que "rezar" não é estratégia

Antes de instalar qualquer ferramenta, é preciso entender exatamente o que cada uma faz — e, mais importante, o que ela não faz. SAST e DAST não são a mesma coisa e não são opcionais uma em relação à outra. Tratá-las como intercambiáveis é o primeiro erro de quem está tentando parar de apagar incêndio.

SAST — Static Application Security Testing

SAST analisa o código-fonte, bytecode ou binário sem executar a aplicação. Ele lê o texto do seu código e procura padrões que denunciam vulnerabilidades conhecidas: SQL Injection hardcoded, senha em plain text, uso inseguro de função criptográfica, input sem sanitização. Ferramentas de referência: SonarQube, Semgrep, Snyk Code, CodeQL.

Pense em SAST como um revisor obcecado por segurança que lê cada linha antes de qualquer coisa ir ao ar. Ele não precisa ver o sistema rodando — só precisa do código na tela.

** Origem do termo**
A OWASP classifica SAST como técnica de "white-box testing": o analisador tem acesso total ao código-fonte, à estrutura interna e à lógica da aplicação. É o oposto direto do DAST, que opera como "black-box".

DAST — Dynamic Application Security Testing

DAST ataca a aplicação em execução, simulando o comportamento de um agente externo malicioso — como um pentester faria de verdade. Ele não lê uma linha de código: manda requisição HTTP, tenta injeção, manipula token, explora endpoint não documentado e observa a resposta. Ferramentas de referência: OWASP ZAP (open-source), Burp Suite, Acunetix.

Se SAST é o revisor de texto, DAST é o invasor simulado testando cada fechadura da casa, uma por uma.

Dimensão	SAST	DAST
Perspectiva	White-box (com acesso ao código)	Black-box (sem acesso ao código)
Quando executa	Antes do build / no commit	Após o deploy em ambiente de teste
O que detecta	Vulnerabilidades no código, más práticas, segredos expostos	Vulnerabilidades em runtime: XSS, CSRF, falhas de autenticação, headers inseguros
Ponto cego	Não detecta problemas de configuração de infraestrutura	Não detecta vulnerabilidades em código não exposto pela interface
Velocidade	Segundos a poucos minutos por scan incremental	Minutos a horas (varredura completa)
Exemplos de ferramentas	SonarQube, Semgrep, Snyk Code, CodeQL	OWASP ZAP, Burp Suite, Acunetix

Onde cada um entra na esteira de CI/CD

A pergunta que importa não é "o que cada ferramenta faz", é em que momento ela entra. Rodar DAST sem um ambiente de staging dedicado, por exemplo, gera ruído em escala industrial e pode até derrubar produção sem querer. A topologia recomendada para uma startup em crescimento:

// CI/CD pipeline — visão de segurança

Fase 1: Commit / PR → SAST + Secret Scan
Fase 2: Build & Unit Tests → SCA (dependências)
Fase 3: Staging Deploy → DAST + E2E
Fase 4: Gate de Qualidade → Quality Gate
Fase 5: Produção → RASP / WAF

O SAST na fase de commit barra vulnerabilidade óbvia antes de entrar na branch principal — o custo de correção aqui é praticamente zero. O SCA (Software Composition Analysis), uma variante do SAST focada em dependências de terceiros (npm, PyPI, Maven), entra junto ao build para caçar pacote com CVE conhecida. O DAST só faz sentido em staging, onde a aplicação roda de verdade sem colocar usuário real em risco.

Reparem: em nenhum ponto desse pipeline existe a fase "cruzar os dedos". Isso não é acidente.

2. Sinergia: Testes automatizados como primeira linha de defesa

Existe um equívoco recorrente em times que adotam segurança tarde demais: achar que SAST e DAST substituem uma suíte de testes sólida. Não substituem. Se o código chega quebrado para o scanner de segurança, a ferramenta vai apontar problema demais para priorizar — e o time afoga em alerta antes mesmo de começar a corrigir o que importa.

A analogia certa é a de uma fortaleza: você não começa pela catapulta (DAST). Começa pelo fosso (testes unitários), depois pelas muralhas (testes de integração), e só então posiciona sentinelas nas torres (SAST). A catapulta simulada (DAST) entra por último, para validar se a fortaleza resiste a um ataque real.

A pirâmide de testes como fundação de segurança

Testes Unitários — a base
Validam a lógica de cada função isoladamente. Do ponto de vista de segurança, garantem que funções de validação, sanitização e autenticação se comportam exatamente como esperado. Um teste que confirma que sanitizeInput() rejeita <script> é a defesa mais barata que existe contra XSS.
(rápido · barato · granular)
Testes de Integração — as muralhas
Verificam como componentes interagem — API com banco, serviço de autenticação com módulo de sessões. Expõem falha de segurança que só aparece na fronteira entre sistemas: token que não expira, permissão que vaza entre contextos, dado sensível trafegando sem criptografia entre microserviços.
(médio · contextual · sistêmico)
Testes E2E — a experiência do usuário malicioso
Simulam fluxos completos do ponto de vista de quem usa (ou abusa d)o sistema. É aqui que se testa o fluxo inteiro de reset de senha, sessões concorrentes, ou se um usuário comum chega ao painel admin só manipulando a URL. Playwright e Cypress com cenários de segurança cobrem o que teste unitário nunca alcançaria.
(lento · abrangente · realista)
SAST / DAST — as sentinelas especializadas
Entram depois, quando o código já passou pelo crivo lógico e funcional. Aí sim focam no que fazem de melhor: identificar padrão de vulnerabilidade que humano nenhum notaria — algoritmo criptográfico obsoleto, endpoint sem rate limiting.
(especializado · complementar)

Cobertura de código não é métrica de vaidade

Time imaturo em qualidade trata cobertura de código como número bonito para o slide de retrospectiva. Time maduro entende cobertura como declaração de risco: cada linha sem teste é uma linha onde pode existir uma vulnerabilidade que nenhum scanner vai detectar com confiança, porque nem o comportamento esperado está documentado.

"A security tool can only find bugs in code that humans understand. Tests document what the code is supposed to do — without that context, automated tools are guessing."
— Gene Kim et al., The DevOps Handbook, 2nd edition

A recomendação prática não é perseguir 100% de cobertura no dia 1 (isso paralisa o time) — é definir coverage gates por domínio crítico: autenticação e autorização com cobertura mínima de 90%; pagamentos e dados pessoais, o mesmo patamar. O resto cresce de forma iterativa.

O custo real de corrigir bugs tarde

O IBM Systems Sciences Institute publicou um dado que virou referência: o custo de corrigir um defeito cresce exponencialmente conforme avança no ciclo de desenvolvimento. Bug pego em teste unitário custa uma fração do mesmo bug pego em produção.

Fase de Descoberta	Custo Relativo de Correção
Teste unitário	1×
Teste integração	2-5×
SAST no CI	5-10×
Teste E2E / DAST	10-20×
Produção	50-100×

Custo relativo de correção por fase de descoberta (baseado em IBM Systems Sciences Institute / NIST)

3. Análise Crítica: Velocidade comercial vs. segurança — e por que "depois a gente arruma" é a pior frase do dicionário de startup

Chegamos à parte que consultor evita escrever porque não tem resposta confortável. Startup em hipercrescimento sofre pressão real para entregar. Produto quer feature. Investidor quer crescimento. Cliente corporativo quer a integração prometida para o demo da próxima semana.

E o tech lead olha para o pipeline com SAST e DAST configurados e pensa: "e esses 200 falsos positivos que o SonarQube jogou na minha cara ontem?"

O problema real dos falsos positivos

Ferramenta de SAST é notoriamente ruidosa, sobretudo nas primeiras semanas. O SonarQube vai marcar MD5 usado para gerar hash de avatar como "Critical Security Hotspot" — mesmo sabendo que esse uso específico não exige resistência a colisão. O Semgrep vai reclamar de um padrão de SQL que na verdade passa por ORM com parametrização automática.

O problema não é o falso positivo isolado. É a fadiga de alerta: quando o time começa a ignorar tudo porque tem ruído demais, ele ignora junto o alerta real. É o efeito manada — só que o lobo, dessa vez, existe.

** Antipadrão perigoso**
Configurar o SAST para "quebrar o build" em qualquer alerta, sem antes triar e calibrar as regras, é o jeito mais rápido de fazer o time desabilitar a ferramenta em silêncio. Comece em modo aviso (warning), não bloqueio (blocking).

A abordagem pragmática: segurança incremental, não segurança perfeita

A resposta ao dilema velocidade-vs-segurança não é binária. Não é "resolve tudo antes do deploy" nem "deixa pra depois". É risco gerenciado com dívida técnica explícita — e documentada, não escondida debaixo do tapete.

Na prática, três movimentos:

1. Estabeleça um baseline e evolua a partir dele. Na primeira semana com SAST, rode o scan mas não bloqueie nada. Classifique o que existe, separe falso positivo de vulnerabilidade legítima, crie supressão justificada para o ruído. Daí em diante, só alerta novo (introduzido em PR novo) bloqueia pipeline. Isso evita herdar a dívida técnica histórica inteira como barreira ao progresso.

2. Implemente um Security Champions Program. Um engenheiro por squad como referência de segurança — não especialista, apenas alguém que mantém a conversa viva — tem impacto maior que qualquer ferramenta isolada. Modelo documentado pela OWASP, distribui responsabilidade sem criar gargalo central.

3. Defina o que é release-blocker. Nem toda vulnerabilidade pesa igual. CVSS 9+ em produção? Para tudo. SQL Injection em endpoint autenticado interno? Sprint dedicado. Hash fraco em funcionalidade de baixo risco? Backlog com prazo. Essa categorização explícita é o que permite ao time seguir entregando sem fingir que segurança não existe.

Existe cenário onde vale a pena pular essas etapas?

// Nossa posição
A resposta curta: tecnicamente, não. Estrategicamente, às vezes — por um prazo curto e sob condição clara.
Do ponto de vista técnico, nunca é aceitável "pular" segurança. Você não elimina o risco, só adia o momento em que ele explode. Vulnerabilidade não descoberta em staging que chega à produção não some por isso. Ela espera.
Do ponto de vista estratégico, existe um único cenário em que uma startup pode operar temporariamente sem DAST completo: quando ainda não há staging estável, o produto não trata dado sensível e não há usuário externo exposto. Isso raramente dura mais de 60 dias numa startup que está crescendo de verdade.
O que nunca é negociável, em nenhum estágio: rodar em produção sem varredura mínima de dependências (SCA) e sem teste unitário nos módulos de autenticação. O custo de um incidente de vazamento — LGPD, reputação, churn — supera em ordens de grandeza qualquer ganho de velocidade obtido ao pular essas checagens.
"Agora a gente cresce, depois a gente arruma" é a frase que abre praticamente todo post-mortem de incidente de segurança que já foi publicado.

O que as referências dizem sobre isso

O NIST SP 800-218 (Secure Software Development Framework), de 2022, estabelece que segurança deve estar integrada em cada fase do desenvolvimento, com ênfase em automação de teste de segurança como prática padrão — não opcional, não luxo de empresa grande.

A Snyk's State of Open Source Security de 2023 mostrou que 44% das empresas sofreram incidente de segurança ligado diretamente a uma dependência de código aberto vulnerável que já era conhecida no momento do deploy — mas sem SCA configurado para pegar. O problema não era falta de tecnologia. Era ausência de processo.

"Security is not a feature. It is a quality attribute. And like performance or reliability, it cannot be bolted on after the fact."
— OWASP DevSecOps Guideline, 2023

Um roadmap para a startup deste caso

Para a startup que contratou este consultor, a recomendação não é implantar tudo de uma vez. É sequenciar por impacto de risco:

Horizonte	Ação	Impacto esperado
Semanas 1-2	Snyk ou Dependabot no repositório principal (SCA)	Elimina dependência com CVE crítica de imediato
Semanas 2-4	Semgrep no CI com regras padrão de segurança (modo warning)	Baseline de SAST sem bloquear deploy ainda
Mês 2	Cobertura mínima de testes unitários em auth/pagamentos (≥80%)	Reduz bug e falso negativo nos scanners
Mês 3	OWASP ZAP em pipeline de staging (CI completo)	DAST automatizado sem impacto em produção
Mês 4+	Quality Gates configurados (SAST bloqueia novo alerta crítico)	Segurança como parte da definição de "done"

** Princípio central**
Segurança não é projeto com data de término. É prática de engenharia que cresce junto com o produto. O objetivo não é "segurança perfeita" — é tornar o custo do ataque maior que o benefício esperado pelo atacante, de forma sistemática e mensurável.

Conclusão

SAST e DAST não são a mesma coisa; são complementares e pertencem a momentos diferentes da esteira. Teste automatizado não é o oposto de segurança — é sua precondição. E pressão por velocidade comercial não é desculpa para ignorar vulnerabilidade: é justamente o contexto em que o processo de segurança precisa ser simples, automatizado e integrado ao fluxo, não um checkpoint manual que ninguém quer rodar.

A startup que sofre com bug em produção e vazamento de dado não precisa de mais ferramenta. Precisa de sequência, priorização e cultura. SAST no commit, teste cobrindo módulo crítico, DAST em staging, e um time que entende que "seguro o suficiente para hoje" não é a mesma coisa que "inseguro para sempre".

O primeiro passo não é configurar o SonarQube. É convencer o CEO de que o incidente que vai derrubar a startup não vem de um concorrente com feature melhor — vem de um campo de formulário que ninguém sanitizou, e de um deploy que foi na fé.

Referências

OWASP Foundation. DevSecOps Guideline. Disponível em: owasp.org/www-project-devsecops-guideline (2023)
OWASP Foundation. OWASP Top Ten. Disponível em: owasp.org/www-project-top-ten (2021)
NIST. Secure Software Development Framework (SSDF) — SP 800-218. National Institute of Standards and Technology (2022)
Kim, G.; Humble, J.; Debois, P.; Willis, J.; Forsgren, N. The DevOps Handbook, 2nd Edition. IT Revolution Press (2021)
Snyk. The State of Open Source Security 2023. Disponível em: snyk.io/reports (2023)
SonarSource. SonarQube Documentation — Security Reports. Disponível em: docs.sonarqube.org (2024)
IBM Systems Sciences Institute. Relative Cost of Fixing Defects. Referenciado em: Pressman, R. Software Engineering: A Practitioner's Approach, 8th Ed.
Forsgren, N.; Humble, J.; Kim, G. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press (2018)
Checkmarx. The State of DevSecOps 2023. Disponível em: checkmarx.com/resources (2023)

Artigo técnico-estratégico · Consultoria de Qualidade e Segurança
Produzido como entrega acadêmica · Tema: DevSecOps e Engenharia de Qualidade

Acadêmicos:

Matheus Armando Piazza Chioquetta
Guilherme Kruger Andrade
Nathan Augusto Prates Piontkoski

DEV Community: Matheus Armando