AppSec Shift-Left: SAST, SCA e Secrets Scanning sem Travar o Time

Toda vez que um CISO anuncia 'shift-left' numa quinta-feira, alguma equipe de plataforma passa o fim de semana removendo gates do pipeline. A promessa de detectar vulnerabilidades antes do merge eh real, mas a execucao costuma virar um SAST com 4 mil findings, um SCA reclamando de CVE 2017 numa lib de teste, e um scanner de secrets que falha porque alguem versionou um .env.example. O resultado eh previsivel: PRs ignorados, builds quebrados, dev frustrado e seguranca virando burocracia. Na Basilisk OffSec a gente trata AppSec como produto interno, com SLA, metricas de friccao e um caminho de adocao escalonado que comeca com warning-only e termina com bloqueio cirurgico.

Antes de instalar qualquer ferramenta, defina o que voce chama de 'critico'. Sem essa definicao, Semgrep, Snyk e CodeQL vao competir entre si pra ver quem alarma mais. Use o threat model do servico como base: se voce ainda nao tem um, comece pelo Threat Modeling com STRIDE em Sprints: Exemplo Completo de Microservico e classifique os ativos em tres tiers. Para um microservico tier-1 que processa PII, qualquer CWE-89 ou CWE-78 detectada via SAST deve quebrar o build. Para um job batch interno, talvez so um relatorio semanal seja suficiente. Esse mapeamento de severidade-por-contexto reduz em 60-80% os falsos positivos relevantes, segundo medicoes do nosso pilot com 12 squads em 2025.

SAST sozinho nao resolve. Combine Semgrep (regras customizadas em YAML, baratas de manter) com CodeQL pra fluxos de dados mais profundos em Java e C#. Comece em modo 'comment-only' no GitHub: o bot posta o achado no PR, sem falhar o check. Meca duas coisas durante 30 dias: tempo medio entre o comentario e o fix, e taxa de 'wont-fix'. Se 'wont-fix' passar de 40%, sua baseline de regras esta errada, nao o time. Depois desse periodo, promova somente as regras com precisao acima de 85% para gate bloqueante. Para casos avancados como injection web, complemente com aprendizado pratico em SQL Injection na Pratica: Explorando, Detectando e Mitigando em Lab Controlado e XSS Moderno: DOM, Stored e Reflected com Exemplos Reais em Ambiente de Teste para que os devs entendam o que o linter esta alarmando.

SCA eh onde mais times tropecam. Trivy, Grype e osv-scanner sao bons, mas todos vao apontar centenas de CVEs transitivas em dependencias que voce nao chama. A unica metrica que importa eh reachability. Use Endor Labs, Socket ou ate o proprio osv-scanner com flag --experimental-call-analysis pra filtrar CVEs em funcoes nao invocadas. Combine com SBOM assinado e politica de quarentena, conforme descrito em Supply Chain Security: Assinatura com Sigstore e SBOM Real em CI/CD. E nao esqueca de typosquatting e namespace hijacking: configurar um proxy interno (Artifactory, Nexus) com allowlist resolve 90% do problema, e Dependency Confusion e Typosquatting: Defesa Pratica para Times Dev detalha as armadilhas que ainda escapam.

Secrets scanning eh a vitoria rapida que muita gente faz errado. Gitleaks e Trufflehog rodando no pre-commit pegam o vazamento antes do push, mas voce precisa de um segundo scanner no server-side (Github Advanced Security ou o proprio Gitleaks via Action) pra cobrir bypass do hook local. O ponto critico: quando um secret eh detectado em commit ja pushado, considere-o publicado. Force rotacao, nao rewrite de historico. Em 2025 vimos 3 incidentes onde times perderam horas no git filter-repo enquanto a chave AWS ja estava sendo abusada. Tenha um runbook automatizado que revoga a credencial em menos de 5 minutos e abre ticket de post-mortem.

Metricas de friccao sao o que separa AppSec funcional de teatro de seguranca. Acompanhe quatro KPIs por squad: tempo medio do pipeline de seguranca (alvo abaixo de 4 minutos), taxa de rerun causada por flaky scanners (alvo abaixo de 5%), MTTR de findings criticos (alvo abaixo de 7 dias) e NPS interno do time de produto sobre as ferramentas. Se o NPS cair abaixo de zero, pause a expansao e investigue. Combine com sessoes mensais de purple team focadas em fluxos reais, alinhadas a Purple Team na Pratica: Construindo Ciclo de Feedback Red x Blue, pra validar que o que o SAST acha bate com o que o red team explora.

O takeaway pratico eh simples: nao ligue tudo no bloqueio no dia um. Comece com warning, defina criticidade por contexto, meca friccao, e so promova regras com precisao comprovada. Em seis meses voce tera um pipeline que devs respeitam porque ele raramente erra, e quando alarma, vale a pena olhar. Isso eh shift-left real, nao shift-blame.