Cómo crear un sistema de gestión de vulnerabilidades con software libre: inventario, CVE, prioridades, parches y seguimiento

La gestión de vulnerabilidades no consiste en ejecutar un escáner una vez al mes y guardar un PDF. Un sistema serio debe saber qué activos existen, qué software tienen instalado, qué CVE los afectan, qué vulnerabilidades son realmente urgentes, quién debe corregirlas, cuándo vence el plazo, qué parche se aplicó y cómo se verificó el cierre.

La buena noticia es que se puede construir un sistema completo con software libre y herramientas abiertas. NIST recomienda que la gestión de parches sea una estrategia empresarial planificada y orientada a reducir riesgo, no una actividad improvisada; CISA, por su parte, insiste en priorizar vulnerabilidades explotadas activamente mediante su catálogo KEV como parte de la práctica de gestión de vulnerabilidades.

1. Qué es un sistema de gestión de vulnerabilidades

Un sistema de gestión de vulnerabilidades es un proceso continuo para identificar, evaluar, priorizar, corregir y verificar fallas de seguridad en servidores, estaciones, aplicaciones, contenedores, dependencias, sistemas operativos, configuraciones y servicios expuestos.

El enfoque moderno combina varias fuentes: inventario de activos, escaneo de red, análisis de paquetes instalados, SBOM de aplicaciones, CVE, CVSS, EPSS, CISA KEV, exposición a Internet, criticidad del activo y disponibilidad de parches. El NVD de NIST soporta métricas CVSS y datos de vulnerabilidades basados en estándares; FIRST define EPSS como un modelo que estima la probabilidad de explotación de una CVE en los próximos 30 días.

2. Arquitectura recomendada con software libre

Una arquitectura práctica puede combinar herramientas especializadas. Wazuh ayuda con inventario y detección continua en endpoints; Greenbone Community Edition/OpenVAS permite escaneo de vulnerabilidades en red; Trivy, Grype y OSV-Scanner sirven para aplicaciones, contenedores, repositorios y SBOM; OpenSCAP aporta evaluación de configuración y cumplimiento; OWASP Dependency-Track gestiona SBOM; y DefectDojo centraliza hallazgos, deduplicación, priorización y seguimiento.

Activos Linux / Windows / Cloud / Contenedores / Código
        ↓
Inventario: Wazuh, Ansible, SBOM, CMDB simple
        ↓
Escaneo: Greenbone, Trivy, Grype, OSV-Scanner, OpenSCAP
        ↓
Normalización: CSV, JSON, SARIF, CycloneDX, reportes
        ↓
Gestión: DefectDojo / Dependency-Track / tickets
        ↓
Priorización: KEV + EPSS + CVSS + exposición + criticidad
        ↓
Parches, mitigaciones, excepciones y verificación
        ↓
Indicadores: SLA, riesgo reducido, vulnerabilidades abiertas, reincidencia

3. Inventario: sin activos no hay gestión

El inventario es la base. No puedes corregir una vulnerabilidad en un servidor que nadie sabe que existe. El inventario debe incluir hostname, IP, sistema operativo, versión, paquetes instalados, aplicaciones, responsables, criticidad, exposición a Internet, ambiente, ubicación, backups y fecha del último escaneo.

Wazuh documenta que su agente recolecta inventario de software de endpoints y que el módulo de detección de vulnerabilidades correlaciona ese inventario con información de vulnerabilidades para identificar paquetes y software afectados. Ansible también ofrece el módulo package_facts para recopilar información de paquetes instalados como facts, útil cuando se administra infraestructura Linux con automatización.

activo,ip,sistema,version,ambiente,criticidad,expuesto_internet,responsable,ultimo_escaneo
web-01,10.10.1.20,Ubuntu,24.04,Producción,Alta,Sí,Equipo Web,2026-09-02
db-01,10.10.1.30,Debian,12,Producción,Crítica,No,Equipo DBA,2026-09-02
git-01,10.10.1.40,Rocky Linux,9,Producción,Alta,No,DevOps,2026-09-02

4. Escaneo de red con Greenbone Community Edition / OpenVAS

Greenbone Community Edition cubre el código fuente del stack Greenbone Vulnerability Management, conocido históricamente como OpenVAS. Es una opción libre para ejecutar escaneos de vulnerabilidades contra servidores, servicios y redes internas.

El valor de Greenbone está en detectar servicios expuestos, versiones vulnerables, configuraciones débiles y CVE asociadas. Debe usarse con ventanas controladas, credenciales cuando sea posible y reglas claras para no afectar sistemas sensibles.

5. Detección continua con Wazuh

Wazuh permite pasar de escaneos puntuales a detección continua en endpoints. Su módulo de detección de vulnerabilidades analiza el inventario recolectado por los agentes y lo correlaciona con contenido de vulnerabilidades para mostrar alertas en el dashboard.

En una empresa, esto ayuda a saber qué servidores tienen paquetes vulnerables, qué endpoints necesitan parches y qué activos se mantienen desactualizados. Su mayor ventaja es que el inventario proviene del endpoint, no solo de lo que se observa desde red.

6. Aplicaciones, contenedores y dependencias: Trivy, Grype y OSV-Scanner

Las vulnerabilidades no están solo en el sistema operativo. También viven en imágenes Docker, dependencias npm, paquetes Python, bibliotecas Java, binarios, repositorios Git y componentes de terceros. Trivy detecta vulnerabilidades conocidas en componentes que encuentra en el objetivo de escaneo y puede trabajar con imágenes, filesystem, repositorios, Kubernetes y SBOM; Grype se describe como un escáner open source para imágenes de contenedores y filesystems; OSV-Scanner permite iniciar escaneos contra código fuente y SBOM.

# Escanear una imagen de contenedor
trivy image nginx:latest
grype image:nginx:latest

# Escanear un directorio de aplicación

trivy fs --scanners vuln,secret,misconfig .
grype dir:.

# Generar reporte JSON para cargarlo a una plataforma de gestión

trivy image --format json -o reportes/trivy-nginx.json nginx:latest
grype image:nginx:latest -o json > reportes/grype-nginx.json

# Escanear un SBOM

trivy sbom ./sbom.cdx.json
grype sbom:./sbom.json

Trivy también puede tomar SBOM como entrada para buscar vulnerabilidades y licencias; esto es clave cuando una organización quiere separar la generación de inventario de software del análisis continuo de vulnerabilidades.

7. SBOM: saber qué componentes tiene cada aplicación

Un SBOM es una lista de materiales de software: componentes, dependencias, versiones, relaciones y metadatos. CycloneDX es un estándar de Bill of Materials reconocido como ECMA-424 y diseñado para representar inventario de software, hardware, servicios, dependencias, vulnerabilidades y otros elementos relevantes para transparencia de cadena de suministro.

OWASP Dependency-Track aprovecha SBOM para analizar el uso de componentes de terceros en el portafolio de aplicaciones de una organización y hacer seguimiento de riesgos. La documentación de OWASP indica que Dependency-Track trabaja con SBOM CycloneDX y VEX para monitoreo continuo de componentes.

8. OpenSCAP: configuración segura y cumplimiento

No todas las debilidades aparecen como CVE. Un servidor puede tener contraseñas débiles, servicios innecesarios, SSH inseguro, permisos incorrectos, logs incompletos o configuración fuera de línea base. OpenSCAP ofrece herramientas para escaneo de configuración y vulnerabilidades en sistemas Linux, y su herramienta oscap permite evaluar sistemas con contenido SCAP, XCCDF y OVAL.

# La ruta y el perfil cambian según distribución y contenido SCAP instalado
oscap xccdf eval \
  --profile perfil-seguridad \
  --results resultados-openscap.xml \
  --report reporte-openscap.html \
  contenido-scap.xml

OpenSCAP complementa a los escáneres de CVE porque permite evaluar cumplimiento técnico: configuración del sistema, parámetros de seguridad, servicios, auditoría, políticas y hardening.

9. Centralizar hallazgos con DefectDojo

Un problema común es terminar con reportes dispersos: un PDF de Greenbone, un JSON de Trivy, un reporte de Grype, una hoja de cálculo de Wazuh y correos sueltos. DefectDojo ayuda a centralizar hallazgos, importar resultados de herramientas, deduplicar vulnerabilidades, asignar riesgo, generar métricas y hacer seguimiento de remediación. Su documentación lo describe como una plataforma open source de gestión de vulnerabilidades y DevSecOps, con funciones de importación, deduplicación y priorización.

1. Crear producto: Portal Web, ERP, Servidores Linux, Red Interna
2. Crear engagement: Escaneo mensual, CI/CD, revisión de emergencia
3. Importar reportes: Greenbone, Trivy, Grype, Dependency-Track, SAST
4. Deduplicar hallazgos repetidos
5. Asignar responsables y SLA
6. Registrar mitigación o parche
7. Reescanear
8. Cerrar solo con evidencia

La deduplicación es clave porque una misma CVE puede aparecer en varios escáneres, contenedores, hosts o versiones. DefectDojo documenta mecanismos para identificar y administrar hallazgos duplicados, lo que ayuda a reducir ruido y evitar que el equipo pierda tiempo corrigiendo el mismo problema varias veces en sistemas de seguimiento distintos.

10. Priorización: no todo CVE crítico es igual de urgente

El error más caro es priorizar solo por CVSS. CVSS mide severidad técnica, pero no siempre indica si una vulnerabilidad está siendo explotada, si afecta un activo expuesto, si hay parche disponible o si el sistema vulnerable es crítico para la organización. NVD soporta CVSS v2, v3.x y v4.0 para métricas de vulnerabilidad, mientras EPSS estima probabilidad de explotación en los próximos 30 días; ambos deben combinarse con contexto local.

CISA mantiene el catálogo KEV como fuente de vulnerabilidades explotadas en la práctica y recomienda a las organizaciones priorizar su remediación. Además, CISA ha impulsado enfoques de priorización basados en riesgo que consideran exposición del activo, estado KEV, automatización del exploit e impacto técnico posterior a la explotación.

11. Modelo simple de prioridad

Para una empresa que está empezando, basta un modelo de cinco niveles. La prioridad no debe salir solo del escáner: debe revisarse con contexto técnico y operativo.

Prioridad = CVSS + KEV + EPSS + exposición + criticidad + facilidad de explotación + parche disponible

P1 = Explotada activamente, pública, crítica o con impacto alto.
P2 = Alta severidad, expuesta o con alta probabilidad de explotación.
P3 = Importante, pero con menor exposición o controles compensatorios.
P4 = Riesgo medio/bajo, corregible en mantenimiento regular.
P5 = Informativa, falso positivo o riesgo aceptado con justificación.

12. Parches: corregir sin romper producción

Aplicar parches no debe ser una ruleta. NIST SP 800-40 Rev. 4 plantea la gestión de parches como mantenimiento preventivo de tecnología, con estrategia, planificación y reducción de riesgo. En la práctica, eso significa probar, respaldar, programar ventanas, aplicar cambios, verificar y documentar.

1. Confirmar CVE y paquete afectado
2. Revisar si el activo está expuesto o es crítico
3. Validar respaldo o snapshot
4. Probar parche en laboratorio o staging
5. Aplicar en ventana de mantenimiento
6. Reiniciar servicio o servidor si corresponde
7. Verificar versión instalada
8. Reescanear
9. Cerrar ticket con evidencia

# Debian / Ubuntu
sudo apt update
apt list --upgradable
sudo apt upgrade

# RHEL / Rocky / AlmaLinux / Fedora

sudo dnf check-update || true
sudo dnf upgrade

# Verificar paquetes instalados

dpkg -l | grep nombre-paquete
rpm -qa | grep nombre-paquete

13. Mitigación cuando no puedes parchear

No siempre se puede parchear de inmediato. A veces el proveedor aún no publicó actualización, el sistema es heredado, la aplicación no soporta nueva versión o el cambio exige pruebas largas. En esos casos se deben aplicar controles compensatorios y documentar la excepción.

14. Seguimiento: tickets, responsables y evidencia

Un sistema de gestión de vulnerabilidades debe producir trazabilidad. Cada hallazgo relevante necesita estado, responsable, fecha de detección, SLA, evidencia, decisión, acción correctiva y verificación. DefectDojo puede servir como repositorio central, pero también se puede integrar con GitLab Issues, Jira, Redmine, GLPI, Zammad o una mesa de ayuda.

15. Indicadores que debe mirar la gerencia

Un buen programa no solo muestra CVE, muestra gestión. Los indicadores deben responder si la organización está reduciendo riesgo o solo acumulando reportes.

16. Frecuencia de escaneo recomendada

La frecuencia depende del riesgo. Un servidor público, una API crítica o una imagen de contenedor de producción requieren más control que un equipo de laboratorio. El inventario debe actualizarse continuamente o al menos cada semana; los activos expuestos deben escanearse con mayor frecuencia; y el código debe analizarse en cada pipeline.

17. Pipeline DevSecOps básico

En desarrollo de software, la gestión de vulnerabilidades debe integrarse al flujo de trabajo. No conviene esperar a producción para descubrir que una imagen Docker o una dependencia crítica tiene CVE conocidas.

Commit / Merge Request
        ↓
Escaneo de dependencias: OSV-Scanner, Trivy
        ↓
Escaneo de secretos y configuración: Trivy
        ↓
Generación de SBOM: CycloneDX
        ↓
Escaneo de imagen: Trivy o Grype
        ↓
Carga a Dependency-Track o DefectDojo
        ↓
Bloqueo si hay P1 o P2 sin excepción aprobada
        ↓
Despliegue con evidencia

Dependency-Track operacionaliza el SBOM como una tubería continua, mientras herramientas como Trivy y Grype permiten escanear imágenes y SBOM dentro del flujo de integración.

18. Checklist para implementar el sistema

19. Errores comunes

20. Preguntas clave

Recomendamos

En resumen

Crear un sistema de gestión de vulnerabilidades con software libre es totalmente posible, pero exige método. Primero se inventarian activos y software; luego se detectan CVE y configuraciones inseguras; después se prioriza con CVSS, EPSS, CISA KEV, exposición y criticidad; finalmente se aplican parches, mitigaciones, excepciones controladas y reescaneos de verificación.

La diferencia entre una organización reactiva y una organización madura no está en tener más reportes, sino en cerrar vulnerabilidades reales antes de que sean explotadas. El software libre aporta las herramientas; la disciplina operativa convierte esas herramientas en reducción efectiva de riesgo.