Contar vulnerabilidades ya no es suficiente para medir el riesgo real del software de código abierto

La seguridad del código abierto entra en una nueva etapa marcada por la inteligencia artificial, las complejas cadenas de dependencias y la necesidad de priorizar riesgos reales en lugar de limitarse a contabilizar vulnerabilidades. El primer Observatorio de Seguridad del Código Abierto de Red Hat concluye que el futuro de la ciberseguridad pasa por comprender el contexto de cada amenaza, acelerar la remediación y maximizar el valor de las correcciones reutilizables.

El ecosistema de código abierto se ha convertido en la base tecnológica sobre la que se desarrolla gran parte del software moderno. Sin embargo, según el Observatorio, la creciente complejidad de las aplicaciones y de sus cadenas de dependencias obliga a replantear la forma en que las organizaciones evalúan y gestionan el riesgo.

El informe sostiene que indicadores tradicionales como el número de vulnerabilidades detectadas o su nivel de severidad continúan siendo relevantes, pero ya no resultan suficientes para determinar la exposición real de una organización. La pregunta clave ya no es cuántas vulnerabilidades existen, sino cuáles representan un riesgo efectivo, qué impacto pueden tener y con qué rapidez pueden corregirse.

Para responder a esta cuestión, el estudio analiza tres grandes áreas: la relevancia real del riesgo, la eficacia de la remediación y el valor que generan las correcciones reutilizables dentro del ecosistema de código abierto.

 

La gravedad ya no refleja por sí sola el nivel de riesgo

Una de las principales conclusiones del informe es que la puntuación CVSS o la clasificación tradicional de gravedad no siempre permiten identificar qué vulnerabilidades requieren atención inmediata.

Según Red Hat, el riesgo real depende de múltiples factores adicionales, incluyendo la posibilidad práctica de explotación, los permisos asociados, la configuración del entorno, las dependencias afectadas, la existencia de controles compensatorios o la capacidad de combinar varias debilidades para construir una cadena de ataque.

La irrupción de la inteligencia artificial añade una nueva dimensión al problema. El estudio cita una investigación de IBM X-Force sobre 223 vulnerabilidades descubiertas mediante modelos avanzados de IA que revela que el 55,2% fueron clasificadas como de gravedad alta o crítica, el 91% podían explotarse de forma remota y el 25,6% permitían ejecución de código.

Para los investigadores, esta situación obliga a abandonar los enfoques centrados exclusivamente en la severidad y adoptar modelos basados en contexto y exposición real.

El informe utiliza el incidente sufrido por el proyecto de Python Ultralytics en diciembre de 2024 como ejemplo de la complejidad actual de los ataques sobre la cadena de suministro de software. En este caso, los atacantes comprometieron el entorno de compilación de GitHub Actions e introdujeron código malicioso en paquetes distribuidos a través de PyPI. El malware nunca estuvo presente en el repositorio público del proyecto, lo que dificultó inicialmente la investigación.

La utilización de mecanismos como Trusted Publishing, certificaciones de procedencia y registros de transparencia permitió finalmente localizar el origen del ataque en el sistema de caché de GitHub Actions.

Según Red Hat, este incidente demuestra que una vulnerabilidad aislada rara vez cuenta toda la historia y que los equipos de seguridad deben analizar la cadena completa de ataque: vulnerabilidades, configuraciones, credenciales, accesos y recursos comprometidos.

 

La velocidad de remediación se convierte en un indicador crítico

El segundo gran hallazgo del observatorio es que descubrir una vulnerabilidad representa únicamente el inicio del proceso.

El software moderno se construye mediante miles de componentes reutilizados y conectados entre sí. A fecha 1 de octubre, la plataforma Lightwell había distribuido más de 30.000 versiones validadas de paquetes Java y Python, lo que refleja el enorme entramado de dependencias sobre el que operan las aplicaciones empresariales.

La investigación recuerda que una corrección de seguridad solo aporta valor cuando consigue llegar a los sistemas que realmente la necesitan.

El informe destaca ejemplos como Netty, cuya versión 4.1.133.Final corrigió doce vulnerabilidades que afectaban a múltiples componentes de red, o las sucesivas correcciones publicadas por Spring Framework tras la vulnerabilidad crítica Spring4Shell.

Para Red Hat, la verdadera medida de la eficacia en seguridad no reside en el número de fallos corregidos, sino en la velocidad con que el conocimiento, las correcciones y las mejoras se propagan a través del ecosistema.

 

Una sola corrección puede ahorrar cientos de millones de dólares

El tercer indicador estudiado analiza el valor económico de las correcciones reutilizables.

Para ilustrarlo, el observatorio utiliza el caso de Jakarta XML Binding (JAXB), uno de los componentes históricos más utilizados dentro del ecosistema Java. A partir de diferentes modelos y estimaciones de mercado, el informe concluye que JAXB podría estar presente en alrededor de 1,14 millones de aplicaciones Java en producción. De ellas, unas 285.000 aplicaciones podrían estar utilizando versiones potencialmente vulnerables.

Si cada organización tuviera que analizar, corregir, validar y desplegar una solución de forma independiente, el esfuerzo acumulado alcanzaría aproximadamente 5,7 millones de horas de ingeniería y 712,5 millones de dólares en esfuerzo técnico estimado. Según el modelo elaborado por Red Hat, una única corrección reutilizable distribuida de forma eficiente puede evitar una enorme cantidad de trabajo duplicado en miles de organizaciones.

El informe también cuantifica el impacto temporal de las correcciones compartidas. Tomando como referencia un estudio de Edgescan, las vulnerabilidades críticas y altas tardan una media de 54,81 días en ser remediadas. El modelo utilizado por Red Hat plantea un escenario acelerado en el que una corrección validada puede desplegarse en 10 días. La diferencia supone una mejora del 81,8% en el tiempo de remediación.

Aplicado a las 285.000 aplicaciones potencialmente afectadas en el ejemplo de JAXB, el resultado equivaldría a evitar aproximadamente 12,8 millones de días de exposición acumulada a vulnerabilidades dentro del ecosistema empresarial Java.

El observatorio resume sus conclusiones en tres mensajes fundamentales. En primer lugar, el riesgo depende del contexto y no únicamente de la gravedad asignada a una vulnerabilidad. En segundo lugar, la seguridad debe entenderse como un proceso continuo de descubrimiento, evaluación, corrección y aprendizaje que afecta a múltiples generaciones de software. Y, finalmente, las correcciones reutilizables constituyen una de las mayores ventajas del código abierto, ya que permiten que el esfuerzo invertido por una comunidad beneficie simultáneamente a miles de organizaciones.

Para Red Hat, el gran reto de la próxima década no será identificar más vulnerabilidades, sino comprender cuáles son realmente importantes, corregirlas con rapidez y garantizar que las mejoras lleguen a todo el ecosistema de software que depende de ellas.