Todo sobre las dependencias

Muchas gracias por estar aquí. Mi nombre es Xuxa Ruiz. Soy de México y vivo en Suiza. Soy un Java Champion. Trabajo para una empresa, Jfrog.

La presentación de hoy trata sobre una parte clave de nuestro proceso de desarrollo de software, las dependencias. No necesitamos reinventar la rueda cada vez que queremos lograr un nuevo nivel de funcionalidad o entregar software más rápido. Queremos y reutilizamos software escrito por otros todos los días, dependencias de software. Y son una parte integral del ciclo de desarrollo de software. Se utilizarán en diferentes etapas, desarrollo, runtime o ejecución y testing. Pero no todas son iguales.

Así que les voy a presentar dos afirmaciones y ustedes me dirán si son verdaderas o falsas. Las dependencias son colecciones que contienen código probado de alta calidad que proporciona funcionalidad que requiere una experiencia significativa para desarrollar. Verdadero. Los gestores de dependencias como NPM han hecho posible que la funcionalidad casi trivial se pueda empaquetar y publicar. Verdadero. Estos son los dos extremos del espectro en términos de cómo se proporciona la funcionalidad mediante dependencias.

Sabemos que hay diferentes tipos de dependencias. Para esta charla súper rápida, solo las mencionaré. Bibliotecas de frameworks, modules de paquetes y recursos. Y tenemos un ejemplo muy claro en Angular, que es una plataforma, y React, que es una biblioteca. Por lo tanto, ya te están indicando el nivel de integración entre diferentes componentes funcionales y cuán unidos están. Y por otro lado, esta es una lista de micro-paquetes de NPM que son muy útiles.

Hemos discutido que hay diferentes tipos de dependencias, por lo que con esto también podemos comenzar a pensar en nuestro grado de necesidad, o nivel de dependencia. Podemos crear un mapa de cuáles de nuestras dependencias son cruciales, importantes, cosméticas, fácilmente cambiables o superfluas. Y todo esto nos ayudará a definir los cánones de actualización, el costo de migración o los esfuerzos de limpieza. Y esto es realmente importante durante el proceso de desarrollo y en circunstancias normales, cuando las dependencias están bien. Pero las cosas salen mal y generalmente salen mal. Por lo tanto, agregar una dependencia externaliza el trabajo de desarrollar ese código, diseñar, escribir, testing, depurar, y mantener a otra persona, a menudo a un programador desconocido. Y al usar ese código específico, nuestros programas quedan expuestos a todas las fallas y defectos que existan en nuestra dependencia.

Por ejemplo, en NPM, en marzo de 2016, hubo una disputa por el nombre. Fue eliminado tres horas después. El Registro de NPM lo publicó nuevamente e incluso cambió sus políticas. En febrero de 2018, hubo un problema con las versiones de NPM 5.7.0. Y en Linux, cuando ejecutas el comando sudo npm, cambió la propiedad del archivo del sistema. Así que rompieron la máquina. En julio de 2018, las credenciales de NPM de un mantenedor de Estlin-Scope fueron comprometidas. Por lo tanto, hubo un lanzamiento malicioso de Estlin-Scope en la versión 3.7.2. Y eso copió las credenciales de NPM de la máquina en la que se estaban ejecutando y las subió. En noviembre de 2018, se descubrió que se había agregado un paquete malicioso como dependencia a la versión 3.3.6 de EventStream. Este era un paquete plano de montaje de cadenas y contenía cargas encriptadas que robaban bitcoins de ciertas aplicaciones. En abril de 2020, un paquete pequeño llamado spromise hizo que muchas aplicaciones serverless se cayeran. En enero de 2022, creo que todos ustedes saben que el mantenedor de colors hizo cambios que imprimían texto basura en un bucle infinito. Y eso fue un problema. Más recientemente, compañías como la mía, jfrog, actualmente están actualizando y enviando información sobre paquetes maliciosos de npm que han aparecido. Así que esos son algunos de los más recientes. Pero con todos estos problemas, no desesperen, hay herramientas, por ejemplo, X-Ray, que es una herramienta de seguridad de aplicaciones adjunta a Artifactory que realiza análisis completamente automatizados en nuestros binarios y admite todos los tipos principales y profundiza realmente en los paquetes de dependencias que contienen imágenes, archivos zip, etc. Esta puntuación es más para los autores de código abierto, para que puedan ejecutar este proyecto y evaluará una serie de heurísticas importantes y le dirá cuáles son las áreas en las que debe mejorar en su proyecto de código abierto y los identificadores de riesgo, etc. Así que es realmente bueno para los mantenedores hacer mejoras. Aquí puedes descargarlo. Hay otro artículo realmente interesante de Russ Koss sobre cómo sobrevivir a las dependencias de software donde habla sobre diferentes tipos de preguntas sobre cómo tratamos las dependencias y cuáles son las características clave que debemos tener en cuenta al decidir si usar una dependencia específica o no. Pero realmente, hay una herramienta en el centro de toda esta discusión que es súper importante el gestor universal de Artifactory e incluso antes de unirme a JFrog, lo usaba y me encantaba, así que JFrog te brindará las capacidades de publicar en los diferentes repositorios, como vimos, tiene x-rays para escanear activamente todos tus binarios, escaneando profundamente todos tus binarios, obteniendo información de las nuevas advertencias y te ayuda en la gestión de roles, puedes tener tantos repositorios como desees, por lo que es muy fácil separar las preocupaciones, si quieres saber más sobre este tema, incluso con ejemplos en Artifactory y X-Ray, deberías consultar la masterclass, que ya ocurrió, lo siento, pero está grabada, así que ve a la página web y mírala, muchas gracias, estoy muy contento de que estuvieras aquí conmigo, espero verte pronto, adiós.