ClickCease Los riesgos de una cadena de suministro de software de código abierto

Tabla de contenidos

Únase a nuestro popular boletín

Únase a más de 4.500 profesionales de Linux y el código abierto.

2 veces al mes. Sin spam.

Los riesgos de una cadena de suministro de software de código abierto

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.

infreaestructura
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.

Resumen
Los riesgos de una cadena de suministro de software de código abierto
Nombre del artículo
Los riesgos de una cadena de suministro de software de código abierto
Descripción
Analicemos los retos que plantea la seguridad de una cadena de suministro de código abierto y cómo abordarlos. Lea sobre estos crecientes retos de seguridad
Autor
Nombre del editor
TuxCare
Logotipo de la editorial

Conéctese a un único repositorio de confianza de paquetes y bibliotecas Java verificados para mantener la seguridad de sus aplicaciones.

Acceso gratuito al repositorio

Conviértete en escritor invitado de TuxCare

Empezar

Correo

Únete a

4,500

Profesionales de Linux y código abierto

Suscríbase a
nuestro boletín