Asegurar el código abierto en 2025 y más allá: una hoja de ruta para el progreso

Han pasado más de tres años desde que se descubrió Log4Shell, una vulnerabilidad crítica en una biblioteca de código abierto poco conocida. Con una puntuación CVSS de 10, su relativa ubicuidad y facilidad de explotación la destacaron como uno de los fallos de software más graves de la década. Pero incluso años después de que se aplicara el parche, más de una de cada diez descargas de la popular utilidad son versiones vulnerables. Está claro que algo no va bien en alguna parte.

Un nuevo informe de la Fundación Linux ofrece información útil sobre los desafíos sistémicos que enfrentan el ecosistema de código abierto y sus usuarios. Lamentablemente, no existen soluciones fáciles, pero los usuarios finales pueden al menos mitigar algunos de los riesgos más comunes mediante las mejores prácticas de la industria.

Un estudio de caso catastrófico

Los componentes de software de código abierto están en todas partes; incluso los desarrolladores de código propietario confían en ellos para acelerar los procesos de DevOps. una estimaciónEl 96% de todas las bases de código contienen componentes de código abierto y tres cuartas partes contienen vulnerabilidades de código abierto de alto riesgo. Dado que se acerca siete billones Los componentes se descargaron en 2024, lo que representa un riesgo potencial masivo para los sistemas de todo el mundo.

Log4j es un excelente caso de estudio de lo que puede salir mal. Destaca un importante desafío de visibilidad en el sentido de que el software no solo contiene "dependencias directas" (es decir, componentes de código abierto a los que un programa hace referencia explícitamente), sino también dependencias transitivas. Estas últimas no se importan directamente a un proyecto, sino que son utilizadas indirectamente por un componente de software. En efecto, son dependencias de dependencias directas. Google explicó En ese momento, esta fue la razón por la que no se descubrieron tantas instancias de Log4j.

“Cuanto más profunda sea la vulnerabilidad en una cadena de dependencia, más pasos se requieren para solucionarla”, señaló.

Brian Fox, director de tecnología de Sonatype, explica que la “mala gestión de la dependencia” en las empresas es una fuente importante de riesgo de ciberseguridad de código abierto.

“Log4j es un gran ejemplo. Descubrimos que el 13% de las descargas de Log4j son de versiones vulnerables, y esto es tres años después de que se aplicara el parche a Log4Shell”, comenta a ISMS.online. “Este tampoco es un problema exclusivo de Log4j: calculamos que, en el último año, el 95% de los componentes vulnerables descargados ya tenían una versión corregida disponible”.

Sin embargo, el riesgo del código abierto no se limita a las posibles vulnerabilidades que aparecen en componentes difíciles de encontrar. Los actores de amenazas también están instalando activamente malware en algunos componentes de código abierto con la esperanza de que se descarguen. Sonatype descubrió 512,847 paquetes maliciosos en los principales ecosistemas de código abierto en 2024, un aumento anual del 156%.

Desafíos sistémicos

Log4j fue solo la punta del iceberg en muchos sentidos, como revela un nuevo informe sobre Linux. Señala varios desafíos importantes para toda la industria con los proyectos de código abierto:

Tecnología heredada: Muchos desarrolladores siguen confiando en Python 2, a pesar de que Python 3 se introdujo en 2008. Esto genera problemas de incompatibilidad con versiones anteriores y software para el que ya no hay parches disponibles. Las versiones anteriores de los paquetes de software también persisten en los ecosistemas porque sus reemplazos a menudo contienen nuevas funciones, lo que las hace menos atractivas para los usuarios.

Falta de un esquema de nombres estandarizado: Las convenciones de nomenclatura para los componentes de software son “únicas, individualizadas e inconsistentes”, lo que limita las iniciativas para mejorar la seguridad y la transparencia.

Un grupo limitado de colaboradores:

“Algunos proyectos de OSS ampliamente utilizados son mantenidos por una sola persona. Al revisar los 50 proyectos principales que no son de NPM, el 17 % de los proyectos tenían un desarrollador y el 40 % tenía uno o dos desarrolladores que representaban al menos el 80 % de las confirmaciones”, le dice el director de seguridad de la cadena de suministro de código abierto de OpenSSF, David Wheeler, a ISMS.online.

“Un proyecto con un único desarrollador tiene un mayor riesgo de abandono posterior. Además, tienen un mayor riesgo de negligencia o inserción de código malicioso, ya que pueden carecer de actualizaciones periódicas o revisiones por pares”.

Bibliotecas específicas de la nube: Esto podría crear dependencias de proveedores de la nube, posibles puntos ciegos de seguridad y bloqueos de proveedores.

“La principal conclusión es que el código abierto sigue aumentando en importancia para el software que impulsa la infraestructura en la nube”, afirma Fox de Sonatype. “Ha habido un crecimiento exponencial en términos de uso del código abierto, y esa tendencia solo continuará. Al mismo tiempo, no hemos visto que el apoyo, financiero o de otro tipo, para los mantenedores de código abierto crezca para igualar este consumo”.

Lenguajes que no son seguros para la memoria:La adopción del lenguaje Rust, seguro para la memoria, está creciendo, pero muchos desarrolladores aún prefieren C y C++, que a menudo contienen vulnerabilidades de seguridad de memoria.

Cómo puede ayudar la ISO 27001

As Herve Beraud, colaborador de Red Hat, señala:Deberíamos haber previsto la llegada de Log4Shell porque la utilidad en sí (Log4j) no había sido sometida a auditorías de seguridad periódicas y solo la mantenía un pequeño equipo de voluntarios, un riesgo destacado anteriormente. Sostiene que los desarrolladores deben pensar con más cuidado en los componentes de código abierto que utilizan y plantearse preguntas sobre el retorno de la inversión, los costes de mantenimiento, el cumplimiento legal, la compatibilidad, la adaptabilidad y, por supuesto, si se prueban periódicamente para detectar vulnerabilidades.

Los expertos también recomiendan herramientas de análisis de la composición del software (SCA) para mejorar la visibilidad de los componentes de código abierto. Estas ayudan a las organizaciones a mantener un programa de evaluación y aplicación de parches continuos. Mejor aún, considere un enfoque más integral que también cubra la gestión de riesgos en todo el software propietario. La norma ISO 27001 ofrece un marco estructurado para ayudar a las organizaciones a mejorar su postura de seguridad de código abierto.

Esto incluye ayuda con:

• Evaluaciones de riesgos y mitigaciones para software de código abierto, incluidas vulnerabilidades o falta de soporte
• Mantener un inventario de software de código abierto para ayudar a garantizar que todos los componentes estén actualizados y seguros.
• Controles de acceso para que solo los miembros autorizados del equipo puedan usar o modificar software de código abierto
• Políticas y procedimientos de seguridad sobre el uso, monitoreo y actualización de componentes
• Gestión de relaciones con proveedores para garantizar que los proveedores de software de código abierto cumplan con los estándares y prácticas de seguridad
• Gestión continua de parches para abordar vulnerabilidades de seguridad en software de código abierto
• Procesos de gestión de incidentes, incluida la detección y respuesta a vulnerabilidades o infracciones derivadas de código abierto.
• Promoción de una cultura de mejora continua para mejorar la eficacia de los controles de seguridad
• Capacitación y concientización para que los empleados comprendan los riesgos asociados con el software de código abierto

Hay mucho más que se puede hacer, incluidos los programas gubernamentales de recompensas por errores, las iniciativas educativas y la financiación comunitaria por parte de gigantes tecnológicos y otros grandes usuarios empresariales de código abierto. Este problema no se resolverá de la noche a la mañana, pero al menos las cosas han empezado a ponerse en marcha.