La seguridad del software vive atrapada en una contradicción incómoda. Las organizaciones exigen cada vez más visibilidad sobre vulnerabilidades, dependencias y cadena de suministro, pero cuando esa visibilidad aparece en forma de miles de CVE públicos, muchas veces se interpreta como una señal de mayor riesgo. El código abierto queda así penalizado por una de sus mayores virtudes: enseñar lo que otros esconden, minimizan o corrigen sin demasiada explicación pública.
Red Hat ha puesto el dedo en una cuestión que muchas empresas ya sufren en sus programas de gestión de vulnerabilidades. La vieja consigna de “parchearlo todo” se ha quedado corta para el volumen actual de fallos documentados. En 1999, el primer año del programa CVE, se catalogaron centenares de vulnerabilidades. En 2024 se superaron las 40.000, con un crecimiento impulsado por la madurez del sistema, la incorporación de más autoridades de numeración y la entrada del kernel Linux como CNA.
El problema no es que haya más vulnerabilidades visibles. El problema es que muchas organizaciones siguen tratando cada CVE como si tuviera la misma urgencia. Eso ya no escala. En entornos complejos, con miles de servidores, contenedores, librerías, aplicaciones, appliances, sistemas OT y servicios cloud, perseguir cada vulnerabilidad de baja criticidad puede consumir recursos que deberían dedicarse a los fallos realmente explotables.
El fin del “parchear todo”
La gestión moderna de vulnerabilidades necesita aceptar una realidad: no todos los fallos son iguales. Una vulnerabilidad remota, explotable sin autenticación, con escalada de privilegios y código de explotación disponible no puede tener la misma prioridad que un bug de bajo impacto, difícil de explotar y situado en un componente no expuesto.
Red Hat defiende que el criterio clave debe ser la explotación real y el impacto potencial. Para ello cita fuentes como el catálogo Known Exploited Vulnerabilities de CISA, que recopila vulnerabilidades explotadas activamente y ayuda a los equipos de seguridad a priorizar. Según el análisis compartido por Red Hat, las tasas históricas de explotación siguen siendo muy bajas en relación con el volumen total de CVE, por debajo del 0,5 % anual. En 2024, solo el 0,26 % de las vulnerabilidades de código abierto que afectaban a software de Red Hat, 11 de más de 4.200, se conocían como explotadas en situaciones reales en alguna plataforma.
Ese dato no significa que haya que ignorar el resto. Significa que la urgencia debe estar mejor asignada. En seguridad, el recurso escaso no es solo el presupuesto. También lo son el tiempo de los equipos, las ventanas de mantenimiento, la capacidad de probar parches, la tolerancia a interrupciones y la atención de los responsables técnicos.
| Enfoque tradicional | Enfoque basado en riesgo |
|---|---|
| Contar CVE y exigir cero vulnerabilidades | Priorizar por explotación, exposición e impacto |
| Tratar todo como urgente | Separar crítico, importante, moderado y bajo |
| Parchear por volumen | Parchear por amenaza probable |
| Penalizar software visible | Comparar riesgo real entre todo tipo de software |
| Medir actividad | Medir reducción de riesgo |
La frase “patch everything” pudo tener sentido cuando los entornos eran más pequeños y el número de vulnerabilidades era manejable. Hoy puede llevar a una falsa sensación de control. Una organización puede cerrar cientos de CVE de bajo impacto y seguir expuesta a tres fallos críticos explotados activamente en internet.
La transparencia del open source crea un sesgo
El código abierto expone más información porque su modelo lo permite. El código se puede revisar, los fallos se discuten públicamente y las vulnerabilidades menores suelen documentarse con más frecuencia. En software propietario, en cambio, muchas vulnerabilidades de bajo impacto pueden no publicarse, corregirse de forma silenciosa o agruparse en boletines poco detallados.
Esto genera una comparación injusta. Si una política interna exige “cero vulnerabilidades conocidas”, el software abierto aparecerá peor en las métricas simplemente porque documenta más. No porque sea necesariamente más peligroso. La opacidad del software propietario no elimina los fallos; solo reduce lo que el cliente puede ver.
Red Hat lo plantea como una cuestión de equidad. El riesgo residual que muchas organizaciones aceptan de forma implícita en software cerrado debería evaluarse de forma explícita también en el código abierto. La diferencia no está solo en el riesgo, sino en la visibilidad.
El ejemplo que cita Red Hat es llamativo. En su informe de riesgo de 2024, el 92 % de las vulnerabilidades que afectaban a software de Red Hat estaban clasificadas como moderadas o bajas. En la comparación con un gran proveedor propietario que usa una escala de severidad similar, solo el 5,5 % de las vulnerabilidades publicadas aparecían como moderadas o bajas. Esa diferencia no sugiere necesariamente que un proveedor genere muchos menos fallos de bajo impacto que otro. Puede reflejar políticas de divulgación muy distintas.
Contar vulnerabilidades ya no basta
Medir la seguridad de una organización por el número bruto de CVE pendientes es una simplificación peligrosa. Puede servir como indicador inicial, pero no como criterio único de decisión. Un inventario con 1.000 vulnerabilidades moderadas en componentes no expuestos puede ser menos urgente que una sola vulnerabilidad crítica explotada en un sistema accesible desde internet.
La madurez está en cruzar varias señales: si existe explotación activa, si hay código público de exploit, si el activo está expuesto, si el servicio es crítico para el negocio, si hay datos sensibles, si el fallo permite movimiento lateral, si existen mitigaciones y si el parche puede aplicarse sin romper producción.
| Señal de priorización | Pregunta útil |
| KEV de CISA | ¿Está siendo explotada en el mundo real? |
| Exposición | ¿El sistema es accesible desde internet o desde redes no confiables? |
| Impacto | ¿Permite ejecución remota, escalada o acceso a datos sensibles? |
| Criticidad del activo | ¿Afecta a sistemas clave del negocio? |
| Disponibilidad de exploit | ¿Hay PoC funcional o explotación masiva? |
| Mitigaciones | ¿Puede reducirse el riesgo sin parche inmediato? |
| Coste operativo | ¿Qué impacto tiene aplicar el parche ahora? |
Este enfoque no excusa la dejadez. Al contrario, exige más criterio. Un equipo que prioriza bien debe saber qué no va a parchear de inmediato y por qué. Esa aceptación de riesgo debe quedar documentada, revisarse y cambiar si aparece explotación activa o si el activo se vuelve más expuesto.
Qué deberían cambiar los equipos de seguridad
El primer cambio es abandonar las políticas absolutas de “cero CVE” como objetivo operativo. En algunos entornos regulados puede ser necesario aplicar criterios muy estrictos, pero incluso ahí conviene distinguir vulnerabilidades por riesgo real. Una política que no diferencia acaba generando excepciones informales, fatiga y parches aplicados sin buena prueba.
El segundo es incorporar inteligencia de explotación. El catálogo KEV de CISA, EPSS, inteligencia de amenazas, telemetría interna y exposición de activos deben formar parte de la priorización. CVSS sigue siendo útil, pero no basta. Una puntuación alta no siempre implica explotación probable, y una vulnerabilidad de puntuación media puede ser urgente si afecta a un componente muy expuesto.
El tercero es tratar el código abierto y el propietario con el mismo criterio. Si se exige transparencia a las dependencias open source, también se debe exigir claridad a proveedores cerrados: boletines detallados, plazos de corrección, SBOM, historial de vulnerabilidades, impacto real y mitigaciones.
El cuarto es mejorar el inventario. No se puede priorizar lo que no se conoce. Saber qué versiones corren, dónde, con qué exposición y qué dependencia usa cada aplicación sigue siendo una de las tareas más difíciles. Sin SBOM, CMDB actualizada, escaneo continuo y contexto de negocio, la gestión de vulnerabilidades se convierte en una lista interminable sin jerarquía.
El quinto es aceptar que la transparencia no es un defecto. Ver más fallos permite decidir mejor. El riesgo no desaparece porque un proveedor lo oculte o lo publique con menos detalle.
Una lección para compras, cumplimiento y dirección
El debate no afecta solo a los equipos técnicos. También importa a compras, legal, cumplimiento y dirección. Muchas decisiones de software se toman con cuestionarios que penalizan el número de vulnerabilidades conocidas sin analizar severidad, explotación o política de divulgación. Eso puede llevar a elegir soluciones menos transparentes en lugar de soluciones más seguras.
Un buen proceso de compras debería preguntar cómo gestiona el proveedor las vulnerabilidades, cuánto tarda en corregir las críticas, cómo comunica riesgos, si publica SBOM, qué soporte ofrece, qué parches prioriza y qué mitigaciones propone. El número total de CVE solo tiene sentido dentro de ese contexto.
También hay una cuestión cultural. El código abierto ha pasado de ser visto como una alternativa marginal a ser base de la nube, contenedores, Kubernetes, Linux, bases de datos, lenguajes, frameworks y herramientas de seguridad. Tratar su transparencia como una debilidad es no entender cómo se construye el software actual.
La paradoja del open source en seguridad es que parece más vulnerable porque permite mirar dentro. Pero la opacidad no es protección. Es incertidumbre. Y la gestión madura del riesgo no consiste en tener menos información, sino en usar mejor la que se tiene.
Preguntas frecuentes
¿El código abierto tiene más vulnerabilidades que el software propietario?
No necesariamente. Suele tener más vulnerabilidades visibles porque su modelo de transparencia facilita la revisión, documentación y publicación de fallos, incluidos los de bajo impacto.
¿Por qué ya no sirve “parchear todo”?
Porque el volumen de CVE ha crecido mucho y no todos los fallos tienen el mismo riesgo. Priorizar por explotación real, exposición e impacto permite usar mejor los recursos de seguridad.
¿Qué es el catálogo KEV de CISA?
Es una lista de vulnerabilidades conocidas como explotadas en el mundo real. Ayuda a las organizaciones a identificar fallos que deben priorizarse frente a vulnerabilidades menos probables o de menor impacto.
¿Qué debería hacer una empresa con vulnerabilidades moderadas o bajas?
Debe evaluarlas en contexto. Algunas podrán aceptarse temporalmente, otras requerirán mitigaciones y otras se corregirán en ciclos normales de mantenimiento. La clave es documentar la decisión y revisarla.
Fuente: Red Hat, “The open source paradox: Unpacking risk, equity and acceptance”.
