La paradoja del open source: análisis del riesgo, la igualdad y la aceptación

El open source siempre ha sido paradójica: se trata de sistemas de software que crean los desarrolladores entusiastas y que se ofrecen de forma gratuita, pero algunas de las empresas más grandes del mundo los rentabilizan y financian.Suele ser subestimado, e incluso una vez se lo llamó "cáncer"; sin embargo, es el mayor impulsor de la innovación y el progreso tecnológico que jamás hayamos visto. En este ámbito, la paradoja siempre existirá, principalmente en lo que respecta a la comprensión de los puntos vulnerables de seguridad.

Hace 25 años, se estableció el programa de puntos vulnerables y exposiciones comunes (CVE) para estandarizar la denominación y el registro de las fallas del software. En una época en la que la identificación de un punto vulnerable específico solía dar lugar a resultados ambiguos, con varios problemas en sistemas de software comunes, como sendmail, CVE llegó para aportar claridad y organización. Si bien hubo soluciones iniciales como SecurityFocus y Bugtraq, el CVE de MITRE proporcionó un sistema global muy necesario. En su primer año, 1999, se catalogaron 894 puntos vulnerables, lo que puso de manifiesto la necesidad de identificarlos de manera uniforme desde el comienzo, incluso cuando la cantidad era relativamente más pequeña. Este contexto histórico es fundamental para comprender los desafíos que enfrentamos con los CVE en la actualidad.

A lo largo de este tiempo, el panorama de los puntos vulnerables de software ha cambiado drásticamente. En los primeros seis años del programa, la cantidad de CVE asignados aumentó más de un 450 % debido a la adopción generalizada. Este crecimiento continuó de manera exponencial, con una cifra de casi 15 000 CVE en 2017, lo que representa un aumento del 125 % en tan solo dos años. Para 2023, esta cifra había aumentado en un 50 %, es decir, se detectaron más de 29 000 puntos vulnerables. Este aumento exponencial evidencia la creciente complejidad y disponibilidad del software, así como el aumento de la adopción de los CVE por parte de los proveedores.

El panorama de los puntos vulnerables sigue creciendo de manera considerable. En 2024, los CVE asignados aumentaron en un 39 %, superando los 40 000, en parte debido al estado de las autoridades de numeración de CVE (CNA) del kernel de Linux. La tendencia de crecimiento podría acelerarse considerablemente si otros sectores del software, como el desarrollo de aplicaciones móviles o de juegos, comenzaran a realizar un registro formal de los CVE. Esta gran cantidad requiere una reevaluación esencial de nuestra estrategia de gestión de puntos vulnerables.

"Aplicar todos los parches posibles" no es sostenible

Hace tiempo que defendemos el viejo mantra de "aplicar todos los parches posibles". Si bien en otros tiempos era más fácil implementarlo, ahora es insostenible y estratégicamente poco apropiado para los entornos complejos. Funciona sin una auténtica evaluación de riesgos. No todos los puntos vulnerables requieren una corrección inmediata, que consume muchos recursos. Son fundamentales los factores como la probabilidad de explotación y el posible impacto. Si todas las fallas identificadas se trataran de la misma manera, sería como recomendar una cirugía invasiva para los tumores tanto benignos como malignos, ya que se ignoraría el nivel real de amenaza y los riesgos del propio tratamiento.

El indicador más importante para establecer un orden de prioridad de las acciones es la probabilidad de explotación real. El análisis de datos, que utiliza fuentes como el catálogo de puntos vulnerables conocidos explotados (KEV) de la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA), muestra de manera uniforme que las tasas de explotación siguen siendo bastante bajas, muy por debajo del 0,5 % anual. Esto se traduce en que aproximadamente 1 de cada 200 puntos vulnerables se convierte en una herramienta de ataque. Si tenemos en cuenta todo esto, debemos centrarnos en enfoques más pragmáticos y basados en los riesgos.

Es necesario centrarse en los puntos vulnerables que tienen más probabilidades de ser explotados y que podrían causar daños importantes. Por lo general, llamamos puntos vulnerables graves o importantes a aquellos que permiten el acceso remoto no autenticado con privilegios elevados. Al orientar las iniciativas de corrección hacia estos puntos vulnerables, reducimos al mínimo el riesgo con los recursos disponibles. De esta manera, se acepta de forma estratégica el menor riesgo remanente que presentan los puntos vulnerables que no serán afectados o que tendrán un impacto material si son explotados, es decir, la mayoría de los problemas de importancia baja y moderada. 

La gestión eficaz de los riesgos no consiste en eliminar todos los puntos vulnerables, sino en priorizar aquellos que representan una amenaza real y probable, así como aceptar conscientemente los que pueden controlarse.

¿Qué relación tiene esto con el open source?

Las preocupaciones sobre los puntos vulnerables sin parches suelen centrarse en la tecnología de open source, principalmente debido a su transparencia. Todos podemos ver el código y los CVE. Por el contrario, los proveedores propietarios no suelen revelar las fallas de bajo impacto que consideran que no merece la pena corregir, lo que crea un panorama de riesgos poco claro. Es posible que una falla menor que genere un CVE público en un software open source no se informe ni se corrija, o bien que se apliquen parches en un software propietario sin notificación alguna.

Esta diferencia de visibilidad origina un doble criterio. Las políticas que exigen la "ausencia de puntos vulnerables conocidos" apuntan inherentemente a la transparencia de la tecnología de open source, no a su mayor riesgo. Tu empresa ya acepta implícitamente el riesgo de que se produzcan fallas menores no reveladas en el software propietario que utilizas a diario. Para tener una buena gestión de riesgos, es necesario reconocer esto. Debemos realizar una evaluación de riesgos explícita y uniforme que se centre en la probabilidad de explotación y en el impacto en todo el software, en lugar de penalizar la propia visualización de la tecnología de open source.

Para lograr una verdadera igualdad en el ámbito de la gestión de puntos vulnerables, debemos reconocer que el open source es diferente: es mucho más transparente desde sus inicios (aspecto positivo) y probablemente tendrá más puntos vulnerables. Debemos aceptar explícitamente los riesgos que asumimos de forma implícita en el software propietario.

Hay algunos datos interesantes que respaldan esta explicación. Si comparamos los datos de Red Hat y los de nuestro informe sobre riesgos de 2024 con los de un proveedor de software propietario principal y conocido, obtenemos información muy interesante que prueba la hipótesis mencionada anteriormente. A menos que el proveedor propietario solo genere errores que tengan un gran impacto (es decir, que sean explotables fácilmente), esperaríamos ver una distribución similar de problemas graves e importantes a moderados y bajos. En otras palabras, a menos que los errores de seguridad que causan sean siempre graves, peligrosos y evidentes, veremos una mayor cantidad de errores con menos impacto. Sin embargo, las cifras muestran que hay pocos problemas de baja gravedad. Por otro lado, este proveedor utiliza la misma escala de gravedad de cuatro puntos que Red Hat.

Los indicadores de los informes sobre los puntos vulnerables pueden ofrecer una imagen engañosa. La mayor cantidad de CVE de baja gravedad que se informaron de manera transparente en los proyectos open source (el 92 % de los puntos vulnerables de Red Hat fueron de gravedad moderada y baja en 2024) en comparación con este proveedor propietario (con un 5,5 % de puntos calificados con gravedad moderada y baja en 2024) no ilustra realmente el riesgo, ya que refleja principalmente las diferentes ideas de divulgación.

En lugar de buscar solo las calificaciones por cantidad o gravedad, es preferible centrarse en el factor fundamental: la explotación real. En 2024, solo el 0,26 % de los puntos vulnerables open source (11 de más de 4200) que afectaron al software de Red Hat se explotaron en alguna plataforma real. Si los puntos vulnerables se priorizan únicamente en función de su cantidad, se genera una gran pérdida de recursos en problemas que representan una amenaza práctica mínima.

Tanto los proveedores propietarios como los de tecnología de open source priorizan la corrección de los problemas más importantes. Sin embargo, la principal diferencia suele ser la transparencia en relación con los puntos vulnerables de menor impacto y sin parches. Ya aceptamos implícitamente este riesgo remanente del software de código cerrado, así que es momento de aplicar esta misma evaluación pragmática y basada en riesgos explícitamente en todo el software, incluida la tecnología de open source. Desde un punto de vista filosófico, todos estamos de acuerdo en que primero debemos solucionar lo más importante y postergar lo secundario.

Como líderes en seguridad, creemos que tu programa no debe limitarse a contar los puntos vulnerables únicamente. Debes impulsar una estrategia que se centre en la inteligencia sobre la probabilidad de explotación y en el posible impacto en la empresa. Implementa procesos que prioricen rigurosamente la fracción de amenazas que probablemente se utilicen en los ataques y fomenta una cultura que comprenda y acepte con consciencia el riesgo remanente gestionable. Destina los recursos a la reducción de amenazas reales para la empresa.

Si deseas profundizar en este tema, consulta mi conferencia SOSS/Fusion Conference del año pasado de OpenSSF con datos de 2023, así como la de VulnCon 2025 de este año, que está actualizada con datos de 2024.