Cómo abordar los desafíos de ciberseguridad del software de código abierto con la Linux Foundation

Snyk colaboró recientemente con la Linux Foundation para elaborar un informe sobre el estado del software de código abierto (OSS). El informe se basó en más de 550 respuestas a una encuesta y 15 entrevistas con especialistas en mantenimiento de proyectos OSS y ciberseguridad.

Tras la publicación del informe, especialistas de Snyk organizaron un seminario web con la Linux Foundation para analizar algunos de los hallazgos clave: Cómo abordar los desafíos de ciberseguridad del software de código abierto: panel de expertos. Entre los participantes del seminario web estuvieron Mic McCully (estratega de campo, Snyk), Matt Jarvis (director de relaciones con desarrolladores, Snyk) y Steve Hendrick (vicepresidente de investigación, Linux Foundation).

Sigue leyendo para descubrir cómo mejorar la seguridad y la sostenibilidad del código abierto.

Vulnerabilidades en la cadena de suministro de software

A medida que las cadenas de suministro de software se vuelven más complejas, la seguridad del código abierto es más importante que nunca. Por ejemplo, la mayoría del software actual tiene muchas dependencias indirectas o transitivas, que son difíciles de visualizar y evaluar desde la perspectiva de la seguridad de las aplicaciones.

Cuando los desarrolladores incorporan un paquete de código abierto, este suele hacer referencia a otros proyectos de código abierto. Así se crea una jerarquía, y los paquetes de niveles inferiores suelen llamarse dependencias indirectas o transitivas.

Según el informe reciente, cada proyecto OSS tiene, en promedio, 49 vulnerabilidades distribuidas entre 79 dependencias directas. Sin embargo, esto varía según el ecosistema: los proyectos de JavaScript tienen muchas más vulnerabilidades que los de Python, Go, Java y .NET.

También es importante saber dónde se encuentran esas vulnerabilidades dentro de los paquetes. El informe reveló que más del 40 % de estos problemas de seguridad se encuentran en dependencias indirectas, lo que significa que los equipos de desarrollo muchas veces no saben que están incorporando código vulnerable a sus proyectos.

Como hemos visto en Snyk, estas vulnerabilidades pueden estar muy profundamente anidadas. Algunos de estos problemas en la cadena de suministro de software suelen provenir de dependencias que están cuatro o cinco niveles más abajo.

La necesidad de SBOM y políticas de seguridad para OSS

Como los problemas de seguridad suelen estar ocultos en lo más profundo de árboles de dependencias complejos, cada vez más se habla de la idea

de crear una lista de materiales de software (SBOM). Las SBOM son registros formales de los componentes de un software y las relaciones de su cadena de suministro, cuyo objetivo es mejorar la transparencia.

La realidad es que necesitamos saber qué contiene un componente. Necesitamos entender qué tan útil es y si podemos confiar en él. Cuando hay dependencias transitivas, obtener esta información puede ser muy difícil.

Una de las razones por las que muchas empresas no están creando SBOM es la falta general de seguridad para el código abierto. De hecho, los resultados de la encuesta del informe revelaron que solo el 49 % de las organizaciones tiene una política de seguridad que aborda la seguridad del código abierto.

Sin una política de software de código abierto, no puedes gestionar los riesgos de forma eficaz. En realidad, no sabes lo suficiente sobre cómo actuar ante las vulnerabilidades, y eso perjudica tu postura de seguridad.

¿Cómo verifican las organizaciones la seguridad de los paquetes OSS?

Aunque el informe reveló que el 44 % de las empresas hace que sus desarrolladores examinen el código fuente en busca de vulnerabilidades, existen casi una docena de tipos de herramientas para hacerlo. Dos de las más populares son las pruebas estáticas de seguridad de aplicaciones (SAST) y el análisis de composición de software (SCA).

Otra forma habitual en que las organizaciones verifican la seguridad de los paquetes OSS es evaluarlos antes de adoptarlos. Buscan proyectos OSS con buenas calificaciones, una comunidad activa que publique cambios de código con frecuencia y una política de seguridad divulgada públicamente. Sin embargo, estos componentes aún podrían tener vulnerabilidades en sus dependencias transitivas si quienes mantienen el proyecto no implementan medidas de seguridad para OSS de forma proactiva.

Lo que empezamos a ver en toda la industria son nuevas formas de ofrecer información sobre la seguridad y la confiabilidad a quienes consumen software de código abierto. Empezamos con las estrellas de GitHub, pero ahora tenemos OpenSSF Scorecards y otras fuentes de información detallada.

El impacto de Log4Shell en la comunidad de Java

El informe también reveló hallazgos interesantes sobre la amplia vulnerabilidad Log4Shell en la comunidad de Java. En particular, el 79 % de los proyectos afectados por Log4Shell tiene más de una vulnerabilidad Log4Shell en su base de código, y el 60 % de los casos se encontró en dependencias indirectas.

Log4Shell dejó muy claro que los proyectos de código abierto pueden convertirse en víctimas de su propio éxito. Cuando una biblioteca de código abierto se usa en una gran variedad de proyectos, como Log4j, el impacto de los problemas de seguridad puede ser enorme. Esto puso en primer plano la necesidad de contar con herramientas de análisis SCA.

Cada vez es más difícil corregir las vulnerabilidades del código abierto

Las cadenas de suministro de software son cada vez más complejas, y para muchas organizaciones es cada vez más difícil tener visibilidad de la seguridad. Como resultado, también es más difícil corregir las vulnerabilidades del código abierto. De hecho, el tiempo para corregir vulnerabilidades aumentó de 49 días en 2018 a 110 días en 2021.

En el transcurso de tres años, el tiempo necesario para corregir vulnerabilidades se ha más que duplicado. Al mismo tiempo, han ocurrido otras dos cosas: 1) el uso y el desarrollo de software han crecido a un ritmo extraordinario; 2) dedicamos mucho más tiempo y atención a la seguridad.

Otro desafío que enfrentan las organizaciones ante el aumento de los tiempos de corrección es la falta de recursos. De hecho, algunas empresas están corrigiendo los problemas críticos más rápido que antes, pero las vulnerabilidades de baja prioridad se atienden demasiado tarde debido a la falta de recursos de seguridad de aplicaciones. Por eso, las herramientas SAST y SCA son las dos principales formas en que las empresas dicen abordar los problemas de seguridad.

Las herramientas de análisis SAST y SCA se pueden integrar en los pipelines de CI/CD y en el proceso de desarrollo para automatizar la detección y corrección de muchas vulnerabilidades de código abierto. Esto ayuda a las organizaciones a superar algunos de los desafíos relacionados con los recursos de seguridad de aplicaciones.

Existe una correlación muy fuerte entre la automatización de los pipelines de implementación y el tiempo que toma corregir los problemas de seguridad, porque cuando tienes un CI/CD totalmente automatizado, cuentas con muchos puntos de integración para incorporar verificaciones de seguridad.

El estado de la seguridad del código abierto en 2022

En esta conversación entre Snyk y The Linux Foundation se analizaron algunos hallazgos clave del informe, pero aún queda mucho por descubrir. Descarga el informe completo para conocer más sobre la complejidad y los riesgos del panorama actual de las cadenas de suministro de software: Estado de la seguridad del código abierto 2022.