Metrics de segurança: MTTR, vulnerability density e coverage

1. Por que métricas de segurança importam para desenvolvedores

1.1. Mudança de paradigma: de compliance reativo para melhoria contínua

Historicamente, times de desenvolvimento tratavam segurança como uma lista de verificação de compliance — algo que se resolvia uma vez por trimestre. Esse modelo falha porque vulnerabilidades emergem continuamente: novas bibliotecas, novas ameaças, novas configurações incorretas. Métricas como MTTR, vulnerability density e coverage transformam segurança em um processo de melhoria contínua, onde cada sprint gera dados acionáveis.

1.2. O papel do desenvolvedor na cadeia de responsabilidade por segurança

Desenvolvedores não são mais apenas "implementadores de features". Eles são os primeiros a tocar no código que pode conter falhas. Sem métricas, o desenvolvedor não tem visibilidade do impacto de suas decisões. Com métricas, ele pode responder: "Meu PR aumentou a densidade de vulnerabilidades?" ou "Quanto tempo levamos para corrigir a última falha crítica?"

1.3. Métricas como linguagem comum entre Dev, Sec e Ops

Security quer reduzir riscos. Ops quer estabilidade. Dev quer velocidade. Métricas de segurança bem definidas criam uma linguagem comum. Um MTTR de 48 horas diz algo para todos os três times; uma vulnerability density de 0,5 por KLOC orienta decisões de revisão de código.

2. MTTR (Mean Time to Remediate): tempo médio para corrigir

2.1. Definição e cálculo: desde a descoberta até a correção efetiva

MTTR mede o tempo médio entre a identificação de uma vulnerabilidade e sua correção efetiva em produção. O cálculo é simples:

MTTR = Soma dos tempos de correção (em horas) / Número total de vulnerabilidades corrigidas

Exemplo prático:

Vulnerabilidade A: descoberta em 01/03, corrigida em 03/03 = 48 horas
Vulnerabilidade B: descoberta em 05/03, corrigida em 07/03 = 48 horas
Vulnerabilidade C: descoberta em 10/03, corrigida em 12/03 = 48 horas
MTTR = (48 + 48 + 48) / 3 = 48 horas

2.2. Fatores que influenciam o MTTR

  • Criticidade: vulnerabilidades críticas (CVSS 9+) devem ter MTTR menor que 24h
  • Complexidade do fix: patches que exigem refatoração arquitetural elevam o MTTR
  • Blockers: dependências de terceiros, aprovações manuais, falta de acesso a ambientes

2.3. Como reduzir o MTTR: automação de triagem, playbooks e patches rápidos

Estratégias para reduzir MTTR:
1. Automação de triagem: ferramentas que classificam vulnerabilidades por severidade
2. Playbooks de resposta: scripts prontos para correções comuns (ex: atualizar versão de lib)
3. Patches rápidos: hotfixes aprovados em pipeline separado, sem passar por todo o ciclo de QA

3. Vulnerability Density: densidade de vulnerabilidades no código

3.1. Definição: vulnerabilidades por unidade de código

Vulnerability density é o número de vulnerabilidades encontradas dividido pelo tamanho do código-fonte, geralmente por 1.000 linhas de código (KLOC).

Fórmula: Vulnerability Density = (Número de vulnerabilidades / Linhas de código) * 1000

Exemplo:

Módulo A: 1.500 linhas, 3 vulnerabilidades
Densidade A = (3 / 1500) * 1000 = 2,0 vulnerabilidades/KLOC

Módulo B: 8.000 linhas, 4 vulnerabilidades
Densidade B = (4 / 8000) * 1000 = 0,5 vulnerabilidades/KLOC

3.2. Interpretação prática: densidade alta vs. baixa

Densidade alta (ex: acima de 1,0/KLOC) sugere que o módulo precisa de revisão de segurança profunda, possivelmente refatoração. Densidade baixa (ex: abaixo de 0,3/KLOC) indica práticas de codificação seguras, mas não elimina a necessidade de testes contínuos.

3.3. Estratégias para reduzir a densidade: SAST, revisão de código e treinamento

Ações para reduzir vulnerability density:
- SAST (Static Application Security Testing): escaneamento automático a cada commit
- Revisão de código focada em segurança: checklist de OWASP Top 10
- Treinamento direcionado: times com alta densidade recebem workshops específicos

4. Coverage: cobertura de segurança no pipeline

4.1. Tipos de coverage: testes de segurança automatizados, scanning de dependências, SCA

Coverage de segurança mede quanto do pipeline está sendo efetivamente testado contra ameaças. Inclui:

Tipos de coverage:
- SAST coverage: % de branches que passam por análise estática
- SCA coverage: % de dependências escaneadas em busca de CVEs conhecidas
- DAST coverage: % de endpoints testados contra ataques comuns (XSS, SQLi)
- Secret scanning: % de commits verificados para credenciais expostas

4.2. Métricas de coverage: % de branches testados, % de dependências escaneadas

Exemplo de dashboard de coverage:
- Branches com SAST ativo: 85% (15% sem cobertura → risco)
- Dependências escaneadas: 92% (8% sem escaneamento → vulnerabilidades ocultas)
- Endpoints com DAST: 60% (40% sem cobertura → falsa sensação de segurança)

4.3. Impacto da cobertura baixa: falsa sensação de segurança e riscos ocultos

Uma cobertura de 60% pode dar a impressão de que "estamos testando", mas 40% do código ou das dependências podem conter vulnerabilidades críticas. O risco não é uniforme — uma dependência não escaneada pode ser a biblioteca de autenticação.

5. Como integrar essas métricas no dia a dia do desenvolvedor

5.1. Dashboards self-service: visibilidade em tempo real para cada squad

Dashboard ideal por squad:
- MTTR atual (últimos 30 dias)
- Vulnerability density por módulo
- Coverage de SAST e SCA
- Top 5 vulnerabilidades abertas mais antigas

5.2. Gatilhos de alerta: quando o MTTR ou a density disparam

Alertas configuráveis:
- MTTR > 72h para vulnerabilidades críticas → notificação no Slack do squad
- Vulnerability density > 1,5/KLOC em novo PR → bloqueio de merge
- Coverage < 70% em SAST → alerta para o tech lead

5.3. Cultura de dados: usando as métricas para priorizar débitos técnicos de segurança

Métricas não são para punir, mas para priorizar. Se um módulo tem densidade alta e MTTR alto, ele merece um sprint dedicado à segurança. Se a cobertura de SCA está baixa, o time precisa configurar o escaneamento automático.

6. Armadilhas comuns e como evitá-las

6.1. MTTR enganoso: correções superficiais que não resolvem a causa raiz

Um time pode reduzir o MTTR aplicando patches rápidos que não eliminam a vulnerabilidade real. Exemplo: desabilitar um endpoint vulnerável em vez de corrigir a lógica. A métrica melhora, mas o risco persiste.

6.2. Density como único indicador: ignorar gravidade e contexto do negócio

Densidade de 2,0/KLOC com todas vulnerabilidades de baixa severidade pode ser menos preocupante que densidade de 0,2/KLOC com uma vulnerabilidade crítica no módulo de pagamento. Sempre contextualize a densidade com CVSS e impacto no negócio.

6.3. Coverage como meta cega: testar tudo, mas sem qualidade nos testes

Cobertura de 100% em SAST não significa segurança. Ferramentas SAST têm falsos positivos e negativos. O importante é a qualidade dos testes: regras bem configuradas, revisão manual dos resultados e integração com o fluxo de desenvolvimento.

7. Exemplos práticos de cálculo e interpretação

7.1. Cálculo de MTTR: fórmula e exemplo com dados reais de um time

Time X: 10 vulnerabilidades corrigidas em 30 dias
Tempos individuais (horas): 12, 48, 24, 72, 36, 18, 96, 24, 48, 12
Soma: 12+48+24+72+36+18+96+24+48+12 = 390 horas
MTTR = 390 / 10 = 39 horas
Interpretação: o time leva em média 39 horas para corrigir uma vulnerabilidade.
Meta: reduzir para < 24h para vulnerabilidades críticas.

7.2. Cálculo de vulnerability density: comparando dois módulos de um sistema

Módulo de autenticação: 2.500 linhas, 8 vulnerabilidades
Densidade = (8 / 2500) * 1000 = 3,2/KLOC (ALTA)

Módulo de notificações: 10.000 linhas, 5 vulnerabilidades
Densidade = (5 / 10000) * 1000 = 0,5/KLOC (BAIXA)

Ação: priorizar revisão de segurança no módulo de autenticação.

7.3. Dashboard de coverage: mostrando gaps e ações corretivas

Dashboard atual:
- SAST coverage: 78% (gap de 22% em branches de feature)
- SCA coverage: 65% (gap de 35% em dependências indiretas)
- Secret scanning: 100% (todos os commits verificados)

Ações corretivas:
1. Configurar SAST obrigatório em todas as branches de feature
2. Habilitar escaneamento de dependências transitivas
3. Manter secret scanning como está (exemplo de boa prática)

Métricas de segurança não são um fim em si mesmas. Elas são ferramentas para guiar decisões, priorizar investimentos e criar uma cultura de segurança orientada a dados. Quando usadas corretamente, MTTR, vulnerability density e coverage transformam segurança de um fardo em um diferencial competitivo.

Referências