DevSecOps Metrics: medindo segurança em pipelines CI/CD
Sem métricas de segurança, o shift-left vira teatro. Este post cobre as métricas que realmente indicam se o programa de DevSecOps está avançando, como coletá-las e como evitar armadilhas de vaidade.
Quando um time adota ferramentas de scanning no pipeline, a pergunta que segue, se houver honestidade, é: como saber se isso está funcionando? Rodar um SAST em cada pull request e contar o total de alertas não responde à pergunta. Responde outra, menos útil: a ferramenta está produzindo saída. Métricas de segurança existem para transformar essa saída em sinal que orienta decisões.
Este post cobre as métricas que fazem isso com mais fidelidade, como instrumentá-las e onde o time costuma se perder entre vanity metrics e indicadores acionáveis.
Por que medir
O argumento para shift-left é que detectar uma vulnerabilidade no código custa menos do que detectá-la em produção. Esse argumento só se sustenta se houver como verificar que a detecção está, de fato, acontecendo mais cedo, e que as falhas encontradas estão sendo corrigidas em tempo razoável.
Sem métricas, o programa de DevSecOps corre dois riscos opostos: pode estar funcionando bem sem que ninguém perceba (e portanto seja contestado no próximo ciclo de corte de budget), ou pode estar acumulando débito silenciosamente enquanto o time acredita estar em controle. Os números resolvem a ambiguidade.
As métricas que importam
A tabela abaixo lista os indicadores mais usados em programas maduros de DevSecOps, o que cada um mede de fato e por que tem relevância prática.
| Métrica | O que mede | Por que importa |
|---|---|---|
| MTTR por severidade | Tempo médio entre detecção e remediação, segmentado por crítica/alta/média | Indica se o time trata vulnerabilidades com prioridade proporcional ao risco |
| Backlog aging | Idade das vulnerabilidades abertas | Vulnerabilidades antigas tendem a ficar invisíveis; o aging expõe débito acumulado |
| Densidade de vulnerabilidades | Vulnerabilidades por KLOC ou por serviço | Permite comparação entre repositórios e acompanhamento de tendência ao longo do tempo |
| Taxa de falsos positivos | Percentual de alertas descartados como FP por ferramenta | Mede a qualidade do tooling; taxa alta corrói a confiança do time nos alertas |
| Cobertura de scanning | % de repositórios ou pipelines com checks ativos | Indica pontos cegos na superfície de ataque |
| Taxa de escape | Vulnerabilidades detectadas primeiro em produção (não no pipeline) | Mede o quanto o pipeline está falhando em pegar o que deveria |
| % de builds barrados | Builds rejeitados pelos quality gates de segurança | Em excesso, indica gates mal calibrados; em déficit, gates muito permissivos |
| Tempo de detecção | Intervalo entre introdução e primeiro alerta | Valida se o shift-left está de fato acelerando a descoberta |
Algumas observações sobre como ler esses números. O MTTR não tem valor absoluto universal: o que é aceitável para uma vulnerabilidade de severidade média em um serviço interno é diferente do que é aceitável para uma crítica em um serviço exposto publicamente. A métrica só faz sentido segmentada. O mesmo vale para densidade: comparar repositórios sem considerar linguagem, tamanho ou fase do projeto gera conclusões erradas.
Métricas de vaidade e como evitá-las
A mais comum é o total de vulnerabilidades encontradas. Esse número sobe quando o time adiciona uma nova ferramenta, expande a cobertura, ou simplesmente mantém o backlog aberto. Ele sobe em situações boas e ruins, e por isso não diz nada sobre o estado real de segurança.
Outro candidato a vaidade é o total de builds executados com scanning ativo, sem olhar para o que o scanning está encontrando ou o que está sendo feito com os achados. Cobertura de scanning é útil; cobertura como fim em si mesma não é.
A distinção entre vaidade e acionável é simples na prática: a métrica leva o time a tomar uma decisão específica? O backlog aging leva (ou deveria levar) a uma triagem das vulnerabilidades mais antigas. A taxa de falsos positivos leva a uma revisão das regras do SAST. O total de vulnerabilidades encontradas não leva a nada por si só.
Como instrumentar
A maioria das ferramentas de scanning expõe APIs que permitem extrair resultados estruturados: Snyk, Semgrep, Trivy, OWASP ZAP, entre outras, todas têm endpoints ou formatos de export (SARIF, JSON) compatíveis com agregação.
O caminho mais comum para times que já operam com observabilidade é exportar esses dados via script para o mesmo stack de métricas que já existe: Prometheus com um exporter customizado, ou ingestão em um data warehouse consultável via Grafana. O trabalho manual costuma ser normalização: cada ferramenta reporta severidade de forma ligeiramente diferente, e sem um mapeamento explícito as comparações ficam inconsistentes.
Plataformas de ASPM (Application Security Posture Management), como Apiiro ou Ox Security, agregam esse trabalho de correlação como produto principal. Fazem sentido quando o volume de ferramentas e repositórios torna a instrumentação manual cara de manter. Para times menores, dashboards customizados em Grafana ou mesmo planilhas atualizadas por CI costumam ser suficientes para começar.
O critério de instrumentação deve ser: a métrica precisa ser coletada automaticamente, sem esforço manual recorrente. Métricas que dependem de alguém preencher um formulário tendem a não sobreviver à segunda semana.
Relação com as métricas DORA
As quatro métricas DORA (lead time for changes, deployment frequency, change failure rate e time to restore service) medem a saúde do processo de entrega. As métricas de segurança que discutimos aqui são complementares, não concorrentes.
A sobreposição mais direta é com o change failure rate: uma vulnerabilidade crítica que chega a produção e exige rollback ou hotfix emergencial é exatamente o tipo de evento que o DORA quer capturar. A taxa de escape de segurança contribui diretamente para essa métrica. Da mesma forma, o MTTR de uma vulnerabilidade crítica tem equivalência com o time to restore service quando o incidente tem componente de segurança.
Times que já coletam DORA têm boa parte da infraestrutura de rastreamento no lugar. Adicionar as métricas de segurança nesse contexto é menos um projeto novo do que uma extensão da mesma instrumentação.
Por onde começar
O erro típico é tentar monitorar tudo de uma vez. Cinco métricas que o time consulta toda semana valem mais do que quinze que ficam em um dashboard que ninguém abre.
Uma sequência razoável para quem está começando: primeiro, cobertura de scanning (saber onde há pontos cegos), depois MTTR por severidade (saber se o que é encontrado está sendo resolvido), e em seguida backlog aging (evitar que débito acumule silenciosamente). Com essas três estabilizadas e integradas ao ritual de revisão do time, adicionar taxa de escape e taxa de falsos positivos fica natural.
O objetivo não é um número alto em nenhum indicador isolado. É ter visibilidade suficiente para priorizar o trabalho de segurança com a mesma clareza com que o time prioriza o restante do backlog de engenharia.