Segurança e Qualidade na Prática: o papel do SAST, DAST e dos testes automatizados no ciclo de vida do software moderno

Artigo técnico-estratégico escrito por Cauã Brustolin Tardetti e Gustavo Gehlen Basseggio.
Cenário: consultoria de Qualidade e Segurança para uma startup em hipercrescimento sofrendo com bugs em produção e vazamento de dados.

O problema que ninguém quer admitir

Toda startup em hipercrescimento vive a mesma tensão: entregar rápido ou entregar seguro. O discurso oficial é "os dois", mas na prática, quando a sprint aperta, segurança e testes são as primeiras coisas a serem "vistas depois". O resultado é previsível — e é exatamente o que essa empresa está enfrentando: bugs vazando para produção e, pior, dados de usuário vazando para fora.

A boa notícia é que essa não é uma escolha binária. A abordagem de DevSecOps parte de uma premissa simples: segurança não é uma etapa no fim da esteira, é uma propriedade que se constrói desde o primeiro commit. Nesse modelo, três peças trabalham juntas: SAST, DAST e uma suíte robusta de testes automatizados.

Este artigo é o diagnóstico e o plano de ação. Vamos do fundamento técnico até a parte que realmente importa numa startup: como não deixar a segurança virar o gargalo que trava as entregas.

1. Fundamentação: o que são SAST e DAST, e onde eles entram na esteira

Antes de tudo, uma distinção que resolve 80% da confusão: SAST e DAST não competem entre si. Eles olham para o mesmo problema de ângulos opostos, em momentos diferentes do ciclo de vida. A OWASP e praticamente todos os fornecedores da área (Snyk, Checkmarx, SonarSource) são unânimes nisso — a pergunta certa não é "SAST ou DAST", é "SAST e DAST, quando cada um".

SAST — a análise "de dentro para fora"

O Static Application Security Testing é um teste de caixa-branca: a ferramenta tem acesso ao código-fonte (ou bytecode/binário) e o analisa sem executar a aplicação. Ele lê o código linha a linha procurando padrões conhecidamente perigosos — injeção de SQL, cross-site scripting, segredos hardcoded, criptografia fraca, input não sanitizado.

A grande força do SAST é a granularidade e a precocidade. Ele aponta o problema no nível da linha de código, o que transforma cada finding numa oportunidade de aprendizado para o desenvolvedor. Por isso o SAST é o representante clássico do shift-left: quanto antes a falha aparece, mais barato é corrigi-la.

Onde entra na esteira: o mais à esquerda possível. Idealmente já no IDE (plugins que sinalizam o problema enquanto você digita), depois em pre-commit hooks e, principalmente, no Pull Request / CI, rodando análise incremental apenas sobre o código que mudou. Ferramentas como Snyk Code e SonarQube foram desenhadas para rodar em 1–3 minutos sobre um diff, justamente para caber dentro do PR sem virar gargalo.

O calcanhar de Aquiles: como o SAST não executa a aplicação, ele não tem contexto de runtime. Ele pode apontar uma injeção de SQL num trecho que, na prática, nunca é alcançado por input do usuário. Isso gera o famoso problema dos falsos positivos — voltaremos a ele, porque é o centro de tudo.

DAST — a análise "de fora para dentro"

O Dynamic Application Security Testing é o oposto: teste de caixa-preta. A ferramenta não vê o código; ela ataca a aplicação rodando, do ponto de vista de um atacante externo. Ela dispara payloads maliciosos (SQLi, XSS, CSRF), observa as respostas do servidor e conclui se a aplicação é vulnerável no mundo real.

Justamente por atacar a aplicação em execução, o DAST encontra o que o SAST não consegue: falhas que só existem em tempo de execução — autenticação e autorização quebradas, erros de configuração de servidor, headers inseguros, TLS mal configurado, falhas de lógica de negócio. E como valida o comportamento real, tende a gerar menos falsos positivos que o SAST: se o ataque funcionou, o problema é concreto.

Onde entra na esteira: mais à direita. O DAST precisa de um ambiente rodando, então seu lugar natural é staging / QA, depois do deploy do build. Como um scan completo pode ser lento (de minutos a, em casos extremos, dias, dependendo da configuração), ele raramente bloqueia cada commit — costuma rodar em pipelines nightly ou em gates de pré-release.

A limitação: ele diz que você é vulnerável, mas não onde no código está o problema. Não aponta a linha; aponta o endpoint. Por isso ele é ótimo para priorizar (o que é exploitável de verdade), mas não substitui a precisão cirúrgica do SAST.

O quadro completo

Vale mencionar que SAST e DAST não são a história inteira. Como modelos modernos são compostos por 80–90% de código open source, o SCA (Software Composition Analysis) — que cruza suas dependências contra bancos de CVEs — costuma ser a primeira e mais barata camada a adotar, com baixíssima taxa de falso positivo. E camadas como IAST e RASP entram para casos de maior maturidade. Mas para o escopo desta startup, SAST + DAST + SCA já cobrem a esmagadora maioria do OWASP Top 10.

2. Sinergia: por que a cobertura de testes é a primeira linha de defesa

Aqui está o ponto que muita gente pula: antes de qualquer ferramenta de segurança entrar em ação, a sua suíte de testes já deveria ter feito o trabalho pesado.

A pirâmide de testes — ideia que vem de Mike Cohn e foi consolidada por Martin Fowler — organiza isso: muitos testes unitários na base (rápidos, baratos, isolados), uma camada intermediária de testes de integração e uma fina camada de testes e2e no topo. E existe um consenso na engenharia de qualidade que resume o papel dessa base: o teste unitário é a primeira linha de defesa.

Por quê? Por causa do custo. A regra empírica que circula na indústria é brutal: um bug pego no teste unitário custa ~$1 para corrigir; o mesmo bug pego na integração, ~$10; no e2e, ~$100; em produção, $1.000 ou mais. Cada nível de distância do código multiplica o custo. Um vazamento de dados, então, está no topo dessa escala — com juros de LGPD e de reputação.

Mas onde exatamente os testes ajudam a segurança, e não só a corretude? Em quatro frentes concretas:

a) Testes forçam código testável — e código testável é código mais seguro. Para escrever um bom teste unitário, você precisa de baixo acoplamento, funções coesas e validação de input isolada. Esse mesmo desenho torna trivial raciocinar sobre a superfície de ataque de cada função. Código impossível de testar costuma ser código impossível de auditar.

b) Testes de borda pegam a origem de muitas vulnerabilidades. Boa parte das falhas de segurança nasce de casos de borda mal tratados: input nulo, string vazia, valor fora do intervalo, overflow, off-by-one. Um teste unitário que exercita esses limites já elimina, na base, a classe de bug que depois viraria um finding de SAST — ou um incidente.

c) Ferramentas dinâmicas dependem de código exercitado. DAST e IAST só encontram o que o app efetivamente executa. Sem uma suíte que percorra os caminhos da aplicação, essas ferramentas têm pouca superfície para observar. Cobertura de testes é, indiretamente, cobertura de análise dinâmica.

d) Testes dão a confiança para corrigir a vulnerabilidade. De nada adianta o SAST apontar uma falha se o time tem medo de refatorar a correção porque "pode quebrar alguma coisa". Uma suíte verde é a rede de segurança que permite corrigir rápido — e essa velocidade de remediação é o que separa uma vulnerabilidade de um incidente.

O ponto de amarração de tudo isso é o Quality Gate. Ferramentas como o SonarQube unem, num único checkpoint de CI/CD, a cobertura de testes e a análise de segurança. A filosofia do "Clean as You Code" é elegante justamente por ser pragmática: o gate não te obriga a consertar a base legada inteira; ele olha apenas para o código novo e falha o build se aquele diff derrubar a cobertura ou introduzir uma vulnerabilidade. Você não precisa "ferver o oceano" — só precisa manter limpo o que você tocou hoje. A qualidade da base sobe organicamente.

Uma ressalva honesta, para não vender ilusão: testes não substituem SAST/DAST. São coisas distintas. O teste verifica se o software faz o que deveria; o SAST/DAST caçam o que ele não deveria permitir. Um teste unitário passando não garante ausência de injeção de SQL. Mas uma suíte robusta reduz drasticamente o volume de bugs que chega às ferramentas de segurança — e é isso que as torna gerenciáveis em vez de sobrecarregadas de ruído.

3. Análise crítica: velocidade comercial vs. falsos positivos — dá para "pular"?

Chegamos à parte incômoda. Numa startup em hipercrescimento, a pressão por features é real e legítima — não é preguiça, é sobrevivência de mercado. E a maior fonte de atrito entre essa pressão e a segurança tem nome: falso positivo.

Os números explicam a dor. Ferramentas de SAST legadas operavam com taxas de 40% a 60% de falso positivo — em casos extremos, de 50% a 80%. A triagem de um único falso positivo custa entre 15 e 30 minutos de um desenvolvedor, que sai do fluxo de trabalho para investigar um fantasma. Multiplique isso por centenas de findings por scan. Pesquisas da Veracode chegaram a apontar que apenas ~11% das falhas descobertas representavam risco real; o resto é o que a Pixee chamou, com precisão cirúrgica, de "triage theater" — o teatro da triagem, o trabalho de segurança sem o resultado de segurança.

E aqui está o efeito mais perigoso, o "poço envenenado": quando o desenvolvedor aprende que a maioria dos alertas é ruído, ele passa a tratar todos os alertas como ruído — inclusive os verdadeiros. Um gate que grita o tempo todo é um gate que ninguém escuta. Nesse ponto, a ferramenta de segurança não só falhou em proteger, como criou uma falsa sensação de segurança, que é pior que nenhuma.

Nossa tese

O dilema real não é "velocidade vs. segurança". É "ruído vs. sinal". Você não equilibra entrega e segurança pulando etapas; você equilibra calibrando a segurança para que ela seja rápida o bastante para não ser o gargalo. A pressão comercial não é desculpa para abrir mão da análise — é o motivo pelo qual a análise precisa ser bem configurada.

Em vez de "pular", o time faz cinco movimentos técnicos:

1. Prioriza por severidade e exploitability, não por volume. O build bloqueia apenas em Critical/High que sejam reachable (alcançáveis por input real). Medium/Low viram warning e backlog priorizado. A análise por reachability é o que separa "teoricamente vulnerável" de "de fato explorável" — e ferramentas modernas reduzem o ruído acionável em 85–95% justamente por aí.

2. Escaneia o diff, não o mundo. Análise incremental sobre o código novo (a lógica do Clean as You Code) dá feedback em minutos dentro do PR, em vez de reprocessar a base inteira a cada commit.

3. Gerencia a supressão com dono e registro. Um falso positivo confirmado é marcado uma vez e não volta a poluir. Investir tempo em tuning das regras é o que decide se a ferramenta será usada ou ignorada.

4. Coloca cada teste no lugar certo do tempo. SAST rápido e inline no IDE/PR; DAST pesado no nightly de staging. Nunca o scan lento bloqueando cada push.

5. Configura o gate para ser útil, não punitivo. Como bem colocou um autor no Dev.to sobre SonarQube: o gate não é sobre "código perfeito" nem sobre expor ninguém no PR — é sobre traçar uma linha clara: o código novo não pode piorar o sistema. Ponto.

Então... existe cenário onde é aceitável "pular"?

Sim, mas com uma distinção que muda tudo: pular o gate bloqueante temporariamente ≠ pular a análise. Você pode decidir não bloquear o merge em um caso específico, mas continua escaneando e registrando o achado. Visibilidade nunca se abre mão; enforcement é negociável, caso a caso.

Onde nunca é aceitável pular — nem o gate, nem a análise:

• Código que toca autenticação, autorização, pagamento, PII ou qualquer dado sensível.
• Qualquer superfície exposta à internet.
• Essa startup em particular: ela já teve um vazamento. Pular segurança aqui não é trade-off, é negligência. O custo esperado de um segundo vazamento (multas de LGPD, churn, perda de confiança) supera com folga o custo de uma feature atrasada.

Onde é defensável relaxar o gate bloqueante temporariamente — sempre com trade-off explícito, dono e prazo:

• Protótipos, spikes e código descartável que comprovadamente não vão a produção.
• Ferramental interno sem exposição externa nem dados sensíveis.
• Código atrás de feature flag desligada (efetivamente código morto naquele momento).
• Quando o próprio gate está mal calibrado e gerando 90% de ruído. Nesse caso você desbloqueia o merge e conserta a configuração — você não abandona a prática, você a repara.

A regra de ouro é uma só: nunca pule silenciosamente. Toda exceção precisa de dono, prazo e registro formal de aceitação de risco. Dívida de segurança funciona igual a dívida técnica — é aceitável quando é consciente e tem data para ser paga. O problema nunca foi tomar um atalho; foi tomá-lo sem ninguém saber e sem plano de volta.

Conclusão: a esteira que resolve o problema da startup

Voltando ao diagnóstico inicial — bugs em produção e vazamento de dados. A solução não é escolher entre andar rápido e andar seguro. É montar uma esteira onde a segurança é rápida o suficiente para não atrapalhar:

IDE            → SAST inline + SonarLint (feedback enquanto digita)
Pre-commit     → lint + secrets scan
Pull Request   → Testes unitários + integração + SAST incremental + SCA
                 └─ Quality Gate (Clean as You Code): bloqueia só o código novo
Merge → Deploy staging → DAST (nightly) + e2e
Produção       → monitoramento + gestão de dívida de segurança registrada

Testes unitários e de integração formam a fundação barata que elimina bugs na origem. O SAST entra cedo, incremental e calibrado, pegando as falhas de código com o mínimo de ruído. O DAST valida em staging o que só aparece em execução. E o Quality Gate amarra qualidade e segurança num único "pode passar / não pode passar", focado no código novo.

Numa startup em hipercrescimento, a segurança que "atrasa entregas" quase sempre é uma segurança mal configurada, não uma segurança em excesso. Ferramenta calibrada, análise no diff e gate sobre código novo entregam as duas coisas ao mesmo tempo. Pular vira dívida — e dívida de segurança cobra juros compostos, geralmente na forma de um vazamento no pior momento possível.

Referências

• OWASP Foundation — DevSecOps Guideline (SAST, DAST e IAST). https://owasp.org/www-project-devsecops-guideline/
• OWASP — Top 10. https://owasp.org/www-project-top-ten/
• Snyk — How does SAST work? Benefits & Limitations. https://snyk.io/articles/application-security/static-application-security-testing/
• Snyk — SAST vs. DAST vs. IAST vs. RASP. https://snyk.io/articles/sast-dast-iast-rasp/
• SonarSource — Quality Gates (documentação oficial). https://docs.sonarsource.com/sonarqube-server/quality-standards-administration/managing-quality-gates/introduction-to-quality-gates
• SonarSource — Clean as You Code. https://docs.sonarsource.com/sonarqube-server/9.9/user-guide/clean-as-you-code
• Martin Fowler — The Practical Test Pyramid. https://martinfowler.com/articles/practical-test-pyramid.html
• Checkmarx — SAST vs. DAST: Key Differences and When to Use Each. https://checkmarx.com/learn/sast/sast-vs-dast/
• Wiz — SAST vs. DAST: What's the difference?. https://www.wiz.io/academy/application-security/sast-vs-dast
• Pixee — SAST False Positives: 91% Are Noise (dados de falso positivo e "triage theater"). https://www.pixee.ai/blog/sast-false-positives-reduction
• Astra Security — What's a False Positive & How to Triage It in SAST+DAST?. https://www.getastra.com/blog/dast/false-positive-triage/