La vulnerabilidad me causa amzhiedad: guía de iniciación para resolver vulnerabilidades

La vida de un desarrollador de software es como una caja de bombones … deliciosa, entre nuestras actividades no solo se trata de hacer código sino de procurar el buen funcionamiento del software, a veces ese funcionamiento puede alterarse debido a la existencia de vulnerabilidades en nuestras dependencias.

Debemos de ser responsables con el código que usa nuestra aplicación aunque no sea el nuestro

Vulnerabilidad

Podríamos decir que una vulnerabilidad es una característica que alguien puede utilizar para alterar el funcionamiento normal de nuestra aplicación, dependiendo de que tan severa sea por el impacto que pueda tener en nuestra aplicación normalmente se catalogan en: Critical, High, Moderate y Low. Puedes ver más aquí

Esto ha sido tan importante que en las últimas versiones de npm al hacer una instalación se ejecuta un comando llamado npm audit, para mostrarnos las vulnerabilidades que hay en los paquetes que hemos instalados.

Tranquilo no hay nada que temer más que al miedo mismo … y a las serpientes gigantes, antes tenemos que entender la naturaleza del proyecto y como las dependencias afectan a este.

Les voy a poner un ejemplo, en un proyecto en el cual trabajo teníamos una dependencia que tenía otra dependencia con una vulnerabilidad con severidad High … pero era de Storybook en un aplicación frontend, si bien es mejor no tener vulnerabilidades la naturaleza de cómo se usa no afectaba en “nada” a mi aplicación y puedes permitirte ignorarla más adelante les contaré como estuvo ese rollo.

Resolviendo vulnerabilidades

Hay varios métodos para eliminar vulnerabilidades y no son cosas de otro mundo, si bien hay software como dependabot que hace Pull Requests a nuestros proyectos y nos permite no tener que lidiar con esta tarea,hay que entender que aún así no esta 100% libre de efectos no deseados en nuestro software.

El proceso que yo sigo es el siguiente:

• Correr npm audit
• Correr npm audit fix
• Analizar si vale la penar correr npm audit fix — force o usar npm update <package>
• Cambiar el resolution de mi package.json

Para comenzar vamos a correr el comando npm audit, este comando nos da información sobre quien depende del paquete vulnerable y a veces hasta como podemos solucionarlo

npm audit fix

Al obtener el reporte de npm audit a veces tenemos vulnerabilidades que pueden ser resueltas simplemente usando npm audit fix. Solo recuerden, el cambiar cualquier dependencia es un riesgo de romper algo, en teoría con semver nos indica si hay un breaking change, pero la teoría y la práctica suelen ser distintas a veces

Simplemente corremos npm audit fix y resolvemos estas vulnerabilidades.

npm update o npm audit — force

Algunas veces de este reporte puede ofrecernos otro tipo de soluciones, como el uso de npm audit — force, la razón por la cual tenemos que usar el — force es que el cambio puede incluir un breaking change tanto para dar un upgrade como para un downgrade, esto bien podría solucionar nuestro problema o traernos más.

Una problemática de usar npm audit — force es que podríamos afectar a más de un paquete.

En el siguiente ejemplo había una vulnerabilidad en una dependencia usada por un paquete llamado node-sass, este era usada por mi sass-loader para procesar sass usando webpack.

Para resolver este problema tenía 2 opciones (excluyendo el npm audit — force). Utilizar el comando npm update node-sass o reemplazar el paquete por uno sin vulnerabilidades que hiciera lo mismo, la verdad que node-sass ya está en decadencia así que decidí reemplazarla por otro paquete llamado sass.

Resolution

Hay veces que sentimos que el universo no nos quiere y por alguna razón del destino no puedes actualizar la dependencia porque es una subdependencia de un paquete que utilizas y no puedes cambiar la versión del paquete a una más actual porque incluso la última versión usa la dependencia vulnerable

Esto me pasó a mí y seguro en algún punto te va a pasar a ti, entonces tu dirás “sustituyamos el paquete por otro que haga algo similar” y yo te diré, “¿cambiar tu forma de trabajo por un paquete?”. Este caso me sucedió con Storybook, es una herramienta que al menos en el proyecto del que les hablo lo usamos para visualizar componentes y revisar su diseño a nivel desarrollo.

En este punto el npm audit — force no es opción, cambiar de paquete tampoco. Me cuestioné si realmente valía la pena arreglar eso ya que es algo que solo utilizamos a nivel desarrollo y jamás iba a ser parte del código del cliente o algo similar. Es un punto válido y me convencí de ello.

Solo tenía 3 vulnerabilidades y todas relacionadas con storybook: browserslist, glob-parent y trim.

Demasiada ansiedad, hasta que una voluntad y terquedad inquebrantable, 2 tacos y el opening de la temporada 4 de Baki me hicieron encontrar la solución resoluciones de dependencia selectiva, lo cual resolvía mi problema ya que podría sobreescribir la resolución e indicar que se resolvieran las dependencias que no tenían vulnerabilidades pero como es normal en la vida no todo es tán fácil ya que esto es exclusivo de yarn y yo uso npm.

Afortunadamente el don y la maldición del mundo de npm es que un paquete puede ser tu salvación o tu maldición, en esta ocasión este paquete resolvía mis problemas npm-force-resolutions

Pero no tan rápido como estar seguro de no estar un flashpoint (película de Flash), este paquete si bien ofrece la posibilidad de reescribir la resolución no permite hacerlo solo para ciertos paquetes, en ese caso lo que debemos hacer es usar el comando npm ls <package> y asegurarnos que ningún otro paquete lo utilice.

Normalmente npm audit te dice el rango de las versiones del paquete que poseen esa vulnerabilidad, pero no me garantiza que no haya otras en paquetes fuera de ese scope así que busqué en la base de datos de vulnerabilidades de snyk una versión sin vulnerabilidades.

Si todo esto sale bien podemos configurar este npm-force-resolutions con la esperanza de que hayamos eliminado las dependencias y el software siga funcionando de la manera esperada.

Lo primero es agregar la llave resolutions a nuestro package.json y especificar el nombre del paquete y la versión que se entregará.

resolutions configuration

Una vez hecho esto debemos configurar el script preinstall (adicionalmente agregue npm_config_yes) para que no saliera el prompt y se ejecute sin ningún problema

preinstall script

Y con esto llegamos al fin, espero les sirva y que den like, compartan, me sigan, encuentren el amor y escuchen mi podcast en anchor, spotify o apple podcast.