Las empresas maduran su estrategia de seguridad para software de código abierto

Recomendados:  Informe. Tendencias tecnológicas 2022 Leer  Impacto económico de una plataforma de Comunicaciones unificadas Leer Empresas nativas digitales. Cómo elegir la tecnología correcta para mi empresa Leer

Muchas empresas están abandonando el enfoque tradicional de apostar por software propietario, debido a su coste elevado y a las limitaciones de interactividad con otras plataformas, que frenaban el desarrollo interno de aplicaciones. En su lugar, están optando cada vez más por software de código abierto (OSS), adoptando soluciones que facilitan el trabajo de los desarrolladores y aceleran la puesta en marcha de nuevas herramientas. Al tratarse de software de código abierto, basado en contribuciones externas, la seguridad ha sido una preocupación creciente entre las empresas y líderes de TI, lo que ha llevado a muchas organizaciones a establecer nuevas políticas de seguridad para estas herramientas, que guían a los desarrolladores en su uso.

Una encuesta realizada por la empresa de seguridad Snyk y la Linux Foundation revela que 7 de cada 10 empresas que cuentan con una política de software de código abierto confían en que el desarrollo de sus aplicaciones es muy seguro, o medianamente seguro. Y solo el 45% de las empresas que no han implementado estas políticas consideran que el proceso es algo menos que seguro. Pero esta investigación muestra que aquellas que sí disponen de una política de seguridad suelen desempeñarse mucho mejor en las medidas de preparación autoevaluadas.

Matt Jarvis, director de relaciones con desarrolladores de Snyk, explica que el software de código abierto ofrece beneficios importantes para el desarrollo de aplicaciones, pero las empresas deberían identificar sus desventajas y estar preparadas para afrontarlas. Dice que “si bien el código abierto es un mecanismo comprobado para la innovación y la creación de software de alta calidad, se está convirtiendo en una víctima de su propio éxito, en el sentido de que su ubicuidad lo ha convertido en 0un objetivo para los ataques a la cadena de suministro”.

Por ello, opina que las organizaciones deberían adquirir una mayor comprensión de los mecanismos bajo los que funciona el código abierto, lo que abarca la gobernanza y el código. Y cree que también deberían fortalecer su enfoque para la gestión de la cadena de suministro a través de herramientas y metodologías de seguridad para desarrolladores.

Otro dato que revela esta investigación es que las empresas más pequeñas son las menos avanzadas en la adopción de estas políticas y metodologías. Actualmente solo la mitad de las empresas disponen de una política de seguridad de código abierto para apoyar a los desarrolladores en el uso de los componentes y marcos, pero entre las pequeñas empresas el porcentaje de las que no siguen este camino es del 60%.

Los expertos atribuyen esta falta de priorización hacia la seguridad Open Source en las empresas emergentes y pequeñas a cuestiones económicas. Y Jarvis dice que “las organizaciones pequeñas tienen presupuestos y personal de TI reducidos, y las necesidades funcionales de la empresa a menudo tienen prioridad para que la empresa pueda seguir siendo competitiva”. Su encuesta revela que las principales razones para no abordar las mejores prácticas en seguridad de código abierto entre estas empresas son la falta de recursos y tiempo.

Por otra parte, existen diferencias en la seguridad que se busca y se aplica a los distintos lenguajes de programación. Así, las aplicaciones desarrolladas en .NET presentan el tiempo promedio de corrección de fallas más elevado, de hasta 148 días, seguido por JavaScript. En el otro extremo están las aplicaciones programadas en Go, que muestran el tiempo de parcheo más rápido, cifrado en unos 49 días de media.

El informe de Snyk destaca que, además, se está viendo una mayor cantidad de dependencias en las aplicaciones JavaScript, mientras que Phyton muestra la menor cantidad, con un promedio de 25 dependencias por proyecto. Explican que los grandes árboles de dependencias transitivas pueden complicar la resolución de vulnerabilidades, pero el número de dependencias no es una desventaja en sí, si la empresa cuenta con formas de rastrear las relaciones entre sus diferentes proyectos.

En su informe, Jarvis dice que “los paquetes de JavaScript tienden a tener un alcance más pequeño que otros ecosistemas, por lo que, si bien hay más, puede haber menos código para auditar en busca de posibles debilidades. La cuestión más importante es comprender las dependencias que está utilizando, en particular las transitivas que se presentan como dependencias de dependencias, y eso se reduce a usar las herramientas de seguridad adecuadas para escanear cosas”.

En cualquier caso, los datos recogidos en esta encuesta muestran que los diferentes lenguajes de programación presentan distintos grados de fallas. Así, un proyecto promedio de Java muestra más de 47 vulnerabilidades de gravedad alta y 28 de gravedad media. Mientras tanto, una aplicación escrita en JavaScript tiene de media 18 y 21 vulnerabilidades, respectivamente. Y Phyton solo presenta vulnerabilidades de menor gravedad, con una media de 20 por proyecto.

Pero cabe aclarar que esto depende de diferentes variables, como la complejidad de cada proyecto, la cantidad de desarrolladores implicados o la popularidad. Por ello, Jarvis, dice que es probable que muchos desarrolladores que se centran en proyectos altamente populares muestren más errores en su trabajo.

En cuanto a las estrategias y políticas de seguridad para el software de código abierto, esta encuesta señala que un 60% de las empresas maduras en la seguridad del software de código abierto confían en los avisos de vulnerabilidades emitidos por la industria. Y un 49% en las notificaciones de los responsables del mantenimiento de los paquetes.

La brecha más importante entre las empresas más maduras y las que no tienen políticas de seguridad de código abierto está en la monitorización automatizada, ya que solo un 38% de las empresas que no siguen esta estrategia utilizan algún tipo de monitorización automatizado, mientras que el porcentaje entre las empresas más maduras es del 60%.

Jarvis recomienda a las empresas menos avanzadas en este aspecto que implementen una política de seguridad de OSS, aunque sea básica, porque asegura que “existe una correlación entre tener una política y el sentimiento de afirmar que el desarrollo es algo seguro. Creemos que tener una política implementada es un punto de partida razonable para la madurez de la seguridad, ya que indica que la organización es consciente de los problemas potenciales y ha iniciado ese viaje”.