La seguridad forma parte de ese modelo. El desarrollo de código abierto pone el código a disposición para su revisión. Los investigadores pueden analizarlo. Las comunidades pueden mejorarlo. Las correcciones pueden beneficiar a cualquiera que dependa de ese software.

La misma escala que hace poderoso al código abierto también hace que la seguridad sea más compleja. Las aplicaciones modernas pueden depender de cientos o miles de componentes conectados a través de complejas cadenas de dependencias. Entender su exposición real al riesgo requiere mucho más que contar vulnerabilidades.

¿Cuántas vulnerabilidades han salido a la luz? ¿Cuántas eran críticas? ¿Cuántos paquetes resultaron afectados? Estas métricas son importantes, pero no responden a una pregunta más amplia:

¿Hasta qué punto estamos identificando, priorizando y corrigiendo los riesgos de seguridad de código abierto que realmente importan?

Una vulnerabilidad aparentemente crítica puede tener una exposición práctica limitada en un entorno concreto. Una debilidad de menor severidad puede volverse mucho más grave al combinarse con otra vulnerabilidad. Unas credenciales comprometidas o una configuración demasiado permisiva también pueden cambiar completamente el escenario.

Detectar una vulnerabilidad es solo el comienzo. Los equipos de seguridad deben comprender el riesgo, determinar si es necesaria una acción, encontrar una solución viable y hacer llegar esa corrección al software que la necesita.

En esta primera edición del Observatorio de Seguridad del Código Abierto analizamos tres aspectos de ese proceso:

La gravedad de una vulnerabilidad no lo es todo

Los atacantes explotan vulnerabilidades, no puntuaciones

La gravedad de una vulnerabilidad aporta información útil. Sin embargo, el riesgo real, especialmente en un contexto marcado por el auge de las amenazas impulsadas por la IA agéntica, depende de muchos más factores. Las vulnerabilidades críticas e importantes deben corregirse siempre lo antes posible, pero las de menor gravedad también merecen cada vez mayor atención, especialmente porque los agentes avanzados son capaces de combinarlas para crear ataques mucho más dañinos.

No es de extrañar que la inteligencia artificial esté complicando aún más la tarea de establecer prioridades. Un análisis de IBM X-Force de 223 vulnerabilidades divulgadas públicamente y descubiertas mediante modelos frontera de IA de reveló que el 55,2 % eran de gravedad alta o crítica, el 91,0 % eran accesibles de forma remota y el 25,6 % permitían la ejecución de código. A medida que la IA amplía las posibilidades de descubrir vulnerabilidades, limitarse a identificar y puntuar un mayor número de vulnerabilidades no será suficiente. Los responsables de la seguridad necesitan contexto para determinar qué hallazgos generan una exposición significativa, así como las posibles vías que puede seguir una vulnerabilidad.

Los recientes ataques muestran por qué es importante comprender toda la cadena de ataque.

El incidente de seguridad que afectó al popular proyecto de Python Ultralytics en diciembre de 2024 es un buen ejemplo de por qué es importante comprender toda la cadena de ataque. Los atacantes comprometieron el entorno de compilación GitHub Actions del proyecto e inyectaron código malicioso en paquetes publicados en PyPI. Ese código malicioso no estaba presente en el repositorio público del proyecto en GitHub. Finalmente, las cuatro versiones afectadas fueron retiradas de PyPI.

El incidente también puso de manifiesto el valor de otros controles presentes en la cadena de suministro del software. Las funcionalidades de publicación confiable (Trusted Publishing) de PyPI, las certificaciones de procedencia y los registros de transparencia ayudaron a los investigadores a determinar que los primeros paquetes maliciosos habían sido publicados a través del flujo de trabajo legítimo de GitHub Actions del proyecto, lo que permitió acotar la investigación al repositorio de código fuente o al proceso de compilación. Finalmente, se descubrió que el origen del ataque estaba en el caché de GitHub Actions.

Este incidente demuestra cómo una infraestructura de desarrollo fiable puede convertirse en un eslabón más de una cadena de ataque. También pone de relieve la importancia de comprender toda la cadena de ataque y los controles de seguridad que operan en cada una de sus fases.

Vulnerabilidad → Configuración → Credencial → Recurso sensible

Debilidades aparentemente menores pueden combinarse para generar un riesgo significativo.

¿Cuál es la gravedad de la debilidad? ¿A qué recursos puede dar acceso? ¿Qué puede detenerlos?

Responder a estas preguntas requiere más contexto. Los equipos pueden necesitar analizar factores como la posibilidad real de explotación, el alcance efectivo de la vulnerabilidad, la existencia de casos conocidos de explotación, su posición dentro de la cadena de dependencias, la configuración del entorno, los privilegios asociados, los controles de seguridad existentes (defensa en profundidad) u otras debilidades presentes en la misma cadena de ataque.

Los equipos de seguridad necesitan saber qué vulnerabilidades requieren intervención, por qué son relevantes en un entorno concreto y con qué urgencia deben actuar.

Indicador 2
La seguridad del código abierto debe llegar a donde se la necesita

El software moderno es un sistema interconectado

Una de las mayores fortalezas del código abierto es su capacidad para combinar y reutilizar componentes. Los desarrolladores pueden aprovechar el trabajo realizado por miles de proyectos en lugar de recrear por sí mismos las mismas funcionalidades.

Las observaciones obtenidas a partir de nuestro trabajo en Lightwell nos ofrecen una visión de los paquetes y versiones de código abierto utilizados en aplicaciones empresariales. Los paquetes analizados durante el tercer trimestre muestran cómo funciona, en la práctica, este ecosistema interconectado.

A 1 de octubre, Lightwell había distribuido más de 30.000 versiones validadas de paquetes de código abierto para Java y Python. En ese conjunto encontramos tanto frameworks de aplicaciones como el software sobre el que estos se sustentan: redes, serialización, autenticación, criptografía, observabilidad, servicios en la nube, gestión de paquetes, herramientas de compilación, inteligencia artificial y desarrollo de agentes.

Muchas de estas tecnologías incorporan sus propias familias de dependencias. Los servicios en la nube dependen de SDK y bibliotecas de soporte. La observabilidad se extiende a frameworks de desarrollo, bases de datos, servicios de red e infraestructuras de aplicaciones. El desarrollo de inteligencia artificial también está construyendo su propio ecosistema de dependencias. Los SDK de modelos conviven con plataformas de orquestación, herramientas para agentes, componentes MCP, servicios en la nube y soluciones de telemetría.

Gran parte de este software se sitúa por debajo de la capa de aplicación e incluye artefactos, paquetes y dependencias. Los desarrolladores rara vez interactúan directamente con estos componentes, pero las aplicaciones dependen de ellos cada día. El código abierto permite que la innovación fluya a través de esas conexiones. La seguridad también puede transmitirse a través de ellas.

Cuando los investigadores descubren una vulnerabilidad en un proyecto base, los equipos pueden verse obligados a evaluar varios componentes relacionados. El problema también puede propagarse a otros elementos situados más abajo en la cadena de dependencias. Las versiones publicadas de proyectos de código abierto muestran cómo puede ocurrir esto.

La actualización de seguridad 4.1.133.Final de Netty, publicada en mayo, corrigió 12 CVE que afectaban a distintas partes del proyecto, incluidas funcionalidades relacionadas con HTTP, HTTP/2, HTTP/3, MQTT, DNS, Redis, proxies y compresión.

Desarrollar una corrección es solo una parte del trabajo. Esa corrección también debe llegar al software que la necesita.

El código abierto ofrece una ventaja importante en este sentido. La investigación puede compartirse. Las correcciones pueden reutilizarse. Las mejoras introducidas en un proyecto pueden reforzar el software de todo el ecosistema que depende de él.

La misma interconexión que difunde la innovación del código abierto también puede extender los beneficios de su seguridad. Las correcciones también deben llegar a las versiones anteriores.

El trabajo de seguridad no termina con la versión más reciente de un software.

Las versiones analizadas por Lightwell abarcan desde software publicado hace apenas unos meses hasta versiones lanzadas hace varios años.

Esto es habitual en el software empresarial. Las comunidades de desarrollo siguen avanzando. Las organizaciones adoptan nuevas versiones según calendarios marcados por sus aplicaciones, infraestructuras y requisitos de ciclo de vida.

Spring Boot 2.7.18 es un ejemplo público. Publicada en noviembre de 2023, marcó el final del soporte de código abierto para la rama Spring Boot 2.x tras 5,5 años y 121 versiones. Sin embargo, la investigación en seguridad continúa después de cada lanzamiento.

Otro ejemplo es Spring Framework 5.3.18. Esta versión se publicó en marzo de 2022 para corregir la vulnerabilidad crítica Spring4Shell (CVE-2022-22965).

Menos de dos semanas después, el equipo de Spring comunicó otra vulnerabilidad que afectaba a las versiones hasta la 5.3.18. La corrección llegó con la versión 5.3.19. Los investigadores descubrieron esta segunda vulnerabilidad mientras analizaban el problema anterior.

Esta secuencia muestra cómo funciona la seguridad en el código abierto. La investigación genera nuevo conocimiento. Ese conocimiento se comparte. Llegan nuevas correcciones. Pero ¿qué ocurre con los sistemas que siguen ejecutando versiones anteriores afectadas?

La adaptación de correcciones a versiones anteriores no siempre es posible. Tampoco resulta siempre viable actualizar a una versión más reciente y corregida, especialmente en entornos de producción críticos desde el punto de vista operativo y de la gestión del riesgo.

La seguridad es un proceso continuo de descubrimiento, evaluación, mejora y respuesta.

En las organizaciones, las correcciones pueden tener que propagarse a dependencias relacionadas. También puede ser necesario hacerlas llegar a software antiguo que sigue en uso. Y las lecciones aprendidas de esos hallazgos pueden servir para mejorar versiones más recientes.

Por ello, la velocidad de remediación constituye un indicador útil de la eficacia de la seguridad en el código abierto.

¿Con qué rapidez pueden los equipos comprender un riesgo relevante? ¿Con qué rapidez pueden desarrollar una corrección fiable? ¿Cuánto tiempo tardan las organizaciones que dependen de ese software en ponerla en práctica?

Estas preguntas pueden decirnos mucho más sobre el funcionamiento de la seguridad en el código abierto que el simple recuento de vulnerabilidades.

Indicador 3
Una sola corrección puede generar valor mucho más allá de un único paquete

El valor de una única corrección: el caso de la implementación Eclipse de Jakarta XML Binding (JAXB)

El código abierto multiplica su valor porque muchas organizaciones dependen del mismo software. Cuando aparece una vulnerabilidad en un componente ampliamente utilizado, esas organizaciones suelen enfrentarse a tareas similares: determinar si están afectadas, obtener o desarrollar una corrección segura, probarla e incorporarla a producción.

Una corrección reutilizable puede reducir la necesidad de repetir ese trabajo una y otra vez.

JAXB^[1] es un buen ejemplo del alcance potencial que puede tener este efecto.

JAXB es una implementación base de código abierto para el enlace de datos XML dentro del ecosistema Java. Se incluyó en el JDK hasta Java 8. A partir de Java 11, las aplicaciones que necesitan JAXB deben obtenerlo por separado, ya sea de forma directa o a través de otra dependencia.

Para estimar el alcance potencial de una vulnerabilidad en JAXB y el valor económico de una corrección reutilizable, hemos elaborado un modelo que analiza tanto las aplicaciones Java 8 como los entornos Java más recientes.

Combinando investigaciones sectoriales de New Relic y otros referentes del ecosistema, nuestro modelo parte de una estimación de 3 millones de aplicaciones Java en producción en todo el mundo^[2].

Estimación de la presencia de JAXB

New Relic observó que Java 8 pasó de representar aproximadamente el 33 % de las aplicaciones Java monitorizadas en 2023 al 28,8 % en 2024. Si esa tendencia se proyecta proporcionalmente hasta 2026, la cuota estimada se situaría en torno al 22 %. Para mantener un enfoque conservador, nuestro modelo utiliza un 20 %.

Dado que JAXB estaba integrado en Java 8, aplicamos una segunda hipótesis: el 90 % de las aplicaciones Java 8 incluidas en el modelo utilizan funcionalidades XML que podrían depender de JAXB.

20% x 90% = 18%
Participación de Java 8 × uso estimado de JAXB = proporción sobre el total de aplicaciones Java

El 80 % restante, equivalente a 2,4 millones de aplicaciones, corresponde a entornos Java más recientes.

A partir de Java 11, JAXB dejó de estar incluido en el JDK. Para las aplicaciones que utilizan estas versiones más recientes de Java, asumimos que JAXB está presente en el 25 % de los casos: aproximadamente un 10 % a través de dependencias directas y un 15 % mediante dependencias transitivas.

Estas hipótesis se basan en el uso continuado de JAXB a través de Maven Central y de pipelines CI/CD automatizadas, en las iniciativas de modernización Java impulsadas por herramientas como Moderne y OpenRewrite, y en investigaciones de Endor Labs y Black Duck que muestran hasta qué punto las dependencias transitivas forman parte de los grafos de dependencias de las aplicaciones modernas.

Aplicado a las aplicaciones Java más recientes:

3 million x 80% = 2,4 million
Aplicaciones Java 11 o superiores

1,14 millones
Aplicaciones Java usando JAXB

¿Cuántas podrían estar utilizando una versión vulnerable?

Que un componente esté presente en una aplicación no significa necesariamente que esta sea vulnerable. La versión utilizada es un factor determinante.

Por ello aplicamos diferentes tasas de permanencia de versiones vulnerables a los dos grupos de aplicaciones que utilizan JAXB.

Para las 600.000 aplicaciones Java más recientes que utilizan JAXB, aplicamos una tasa del 20,5 %, basada en investigaciones de Sonatype sobre compilaciones modernas que siguen utilizando versiones menores o parches con vulnerabilidades conocidas en dependencias activas.

600.000 x 20,5% = 123.000
Aplicaciones potencialmente vulnerables

Para las 540.000 aplicaciones Java 8 que utilizan JAXB, aplicamos una tasa del 30 %, basada en investigaciones de OpenLogic sobre sistemas de código abierto más antiguos que siguen sin parchearse debido a las dificultades operativas y de actualización.

540.000 x 30% = 162.000
Aplicaciones potencialmente vulnerables

En conjunto:

285.000
Aplicaciones potencialmente vulnerables

¿Cuánto costaría corregirlas de forma independiente?

Es a esta escala cuando el valor de una corrección reutilizable resulta mucho más evidente.

Basándonos en estudios sobre remediación de vulnerabilidades de seguridad del software, nuestro modelo estima que un equipo empresarial podría dedicar unas 20 horas de trabajo por aplicación para evaluar una vulnerabilidad, desarrollar o aplicar una corrección, ejecutar pruebas de regresión sobre esquemas XML e incorporar el cambio a su proceso de despliegue.

Utilizando un coste total de ingeniería de 125 dólares por hora, basado en datos salariales de desarrolladores de software publicados por U.S. Bureau of Labor Statistics:

20 horas x 125 dólares = 2.500 dólares
Por aplicación

Aplicado a las 285.000 aplicaciones potencialmente afectadas:

285.000 x 20 horas=  

5,7 millones de horas de ingeniería

y: 285.000 x $2.500 horas =

712,5 millones de dólares en esfuerzo de ingeniería estimado

Una corrección reutilizable no eliminaría todo el trabajo posterior. Las organizaciones seguirán teniendo que determinar si están afectadas, incorporar la corrección, validar sus aplicaciones y desplegar el cambio.

Sin embargo, una corrección validada y compatible con versiones anteriores puede reducir un trabajo que, de otro modo, tendría que repetirse en muchas organizaciones que se enfrentan a la misma vulnerabilidad subyacente.

El valor del tiempo

El esfuerzo de ingeniería es solo una parte del coste. El otro factor es cuánto tiempo permanece expuesta una aplicación afectada mientras se lleva a cabo la remediación.

El 2026 Vulnerability Statistics Report de Edgescan concluyó que las vulnerabilidades de gravedad alta y crítica en aplicaciones y API tardaban una media de 54,81 días en remediarse. Para una dependencia de código abierto de terceros como JAXB, esos 54,81 días podrían considerarse incluso una referencia conservadora. Por su parte, el estudio 2026 State of Software Security de Veracode concluyó que, incluso después de 358 días, solo se había corregido la mitad de los fallos de terceros identificados mediante análisis de composición de software. Aunque para este ejercicio utilizamos la cifra más conservadora de 54,81 días, ambos datos ilustran la persistencia del reto que supone remediar vulnerabilidades en aplicaciones y dependencias de terceros.

Para este modelo, asumimos un escenario acelerado de remediación de 10 días desde que una corrección está disponible hasta que es incorporada y desplegada por una organización. Se trata de un escenario utilizado para este ejercicio de modelización, no de una referencia observada en clientes de Lightwell. Los tiempos reales de despliegue variarán en función de la complejidad de la aplicación, los requisitos de pruebas, los procesos de gestión del cambio y la arquitectura de despliegue.

Comparado con la referencia sectorial de 54,81 días, este escenario pone de manifiesto un potencial significativo:

54,81 días - 10 días = 44.81 días O
81,8% más rápido en la remediación

Aplicado a las 285.000 aplicaciones potencialmente vulnerables:
285.000 × 44,81 días = 12.770.850 días de exposición de aplicaciones

12,8 millones 

de días de exposición a vulnerabilidades en el ecosistema empresarial Java.

El efecto multiplicador de una única corrección

Estas cifras son estimaciones basadas en un modelo. Muestran el valor potencial que puede generarse cuando una corrección para una dependencia común de código abierto puede reutilizarse en un gran número de aplicaciones.

Una única corrección puede evitar 5,7 millones de horas de trabajo duplicado de remediación, lo que equivale a hasta 712 millones de dólares en esfuerzo de ingeniería estimado para el conjunto del sector. 

Esta es una de las fortalezas de la seguridad del código abierto. La investigación puede beneficiar a muchos usuarios. Las correcciones pueden propagarse a lo largo del ecosistema. Un trabajo realizado una sola vez puede generar valor mucho más allá del proyecto en el que se originó el problema.

Tres señales del tercer trimestre

1.      El riesgo depende del contexto

La gravedad importa. También importan factores como la posibilidad de explotación, la accesibilidad real, las relaciones entre dependencias, el entorno, los controles de seguridad y otras debilidades que un atacante pueda aprovechar.

Comprender cuál puede ser el siguiente paso de un atacante ayuda a los equipos a decidir dónde actuar primero.

2.      La seguridad está en constante evolución

El código abierto hace que el software sea visible para investigadores, desarrolladores, proveedores y usuarios. Ese escrutinio genera nuevo conocimiento con el tiempo.

Las aplicaciones modernas combinan complejas cadenas de dependencias y varias generaciones de software. Una seguridad eficaz requiere que las correcciones lleguen al software que realmente las necesita.

3.      La remediación reutilizable genera beneficios acumulativos

El código abierto permite que el trabajo de seguridad beneficie a muchas más organizaciones.

La investigación puede compartirse. Las correcciones pueden reutilizarse. Una solución desarrollada para una dependencia común puede evitar que los usuarios que dependen de ella tengan que repetir el mismo trabajo.

Acerca del Observatorio de Seguridad del Código Abierto

El Observatorio de Seguridad del Código Abierto analiza cómo funciona la seguridad en el ecosistema de código abierto, desde la identificación de riesgos relevantes y la evaluación de cadenas de ataque hasta el desarrollo de correcciones y su distribución al software que depende de ellas.

Las próximas ediciones seguirán la evolución de este ecosistema: las vulnerabilidades que afectan al código abierto, qué riesgos requieren actuación, con qué rapidez se evalúan y remedian los problemas relevantes, qué dependencias críticas pueden necesitar una mayor resiliencia y en qué medida las correcciones reutilizables pueden reducir el trabajo repetitivo y la exposición al riesgo.

Nuestro análisis se basa en investigaciones de seguridad de Red Hat, datos de respuesta ante vulnerabilidades, análisis de paquetes y dependencias de código abierto, estudios sectoriales complementarios sobre seguridad, inteligencia sobre amenazas y datos públicos del ecosistema. Cuando una conclusión proceda de un conjunto de datos o de un grupo específico de sistemas analizados, indicaremos qué hemos estudiado, cómo hemos definido la métrica, el periodo cubierto y las limitaciones de los datos.

El código abierto ha transformado la forma en que el mundo desarrolla software. Su seguridad depende mucho más que identificar vulnerabilidades. También depende de la capacidad de las personas para determinar qué es realmente importante, frenar ataques viables, corregir problemas y compartir esas mejoras.