Torne a análise estática sem graça: um pipeline SARIF‑first para times poliglotas

Se você ainda tem cinco scanners e três dashboards discutindo sobre a mesma desreferência de null, você não tem um programa de segurança — você tem uma máquina de ruído. Com o GCC 16 adicionando saída SARIF nativa e o GitHub/GitLab apostando forte no SARIF como a língua franca, acabaram-se as desculpas. Padronize em SARIF, bloqueie apenas problemas novos e torne a análise estática sem graça de novo.

Por que isso, por que agora

Duas manchetes colidem este mês: “Novos recursos no GCC 16: mensagens de erro aprimoradas e saída SARIF” e “GitHub confirma violação de 3.800 repositórios via uma extensão maliciosa do VS Code.” A mensagem para CTOs é direta: a superfície de ferramentas está explodindo, enquanto atacantes adoram pegar carona no seu pipeline de desenvolvedor até a produção. Unificar a análise estática não é um nice‑to‑have — é como você mantém o sinal visível quando o raio de explosão cresce.

A maioria das startups que encontramos segue um antipadrão conhecido:

• JavaScript usa ESLint, tipos do TypeScript e um job de DAST secreto em algum lugar.
• Python roda Bandit e Pylint, cada um publicando seus próprios comentários.
• Go usa go vet e Gosec; times de C++ usam clang‑tidy … às vezes.
• Segurança tenta grampear Sonar ou um SAST comercial por cima de tudo. Ninguém lê o portal.

Engenheiros veem 50+ comentários no PR, metade duplicados, e aprendem a lição errada: ignore os bots. À medida que agentes de IA começam a auto‑refatorar código e abrir PRs por você, esse problema se multiplica — rápido.

A correção não é “um scanner para governar todos”. A correção é um formato e uma política. Esse formato é SARIF. A política é “bloquear apenas problemas novos em linhas alteradas, com uma baseline e um orçamento de risco”.

Uma estrutura de decisões SARIF‑first

1) Quando padronizar

• Você tem 3 ou mais linguagens, 20 ou mais serviços, ou 10 ou mais engenheiros. Acima disso, ferramental sob medida por repositório deixa de escalar.
• Você tem times nearshore ou fornecedores externos. Um único pipeline SARIF dá a todos a mesma fonte da verdade.
• Seu backlog de issues “existentes” de SAST assusta as pessoas. Você precisa de um gate de baseline que não congele a entrega.

2) O que padronizar

• Formato: SARIF 2.1.0. Exija-o para todos os novos analisadores. Aplique conversores nos que não tiverem suporte.
• Armazenamento: Trate SARIF como artefato de CI de primeira classe, não como fluxo de comentários. Guarde 12 meses de artefatos em S3/Blob com versionamento imutável.
• Política: Faça gate em “novos High/Critical apenas em linhas alteradas”, com orçamentos de exceção específicos por serviço.

3) Onde rodar

• Scans de diff no PR: Rode linters rápidos e analisadores de taint nos arquivos alterados. Mire menos de 10 minutos.
• Nightly/semanais: Scans profundos de repositório inteiro (CodeQL, analisadores de programa inteiro) que publicam SARIF mas não bloqueiam PRs; abrem issues apenas se severidade ≥ High.
• Pré‑release: Branches de release recebem um deep scan obrigatório com um SLA curto para correção ou uma aceitação de risco documentada.

4) Como fazer o gate

• OPA na CI: Use Open Policy Agent para ler SARIF e aplicar regras em toda a organização. Exemplo: “Bloqueie se houver qualquer novo CWE‑79 ou CWE‑89 em linhas alteradas.”
• Baselines: Registre o primeiro PR limpo como baseline. Qualquer coisa pré‑existente é backlog, não bloqueador. Apenas deltas fazem o build falhar.
• Orçamentos de risco: Cada serviço recebe um orçamento mensal de “issues conhecidas aceitáveis” (idealmente zero). Gastar o orçamento requer aprovação de produto.

Arquitetura de referência (funciona com GitHub ou GitLab)

Ingestão

• Cada scanner emite SARIF. Para ferramentas sem SARIF nativo, direcione seu JSON/texto para conversores (Microsoft SARIF SDK, sarif‑multitool ou um tradutor simples).
• A CI agrupa todos os arquivos SARIF em um único artefato por job. Carimbe com commit SHA, repositório, branch e ID do build.
• Envie o artefato para armazenamento de objetos (S3/Blob) e para a UI de “code scanning” do seu hospedeiro de código (tanto GitHub quanto GitLab falam SARIF).

Normalização e deduplicação

• Impressões digitais estáveis: Prefira a propriedade “fingerprints” do SARIF. Quando ausente, gere um hash de ruleId + caminho de arquivo normalizado + faixa de linhas + um hash de trecho.
• Deduplicação entre ferramentas: Mapeie regras específicas de ferramenta para CWEs quando possível. Se ESLint security‑xss e Semgrep detectarem o mesmo sink/source, mantenha o achado de maior fidelidade como canônico.
• Mapeamento de severidade: Converja para 4 buckets: Critical, High, Medium, Low. Não importe a severidade do fornecedor ao pé da letra; crie uma tabela de mapeamento uma vez e mantenha-a no código.

Baselines

• Gere uma baseline SARIF na branch padrão. Marque achados pré‑existentes com baselineState=existing.
• Ensine sua política a ignorar achados existentes a menos que mudem arquivos ou elevem a severidade.
• Revise o backlog trimestralmente. Meça burn‑down, não contagens brutas.

Aplicação de política

• Checagens em PR: Rode OPA com uma política rego que lê o SARIF mesclado e o diff. Regra de bolso: bloqueie apenas novos Critical/High em linhas alteradas ou em caminhos de taint que se originem em código alterado.
• Disciplina de comentários: Máximo de 10 comentários de bot por PR. Agregue o restante em um único resumo com links. Se você fizer spam, as pessoas vão silenciar.
• Prazos por severidade: Critical: corrigir ou reverter antes do merge. High: 72 horas. Medium: adicione ao backlog e agende. Low: auto‑triage ou ignore por padrão.

Apresentação

• Anote o código nos diffs pela UI nativa de “code scanning” do hospedeiro de código. Engenheiros não devem sair do PR para ver o achado.
• Forneça um único dashboard somente leitura para tendências: achados novos por severidade/semana, tempo médio até o verde e burn‑down do backlog. Não adicione outro portal full‑time.
• Envie um resumo semanal aos donos do serviço. Mantenha em uma tela.

Mapa de ferramentas: quem já fala SARIF

Boa notícia: você não precisa esperar os fornecedores alcançarem.

• C/C++: GCC 16 (SARIF nativo), clang‑tidy/scan‑build (via conversores), cppcheck (opção SARIF).
• JavaScript/TypeScript: ESLint e o compilador TypeScript ambos suportam formatadores SARIF; scanners de segurança para Node (alternativas ao npm‑audit) podem ser convertidos.
• Python: Bandit e Pylint exportam SARIF via formatadores; mypy pode ser encapsulado.
• Go: go vet e Gosec exportam ou podem ser encapsulados para SARIF.
• Java/Kotlin: SpotBugs/FindSecBugs via conversores; várias ferramentas comerciais exportam SARIF nativamente.
• .NET: Analisadores Roslyn e dotnet build podem emitir SARIF.
• Analisadores focados em segurança: CodeQL (nativo), Semgrep (nativo), Trivy para IaC/K8s (conversor JSON→SARIF), Checkov (conversor JSON→SARIF).

Una tudo com o Microsoft SARIF SDK ou sarif‑multitool para merge e validação. Rode validação de schema na CI — se uma ferramenta emitir SARIF quebrado, falhe rápido e fixe versões.

Processo: torne parte do trabalho, não uma missão paralela

• Aplicação apenas no que mudou: Seus desenvolvedores nunca devem ser bloqueados por problemas legados que não criaram. Essa decisão sozinha é a diferença entre adoção e revolta.
• Uma hora por semana, sem exceções: Todo time de serviço (sim, incluindo contratados nearshore) faz uma triagem de 30–60 minutos. Revise novos Highs, escolha dois Mediums do backlog e feche falsos positivos. 6–8 horas de sobreposição de fuso com Brazil são suficientes para fazer essa cadência pegar.
• Revezar um “steward” de análise estática: Um engenheiro por time é dono da config por um sprint. Eles ajustam regras, não Segurança. Isso cria empatia e mantém as regras relevantes.
• Treine os bots: Se você usa assistentes de código com IA, passe os diffs deles pelos mesmos gates SARIF. Exija do agente a mesma barra de um PR humano.

Modelo de custos: quanto você realmente vai gastar

Estimativas de preços para 2026 que vemos em campo (o seu pode variar):

• GitHub Advanced Security / code scanning: tipicamente preço por usuário; espere dezenas de dólares (USD) por usuário por mês para repositórios privados. Vantagem: UX de SARIF de primeira classe.
• Semgrep Teams/Enterprise: algo em torno de US$ 20–$60 por desenvolvedor por mês no Teams; cotações Enterprise variam. SARIF forte, boa velocidade em diff‑scan.
• SonarQube/SonarCloud: faixas por linhas de código; níveis de entrada na casa de alguns milhares de USD por ano. Suporte a SARIF existe, mas você pode preferir a UI nativa.
• CodeQL: incluído para open‑source; preço enterprise para repositórios privados tipicamente agregado a acordos de plataforma. SARIF nativo, análise profunda.
• Infra: minutos de CI para scans de PR (meta abaixo de 10 minutos, abaixo de US$ 0,10/PR nas taxas típicas de CI), armazenamento de objetos a centavos por GB para artefatos.

Para um time de 40 engenheiros em 25 repositórios, o custo anual all‑in (ferramentas + infra) para rodar um programa SARIF‑first fica entre US$ 25k–US$ 80k. Vemos rotineiramente times recuperarem isso em 1–2 trimestres ao recuperar tempo de engenheiro hoje queimado com comentários barulhentos de bot e apagar incêndios.

Implantação em 12 semanas

Semanas 0–2: Baseline e adesão

• Escolha dois serviços em stacks diferentes. Conecte ESLint/TypeScript e Bandit/Pylint ou Gosec para emitir SARIF.
• Adicione validação e upload de SARIF. Armazene artefatos em object storage com chaves pelo commit SHA.
• Defina seu mapeamento de severidade e a política do OPA. Acorde “bloquear apenas novos High/Critical em linhas alteradas”.

Semanas 3–6: Checagens em PR e scans profundos

• Ative comentários e checagens no PR com limite de 10 comentários mais um resumo.
• Adicione um scan profundo semanal (CodeQL ou regras Semgrep Pro) que abre issues mas não bloqueia merges a menos que seja Critical.
• Crie as primeiras baselines. Transforme o backlog histórico em um board, não um bloqueador.

Semanas 7–12: Escale e ajuste

• Leve para todos os serviços. Exija saída SARIF para qualquer novo analisador; adicione conversores onde necessário.
• Lance a triagem semanal de 30–60 minutos e a rotação de steward.
• Publique um único dashboard com três gráficos: achados novos/semana por severidade, tempo médio até o verde, burn‑down do backlog. Nada além disso.

Como é o estado desejado (números reais)

Em rollouts recentes de clientes (20–60 engenheiros, 15–40 repositórios, stacks mistas), um pipeline SARIF‑first entregou:

• 35–55% menos alertas duplicados em PRs ao mesclar/deduplicar entre ferramentas.
• 30–40% mais rápido no tempo médio até o verde após introduzir gates baseados em diff e limites de comentários.
• Zero logins no “portal de segurança” exigidos por engenheiros de produto — tudo acontece no PR.
• Burn‑down de backlog de 10–20%/trimestre sem congelar a entrega, impulsionado pela triagem semanal.

A surpresa mais comum: depois que o ruído cai, os times param de discutir severidade e começam a corrigir código. Esse é o objetivo.

Armadilhas comuns a evitar

• Bloquear por causa do backlog: Faça isso e a adoção morre. Primeiro baseline, depois gate.
• Estacionar tudo em um novo portal: Se engenheiros tiverem que sair do PR para ver contexto, achados viram teatro.
• Deixar fornecedores definirem suas severidades: Crie um mapeamento único e faça os fornecedores se adaptarem a você.
• Não fixar versões dos analisadores: Uma atualização de regras que transforma 500 achados em “High” numa sexta‑feira vai arruinar seu trimestre. Pinar, testar, promover deliberadamente.
• Sem responsabilidade: Se nenhum time é dono de um achado, ele não será corrigido. Atribua por serviço, não por ferramenta.

Hardening de segurança do próprio pipeline

• Coloque seus scanners em sandbox: Rode em containers mínimos com seccomp/AppArmor e montagens somente leitura. Eles processam código não confiável.
• Allowlists de egress de rede: Scanners não devem “telefonar para casa”. Se uma ferramenta exigir updates, busque via um proxy controlado.
• Configs assinadas: Trate conjuntos de regras como código. Assinados, revisados, versionados. Nada de “click‑ops” mutáveis nas UIs de fornecedores.
• Ateste o build: Use proveniência no estilo SLSA para execuções de CI que geram SARIF. Anexe atestações aos artefatos.

Por que isso importa para times nearshore e distribuídos

Quando seus engenheiros estão distribuídos entre San Francisco, Austin e São Paulo, tooling consistente é cultura. SARIF nivela o jogo: um formato de resultados, um gate, um pequeno conjunto de rituais. Com 6–8 horas de sobreposição com Brazil, a triagem semanal realmente acontece. E quando você traz um parceiro nearshore, eles plugam no seu pipeline no Dia 1 sem discutir scanners — suas regras, seu mapeamento, seu gate.

Em resumo

Padronize tudo que você pode padronizar com segurança. SARIF faz isso para análise estática. Você ainda vai querer scanners diferentes para linguagens e perfis de risco diferentes. Tudo bem. Mas você quer exatamente uma forma de falar sobre o que eles encontraram, um lugar para ver isso no PR, e uma política para decidir se o código embarca.

Pontos‑chave

• Pare de buscar “um único melhor scanner”. Padronize em SARIF e uma política única de aplicação.
• Faça gate apenas em novos problemas High/Critical em linhas alteradas; faça baseline do restante.
• Use OPA na CI para aplicar regras de severidade e cientes de diff de forma consistente entre repositórios.
• Limite comentários de bot e mantenha achados na UI do PR; dashboards servem para tendências, não para triagem.
• Fixe as versões dos analisadores, isole scanners e armazene artefatos SARIF por 12 meses.
• Adote uma triagem semanal de 30–60 minutos e uma rotação de steward; meça tempo médio até o verde e burn‑down do backlog.
• Espere 30–50% menos ruído e ciclos de PR materialmente mais rápidos dentro de um trimestre.