Interpretar alertas de ferramentas de scanner

  • 11 minutos

As ferramentas de Análise de Composição de Software geram inúmeros alertas sobre vulnerabilidades, problemas de licença e preocupações com a qualidade do código nas dependências. Interpretar efetivamente esses alertas requer entender as pontuações de severidade, avaliar a explorabilidade, gerenciar falsos positivos e priorizar os esforços de correção com base no risco real para seus aplicativos. Sem a interpretação e a priorização adequadas, as equipes enfrentam fadiga de alerta e perda de tempo em problemas de baixo impacto enquanto não têm vulnerabilidades críticas.

Noções básicas sobre a gravidade da vulnerabilidade

As pontuações de severidade de vulnerabilidade fornecem avaliações de risco padronizadas:

Sistema de pontuação CVSS

O CVSS (Common Vulnerability Score System) fornece pontuações numéricas padronizadas que indicam gravidade da vulnerabilidade.

Categorias de métricas CVSS:

  • Métricas base: Características de vulnerabilidade intrínseca independentemente de ambientes específicos.
  • Métricas temporais: Características de vulnerabilidade que mudam ao longo do tempo (disponibilidade de exploração, disponibilidade de patch, confiança).
  • Métricas ambientais: Características de vulnerabilidade específicas para determinados ambientes e implantações.

Cálculo da pontuação base do CVSS v3: As pontuações base combinam várias métricas:

Métricas de exploração:

  • Vetor de ataque (AV): Rede (N), Adjacente (A), Local (L) ou Físico (P).
  • Complexidade de ataque (AC): Dificuldade baixa (L) ou Alta (H) em explorar a vulnerabilidade.
  • Privilégios necessários (PR): nenhum (N), privilégios baixos (L) ou altos (H) necessários para exploração.
  • Interação do usuário (interface do usuário): Nenhum (N) ou Obrigatório (R) para exploração bem-sucedida.

Métricas de impacto:

  • Impacto de confidencialidade (C): Nenhuma (N), baixa (L) ou alta (H) divulgação de informações.
  • Impacto na integridade (I): Capacidade de modificação de dados Nenhum (N), Baixo (L) ou Alto (H).
  • Impacto na disponibilidade (A): Nenhuma (N), baixa (L) ou alta (H) interrupção do serviço.

Exemplo de vetor CVSS:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Isso representa uma vulnerabilidade explorável por rede com baixa complexidade de ataque, sem privilégios necessários, sem interação do usuário e alto impacto na confidencialidade, integridade e disponibilidade.

Classificações de severidade

As pontuações do CVSS são mapeadas para classificações de severidade:

Severity Pontuação CVSS Descrição Prioridade
Crítico 9.0 - 10.0 Vulnerabilidades facilmente exploráveis que causam comprometimento generalizado do sistema. Medidas corretivas imediatas necessárias.
High 7.0 - 8.9 Vulnerabilidades graves que permitem a divulgação significativa de informações ou a interrupção do serviço. Remediação necessária dentro de alguns dias.
Medium 4.0 - 6.9 Vulnerabilidades moderadas com explorabilidade ou impacto limitado. Remediação necessária dentro de semanas.
Low 0.1 - 3.9 Vulnerabilidades secundárias com impacto mínimo na segurança. Correção quando conveniente.
Nenhum 0,0 Descobertas informativas sem impacto real na segurança. Correção opcional.

Exemplos de interpretação de severidade:

Vulnerabilidade crítica (CVSS 10.0):

CVE-2021-44228 (Log4Shell)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Description: Remote code execution in Apache Log4j 2
Impact: Unauthenticated attacker can execute arbitrary code remotely
Exploitability: Actively exploited in the wild with publicly available exploits

Alta vulnerabilidade (CVSS 8.1):

CVE-2022-23648
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Description: Path traversal in container runtime
Impact: Authenticated users can access files outside container boundaries
Exploitability: Requires authentication but easily exploitable

Vulnerabilidade média (CVSS 5.9):

CVE-2023-12345
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Description: Information disclosure through timing attack
Impact: Sensitive information disclosure possible with sophisticated attack
Exploitability: Requires specific timing conditions, difficult to exploit

Avaliando a capacidade de exploração

As pontuações do CVSS não contam a história completa – a avaliação de explorabilidade determina o risco real:

Aproveitar a maturidade

Estágios de disponibilidade de exploração:

Não comprovado:

  • Estado: Vulnerabilidade teórica sem exploração conhecida.
  • Nível de risco: Menor risco: a exploração requer um esforço significativo do invasor.
  • Ação: Monitorar o desenvolvimento de exploits; planejar a correção sem urgência.

Prova de conceito:

  • Status: código de exploração de prova de conceito publicado, mas não armado.
  • Nível de risco: Risco moderado: invasores sofisticados podem explorar a vulnerabilidade.
  • Ação: Priorizar a correção; desenvolver estratégias de mitigação.

Funcional:

  • Estado: Código de exploit funcional disponível publicamente.
  • Nível de risco: Alto risco : exploração acessível a invasores moderadamente qualificados.
  • Ação: Agilizar a correção; implemente mitigações temporárias se a aplicação de patch for atrasada.

Exploração ativa:

  • Estado: Vulnerabilidade explorada ativamente na natureza.
  • Nível de risco: Risco crítico: a exploração está acontecendo agora.
  • Ação: Remediação de emergência; implementar mitigações imediatas; monitore sinais de comprometimento.

Exemplo de avaliação de explorabilidade:

CVE-2021-44228 (Log4Shell)
Severity: Critical (CVSS 10.0)
Exploit Maturity: Active exploitation

Analysis:
- Public exploit code available within hours of disclosure
- Automated scanning and exploitation observed globally
- Multiple malware families incorporating the exploit
- Trivial to exploit with single HTTP request

Priority: EMERGENCY - Immediate patching required

Análise da superfície de ataque

Determine se a vulnerabilidade é acessível:

Fatores de acessibilidade:

  • Uso de código: O caminho de código vulnerável é realmente executado pelo seu aplicativo?
  • Exposição à rede: O componente vulnerável está exposto ao acesso à rede?
  • Requisitos de autenticação: A exploração requer acesso autenticado?
  • Dependências de configuração: A vulnerabilidade requer configurações específicas para ser explorável?

Exemplo de acessibilidade:

Vulnerability: SQL injection in unused admin feature
Severity: High (CVSS 8.5)
Reachability: NOT REACHABLE

Analysis:
- Vulnerable code exists in imported library
- Admin features are disabled in production configuration
- Vulnerable code paths never executed
- Network access to admin interface blocked by firewall

Priority: LOW - Update during regular maintenance window

Contexto ambiental

Considere seu ambiente específico:

Segmentação de rede:

  • Voltado para a Internet: As vulnerabilidades em componentes voltados para a Internet têm prioridade mais alta.
  • Rede interna: As vulnerabilidades somente internas terão prioridade mais baixa se a rede for segmentada.
  • Sistemas isolados: sistemas isolados ou desconectados têm um risco mínimo de vulnerabilidades de rede.

Confidencialidade de dados:

  • Dados confidenciais: Vulnerabilidades em sistemas que lidam com dados confidenciais exigem correção urgente.
  • Informações públicas: As vulnerabilidades de divulgação de informações serão de menor prioridade se os dados já forem públicos.
  • Ambientes de teste: Vulnerabilidades em ambientes de não produção normalmente são de menor prioridade.

Controles compensatórios:

  • Firewall do aplicativo Web: As regras do WAF podem atenuar as tentativas de exploração.
  • Detecção de intrusão: O IDS/IPS pode detectar e bloquear tentativas de exploração.
  • Segmentação de rede: O isolamento de rede limita o impacto da exploração.
  • Privilégio mínimo: Permissões restritas reduzem o impacto da exploração.

Gerenciando falsos positivos

Nem todas as vulnerabilidades relatadas realmente afetam seus aplicativos:

Causas comuns de falsos positivos

Componentes com identificação incorreta:

  • Conflitos de nomenclatura: Componentes diferentes com nomes semelhantes correspondentes incorretamente.
  • Erros de detecção de versão: Identificação de versão incorreta que leva a falsas correspondências de vulnerabilidade.
  • Confusão de namespace do pacote: Pacotes em diferentes ecossistemas identificados incorretamente como o mesmo pacote.

Exemplo de falso positivo:

Alert: CVE-2022-12345 in "parser" package (npm)
Severity: High

Investigation:
- Application uses "xml-parser" package
- Scanner incorrectly identified "xml-parser" as vulnerable "parser" package
- Different packages with similar names
- Vulnerability does not affect application

Resolution: Suppress false positive with documented justification

Caminhos de código não utilizados:

  • Código morto: Código vulnerável importado, mas nunca executado.
  • Recursos opcionais: Vulnerabilidades em recursos opcionais que seu aplicativo não habilita.
  • Dependências de desenvolvimento: Vulnerabilidades em pacotes usados somente durante o desenvolvimento, não em produção.

Erros no intervalo de versões:

  • Relatório de correções de versão: Os scanners relatam vulnerabilidade em versões já corrigidas.
  • Patches de backport: os fornecedores fazem backport de correções de segurança para versões mais antigas sem alterar os números de versão.
  • Patches personalizados: Vulnerabilidades já corrigidas por meio de modificações personalizadas.

Verificação de falso positivo

Processo de investigação:

  1. Verificar a identidade do componente: Confirme se o verificador identificou corretamente o componente.
  2. Verifique a precisão da versão: Verifique se a versão detectada corresponde à versão real implantada.
  3. Examine os detalhes da vulnerabilidade: Entenda o que a vulnerabilidade afeta.
  4. Analisar o uso de código: Determine se caminhos de código vulneráveis são realmente usados.
  5. Consultar os avisos do fornecedor: Verifique se o fornecedor fornece contexto adicional.
  6. Exploração de teste: Tente reproduzir a vulnerabilidade no ambiente de teste.

Requisitos de documentação: Ao suprimir falsos positivos, documente:

  • Justificação: Por que a descoberta é um falso positivo.
  • Detalhes da investigação: Etapas tomadas para verificar falso positivo.
  • Aprovador: Membro da equipe de segurança aprovando a supressão.
  • Data de revisão: Data para reavaliar a supressão.

Exemplo de arquivo de supressão (OWASP Dependency-Check):

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
    <suppress>
        <notes>
            False positive: CVE-2022-12345 affects "parser" package but we use "xml-parser".
            Scanner incorrectly matched based on partial name match.
            Investigated by security team on 2025-10-21.
            Review annually.
        </notes>
        <packageUrl regex="true">^pkg:npm/xml-parser@.*$</packageUrl>
        <cve>CVE-2022-12345</cve>
    </suppress>
</suppressions>

Estruturas de priorização

O gerenciamento efetivo de vulnerabilidades requer priorização sistemática:

Priorização baseada em risco

Fatores de priorização:

Pontuação de gravidade (peso de 25%):

  • A pontuação base do CVSS fornece base para a avaliação de risco.
  • Pontuações mais altas indicam um impacto potencial mais severo.

Explorabilidade (35% de peso):

  • O status de exploração ativa é o fator mais crítico.
  • A disponibilidade de exploração pública aumenta significativamente o risco.
  • Exploits de prova de conceito indicam que a exploração é viável.

Criticidade do ativo (20% peso):

  • Aplicativos voltados para a Internet têm prioridade mais alta.
  • Sistemas que processam dados confidenciais exigem aplicação de patch urgente.
  • Aplicativos comercialmente críticos não podem tolerar tempo de inatividade estendido.

Fatores ambientais (20% peso):

  • Os controles compensatórios existentes reduzem o risco efetivo.
  • A segmentação de rede limita o raio de explosão.
  • Os recursos de monitoramento permitem a detecção de ameaças.

Matriz de priorização:

Explorabilidade Severidade crítica Alta gravidade Severidade Média Baixa gravidade
Exploração ativa P0 (Emergência) P0 (Emergência) P1 (crítico) P2 (Alto)
Exploração funcional P0 (Emergência) P1 (crítico) P2 (Alto) P3 (Médio)
Prova de conceito P1 (crítico) P2 (Alto) P3 (Médio) P4 (Baixo)
Não comprovado P2 (Alto) P3 (Médio) P4 (Baixo) P5 (opcional)

SLAs de remediação

Definir acordos de nível de serviço para remediação:

Emergência (P0):

  • Período de tempo: Imediato (dentro de 24 horas).
  • Critérios: Vulnerabilidades críticas sob exploração ativa em sistemas voltados para a Internet.
  • Processo: Processo de alteração de emergência com notificação executiva.
  • Exemplo: Log4Shell (CVE-2021-44228) no aplicativo voltado para o público.

Crítico (P1):

  • Período: 7 dias.
  • Critérios: Gravidade alta/crítica com explorações funcionais ou exposição voltada para a Internet.
  • Processo: Processo de alteração acelerada com a coordenação da equipe de segurança.
  • Exemplo: Injeção de SQL na interface de administrador autenticada.

Alto (P2):

  • Período: 30 dias.
  • Critérios: Gravidade média/alta com exploits de prova de conceito ou exposição interna.
  • Processo: Processo de alteração padrão com a janela de manutenção planejada.
  • Exemplo: XSS (script entre sites) no painel interno.

Médio (P3):

  • Período: 90 dias.
  • Critérios: Gravidade baixa/média sem explorações conhecidas.
  • Processo: Ciclo de atualização regular com aplicação de patch trimestral.
  • Exemplo: Divulgação de informações na dependência da ferramenta de desenvolvimento.

Baixo (P4):

  • Período de tempo: Próxima versão principal.
  • Critérios: Baixa gravidade ou falsos positivos que exigem documentação.
  • Processo: Inclua em atividades regulares de manutenção.
  • Exemplo: Negação de serviço no recurso opcional não utilizado.

Estabelecimento de barreiras de bugs de segurança

As barras de bugs de segurança definem padrões mínimos de segurança que devem ser atendidos:

Critérios de Definição de Concluído

Exemplo de barra de bugs de segurança:

Security Bug Bar:
  Blocking Issues (Must Fix Before Release):
    - No critical severity vulnerabilities
    - No high severity vulnerabilities with public exploits
    - No vulnerabilities actively exploited in the wild
    - No strong copyleft licenses (GPL, AGPL) in proprietary code
    - No secrets in source code or container images

  Non-Blocking Issues (Track and Plan):
    - High severity without public exploits (90-day remediation plan)
    - Medium severity vulnerabilities (next minor release)
    - License issues requiring legal review (document plan)

  Informational (Monitor):
    - Low severity vulnerabilities
    - Informational security findings
    - Code quality issues

Imposição de política

Portão de qualidade do Azure Pipelines:

- task: WhiteSource@21
  inputs:
    cwd: "$(System.DefaultWorkingDirectory)"
    projectName: "$(Build.Repository.Name)"
    checkPolicies: true
    failBuildOnPolicyViolation: true
  displayName: "Enforce security bug bar"

- script: |
    # Custom policy check script
    if [ $(jq '.vulnerabilities.critical' scan-results.json) -gt 0 ]; then
      echo "##vso[task.logissue type=error]Critical vulnerabilities detected"
      echo "##vso[task.complete result=Failed;]Failed security bug bar"
      exit 1
    fi
  displayName: "Validate security bug bar compliance"

Fluxo de trabalho de triagem de vulnerabilidade

A triagem sistemática garante um gerenciamento eficiente de vulnerabilidades:

Processo de triagem

Etapa 1: filtragem automatizada:

  • Ferramentas de scanner: Filtrar vulnerabilidades automaticamente por severidade.
  • Análise de acessibilidade: Remova vulnerabilidades inacessíveis da fila de triagem.
  • Falsos positivos conhecidos: Suprime automaticamente falsos positivos identificados anteriormente.

Etapa 2: Avaliação inicial:

  • Revisão de severidade: Verifique a precisão da pontuação do CVSS para seu ambiente.
  • Verificação de exploração: Determine a disponibilidade de exploração e a exploração ativa.
  • Identificação de ativos: Identifique quais aplicativos e sistemas são afetados.

Etapa 3: Avaliação de risco:

  • Impacto nos negócios: Avaliar o potencial impacto nos negócios da exploração bem-sucedida.
  • Análise de exposição: Determine a exposição à rede e a superfície de ataque.
  • Compensando controles: Identificar mitigações existentes que reduzem o risco.

Etapa 4: Priorização:

  • Atribuir prioridade: Use a matriz de priorização para atribuir prioridade de correção.
  • Defina a data de conclusão: Atribuir prazo de correção com base no SLA.
  • Atribuir proprietário: Designe a equipe responsável para correção.

Etapa 5: Acompanhamento de correção:

  • Criar tíquetes: Gerar itens de trabalho no sistema de acompanhamento (Jira, Azure Boards).
  • Monitoramento de progresso: Acompanhe o progresso da correção em relação aos prazos.
  • Verificação: Valide a correção bem-sucedida por meio de uma nova varredura.

Cadência da reunião de triagem

Triagem de segurança semanal:

  • Participantes: Equipe de segurança, líderes de desenvolvimento, representantes de operações.
  • Agenda: Examine novas descobertas críticas/altas, acompanhe o progresso da correção, ajuste as prioridades.
  • Duração: 30 a 60 minutos.

Revisão mensal de vulnerabilidades:

  • Participantes: Liderança de segurança, gerenciamento de engenharia, equipe de conformidade.
  • Agenda: Examine as tendências, ajuste as políticas, avalie a postura geral de segurança.
  • Duração: 60 a 90 minutos.

Métricas e relatórios

Controlar a eficácia do gerenciamento de vulnerabilidades:

Principais métricas

Métricas de vulnerabilidade:

  • Tempo médio para detectar (MTTD): Tempo desde a divulgação de vulnerabilidades até a detecção em seus sistemas.
  • Tempo médio para correção (MTTR): Tempo da detecção à correção bem-sucedida.
  • Densidade de vulnerabilidade: Número de vulnerabilidades por aplicativo ou linha de código.
  • Taxa de correção: Percentual de vulnerabilidades corrigidas no SLA.

Métricas de tendência:

  • Contagem de vulnerabilidades abertas: contagem de tendências de vulnerabilidades não resolvidas por gravidade.
  • Novo vs. resolvido: Comparação de vulnerabilidades recém-detectadas e corrigidas.
  • Conformidade com o SLA: Percentual de vulnerabilidades corrigidas em SLAs definidas.
  • Taxa de falsos positivos: Percentual de achados determinados como falsos positivos.

Exemplo de painel

Painel de gerenciamento de vulnerabilidades:

Critical Vulnerabilities: 0 (Target: 0)
High Vulnerabilities: 3 (Target: < 10)
Medium Vulnerabilities: 47 (Target: < 100)
Low Vulnerabilities: 132 (Tracking only)

Mean Time to Remediate:
- Critical: 18 hours ✓
- High: 6 days ✓
- Medium: 21 days ✓

Remediation Progress:
- P0 (Emergency): 0 overdue
- P1 (Critical): 1 due in 3 days
- P2 (High): 5 due in next 30 days
- P3 (Medium): 12 due in next 90 days

Trends (Last 90 Days):
- New vulnerabilities: 127
- Remediated: 138
- Net reduction: -11 ✓

Observação

Para obter mais informações sobre SLAs (contratos de nível de serviço) e linhas do tempo de correção, consulte Contratos de Nível de Serviço do Azure.

A interpretação e a priorização eficaz de alertas de vulnerabilidade transformam a produção excessiva do scanner em melhorias de segurança prática. Ao entender as pontuações de gravidade, avaliar a explorabilidade, gerenciar falsos positivos e implementar a priorização sistemática, as equipes concentram os esforços de correção em vulnerabilidades que representam risco real em vez de perseguir todos os alertas. Essa abordagem baseada em risco permite programas de segurança sustentável que protegem aplicativos sem sobrecarregar as equipes de desenvolvimento com ruído.