Interpretación de las alertas de las herramientas de examen

  • 11 minutos

Las herramientas de análisis de composición de software generan numerosas alertas sobre vulnerabilidades, problemas de licencia y problemas de calidad del código en las dependencias. La interpretación eficaz de estas alertas requiere comprender las puntuaciones de gravedad, evaluar la vulnerabilidad de seguridad, administrar falsos positivos y priorizar los esfuerzos de corrección en función del riesgo real para las aplicaciones. Sin una interpretación adecuada y priorización, los equipos se enfrentan a la fatiga de alertas y pierden tiempo en problemas de bajo impacto mientras faltan vulnerabilidades críticas.

Descripción de la gravedad de la vulnerabilidad

Las puntuaciones de gravedad de vulnerabilidad proporcionan evaluaciones de riesgos estandarizadas:

Sistema de puntuación de CVSS

Common Vulnerability Scoring System (CVSS) proporciona puntuaciones numéricas estandarizadas que indican la gravedad de la vulnerabilidad.

Categorías de métricas de CVSS:

  • Métricas base: Características intrínsecas de vulnerabilidades independientes de entornos específicos.
  • Métricas temporales: Características de vulnerabilidad que cambian con el tiempo (disponibilidad de vulnerabilidades, disponibilidad de revisión, confianza).
  • Métricas del entorno: Características de vulnerabilidad específicas de entornos e implementaciones concretos.

Cálculo de puntuación base de CVSS v3: Las puntuaciones base combinan varias métricas:

Métricas de vulnerabilidad:

  • Vector de ataque (AV): Red (N), Adyacente (A), Local (L) o Físico (P).
  • Complejidad del ataque (AC): Dificultad baja (L) o alta (H) para aprovechar la vulnerabilidad.
  • Privilegios necesarios (PR): Ninguno (N), Privilegios Bajos (L) o Alto (H) necesarios para aprovechar.
  • Interacción del usuario (UI): Ninguno (N) o Obligatorio (R) para una explotación correcta.

Métricas de impacto:

  • Impacto en la confidencialidad (C): Ninguna (N), Baja (L) o Alta (H) divulgación de información.
  • Impacto en la integridad (I): Ninguna (N), Baja (L) o Alta (H) capacidad de modificación de datos.
  • Impacto en la disponibilidad (A): Ninguna (N), Baja (L) o Interrupción del servicio High (H).

Ejemplo de vector CVSS:

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

Esto representa una vulnerabilidad que se puede aprovechar en la red con una complejidad de ataque baja, sin privilegios necesarios, ninguna interacción del usuario y un alto impacto en la confidencialidad, integridad y disponibilidad.

Clasificaciones de gravedad

Las puntuaciones de CVSS corresponden a las clasificaciones de gravedad:

Severity Puntuación de CVSS Descripción Prioridad
Crítico 9.0 - 10.0 Vulnerabilidades fácilmente aprovechables que provocan un riesgo generalizado del sistema. Se requiere corrección inmediata.
High 7.0 - 8.9 Vulnerabilidades graves que permiten una divulgación de información significativa o una interrupción del servicio. Corrección necesaria en un plazo de días.
Medium 4.0 - 6.9 Vulnerabilidades moderadas con explotabilidad limitada o impacto limitado. Se requiere corrección en unas semanas.
Low 0.1 - 3.9 Vulnerabilidades menores con un impacto mínimo en la seguridad. Corrección cuando sea conveniente.
Ninguno 0,0 Conclusiones informativas sin impacto real en la seguridad. Corrección opcional.

Ejemplos de interpretación de gravedad:

Vulnerabilidad 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 vulnerabilidad (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

Vulnerabilidad media (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

Evaluación de la explotabilidad

Las puntuaciones de CVSS no cuentan la historia completa: la evaluación de vulnerabilidades determina el riesgo real:

Madurez de exploits

Fases de disponibilidad de exploits:

No comprobado:

  • Estado: Vulnerabilidad teórica sin vulnerabilidad conocida.
  • Nivel de riesgo: Menor riesgo: la explotación requiere un esfuerzo significativo del atacante.
  • Acción: Supervisión del desarrollo de vulnerabilidades de seguridad; planear la corrección, pero no urgente.

Prueba de concepto:

  • Estado: código de vulnerabilidad de prueba de concepto publicado, pero no armado.
  • Nivel de riesgo: Riesgo moderado: los atacantes sofisticados podrían armar la vulnerabilidad.
  • Acción: Priorizar la corrección; desarrollar estrategias de mitigación.

Funcional:

  • Estado: Código de exploit en funcionamiento disponible públicamente.
  • Nivel de riesgo: Alto riesgo: explotación accesible para atacantes moderados cualificados.
  • Acción: Acelerar la corrección; implemente mitigaciones temporales si se retrasa el parcheo.

Explotación activa:

  • Estado: Vulnerabilidad explotada activamente en la naturaleza.
  • Nivel de riesgo: Riesgo crítico: la explotación está ocurriendo ahora.
  • Acción: corrección de emergencia; implemente mitigaciones inmediatas; supervise si hay peligro.

Evaluación de vulnerabilidades de seguridad de ejemplo:

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álisis de la superficie expuesta a ataques

Determine si se puede acceder a una vulnerabilidad:

Factores de accesibilidad:

  • Uso del código: ¿La ruta de código vulnerable se ejecuta realmente en tu aplicación?
  • Exposición de red: ¿Se expone el componente vulnerable al acceso a la red?
  • Requisitos de autenticación: ¿La explotación requiere acceso autenticado?
  • Dependencias de configuración: ¿La vulnerabilidad requiere configuraciones específicas que se puedan aprovechar?

Ejemplo de accesibilidad:

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 del entorno

Tenga en cuenta su entorno específico:

Segmentación de red:

  • Accesible desde Internet: Las vulnerabilidades de los componentes accesibles desde Internet tienen prioridad más alta.
  • Red interna: Las vulnerabilidades solo internas tienen menor prioridad si la red está segmentada.
  • Sistemas aislados: Los sistemas aislados o desconectados tienen un riesgo mínimo de vulnerabilidades de red.

Confidencialidad de los datos:

  • Información confidencial: Las vulnerabilidades de los sistemas que controlan datos confidenciales requieren una corrección urgente.
  • Información pública: Las vulnerabilidades de divulgación de información son menos prioritarias si los datos ya son públicos.
  • Entornos de prueba: Las vulnerabilidades en entornos no productivos suelen ser de menor prioridad.

Controles de compensación:

  • Firewall de aplicaciones web: Las reglas de WAF pueden mitigar los intentos de explotación.
  • Detección de intrusiones: IDS/IPS puede detectar y bloquear intentos de explotación.
  • Segmentación de red: El aislamiento de red limita el impacto en la explotación.
  • Privilegios mínimos: Los permisos restringidos reducen el impacto en la explotación.

Gestión de falsos positivos

No todas las vulnerabilidades notificadas afectan realmente a las aplicaciones:

Causas comunes de falsos positivos

Componentes no identificados:

  • Conflictos de nomenclatura: Distintos componentes con nombres similares coinciden incorrectamente.
  • Errores de detección de versiones: Identificación de versión incorrecta que conduce a coincidencias de vulnerabilidades falsas.
  • Confusión del espacio de nombres del paquete: Los paquetes de diferentes ecosistemas se identifican incorrectamente como el mismo paquete.

Ejemplo 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

Rutas de acceso de código sin usar:

  • Código fallido: Código vulnerable importado pero nunca ejecutado.
  • Características opcionales: Las vulnerabilidades de las características opcionales que la aplicación no habilita.
  • Dependencias de desarrollo: Vulnerabilidades en paquetes usados solo durante el desarrollo, no en producción.

Errores de intervalo de versiones:

  • Informes de versiones corregidos: Los escáneres notifican vulnerabilidades en versiones ya revisadas.
  • Revisiones de backport: los proveedores devuelven correcciones de seguridad a versiones anteriores sin cambiar los números de versión.
  • Revisiones personalizadas: Vulnerabilidades ya revisadas a través de modificaciones personalizadas.

Comprobación de falsos positivos

Proceso de investigación:

  1. Compruebe la identidad del componente: Confirme que el analizador identificó correctamente el componente.
  2. Comprobar la precisión de la versión: Compruebe que la versión detectada coincide con la versión implementada real.
  3. Revise los detalles de vulnerabilidad: Comprenda lo que afecta la vulnerabilidad.
  4. Analizar el uso del código: Determine si se usan realmente rutas de acceso de código vulnerables.
  5. Consulte avisos de proveedores: Compruebe si el proveedor proporciona contexto adicional.
  6. Explotación de pruebas: Intente reproducir la vulnerabilidad en el entorno de prueba.

Requisitos de documentación: Al suprimir falsos positivos, documente:

  • Justificación: Por qué el hallazgo es un falso positivo.
  • Detalles de la investigación: Pasos realizados para comprobar el falso positivo.
  • Aprobador: Miembro del equipo de seguridad que aprueba la supresión.
  • Fecha de revisión: Fecha para volver a evaluar la supresión.

Archivo de supresión de ejemplo (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>

Marcos de priorización

La administración eficaz de vulnerabilidades requiere la priorización sistemática:

Priorización basada en riesgos

Factores de priorización:

Puntuación de gravedad (25 % de peso):

  • La puntuación base de CVSS proporciona la base para la evaluación de riesgos.
  • Las puntuaciones más altas indican un impacto potencial más grave.

Explotabilidad (peso de 35%):

  • El estado de explotación activa es el factor más crítico.
  • La disponibilidad de exploits públicos aumenta significativamente el riesgo.
  • Las vulnerabilidades de seguridad de prueba de concepto indican una explotación factible.

Importancia de los recursos (20% peso):

  • Las aplicaciones accesibles desde Internet tienen mayor prioridad.
  • Los sistemas que procesan datos confidenciales requieren revisiones urgentes.
  • Las aplicaciones críticas para la empresa no pueden tolerar un tiempo de inactividad prolongado.

Factores ambientales (20% peso):

  • Los controles de compensación existentes reducen el riesgo efectivo.
  • La segmentación de red limita el radio de explosión.
  • Las funcionalidades de supervisión habilitan la detección de amenazas.

Matriz de priorización:

Explotabilidad Gravedad crítica Gravedad alta Gravedad media Gravedad baja
Explotación activa P0 (emergencia) P0 (emergencia) P1 (crítico) P2 (alto)
Vulnerabilidad de seguridad funcional P0 (emergencia) P1 (crítico) P2 (alto) P3 (medio)
Prueba de concepto P1 (crítico) P2 (alto) P3 (medio) P4 (bajo)
No comprobado P2 (alto) P3 (medio) P4 (bajo) P5 (opcional)

SLA de corrección

Definir acuerdos de nivel de servicio para la remediación:

Emergencia (P0):

  • Período de tiempo: Inmediato (en un plazo de 24 horas).
  • Criterios: Vulnerabilidades críticas bajo explotación activa en sistemas accesibles desde Internet.
  • Proceso: Proceso de cambio de emergencia con notificación ejecutiva.
  • Ejemplo: Log4Shell (CVE-2021-44228) en la aplicación pública.

Crítico (P1):

  • Período de tiempo: 7 días.
  • Criterios: Gravedad alta o crítica con vulnerabilidades funcionales o exposición accesible desde Internet.
  • Proceso: Proceso de cambio acelerado con coordinación del equipo de seguridad.
  • Ejemplo: Inyección de CÓDIGO SQL en la interfaz de administración autenticada.

Alto (P2):

  • Período de tiempo: 30 días.
  • Criterios: Gravedad media/alta con vulnerabilidades de seguridad de prueba de concepto o exposición interna.
  • Proceso: Proceso de cambio estándar con la ventana de mantenimiento planeado.
  • Ejemplo: Cross-site scripting (XSS) en el panel interno.

Medio (P3):

  • Período de tiempo: 90 días.
  • Criterios: Gravedad baja o media sin vulnerabilidades de seguridad conocidas.
  • Proceso: Ciclo de actualización normal con aplicación de revisiones trimestrales.
  • Ejemplo: Divulgación de información en dependencia de la herramienta de desarrollo.

Bajo (P4):

  • Período de tiempo: Próxima versión principal.
  • Criterios: Gravedad baja o falsos positivos que requieren documentación.
  • Proceso: Incluya en las actividades de mantenimiento normales.
  • Ejemplo: Denegación de servicio en una característica opcional sin usar.

Establecimiento de barras de errores de seguridad

Las barras de errores de seguridad definen los estándares de seguridad mínimos que deben cumplirse:

Definición de criterios de finalización

Barra de errores de seguridad de ejemplo:

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

Cumplimiento de directivas

Puerta de calidad de 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"

Flujo de trabajo de priorización de vulnerabilidades

La evaluación sistemática garantiza una administración eficaz de vulnerabilidades:

Proceso de triaje

Paso 1: Filtrado automatizado:

  • Herramientas del analizador: Filtrar automáticamente las vulnerabilidades por gravedad.
  • Análisis de accesibilidad: quite las vulnerabilidades inaccesibles de la cola de evaluación de prioridades.
  • Falsos positivos conocidos: Suprima automáticamente los falsos positivos identificados previamente.

Paso 2: Evaluación inicial:

  • Revisión de gravedad: compruebe la precisión de la puntuación de CVSS para su entorno.
  • Comprobación de vulnerabilidades: Determine la disponibilidad de vulnerabilidades de seguridad y la explotación activa.
  • Identificación de recursos: Identifique qué aplicaciones y sistemas se ven afectados.

Paso 3: Evaluación de riesgos:

  • Impacto empresarial: Evalúe el impacto empresarial potencial de la explotación correcta.
  • Análisis de exposición: Determine la exposición de red y la superficie expuesta a ataques.
  • Controles de compensación: Identifique las mitigaciones existentes que reducen el riesgo.

Paso 4: Priorización:

  • Asignar prioridad: Use la matriz de priorización para asignar prioridad de corrección.
  • Establecer la fecha de vencimiento: Asigne una fecha límite de corrección basada en el Acuerdo de Nivel de Servicio.
  • Asignar propietario: designe el equipo responsable para la corrección.

Paso 5: Seguimiento de la corrección:

  • Creación de vales: genere elementos de trabajo en el sistema de seguimiento (Jira, Azure Boards).
  • Supervisión del progreso: Realice un seguimiento del progreso de la corrección con respecto a las fechas límite.
  • Verificación: Valide la corrección exitosa mediante un nuevo examen.

Cadencia de reunión de evaluación de prioridades

Evaluación semanal de prioridades de seguridad:

  • Participantes: Equipo de seguridad, responsables de desarrollo, representantes de operaciones.
  • Agenda: Revise los nuevos resultados críticos y altos, realice un seguimiento del progreso de la corrección, ajuste las prioridades.
  • Duración: 30-60 minutos.

Revisión mensual de vulnerabilidades:

  • Participantes: Liderazgo de seguridad, administración de ingeniería, equipo de cumplimiento.
  • Agenda: Revise las tendencias, ajuste las directivas, evalúe la posición general de seguridad.
  • Duración: 60-90 minutos.

Métricas e informes

Seguimiento de la eficacia de la administración de vulnerabilidades:

Métricas clave

Métricas de vulnerabilidad:

  • Tiempo medio para detectar (MTTD): Tiempo desde la divulgación de vulnerabilidades hasta la detección en los sistemas.
  • Tiempo medio para corregir (MTTR): Tiempo de detección a corrección correcta.
  • Densidad de vulnerabilidad: Número de vulnerabilidades por aplicación o línea de código.
  • Tasa de corrección: Porcentaje de vulnerabilidades corregidas en el Acuerdo de Nivel de Servicio.

Métricas de tendencia:

  • Recuento de vulnerabilidades abierto: Recuento de tendencias de vulnerabilidades sin resolver por gravedad.
  • Nuevo frente a resuelto: Comparación de vulnerabilidades recién detectadas y corregidas.
  • Cumplimiento del Acuerdo de Nivel de Servicio: Porcentaje de vulnerabilidades corregidas dentro de acuerdos de nivel de servicio definidos.
  • Tasa de falsos positivos: Porcentaje de hallazgos determinados como falsos positivos.

Ejemplo de panel de control

Panel de administración 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 ✓

Nota:

Para más información sobre los acuerdos de nivel de servicio (SLA) y las escalas de tiempo de corrección, consulte Contratos de nivel de servicio de Azure.

La interpretación y priorización eficaces de las alertas de vulnerabilidades transforman la salida abrumadora del escáner en mejoras de seguridad accionables. Al comprender las puntuaciones de gravedad, evaluar la explotabilidad, administrar falsos positivos e implementar la priorización sistemática, los equipos se enfocan en remediar las vulnerabilidades que realmente suponen un riesgo en lugar de perseguir cada alerta. Este enfoque basado en riesgos permite programas de seguridad sostenibles que protegen las aplicaciones sin sobrecargar a los equipos de desarrollo con ruido.