Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Blog TuxCareLos riesgos de una cadena de suministro de software de código abierto
por Artem Karasev
13 de junio de 2023 - Director de marketing de productos
El software de código abierto se ha convertido en un componente crucial del ecosistema de desarrollo de software. Se ha generalizado entre los desarrolladores de todo el mundo por sus ventajas, como la rentabilidad, la adaptabilidad y el apoyo de la comunidad.
El acceso a componentes de software preexistentes permite a las empresas impulsar sus procesos de desarrollo y lanzar sus productos al mercado mucho más rápidamente. Sin embargo, el creciente uso de paquetes de código abierto en el desarrollo de aplicaciones plantea cada vez más problemas de seguridad. En esta entrada del blog se analizan los retos que plantea la seguridad de una cadena de suministro de código abierto y cómo abordarlos.
El punto dulce para los atacantes
A medida que crece el uso del código abierto, los grupos de amenazas tienen la oportunidad de explotar la cadena de suministro de software para acceder a una amplia gama de objetivos que dependen de él.
Los ciberdelincuentes saben que muchas organizaciones desconocen el software de código abierto utilizado en sus sistemas y las vulnerabilidades presentes en esos componentes. En lugar de pasar mucho tiempo tratando de piratear el código personalizado de una organización, los hackers están utilizando exploits disponibles públicamente para atacar una amplia gama de organizaciones y encontrar sistemas con componentes de código abierto vulnerables que explotar.
Además, una de las principales razones por las que los ataques a las cadenas de suministro de código abierto tienen tanto éxito es la inmensa complejidad de los gráficos de dependencia.
El efecto Jenga
Cada paquete de código abierto tiene su propia cadena de suministro y puede depender de múltiples bibliotecas de código abierto de terceros. Estas bibliotecas de terceros suelen depender de otras bibliotecas, lo que da lugar a una cadena de interdependencias muy compleja.
Teniendo en cuenta el hecho de que las bibliotecas populares son ampliamente utilizadas por muchos paquetes de código abierto, una sola vulnerabilidad en una de ellas puede causar estragos en todo el ecosistema. Ya lo hemos visto muchas veces: desde una vulnerabilidad en la biblioteca de registro gratuita Log4j hasta uno de los casos más recientes, cuando un desarrollador de código abierto introdujo un código de ruptura en su popularísimo paquete npm colores.
Fuente: https://xkcd.com/2347/
No se puede proteger lo que no se ve
En un escenario perfecto, los equipos de ingeniería mantendrían una documentación exhaustiva del software de código abierto utilizado en la organización, también conocida como lista de materiales de software. Actualizarían esta documentación cada vez que se añadiera una nueva dependencia, lo que permitiría identificar fácilmente dónde y si se está utilizando una biblioteca concreta, como log4j.
Esta documentación también ayudaría a descubrir a tiempo los paquetes no mantenidos, ya que pueden introducir riesgos de seguridad adicionales. Sin embargo, a los desarrolladores les cuesta mucho trabajo documentar sistemáticamente los componentes de software. Al mismo tiempo, los equipos de seguridad de muchas organizaciones necesitan más visibilidad de las dependencias que utilizan sus empresas.
Perder el tiempo de comercialización
Teniendo en cuenta la complejidad de las cadenas de dependencia del software de código abierto, mantenerse al día de las últimas correcciones de vulnerabilidades e impulsar la innovación al mismo tiempo se convierte casi en una misión imposible.
Para garantizar la seguridad y el cumplimiento de la legislación, las empresas empezaron a aplicar activamente procesos formales de aprobación para introducir nuevos componentes de código abierto. En algunos casos, conseguir la aprobación de nuevos componentes puede llevar hasta un mes o más.
Al mismo tiempo, los jefes de producto, que deben equilibrar cuidadosamente sus recursos de desarrollo para mantener la competitividad, luchan por dar prioridad a las nuevas funciones frente al creciente número de vulnerabilidades que afectan a sus aplicaciones. Todo esto puede provocar un retraso significativo en el desarrollo y, a su vez, en el plazo de comercialización, que puede ser crítico y provocar, como mínimo, la pérdida de oportunidades.
El camino a seguir
Una de las posibles soluciones a los retos a los que se enfrentan las organizaciones con la seguridad de la cadena de suministro de software de código abierto es la práctica de gestionar de forma centralizada un repositorio de componentes de código abierto preaprobados y continuamente protegidos. Puede establecerlo usted mismo o asociarse con un proveedor de confianza que lo establezca y gestione por usted.
Acceder a un repositorio de este tipo le permitirá:
- Minimice los riesgos de seguridad asegurándose de que sus dependencias están libres de vulnerabilidades y código malicioso.
- Controle su gráfico de dependencias con una lista de materiales de software garantizada para cada paquete.
- Cumpla su política de aplicación de parches y los requisitos normativos estableciendo acuerdos de nivel de servicio fiables para las correcciones de seguridad.
- Acelere su tiempo de comercialización eliminando los excesivos procesos de aprobación y reduciendo su deuda técnica.
Un único repositorio de confianza de paquetes de código abierto verificados le permitirá seguir innovando al tiempo que mantiene automáticamente la seguridad de sus aplicaciones. Si está interesado en proteger su cadena de suministro Java, acceda ahora a nuestro repositorio gratuito de Java.
