Reutilización de software: 4 ideas para gestionar sus riesgos

Una de las formas clave en que las organizaciones de desarrollo de software impulsan la eficiencia es recurriendo a bibliotecas de componentes de software reutilizables existentes al momento de crear sus propios productos y servicios de software. 

Esto ayuda a acelerar la innovación digital, pero las ventajas vienen con un riesgo que muchas veces las organizaciones aceptan, a veces sin saberlo, lo cual puede generar serios problemas de ciberseguridad.

Cuida a tu empresa de los ataques hunting porque las debilidades en tu red saldrán a la luz

Ese riesgo se destacó en diciembre de 2021, cuando salió a la luz que un software de código abierto ampliamente utilizado llamado Log4j contenía una vulnerabilidad crítica. 

La noticia llegó a los titulares porque innumerables piezas de software implementadas en organizaciones, agencias gubernamentales y hogares dependen de este registro para el lenguaje de programación Java. 

Los expertos en seguridad descubrieron que los puntos vulnerables de Log4Shell, podrían tener consecuencias devastadoras para las empresas y las personas. 

También encontraron que la exposición era asombrosamente amplia: el código se había incrustado en los sistemas de software a gran escala, introduciendo una vulnerabilidad grave en muchos sistemas críticos en todo el mundo. 

La exposición de Log4j debería ser una llamada de atención para que los ejecutivos comprendan mejor la reutilización de software y cómo mitigar el riesgo de usarlo en sus organizaciones.

La reutilización de software se originó como una medida de eficiencia dentro de las grandes empresas de sistemas computacionales las cuales revestían un código ya existente con algunos hechos “en casa”. 

La llegada de Internet y la explosión del software de código abierto transformaron la práctica.

Hoy en día, la mayor parte del software se basa, al menos parcialmente, en la funcionalidad adquirida a través de componentes de externos. 

Estos componentes a menudo se comparten para el beneficio de todos en repositorios de código abierto, como PyPI para Python, NPM para Node.js y Maven Central Repository para Java, por nombrar algunos.

La principal ventaja para los desarrolladores que importan componentes de estos repositorios es que no tienen que asumir la propiedad del código ni asumir la responsabilidad de corregir errores o mejorar las funciones. 

Pueden concentrarse en escribir su propio software mientras se benefician del trabajo de otros equipos de desarrolladores. 

Además, es más fácil importar un paquete completo que seleccionar líneas de código específicas que, por lo general, deberán modificarse para que encajen en el propio código fuente. 

Un paquete es autónomo y está construido como una solución para su reutilización que los desarrolladores pueden tratar como una caja negra. 

La selección manual de líneas específicas de código significa tener que leer el código fuente de un paquete e identificar, copiar o reproducir partes de ese código fuente, lo que lleva más tiempo.

Jackpotting, el cibercrimen que afecta a los cajeros porque regala billetes

Haciendo balance de la reutilización a escala

Puede ser difícil para los líderes comprender hasta qué punto la reutilización se ha arraigado en las prácticas de desarrollo de sistemas computacionales.

Para ilustrar su omnipresencia, considere que Lodash, uno de los paquetes JavaScript de código abierto más populares disponibles en el repositorio de NPM, se descargó más de 2 mil millones de veces en 2021 (eso es más de 40 millones de veces por semana en promedio) y que otros 149,000 paquetes publicados en NPM dependen de él para funcionar. 

Chalk, otro paquete popular, se descargó más de 5,000 millones de veces en 2021 y más de 77,000 paquetes publicados en NPM dependen de él.

Algunos investigadores argumentan que escribir software ahora a menudo se trata más de escribir “códigos pegados” para unir piezas de componentes existentes en lugar de escribir conjuntos de instrucciones o algoritmos completamente nuevos. 

Los autores de un estudio reciente de la práctica observaron que “la industria del software está experimentando un cambio de paradigma. A diferencia del pasado, cuando la reutilización de los códigos era solo una anomalía, ahora se convirtió en la norma para cualquier proyecto importante de desarrollo de software”, un sentimiento compartido por muchos.

Para comprender la escala de este fenómeno, considera que por cada componente de software que un equipo elige reutilizar, existe una alta probabilidad de que este componente dependa de otros que también tienen sus propias dependencias. (Consulte “Dependencias de reutilización de software en principio y en la práctica”.)

Lo que esto significa es que cuando un desarrollador importa un solo componente, también conocido como dependencia en este contexto, se pueden incorporar docenas de otras dependencias al mismo tiempo. contenida dentro de ese único elemento como si fueran las muñecas rusas matryoshka. 

Como resultado, un gran proyecto de software puede depender indirectamente de miles de otros componentes creados y mantenidos por muchos equipos de desarrolladores, cada uno con sus propios intereses, objetivos y agendas.

En el caso de Log4j, sus desarrolladores reaccionaron rápidamente ante la vulnerabilidad, y una nueva versión estuvo disponible para su descarga en cuestión de días. 

Este es un testimonio de la capacidad de la comunidad de código abierto para moverse rápidamente cuando surgen problemas. 

Sin embargo, el verdadero problema para miles de organizaciones fue que luego pasó a ser responsabilidad de todos aquellos que usaban una versión vulnerable de Log4j en su software actualizar con una versión “parcheada” y administrar la resolución de incidentes con sus clientes. 

Si bien Log4Shell es sin duda una ilustración extrema del fenómeno, con frecuencia surgen informes sobre el descubrimiento de problemas en paquetes populares o problemas derivados del uso por parte de las organizaciones de paquetes de software obsoletos o de baja calidad para producir su propio software.

En algunos casos, se ha descubierto que estos problemas afectan a millones de dispositivos conectados que no se pueden actualizar fácilmente.

A pesar de estos resultados indeseables, las organizaciones tienen mucho que ganar con la reutilización que seguramente desempeñará un papel cada vez mayor en la práctica del desarrollo de software. 

Al mismo tiempo, los líderes deben ser conscientes de las implicaciones de su reutilización, incluso si no están en el negocio del desarrollo de software.

Aquí hay cuatro ideas clave para los líderes mientras consideran formas para que sus organizaciones gestionen los riesgos:

1. Considera las consecuencias

La reutilización de software puede aumentar la productividad a corto plazo, pero puede tener consecuencias a largo plazo.

Por ejemplo, si hay un error en un componente externo, su organización tendrá que esperar hasta que se corrija ese error para volver a implementar su propio software. 

Algunos proyectos de código abierto se benefician de una comunidad activa y comprometida de desarrolladores, como es el caso de Log4j. Pero también es posible que la comunidad que apoya el desarrollo de un componente pierda interés. 

Los desarrolladores clave pueden pasar a otros proyectos. Y si el desarrollo de un componente se estanca, es posible que tus desarrolladores tengan que lidiar con un paquete obsoleto. 

Al evaluar la idoneidad de un componente para su reutilización, tu equipo de desarrollo debe mirar más allá de las necesidades funcionales inmediatas. 

Deben investigar en la comunidad o la organización (incluida la tuya) el respaldo que tiene el proyecto, evaluar la capacidad de respuesta a errores o solicitudes de funciones de quienes desarrollaron el software originalmente y su historial general. 

Así podrás determinar si tu organización podrá contar con esa familia de códigos en el futuro.

Gamers, las víctimas favoritas de los ciberdelincuentes sufren más ataques

2. Mira más allá de las dependencias directas 

Si la práctica predeterminada en tu organización es buscar sistemáticamente componentes de software reutilizables para implementar la funcionalidad, es probable que tu software dependa de cientos, o miles, de componentes externos. 

Es importante mirar más allá de las dependencias directas para evaluar las dependencias indirectas que son consecuencia de una decisión de reutilización particular.

En algunos casos, valdrá la pena asumir los riesgos de adquirir dependencias indirectas, porque la funcionalidad obtenida ayudará a lograr los objetivos del proyecto.

Pero a veces una sola pieza del código depende de docenas de otros componentes externos. 

En esos casos, puede ser mejor implementar otro código con las funcionalidades que deseas adquirir y, si es necesario, elegir algunos componentes externos para ayudarte en el camino. 

Si bien esto puede implicar una carga de trabajo inicial más pesada, y puede sentirse como reinventar la rueda, a veces es la decisión más sensata, tanto desde el punto de vista comercial como técnico. 

El proceso de decisión de reutilización de su organización debe incluir una evaluación cuidadosa de la necesidad de una funcionalidad específica a la luz de las dependencias indirectas que conlleva.

3. Revisa periódicamente los componentes en uso 

Las decisiones de incluir componentes externos en el software deben revisarse regularmente como parte de la buena práctica de pago de la deuda técnica (definida como el costo de decisiones pasadas para elegir una solución conveniente sobre la mejor solución). 

A menudo se alienta a los equipos de software a participar en la refactorización, una práctica en la que el código fuente se reorganiza para reducir la deuda técnica acumulada en forma de métodos abreviados de codificación anteriores y soluciones alternativas, a fin de mejorar la productividad futura de los desarrolladores y hacer que el código sea más fácil de mantener. 

Desafortunadamente, la refactorización de código generalmente considera solo el código fuente interno, porque eso es lo que los equipos pueden controlar y modificar fácilmente.

Cuando tu equipo escribe código, a veces actualizan componentes externos. 

Con el tiempo, puede convertirse en un reflejo: si un componente ha servido bien a la organización durante meses, de manera predeterminada, el equipo confía en que la última versión se puede usar de manera segura y continúan construyendo alrededor de ese componente, incluso si eso significa tener que implementar o mantener soluciones alternativas para hacerlo. 

Desafortunadamente, esto puede contribuir a aumentar la deuda técnica con el tiempo. La refactorización ofrece una oportunidad para que los equipos reconsideren si aún quieren depender de un componente externo. 

Es importante mantenerse al tanto del desarrollo de un componente y su ruta, incluida la supervisión de posibles problemas y vulnerabilidades a lo largo del tiempo, para asegurarse de que sigue siendo una buena opción para sus necesidades. 

Durante las iniciativas de refactorización, la consideración cuidadosa de los componentes externos puede contribuir a reducir la deuda técnica y minimizar la acumulación de software que puede afectar la calidad del mismo y la productividad del desarrollador.

Ciberresiliencia, ¿qué es, cómo construirla y por qué es importante?

4. Debes saber en qué software se basa tu organización

Puede parecer simplista, pero saber qué software ejecuta tu organización, especialmente el software crítico desde el punto de vista operativo, es importante más allá de los requisitos de las auditorías de TI. 

El descubrimiento de Log4Shell condujo al cierre de los servicios de la Agencia de Ingresos de Canadá; sólo en la provincia de Quebec, se cerraron más de 4000 sitios web gubernamentales como medida preventiva.

Las agencias y organizaciones se vieron obligadas a suspender el acceso a los sistemas mientras realizaban un inventario de su software para evaluar si realmente estaban afectados por la vulnerabilidad. 

Log4j es tan omnipresente que las organizaciones que tenían aplicaciones Java en ejecución probablemente podrían asumir que Log4j se estaba utilizando en algún lugar y podría requerir parches.

Cuando se trata de software comercial, este problema debe ser manejado por tus proveedores de programas computacionales. 

Sin embargo, es importante asegurarse de que cuando seleccione proveedores, esté seguro de que responderán a los problemas que ocurran en sus productos, ya sea que estén vinculados a su propio código fuente o a los componentes que reutilizan. 

Pide a los proveedores que demuestren que tienen un buen control sobre las decisiones de reutilización, incluida la verificación adecuada de la calidad de su producto y el cumplimiento de los requisitos de licencia para reutilizar el software de código abierto. 

Tu organización necesita confiar no solo en el proveedor de software, sino también en los muchos otros equipos de desarrolladores remotos en los que se basa su código.

Los altos ejecutivos reconocen cada vez más que la resiliencia digital es un problema existencial para sus organizaciones. 

Corresponde a los líderes comprender los riesgos inherentes tanto a las prácticas modernas de desarrollo de software como a las decisiones de adquisición de programas empaquetados, y asegurarse de que su función de tecnología tenga buenos procesos para gestionar esos riesgos. 

Si bien la reutilización de estos elementos es fundamental para seguir el ritmo acelerado de la innovación digital, tiene el potencial de causar consecuencias generalizadas, imprevistas y dañinas.

Asegurarse de que la práctica se gestione con cuidado y considere las implicaciones a corto y largo plazo puede mitigar el riesgo que es inextricable de los beneficios.

ACERCA DEL AUTOR

Gregory Vial es profesor asociado de TI en HEC Montréal.

Síguenos en Google News