Ligar um analisador estático no pipeline e quebrar o build a cada achado é o caminho mais curto para o scanner ser desligado em silêncio. Sem critério de aceite, o time recebe centenas de alertas de código antigo que ninguém vai tocar nesta sprint, e o achado novo — o único que dá para bloquear com custo baixo — desaparece no ruído. A decisão que funciona inverte a lógica: requisitos do OWASP ASVS definem o que verificar, o scan por diferença bloqueia apenas o que o pull request introduz, e o estoque antigo vira plano de remediação com dono e prazo. O problema atinge times que já rodam SAST ou scan de secrets no CI/CD e veem a fila de alertas crescer semana após semana.
O OWASP ASVS fornece base para verificação de controles técnicos de segurança em aplicações web e uma lista de requisitos para desenvolvimento seguro que serve de métrica, guia e critério de contratação. É esse segundo uso — transformar requisito em verificação automática — que interessa à engenharia defensiva: em vez de discutir se um alerta importa, o time discute qual requisito do padrão aquele alerta cobre e em que nível de rigor. A mesma pergunta passa a ter resposta escrita, auditável e independente de quem está de plantão.
O problema: achado sem dono
Scanner que reporta tudo, toda vez, ensina o desenvolvedor a ignorar tudo. O sintoma clássico é o pipeline com centenas de alertas abertos, correção medida em meses e um acordo tácito de que segurança não bloqueia nada. O dano não é só o atraso: alerta ignorado vira ruído permanente, e o achado sério que entra numa tarde de terça recebe o mesmo tratamento superficial dos outros duzentos.
A correção estrutural tem duas partes. A primeira é escopo: o pull request é a única fronteira em que autor, contexto e motivação estão disponíveis ao mesmo tempo, e é onde o custo de correção é menor — quem escreveu o código ainda entende o que fez e o diff é pequeno. A segunda é critério: sem um padrão que diga quais requisitos precisam passar antes do merge, a conversa vira opinião contra opinião.
Há também o efeito de evidência. Alerta novo no PR vem com diff pequeno, autor identificado e contexto fresco; o mesmo alerta, seis meses depois, exige arqueologia — quem escreveu, por quê, se o caminho ainda é alcançável, se o dado que passa por ali é sensível. Quanto maior o intervalo entre introdução e descoberta, maior o custo da decisão e maior a chance de a decisão ser “depois”. O gate no PR não busca perfeição; marca o ponto em que decidir custa menos.
O NIST SP 800-218 publica o Secure Software Development Framework na versão 1.1, com recomendações para mitigar o risco de vulnerabilidades de software ao longo do ciclo de desenvolvimento. Publicado em fevereiro de 2022, o documento é a referência natural para estruturar esse processo — da escolha de ferramentas à triagem de resultados — sem depender de esforço heróico de uma pessoa só.
O que o padrão exige
A versão estável do ASVS é a 5.0.0, e cada requisito tem identificador no formato capítulo.seção.requisito, o que permite citar o item exato num ticket, num comentário de revisão ou na mensagem de um alerta. Na prática, a equipe escolhe um subconjunto — capítulos de codificação, validação e manuseio de erros, por exemplo — e declara, para cada requisito escolhido, se ele é verificado por análise estática, por teste dinâmico ou por revisão humana. Essa declaração é o contrato do pipeline: o que a ferramenta consegue provar entra como gate; o que não consegue vira item explícito de revisão, não silêncio.
O padrão também prevê uso explícito em contratos e aquisição: os requisitos servem de base para especificar verificação de segurança de aplicações em acordos com fornecedores. Para a equipe interna, isso significa que o mesmo identificador citado no pipeline serve na auditoria, no questionário de um cliente e na negociação com um terceiro — uma linguagem só, do commit ao contrato.
O erro comum é tentar cobrir o padrão inteiro no primeiro mês. O corte recomendado começa pelos requisitos que o SAST já verifica com regras confiáveis — injeção, codificação de saída, chamadas perigosas de shell e desserialização — e expande a cobertura conforme o time escreve ou adapta regras próprias. DAST complementa os pontos que a análise estática não alcança; o portal já detalhou como avaliar o OWASP ZAP no pipeline com critérios e limites.
Scan por diferença no PR
Ferramentas modernas separam os dois modos de operação com nomes próprios. Na documentação do Semgrep para CI, o modo diff-aware compara o código antes e depois de um baseline e retorna apenas os achados criados por essas mudanças; é o modo adequado para pull request e merge request, porque devolve ao autor somente o que ele próprio introduziu. O scan completo roda sobre todo o repositório e é recomendado na branch padrão em cadência regular — todas as noites ou toda semana — para manter o inventário de dívida visível sem bloquear ninguém.
Dois erros de configuração sabotam o resultado. O primeiro é apontar o baseline para um commit arbitrário em vez da branch padrão: o scan volta a cuspir dívida antiga e o time desiste. O segundo é deixar o scan completo como único modo: ele encontra tudo, sempre, e não responsabiliza ninguém. Os dois modos existem para papéis diferentes — descoberta no repositório inteiro, bloqueio na fronteira do PR — e trocar um pelo outro recria o problema original.
Essa separação resolve o dilema do gate: bloquear apenas achados novos é justo com o autor e barato para o processo, enquanto o inventário antigo é gerenciado como backlog com priorização explícita. Sem os dois modos, a única escolha possível é entre pipeline cego e pipeline que ninguém suporta.
Checklist de implantação
A implantação cabe em uma semana quando o CI/CD já está estruturado. O roteiro mínimo:
| Etapa | Ação | Resultado esperado |
|---|---|---|
| Baseline | Definir a branch padrão como referência e ativar o scan por diferença nos PRs | Autor vê apenas achados que seu código introduziu |
| Critério | Mapear os requisitos do ASVS escolhidos às regras do scanner | Alerta citado com o identificador do padrão |
| Secrets | Ligar scan de segredos com bloqueio imediato no PR | Credencial nova não chega à branch protegida |
| Inventário | Agendar scan completo na branch padrão | Dívida antiga medida e priorizada com dono |
| Exceção | Criar processo com prazo e registro para regra contestada | Falso positivo vira refinamento, não bypass permanente |
O bloqueio de segredos no PR segue a mesma lógica de barreira antecipada já detalhada em segredos no CI/CD: credencial exposta não chega ao repositório, e a resposta automática é rotação, não discussão.
Prioridades e sinais
P1 — semana 1: scan por diferença ativo nos pull requests, com bloqueio para achados de severidade alta e para qualquer segredo exposto, e mensagem de erro citando o requisito do ASVS correspondente. P2 — semanas 2 a 4: scan completo agendado na branch padrão, classificação do inventário antigo em três faixas de prazo e meta de cobertura declarada por capítulo do padrão.
Divisão de papéis acelera a adoção: quem abre o PR corrige o que o scanner apontou no próprio código; a equipe de segurança mantém as regras, o mapa para o ASVS e o processo de exceção; o dono do repositório responde pelo backlog antigo e pela meta de cobertura. Sem essa divisão escrita, o gate vira disputa em cada alerta.
Sinais de que a mudança funciona: número de achados novos que atravessam o PR sem correção em queda; tempo médio entre achado e correção no código novo medido em horas; fila antiga diminuindo sem picos de reabertura. Sinal de alerta: pedidos de exceção virando rotina — isso indica regra com falso positivo crônico, e a resposta correta é refinar a regra, não abrir exceção geral.