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 rollout escalonado que comeca com warning-only e termina com bloqueio cirurgico. Este guia percorre o caminho completo: como definir criticidade, cabear SAST, SCA e secrets scanning pra que ganhem confianca, endurecer o proprio pipeline e medir se o time realmente respeita o resultado.

O que 'critico' significa de verdade: severidade por contexto#

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, e cada alerta vai carregar o mesmo peso visual independente do raio de impacto. Use o threat model do servico como base e classifique os ativos em tres tiers. Um microservico tier-1 que processa PII ou dinheiro nao eh a mesma superficie de risco que um job batch interno que le uma replica somente-leitura. Para um servico tier-1, qualquer CWE-89 (SQL injection) ou CWE-78 (injecao de comando do SO) detectada via SAST deve quebrar o build imediatamente. Para um job batch interno, talvez um relatorio semanal seja suficiente. Esse mapeamento de severidade-por-contexto reduz em 60 a 80 por cento os falsos positivos relevantes, segundo medicoes do nosso piloto com 12 squads em 2025. O mapeamento nao eh uma planilha que voce escreve uma vez, mas um artefato de policy-as-code que vive ao lado do servico e eh revisado quando a classificacao de dados muda.

SAST sem fadiga de alerta#

SAST sozinho nao resolve. Combine Semgrep (regras customizadas em YAML, baratas de manter, rapidas em diffs) com CodeQL pra fluxos de dados interprocedurais mais profundos em Java, C# e Go. Rode Semgrep so nos arquivos alterados no check do PR e mantenha um scan de arvore completa toda noite, pra que a latencia pro dev fique baixa e a cobertura continue total. Comece cada regra nova 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 a taxa de wont-fix. Se wont-fix passar de 40 por cento, sua baseline de regras esta errada, nao o time. Depois desse periodo, promova somente as regras com precisao acima de 85 por cento para gate bloqueante. Precisao se mede, nao se assume: pegue 30 achados, peca a um engenheiro pra rotular cada um como verdadeiro ou falso positivo e calcule a razao antes de deixar o gate vermelho.

Configuracao concreta pra copiar#

Um gate minimo de Semgrep fica assim: semgrep ci --config auto --baseline-commit $(git merge-base origin/main HEAD), que escaneia so o que a branch introduz e suprime a divida pre-existente pra nao bloquear um PR por pecados do ano passado. Uma regra custom sao poucas linhas de YAML: um pattern como pattern: exec.Command($CMD, ...) com um metavariable-pattern que marca input contaminado chegando ao argumento, tagueado severity: ERROR e mapeado pra CWE-78. Pra CodeQL, cabeie a action oficial com languages: java e deixe publicar na aba de code-scanning, pra que os achados sejam deduplicados contra o Semgrep em vez de dobrar o ruido. Mantenha cada regra num repositorio versionado com entrada CODEOWNERS, pra que uma mudanca de regra seja ela mesma um PR revisado e nunca uma virada silenciosa de politica que surpreende um squad na segunda de manha.

SCA e o problema de reachability#

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 nunca chama. A unica metrica que importa eh reachability. Uma CVE num caminho de codigo que seu servico nunca executa eh um item de backlog, nao um quebra-build. Use Endor Labs, Socket ou o proprio osv-scanner com flag --experimental-call-analysis pra filtrar CVEs em funcoes nao invocadas, e faca gate somente sobre achados alcancaveis, corrigiveis e de severidade alta ou critica. Combine com um SBOM assinado em tempo de build (syft ou trivy sbom) e uma politica de quarentena que bloqueia uma versao recem-publicada por 48 horas, o que derruba a maioria dos ataques de release malicioso a supply chain. Nao esqueca de typosquatting e namespace hijacking: um proxy interno como Artifactory ou Nexus com allowlist resolve 90 por cento do risco de dependency confusion ao se recusar a resolver nomes internos desconhecidos contra o registro publico.

Secrets scanning e o reflexo de rotacao#

Secrets scanning eh a vitoria rapida que muita gente faz errado. Gitleaks e TruffleHog num hook de pre-commit pegam o vazamento antes do push, mas um hook local eh consultivo e facilmente burlado com --no-verify, entao voce precisa de um segundo scanner no server-side: GitHub Advanced Security push protection, ou Gitleaks como Action obrigatoria. O modelo mental critico: assim que um secret cai num commit pushado, considere-o publico, ponto final. Force rotacao; nao reescreva a historia e diga que corrigiu. Em 2025 vimos 3 incidentes onde times queimaram horas no git filter-repo enquanto a chave AWS exposta ja estava sendo usada pra subir instancias de mineracao. Tenha um runbook automatizado que revoga a credencial em menos de 5 minutos, invalida sessoes dependentes e abre ticket de post-mortem. O modo de secrets verificados do TruffleHog, que testa se uma chave achada esta viva, vale o minuto extra porque permite triagem por exposicao real em vez de por contagem de matches de regex.

Endurecer o proprio pipeline#

Um scanner eh tao confiavel quanto o runner onde ele roda. Use runners efemeros de uso unico, pra que um job comprometido nao persista pro proximo build. Substitua credenciais cloud de vida longa por federacao OIDC de vida curta: o job de CI troca seu token de identidade assinado por um papel cloud escopado de minutos, de modo que nao existe nenhum AWS_SECRET_ACCESS_KEY estatico pra vazar. Fixe actions de terceiros num SHA de commit completo em vez de uma tag flutuante, porque uma tag pode ser reapontada pra codigo malicioso depois da sua auditoria. Configure permissoes de token de minimo privilegio explicitamente (permissions: contents: read) em vez de herdar defaults amplos. Assine artefatos de build e imagens de container com Sigstore cosign e verifique a assinatura no admission, pra que o pipeline que escaneou o codigo tambem prove o que foi entregue. O tooling de seguranca nao pode virar o alvo mais mole no caminho pra producao.

Rollout escalonado: de warning a blocking#

Nao ligue tudo no bloqueio no dia um. Fase um eh observar: cada ferramenta roda, nada quebra o build, e voce coleta baselines de volume de achados, precisao e latencia de fix. Fase dois eh avisar no novo, ignorar o velho: o truque do baseline-commit faz com que so problemas recem-introduzidos aparecam, alinhando o sinal ao que o dev acabou de escrever. Fase tres bloqueia so o conjunto estreito de achados de alta precisao, alta severidade e alcancaveis, e so esses. Publique os criterios de promocao abertamente, pra que um squad consiga prever exatamente o que vai comecar a falhar e quando. De a cada gate uma saida de emergencia com trilha de auditoria: uma excecao documentada e com expiracao aprovada pelo owner do servico, nao um bypass silencioso. Uma excecao visivel, com prazo e revisada eh uma feature; um bypass que ninguem ve eh como os gates apodrecem de volta ao estado que fez o CISO anunciar shift-left em primeiro lugar.

Metricas de friccao e o SLA interno#

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 por cento), 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 antes de adicionar mais um scanner. Trate as proprias promessas do time de plataforma como um SLA: tempo de resposta de triagem pra um novo critico, uptime do servico de scan e um orcamento maximo de latencia adicionada ao check do PR. Adicione sessoes mensais de purple team sobre fluxos reais pra validar que o que o SAST acha bate com o que um atacante realmente exploraria; um achado de linter sem caminho de exploracao eh uma regra pra rebaixar, e uma falha explorada que o linter perdeu eh uma regra pra escrever.

Armadilhas comuns#

As falhas recorrentes sao entediantemente consistentes. Bloquear sobre todo o backlog historico em vez do diff, o que pune o dev errado. Fazer gate sobre CVEs nao alcancaveis, o que treina todo mundo a clicar ignorar por reflexo ate ignorarem tambem a alcancavel. Guardar comentarios de supressao sem expiracao, de modo que um waiver temporario vira cegueira permanente. Rodar secrets scanning so no lado cliente e confiar no hook. Deixar o pipeline de seguranca rodar num runner com credenciais de producao anexadas. Medir volume de achados como se mais alertas significassem mais seguranca, quando o objetivo real eh um fluxo baixo, confiavel e acionado. E o mais humano: entregar o tooling sem um canal onde um dev possa dizer essa regra esta errada e receber uma resposta rapida e respeitosa. Cada um desses transforma um controle defensavel naquilo que os times contornam.

Um checklist pronto pra entregar#

Antes de dar o rollout por concluido, confirme o seguinte. Tiers de ativos definidos e guardados como policy-as-code. SAST rodando com escopo de diff nos PRs com scan completo noturno, regras novas comecando comment-only. SCA fazendo gate somente sobre CVEs alcancaveis, corrigiveis e de severidade alta ou critica, com SBOM assinado por build e janela de quarentena em releases novos. Um proxy interno de pacotes com allowlist contra dependency confusion. Secrets scanning imposto no server-side com push protection, mais um runbook automatizado de revogar-e-rotacionar abaixo de 5 minutos. Runners efemeros, OIDC em vez de chaves cloud estaticas, actions fixadas por SHA, tokens de minimo privilegio e artefatos assinados-e-verificados. Quatro KPIs de friccao em dashboard por squad com SLA publicado. Excecoes documentadas, com expiracao e auditadas. Se faltar alguma linha, voce tem um deploy de scanner, nao um programa de AppSec.

FAQ#

Deve bloquear primeiro SAST ou SCA? Comece com SCA sobre criticos alcancaveis, porque achados de dependencia costumam ter um fix claro e de baixo esforco (subir uma versao) e uma historia limpa de verdadeiro positivo, entao o primeiro gate bloqueante ganha confianca em vez de ressentimento. O bloqueio de SAST vem depois de voce medir a precisao por regra, ja que um gate de SAST barulhento eh o jeito mais rapido de perder a sala.

Como lidamos com um secret que ja esta no historico do git? Rotacione primeiro, sempre, e trate o valor como comprometido desde o instante do push. Reescrever a historia com git filter-repo eh faxina que voce faz depois de rotacionar pra reduzir a exposicao futura, nunca a resposta ao incidente em si. Automatize o caminho de revogacao pra que o tempo medio de rotacao seja de minutos, nao as horas que um corre-corre manual custa enquanto a chave esta sendo abusada.

O takeaway pratico eh simples: nao ligue tudo no bloqueio no dia um. Comece com warning, defina criticidade por contexto, endureca o pipeline que escaneia, 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.