capítulo 05

Lições Aprendidas

O que fica depois de rodar os três gates de ponta a ponta contra um alvo real, e pra onde este laboratório poderia evoluir a partir daqui.

DAST não se comporta como os outros dois gates

Gitleaks e SonarCloud fazem sentido rodando em toda Pull Request, porque cada PR tem um diff diferente — código novo, commits novos, superfície nova pra avaliar. Um scan de DAST contra um alvo fixo não tem essa propriedade: o Juice Shop encontra os mesmos 8 achados independente de qual commit disparou o scan, porque o alvo não mudou.

Rodar o pre-deploy-dast.yml em todo push, como os outros dois workflows, deixava o repositório permanentemente "vermelho" no Actions — tecnicamente correto (o gate está funcionando), mas um sinal ruim pra quem olha de fora, que não tem como distinguir "gate funcionando como esperado" de "pipeline quebrado" só pelo X vermelho.

Quando cada gate vale a pena

Gate	Vale a pena quando	Custo de rodar sempre
Secret scanning	Sempre — é barato, rápido, e o custo de um segredo vazado é alto	Baixíssimo (segundos)
SAST / Quality Gate	Toda PR, avaliando só código novo — retroativo em código legado gera ruído demais pra ser acionável	Baixo (segundos a poucos minutos)
DAST	Sob demanda, ou agendado contra um ambiente de staging real — não a cada commit	Alto (minutos) e pouco informativo se repetido sem mudança no alvo

Documentar exceções, não silenciá-las

O caso do .gitleaks.toml com o fixture de teste (test/fixtures/fake-credentials.js) reforçou um princípio simples: toda exceção a um gate de segurança devia vir com uma linha explicando por que ela é segura — não só o caminho sendo ignorado silenciosamente. Isso vale tanto pra quem revisa o PR quanto pra quem, meses depois, encontra a exceção sem lembrar do contexto original.

O que ficou provado

Os três gates bloquearam achados reais, não simulados, contra um alvo real:

• Gitleaks — bloqueou uma credencial AWS de teste no formato correto (capítulo 03).
• SonarCloud — reprovou o Quality Gate por Security Rating em código com credencial hardcoded, SQL injection e eval().
• OWASP ZAP — encontrou 8 problemas reais de configuração de segurança no Juice Shop rodando.

Todo o código, os workflows e as evidências estão públicos em github.com/RootKaito/secure-pipeline-poc.

Para onde evoluir

• DefectDojo — consolidar os achados dos três gates num único dashboard, em vez de três relatórios separados. Cortado da v1 de propósito, entra só se justificar um capítulo próprio.
• ZAP agendado — em vez de só disparo manual, rodar semanalmente contra um ambiente de staging de verdade (não um container efêmero do runner).
• Mais regras do SonarCloud — este laboratório provou o gate com um caso deliberadamente óbvio; um próximo passo natural é testar contra vulnerabilidades mais sutis.