para contribuir de manera inteligente de una forma u otra. Entonces, ¿qué ha sucedido en el mundo de
JavaScript o en el entorno de
NPM en los últimos años? Bueno, todos recordamos en marzo de 2016, un paquete llamado LeftBatch que era muy popular con muchas bibliotecas de
JavaScript. Después de una disputa de nombres, fue eliminado. Y causó tanta interrupción que
NPM tuvo que republicarlo tres horas después. Y después de este evento, cambiaron sus políticas de eliminación. El siguiente que salió en las noticias fue en febrero de 2018, hubo un problema con la versión 570 de
NPM. Resulta que en los sistemas Linux, cambió la propiedad del sistema de archivos. Así que, en realidad, rompieron las máquinas Linux En julio de 2018, las credenciales de
NPM de uno de los mantenedores de ESLint scope fueron comprometidas. Hubo una versión 372 en la que, en esta versión en particular, lo que sucedió fue que las credenciales de
NPM de la máquina que ejecutaba ESLint scope fueron robadas y subidas. En noviembre de 2018, se descubrió que había una nueva versión 336 de event stream. Este paquete en particular incluía un flat map strip que contenía una carga útil encriptada que robaba bitcoins de algunas aplicaciones. Y estos son los dos más recientes y tuve que agregar uno nuevo, pero veremos esa diapositiva en abril de 2020. Un pequeño paquete llamado ISPROMIS causó una interrupción en varias aplicaciones de lista. En enero de 2022, y probablemente hayas oído hablar de esto, el mantenedor de colors hizo cambios que imprimían texto basura en un bucle infinito. Y esto es lo que realmente le sucedió a Aron Schwartz. Y más recientemente, esto fue, déjame ver, esto fue a principios de este año, hubo algunos paquetes maliciosos de
NPM que robaron los tokens de puntuación. Y el más reciente, esto fue la semana pasada, y el desarrollador detrás de un paquete
NPM muy popular llamado node, IPC, lanzó una versión subatómica de la biblioteca. En realidad, esta versión en particular no fue descargada mucho hasta que el evangelista Rhea agregó el módulo a la dependencia. Bueno, en realidad la dependencia de node no era el paquete malicioso, sino que fue una dependencia que agregó Rhea evangelist a node PC, lo que hizo que por ejemplo,
Vue JS dependiera de él. Así que eso causó el problema. Entonces, aquí hay algunos problemas. Hay algunos problemas de seguridad y confianza en la comunidad. Hay algunos problemas de seguridad y confianza con el código que consumimos. Y hay herramientas que nos pueden ayudar. Y por supuesto, una de ellas y la vamos a probar ahora mismo, bueno, en unos minutos, es JFocusray, una herramienta de seguridad de aplicaciones adjunta a Artifactory, que realiza un análisis binario completo. Y no solo análisis binario, también verifica en profundidad todas las capas de todas las dependencias, por ejemplo, si tienes imágenes de
Docker, archivos zip o paquetes. La otra que te recomiendo es OWAS dependency check. Esto es algo mantenido por esta fundación, y te dirá qué dependencias tienen algún problema. La tercera, pero esto es más si eres un desarrollador de código abierto, o mantenedor o líder de proyecto. Scorecards es un proyecto que ejecuta diferentes heurísticas asociadas con la seguridad del software y asigna una puntuación. Así, de cero a diez. Y proporciona un informe, este informe se envía a la Linux Foundation y obtienen más información sobre el estado del código abierto y la seguridad en los proyectos de código abierto. Así que eso les ayuda. Y también ayuda a los posibles usuarios o consumidores de las diferentes bibliotecas. Así que te sugiero totalmente que las uses. Y finalmente, esto es más para comenzar las discusiones con tus gerentes o llevarlo aguas arriba. Hay un artículo en el ACMQ. Y trata sobre cómo sobrevivir a las dependencias de software. Y una de las cosas que menciona es que el costo esperado de tener un fallo en tu aplicación depende de la suma de todos los costos pero también de la probabilidad de que algo suceda como un riesgo. Así que dice que, para prevenir eso o reducirlo, deberíamos hacer algunas preguntas sobre cómo está o cuál es el estado de nuestras dependencias. En realidad, algunas de estas preguntas inspiraron el proyecto Scorecards, o al menos se intersectan. Así que, en primer lugar, debes verificar si hay documentación. Eso suele ser una buena señal, aunque a algunos desarrolladores no les gusta hacer documentación. A otros les encanta hacerlo, pero la documentación es importante. ¿Están bien diseñadas las API? ¿Hay un diseño claro, un diseño consistente? ¿Llamamos al parámetro de la misma manera en diferentes versiones? Bueno, no en esta versión, porque puede haber una ruptura, pero al menos en API similares en la misma versión, ¿puedes ver que hay un diseño claro en el conjunto de API o en la documentación? Calidad de código, tenemos que verificar eso. No estoy diciendo que ejecutemos un análisis de código estático en el código fuente de todas nuestras dependencias que estamos introduciendo, porque claramente tenemos dependencias directas y dependencias transitivas, pero nuevamente, en las que dependes mucho, esto es importante, porque va a doler más. Bueno, podemos entrar en esa discusión. Entonces, la calidad de código, ¿el código está bien escrito? ¿Es algo que te gustaría depurar en caso de que algo salga mal? Pruebas, ¿hay pruebas para esta biblioteca en particular? ¿Puedes ejecutarlas? ¿Pasaron? ¿Especifican la funcionalidad básica? Corrección de errores, ¿hacen un seguimiento de los errores, o el proyecto es como, oops, lo hice de nuevo, y tú lo resolverás ¿Cuántos informes de errores están abiertos? ¿Con qué frecuencia los cierran? ¿Responden? Mantenimiento, ¿con qué frecuencia se mantiene? ¿Con qué frecuencia? ¿Cuántas personas están trabajando en el paquete? Si es utilizado por una gran comunidad, es probable que si los líderes del proyecto tienen que renunciar,
Comments