Tema 11

11. Escaneo de vulnerabilidades en imágenes, dependencias y paquetes del sistema

El escaneo de vulnerabilidades permite detectar componentes con fallas conocidas antes y después del despliegue. Su valor no está en producir listas extensas, sino en priorizar, corregir y evitar que los riesgos vuelvan a entrar al pipeline.

Objetivo Detectar y priorizar vulnerabilidades en artefactos
Enfoque Imágenes, paquetes del sistema, dependencias y pipelines
Resultado Bloquear, remediar o aceptar riesgos con criterio

11.1 Introducción

Las imágenes de contenedores combinan sistema operativo, runtime, librerías, dependencias y código de aplicación. Cada componente puede tener vulnerabilidades conocidas. El escaneo permite identificar esas vulnerabilidades y tomar decisiones antes de que lleguen a producción.

Escanear no es suficiente. Una organización puede tener miles de hallazgos y seguir expuesta si no prioriza por criticidad, explotación real, exposición del servicio y posibilidad de corrección.

El objetivo es integrar el escaneo al ciclo DevSecOps: pull request, build, registry, pre-deploy y runtime.

11.2 Qué se escanea

El escaneo puede analizar distintas capas del artefacto y del proyecto. Cada una aporta una visión parcial.

Elemento Qué detecta Ejemplo
Paquetes del sistema Vulnerabilidades en paquetes instalados por la distribución openssl, glibc, curl, bash
Dependencias de lenguaje Vulnerabilidades en librerías de aplicación npm, pip, Maven, NuGet, Go modules
Imagen base Problemas heredados por todas las imágenes derivadas Base desactualizada o sin soporte
Binarios incluidos Componentes externos agregados manualmente Herramientas descargadas en build
Configuración Malas prácticas de Dockerfile o permisos Usuario root, secretos, capabilities amplias

11.3 SCA y vulnerabilidades conocidas

SCA significa Software Composition Analysis. Analiza componentes de terceros para identificar vulnerabilidades, licencias, versiones obsoletas y dependencias transitivas.

Es importante porque muchas aplicaciones dependen de decenas o cientos de librerías. Una vulnerabilidad puede estar en una dependencia directa o en una dependencia transitiva que el equipo ni siquiera conoce explícitamente.

  • Dependencia directa: declarada por el proyecto.
  • Dependencia transitiva: incluida porque otra dependencia la requiere.
  • Paquete vulnerable: componente con CVE o advisory asociado.
  • Versión corregida: versión donde el proveedor o comunidad aplicó parche.
  • Dependencia abandonada: componente sin mantenimiento activo.
El escaneo de dependencias no reemplaza revisión de arquitectura. Una librería vulnerable puede ser crítica o irrelevante según cómo se use y dónde se ejecute.

11.4 CVE, CVSS y EPSS

Las vulnerabilidades suelen identificarse con CVE. CVSS estima severidad técnica. EPSS estima probabilidad de explotación observada o esperada. Ninguna métrica por sí sola alcanza para decidir prioridad.

Métrica Qué aporta Límite
CVE Identificador común de una vulnerabilidad conocida No indica por sí solo exposición real
CVSS Severidad técnica basada en características del fallo No siempre refleja explotación activa o contexto de negocio
EPSS Probabilidad de explotación No reemplaza análisis de impacto interno
Advisory del proveedor Detalle de versiones afectadas y correcciones Puede tardar en sincronizarse entre bases de datos

11.5 Contexto de explotación

Dos vulnerabilidades con la misma severidad pueden tener prioridades distintas. El contexto define si el riesgo es explotable y qué impacto tendría.

Factores de contexto:

  • ¿El servicio está expuesto a internet?
  • ¿El componente vulnerable está cargado y en uso?
  • ¿El contenedor corre como root o con privilegios elevados?
  • ¿Procesa datos sensibles?
  • ¿Existen mitigaciones como WAF, autenticación o segmentación?
  • ¿La vulnerabilidad permite ejecución remota, lectura de archivos o escalamiento?
  • ¿Hay exploits públicos o explotación activa?

11.6 Escaneo en el pipeline

El pipeline es el lugar natural para detectar vulnerabilidades antes de publicar o desplegar. La política debe definir qué hallazgos bloquean y cuáles generan advertencia.

Etapa Escaneo Decisión
Pull request Dependencias declaradas y Dockerfile Advertir temprano y sugerir corrección
Build Imagen generada Bloquear críticos según política
Publicación Artefacto final y metadatos Permitir solo imágenes aprobadas
Pre-deploy Imagen candidata y entorno destino Aplicar gates más estrictos para producción

11.7 Escaneo en registry

Una imagen que era aceptable al publicarse puede volverse vulnerable después, cuando se descubre una nueva CVE. Por eso los registries deben reanalizar imágenes almacenadas.

Beneficios:

  • Detectar vulnerabilidades nuevas en imágenes antiguas.
  • Identificar imágenes obsoletas que siguen disponibles.
  • Bloquear promoción de imágenes vulnerables.
  • Notificar dueños de servicios afectados.
  • Retirar imágenes no usadas o sin mantenimiento.

El registry debe integrarse con inventario y despliegues reales. No todas las imágenes almacenadas están en producción.

11.8 Escaneo en runtime

El escaneo en runtime responde qué imágenes vulnerables están ejecutándose realmente. Esta información es clave para priorizar porque conecta vulnerabilidades con exposición operativa.

Permite responder:

  • ¿Qué pods o contenedores ejecutan una imagen vulnerable?
  • ¿En qué cluster, namespace y ambiente están?
  • ¿El servicio está expuesto públicamente?
  • ¿La imagen tiene una versión corregida disponible?
  • ¿El contenedor tiene privilegios que agravan el impacto?

11.9 Falsos positivos y falsos negativos

Los escáneres no son perfectos. Pueden reportar vulnerabilidades que no aplican o no detectar componentes empaquetados de forma no estándar.

  • Falso positivo: el hallazgo existe en la base de datos, pero no afecta realmente al artefacto o al uso.
  • Falso negativo: el escáner no detecta una vulnerabilidad presente.
  • Vulnerabilidad no explotable: el componente existe, pero la ruta vulnerable no se usa o está mitigada.
  • Componente no identificado: binarios o librerías sin metadatos suficientes.
Ignorar todos los hallazgos por falsos positivos es tan peligroso como bloquear todo sin análisis. La madurez está en validar, priorizar y documentar decisiones.

11.10 Políticas de bloqueo

Una política de bloqueo define cuándo una imagen no puede avanzar. Debe ser clara, medible y ajustada al contexto para no paralizar entregas ni permitir riesgos inaceptables.

Criterios posibles:

  • Bloquear vulnerabilidades críticas con fix disponible.
  • Bloquear vulnerabilidades explotadas activamente.
  • Bloquear imágenes con secretos detectados.
  • Bloquear imágenes base sin soporte.
  • Bloquear producción si no existe escaneo reciente.
  • Permitir excepciones temporales con aprobación y vencimiento.

11.11 Remediación

Remediar no siempre significa actualizar una librería. Puede requerir cambiar imagen base, reconstruir, modificar código, eliminar paquetes, aplicar mitigaciones o aceptar temporalmente el riesgo.

Causa Remediación Riesgo residual
Imagen base vulnerable Actualizar base y reconstruir imágenes derivadas Compatibilidad con runtime o dependencias
Dependencia de aplicación vulnerable Actualizar paquete, ajustar lockfile y probar Cambios funcionales o breaking changes
Paquete innecesario Eliminarlo de la imagen final Dependencia oculta no detectada
Sin parche disponible Mitigar exposición, monitorear y documentar excepción Riesgo aceptado temporalmente

11.12 Excepciones

Las excepciones son necesarias cuando no existe parche, la actualización rompe compatibilidad o el riesgo está mitigado. Pero deben ser temporales y explícitas.

Una excepción debe incluir:

  • CVE o advisory afectado.
  • Imagen, servicio y ambiente.
  • Motivo de aceptación temporal.
  • Controles compensatorios.
  • Fecha de vencimiento.
  • Responsable y aprobador.
  • Plan de remediación definitiva.

11.13 Métricas útiles

Las métricas ayudan a saber si el programa reduce riesgo o solo produce reportes.

  • Vulnerabilidades críticas abiertas por ambiente.
  • Tiempo medio de remediación por severidad.
  • Porcentaje de imágenes con escaneo reciente.
  • Imágenes en producción con vulnerabilidades explotadas activamente.
  • Hallazgos repetidos por imagen base.
  • Excepciones vencidas.
  • Porcentaje de imágenes reconstruidas ante actualización crítica de base.

11.14 Relación con SBOM

Un SBOM lista los componentes de software incluidos en una aplicación o imagen. Facilita responder rápidamente si una vulnerabilidad afecta a la organización.

El SBOM ayuda a:

  • Conocer componentes directos y transitivos.
  • Vincular artefactos con versiones exactas.
  • Consultar impacto ante nuevas CVE.
  • Mejorar trazabilidad de cadena de suministro.
  • Apoyar requisitos de auditoría y cumplimiento.

11.15 Errores frecuentes

  • Escanear solo en el build y no reanalizar imágenes almacenadas.
  • Bloquear por severidad sin considerar contexto ni fix disponible.
  • No asignar dueños de remediación.
  • Actualizar dependencias sin ejecutar pruebas suficientes.
  • Ignorar vulnerabilidades de imagen base porque "no son código propio".
  • Mantener excepciones sin vencimiento.
  • No distinguir imágenes almacenadas de imágenes realmente ejecutadas.
  • Usar escaneo como reporte manual en lugar de integrarlo al pipeline.
El escaneo genera datos. El programa de gestión de vulnerabilidades convierte esos datos en decisiones, remediación y reducción real de riesgo.

11.16 Lista de verificación

  • ¿Las imágenes se escanean durante build, en registry y antes de producción?
  • ¿Las dependencias de aplicación se analizan con SCA?
  • ¿La política de bloqueo distingue severidad, explotación y fix disponible?
  • ¿Los hallazgos tienen dueño y SLA de remediación?
  • ¿Las excepciones tienen vencimiento y controles compensatorios?
  • ¿Se sabe qué imágenes vulnerables están ejecutándose realmente?
  • ¿Las imágenes base se actualizan y reconstruyen regularmente?
  • ¿Se generan o conservan SBOM para artefactos relevantes?

11.17 Qué debes recordar de este tema

  • El escaneo debe cubrir paquetes del sistema, dependencias, imágenes y runtime.
  • CVSS ayuda, pero la prioridad real depende del contexto.
  • Las imágenes deben reanalizarse porque aparecen nuevas vulnerabilidades después del build.
  • La remediación debe corregir base, dependencia o configuración según la causa.
  • Las excepciones son válidas solo si son justificadas, temporales y auditables.

11.18 Conclusión

El escaneo de vulnerabilidades es un componente esencial de DevSecOps, pero solo aporta valor si se integra con priorización, gates de pipeline, remediación, excepciones y métricas. Su propósito es reducir riesgo operativo, no producir listas interminables.

En el próximo tema estudiaremos la seguridad de registros de contenedores, firmas de imágenes y procedencia.

Volver al índice