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 problemas de qualidade de código em dependências. A interpretação eficaz desses alertas requer a compreensão das pontuações de gravidade, a avaliação da capacidade de exploração, o gerenciamento de falsos positivos e a priorização dos esforços de correção com base no risco real para seus aplicativos. Sem interpretação e priorização adequadas, as equipes enfrentam fadiga de alerta e perdem tempo com problemas de baixo impacto enquanto perdem vulnerabilidades críticas.

Compreender a gravidade da vulnerabilidade

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

Sistema de pontuação CVSS

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

Categorias de métricas CVSS:

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

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

Métricas de exploração:

  • Vetor de ataque (AV): Rede (N), Adjacente (A), Local (L) ou Física (P).
  • Complexidade do ataque (CA): Dificuldade baixa (L) ou alta (H) na exploração da vulnerabilidade.
  • Privilégios necessários (PR): Nenhum (N), Baixo (L) ou Alto (H) privilégios necessários para explorar.
  • Interação do usuário (UI): Nenhum (N) ou Necessário (R) para uma exploração bem-sucedida.

Métricas de impacto:

  • Impacto na confidencialidade (C): Nenhuma (N), Baixa (L) ou Alta (H) divulgação de informações.
  • Impacto na integridade (I): Nenhuma (N), Baixa (L) ou Alta (H) capacidade de modificação de dados.
  • 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 pela rede com baixa complexidade de ataque, sem necessidade de privilégios, sem interação do usuário e alto impacto na confidencialidade, integridade e disponibilidade.

Classificações de gravidade

As classificações de gravidade correspondem às pontuações do CVSS:

Severity Pontuação CVSS Descrição Prioridade
Critical 9.0 - 10.0 Vulnerabilidades facilmente exploráveis que causam comprometimento generalizado do sistema. Remediação imediata necessária.
High 7.0 - 8.9 Vulnerabilidades graves que permitam a divulgação significativa de informações ou a interrupção do serviço. Remediação necessária dentro de dias.
Medium 4.0 - 6.9 Vulnerabilidades moderadas com exploração ou impacto limitado. Remediação necessária dentro de semanas.
Low 0.1 - 3.9 Vulnerabilidades menores com impacto mínimo na segurança. Remediação quando conveniente.
Nenhum 0.0 Descobertas informativas sem impacto real na segurança. Remediação opcional.

Exemplos de interpretação da gravidade:

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

Avaliação da capacidade de exploração

As pontuações do CVSS não contam a história completa — a avaliação da capacidade de exploração determina o risco real:

Maturidade de exploit

Estágios de disponibilidade da 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: Monitorizar o desenvolvimento de exploits; planear a remediação, mas não é urgente.

Prova de conceito:

  • Estado: Código de exploração de prova de conceito publicado, mas não utilizado em ataques.
  • Nível de risco: Risco moderado – atacantes sofisticados podem explorar a vulnerabilidade.
  • Ação: Priorizar a remediação; desenvolver estratégias de mitigação.

Funcional:

  • Estado: Código de exploração funcional disponível ao público.
  • Nível de risco: Alto risco — exploração acessível a atacantes moderadamente qualificados.
  • Ação: Agilizar a remediação; implementar atenuações temporárias se a aplicação de patches for atrasada.

Exploração ativa:

  • Estado: Vulnerabilidade ativamente explorada na natureza.
  • Nível de risco: Risco crítico — exploração acontecendo agora.
  • Ação: Remediação de emergência; implementarem mitigações imediatas; monitorizar possíveis comprometimentos.

Exemplo de avaliação da capacidade de exploração:

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 está acessível:

Fatores de acessibilidade:

  • Uso do 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 o seu ambiente específico:

Segmentação da rede:

  • Voltado para a Internet: As vulnerabilidades nos componentes voltados para a Internet têm prioridade máxima.
  • Rede interna: As vulnerabilidades apenas internas têm prioridade menor se a rede for segmentada.
  • Sistemas isolados: Os sistemas isolados ou com ar comprimido têm um risco mínimo de vulnerabilidades na rede.

Sensibilidade dos dados:

  • Dados sensíveis: As vulnerabilidades nos sistemas que tratam dados sensíveis exigem uma correção urgente.
  • Informação ao público: As vulnerabilidades de divulgação de informações são de menor prioridade se os dados já forem públicos.
  • Ambientes de teste: As vulnerabilidades em ambientes que não são de produção são normalmente de menor prioridade.

Controlos compensatórios:

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

Gerir falsos positivos

Nem todas as vulnerabilidades relatadas realmente afetam seus aplicativos:

Causas comuns de falsos positivos

Componentes mal identificados:

  • Conflitos de nomenclatura: Componentes diferentes com nomes semelhantes associados de forma incorreta.
  • Erros de deteção de versão: Identificação incorreta da versão que leva a falsas correspondências de vulnerabilidade.
  • Confusão de namespace de 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.
  • Características opcionais: Vulnerabilidades em recursos opcionais que seu aplicativo não habilita.
  • Dependências de desenvolvimento: Vulnerabilidades em pacotes usados apenas durante o desenvolvimento, não na produção.

Erros de intervalo de versão:

  • Relatórios de versão corrigida: Os scanners relatam a vulnerabilidade em versões já corrigidas.
  • Patches retroativos: Os fornecedores aplicam correções de segurança a versões mais antigas sem modificar os números das versões.
  • Patches personalizados: Vulnerabilidades já corrigidas através de modificações personalizadas.

Confirmação de falsos positivos

Processo de investigação:

  1. Verifique a identidade do componente: Confirme se o scanner identificou corretamente o componente.
  2. Verifique a precisão da versão: Verifique se a versão detetada corresponde à versão real implantada.
  3. Analise os detalhes da vulnerabilidade: Entenda o que a vulnerabilidade afeta.
  4. Analise o uso do código: Determine se os caminhos de código vulneráveis são realmente usados.
  5. Consulte 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: Medidas tomadas para verificar falsos positivos.
  • 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

A gestão eficaz da vulnerabilidade requer uma priorização sistemática:

Priorização baseada no risco

Fatores de priorização:

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

  • A pontuação base do CVSS fornece a 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 da exploração pública aumenta significativamente o risco.
  • Indicações de exploração viável são demonstradas através de explorações de prova de conceito.

Criticidade dos ativos (peso de 20%):

  • As aplicações viradas para a Internet têm maior prioridade.
  • Os sistemas que processam dados confidenciais requerem correções urgentes.
  • Os aplicativos críticos para os negócios não podem tolerar tempo de inatividade prolongado.

Fatores ambientais (peso de 20%):

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

Matriz de priorização:

Explorabilidade Severidade crítica Alta gravidade Gravidade 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

Defina contratos de nível de serviço para remediação:

Emergência (P0):

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

Crítica (P1):

  • Prazo: 7 dias.
  • Critérios: Gravidade alta/crítica com exploits funcionais ou exposição à Internet.
  • Processo: Processo de mudança acelerado com coordenação da equipe de segurança.
  • Exemplo: Injeção de SQL na interface de administração autenticada.

Alta (P2):

  • Prazo: 30 dias.
  • Critérios: Severidade média/alta com explorações de prova de conceito ou exposição interna.
  • Processo: Processo de mudança padrão com janela de manutenção planejada.
  • Exemplo: Scripts entre sites (XSS) no painel interno.

Médio (P3):

  • Prazo: 90 dias.
  • Critérios: Severidade baixa/média sem exploits conhecidos.
  • Processo: Ciclo de atualização regular com aplicação de patches trimestrais.
  • Exemplo: Divulgação de informação na dependência de ferramentas de desenvolvimento.

Baixo (P4):

  • Prazo: Próximo grande lançamento.
  • Critérios: Baixa gravidade ou falsos positivos que requerem documentação.
  • Processo: Incluir em atividades regulares de manutenção.
  • Exemplo: Negação de serviço em recurso opcional não utilizado.

Estabelecendo barras de bugs de segurança

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

Definição dos critérios de Conclusão

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íticas

Porta 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 vulnerabilidades

A triagem sistemática garante uma gestão eficiente das vulnerabilidades:

Processo de triagem

Passo 1: Filtragem automatizada:

  • Ferramentas de scanner: Filtre automaticamente as vulnerabilidades por gravidade.
  • Análise de acessibilidade: Remova vulnerabilidades inacessíveis da fila de triagem.
  • Falsos positivos conhecidos: Suprima automaticamente os falsos positivos previamente identificados.

Passo 2: Avaliação inicial:

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

Passo 3: Avaliação dos riscos:

  • Impacto nos negócios: Avalie o potencial impacto comercial de uma exploração bem-sucedida.
  • Análise da exposição: Determine a exposição da rede e a superfície de ataque.
  • Controlos compensatórios: Identificar mitigações existentes que reduzam o risco.

Passo 4: Priorização:

  • Atribuir prioridade: Use a matriz de priorização para atribuir prioridade de correção.
  • Definir data de vencimento: Atribua o prazo de correção com base no SLA.
  • Atribuir proprietário: Designar equipe responsável pela remediação.

Etapa 5: Rastreamento de correção:

  • Crie bilhetes: Gere itens de trabalho no sistema de rastreamento (Jira, Azure Boards).
  • Acompanhamento dos progressos: Acompanhe o progresso da correção em relação aos prazos.
  • Verificação: Valide a correção bem-sucedida por meio da 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.
  • Ordem do dia: Analise novas descobertas altas/críticas, acompanhe o progresso da remediação, ajuste as prioridades.
  • Duração: 30-60 minutos.

Revisão mensal de vulnerabilidades:

  • Participantes: Liderança em segurança, gestão de engenharia, equipe de compliance.
  • Ordem do dia: Analise tendências, ajuste políticas, avalie a postura geral de segurança.
  • Duração: 60-90 minutos.

Métricas e relatórios

Acompanhe a eficácia do gerenciamento de vulnerabilidades:

Principais métricas

Métricas de vulnerabilidade:

  • Tempo médio de deteção (MTTD): Tempo desde a divulgação da vulnerabilidade até à deteção nos seus sistemas.
  • Tempo médio de correção (MTTR): Tempo desde a deteção até a remediação bem-sucedida.
  • Densidade de vulnerabilidade: Número de vulnerabilidades por aplicativo ou linha de código.
  • Taxa de remediação: Porcentagem de vulnerabilidades corrigidas dentro do SLA.

Métricas de tendência:

  • Contagem de vulnerabilidades abertas: Contagem tendencial de vulnerabilidades não resolvidas por gravidade.
  • Novo vs. resolvido: Comparação de vulnerabilidades recentemente detetadas e corrigidas.
  • Conformidade com SLA: Porcentagem de vulnerabilidades corrigidas dentro de SLAs definidos.
  • Taxa de falsos positivos: Percentagem de resultados considerados 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 contratos de nível de serviço (SLAs) e cronogramas 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 o resultado avassalador do scanner em melhorias de segurança concretas. Ao compreender as pontuações de gravidade, avaliar a capacidade de exploração, gerenciar falsos positivos e implementar 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áveis que protegem os aplicativos sem sobrecarregar as equipes de desenvolvimento com ruído.