Hace unos días NPM liberó la versión 6 de su gestor de paquetes, que incluye una nueva herramienta para identificar vulnerabilidades en el árbol de dependencias de tu proyecto: npm audit.
Siempre que se instala un paquete con NPM en las versiones 5.10 o superiores, se muestra un conjunto de alertas automáticas cuando se está instalando paquetes con un riesgo de seguridad conocido. Esto es bastante interesante, ya que, por primera vez, vas a poder conocer de primera mano que problemas potenciales esconde en tu árbol de dependencias.
La incorporación de esta herramienta está relacionada con la adquisición por parte de NPM, Inc. de la empresa ^ Lift Security que desarrolló Node Security Platform (https://nodesecurity.io/). Este equipo ha aportado un conjunto de soluciones para mantener seguras los paquetes registrados en NPM.
¿Qué es npm audit?
npm audit un nuevo comando que realiza una revisión de seguridad del conjunto de dependencias de tu proyecto, tanto las directas (los paquetes que nosotros utilizamos), como las indirectas (los paquetes que utilizan los paquetes que nosotros utilizamos). Este análisis de árbol de dependencias busca paquetes con versiones donde existen vulnerabilidades conocidas y muestra un informe.
Para cada paquete que ha encontrado con problemas nos va a mostrar las vulnerabilidades con un informe más o menos de este tipo:
Moderate Memory Exposure Package tunnel-agent Patched in >=0.6.0 Dependency of node-sass [dev] Path node-sass > request > tunnel-agent More info https://nodesecurity.io/advisories/598
En el enlace que nos ofrecen, podemos consultar con mayor detalle de que problema se trata y la forma de solucionarlo, normalmente actualizando la versión del paquete.
Aunque no utilizamos npm audit directamente, cuando hacemos npm install nos va a mostrar un resumen de la situación que se encuentran las dependencias:
[!] 12 vulnerabilities found [481 packages audited]
Severity: 7 Low | 5 Moderate
Run `npm audit` for more detail
Si al instalar no se encuentra con ningún problema mostrará algo de este tipo:
[+] no known vulnerabilities found
Packages audited: 373 (0 dev, 50 optional)
Esto sólo funciona con las versiones 5.10 y 6 de NPM, por lo que, si quieres utilizarlo desde ahora mismo, deberías actualizar NPM con una orden de este tipo:
npm install npm -g
¿Qué hago si encuentro vulnerabilidades?
En la práctica hay tres situaciones muy diferentes. La primera es encontrar una vulnerabilidad en un paquete que usamos directamente, es decir, que tenemos su dependencia escrita en nuestro fichero `package.json` y existe una versión más moderna que soluciona el problema.
NPM nos va a proponer que actualicemos la versión en cuestión con un mensaje de este tipo:
# Run npm install --dev karma@2.0.2 to resolve 12 vulnerabilities SEMVER WARNING: Recommended action is a potentially breaking change
En este caso, tendremos que actualizar la versión de nuestra dependencia, comprobar que todo funciona como esperamos, ya que -en algunos casos- nos está dando un aviso de que ha cambiado de versión y puede haber cambiado el comportamiento de alguna funcionalidad del paquete.
Si el problema reside en una dependencia indirecta, es decir, es un problema de un paquete que utiliza internamente nuestro paquete o alguno de sus hijos, npm audit da sugerencias de este tipo:
# Run npm update ws --depth 4 to resolve 1 vulnerability
Lo más responsable sería solicitar al propietario del paquete que nosotros utilizamos que actualice sus dependencias. Por ejemplo, en esta incidencia que abrimos hace unos días en Github le pedimos al equipo que mantiene una aplicación que hiciera una corrección de sus dependencias. Afortunadamente, en unas pocas horas lo había corregido (una respuesta que no siempre se da con la esa velocidad).
Si no existe una versión que resuelva el problema, también tenemos que hablar con quien ha desarrollado el paquete que nosotros utilizamos. Si el problema es suyo, tiene un bug y debería -antes o después- solucionarlo. Si es de su árbol de dependencias, debería encontrar una alternativa.
¿Cómo afecta al ecosistema de paquetes?
En unos pocos días que lleva funcionando, estas alertas han empezado a provocar una avalancha de apertura de incidencias, ya que se ha despertado la conciencia de los desarrolladores sobre las vulnerabilidades de seguridad conocidas dentro de sus aplicaciones. Por ejemplo:
Un proyecto creado con create-react-app, en su última versión, muestra un mensaje de este tipo:
[+] no known vulnerabilities found
Packages audited: 14378 (0 dev, 332 optional)
Un proyecto creado con angular-cli, en su última versión, muestra alertas:
[!] 14 vulnerabilities found - Packages audited: 21351 (21329 dev, 1438 optional)
Severity: 10 Low | 4 High
Un proyecto creado con vue-cli, también en su última versión, muestra alertas, que incluyen 2 de nivel crítico:
[!] 21 vulnerabilities found - Packages audited: 12031 (12029 dev, 336 optional)
Severity: 11 Low | 1 Moderate | 7 High | 2 Critical
No es que de repente todo sea inseguro, es que ahora lo vemos con facilidad y por lo tanto nos sentimos inquietos ante estos avisos. Estas vulnerabilidades llevan tiempo siendo conocidas, pero es ahora cuando, gracias a npm audit se ponen plenamente de relieve. Los mensajes de alerta se pueden ocultar por configuración, pero esta es la técnica del avestruz: ocultar la cabeza y pensar que ya no hay peligro.
La intención de NPM es que a medio plazo nos encontremos con un registro de paquetes con mejor salud que el actual, que podamos confiar con mayor facilidad en nuestro árbol de dependencia y se elimine la sospecha de que dentro del enorme ecosistema de paquetes se esconde un alto riesgo de tener serios problemas de seguridad.
El efecto en red que produce la aparición de estas alertas empieza a ser significativo y en breve vamos a ver bastantes reacciones, por lo que la aparición de npm audit es un importante hito en el ecosistema Javascript.
Si quieres saber más sobre el tema, puedes consultar:
- https://docs.npmjs.com/getting-started/running-a-security-audit
- https://docs.npmjs.com/getting-started/about-audit-reports
Nota: si usas Verdaccio seguramente deberás utilizar npm audit de esta forma:
npm audit --registry https://registry.npmjs.org/
Novedades
HTTP2 para programadores. Enviar mensajes del servidor al cliente con Server Sent Event (sin WebSockets)
En esta charla, organizada por MadridJS, Pablo Almunia nos muestra cómo la mayoría de nosotros cuando oímos hablar por primera vez de HTTP2 nos ilusionamos con las posibilidades que presumiblemente se abrían para el desarrollo de soluciones web avanzadas y cómo muchos nos sentimos defraudados con lo que realmente se podía implementar.
En esta charla podemos ver cómo funciona el HTTP2, que debemos tener en cuenta en el servidor para hace uso de este protocolo y, sobre todo, cómo podemos enviar información desde el servidor al cliente de forma efectiva y fácil. Veremos con detenimiento cómo por medio de los Server-Sent Events (SSE) podemos recibir en el cliente datos enviados desde el servidor sin utilizar websocket, simplificando enormemente la construcción de aplicaciones con comunicación bidireccional.
Observables en Javascript con Proxies
En esta charla, organizada por MadridJS, Pablo Almunia nos habla de la observación reactiva de objetos en Javascript por medio de Proxy. Se describe paso a paso cómo funcionan los Proxies y en que casos pueden ser nuestro mejor aliado. Veremos que no hay que tenerles miedo, son bastante sencillos de utilizar, y nos ofrecen una gran abanico de posibilidades.
Aplicaciones JAMStack, SEO friendly y escalables con NextJS
En esta charla de Madrid JS, Rafael Ventura nos describe las funcionalidades clave de NextJS, nos muestra en vivo cómo desarrollar una completa aplicación JAMStack con Server Side Rendering (SSR) y Static Site Generation (SSG) y termina mostrando como publicar esta aplicación en Vercel.
Stencil JS: mejora el Time To Market de tu producto, por Rubén Aguilera
En esta charla Rubén Aguilera nos cuenta los problemas que tienen muchas empresas a la hora de sacar productos accesibles, vistosos y usables en el Time To Market que requiere Negocio y cómo podemos minimizar este tiempo gracias al DevUI con StencilJS para adecuar una aplicación de Angular a las exigencias del mercado en tiempo record.