Es un mundo salvaje ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta node_modules?

Hola y bienvenidos. Gracias por venir a mi charla. Es una jungla ahí afuera. ¿Qué está realmente sucediendo dentro de su carpeta de módulos de Node? Soy Ferras y soy un mantenedor de código abierto. Comencé WebTorrent, que es un protocolo de transferencia de archivos peer to peer, y Standard JS, un linter que atrapa errores y aplica un estilo de código. He estado trabajando en código abierto desde 2014 y he creado más de cien paquetes npm. En el pasado, fui voluntario en la junta directiva de Node.js y también enseño una clase sobre seguridad web en la Universidad de Stanford. Ahora soy el fundador de una startup llamada Socket, que ayuda a proteger el ecosistema de código abierto. Antes de comenzar, permítanme contarles una historia. El 13 de enero de 2012, hace más de diez años, un desarrollador llamado Faisal Salman publicó un nuevo proyecto en GitHub. Se llamaba UAParserJS y analizaba cadenas de agente de usuario. Ahora, mucha gente encontró este proyecto útil, y así, durante los siguientes 10 años, Faisal continuó desarrollando el paquete, con la ayuda de muchos colaboradores de código abierto. Publicó 54 versiones a medida que el paquete crecía en popularidad. Eventualmente llegó a tener 7 millones de descargas por semana, eventualmente

Ahora este es el script en Windows. Es muy similar. Comienza descargando ese mismo o un minero de Monero similar, pero también descarga un archivo DLL y lo ejecuta. Y aquí pueden ver cómo se inicia el minero de Monero y se registra el archivo DLL en Windows. Ahora, ¿qué hace este archivo DLL adicional? Bueno, roba contraseñas de más de cien programas diferentes en la máquina con Windows, así como todas las contraseñas en el Administrador de credenciales de Windows. Así que, vaya, este es un malware realmente desagradable. Y cualquier persona que tuviera la mala suerte de ejecutar esto perdió todas sus contraseñas y tuvo que hacer un restablecimiento completo de sus cuentas en línea. No fue un buen momento. Así que este es el resultado. Este paquete fue

Entonces, en 2022, creo que esto ya no es suficiente. No podemos simplemente escanear vulnerabilidades conocidas y detenernos ahí. Y sin embargo, eso es lo que hacen la mayoría de los productos populares de seguridad de la cadena de suministro, dejándote vulnerable. La cuestión es que puede tomar semanas o meses para que se descubra, informe y detecte una CVE o una vulnerabilidad conocida por las herramientas. Y simplemente no es lo suficientemente rápido. Así que puede valer la pena tomar un minuto aquí para distinguir rápidamente entre vulnerabilidades conocidas y malware porque son muy diferentes. Las vulnerabilidades son introducidas accidentalmente por los mantenedores, por los buenos, y tienen diferentes niveles de riesgo. A veces está bien enviar intencionalmente una vulnerabilidad conocida a producción si tiene un impacto bajo. Incluso si tienes vulnerabilidades en producción, es posible que no se descubran o exploten antes de que actualices a una versión corregida. Así que generalmente tienes tiempo para abordar este tipo de problemas. Ahora, el malware, por otro lado, es bastante diferente. El malware es introducido intencionalmente en un paquete por un atacante, casi nunca por el mantenedor. Siempre terminará mal si envías malware a producción. No tienes unos días o semanas para mitigar el problema. Necesitas detectarlo realmente antes de instalarlo en tu computadora portátil o en un servidor de producción. Pero en la cultura actual de desarrollo rápido, una dependencia maliciosa puede actualizarse y fusionarse en muy poco tiempo. Desafortunadamente, esto conduce a un mayor riesgo de ataques a la cadena de suministro. Porque cuanto más rápido actualices tus dependencias, menos ojos habrán tenido la oportunidad de revisar el código. Realmente creo que necesitamos un nuevo enfoque para detectar y bloquear dependencias maliciosas.

Pero antes de entrar en eso, pero antes de entrar en eso, echemos un vistazo más profundo a cómo funciona realmente un ataque a la cadena de suministro y su mecánica. Así que descargamos cada paquete en npm y pasamos unas semanas investigando. La descarga fue de 100 gigabytes de metadatos y 15 terabytes de paquetes comprimidos. Mientras investigábamos estos metadatos y todos estos paquetes, notamos algunas tendencias en los tipos de ataques que vimos. Así que voy a repasar estos ataques. Esto es lo que encontramos.

Entonces, hay vectores de ataque, que es cómo el atacante te engaña y logra que ejecutes su código en primer lugar. Y luego hay tácticas de ataque, que es lo que realmente hace el código de ataque o las técnicas que el atacante utiliza para ocultar su código. Así que hablemos de los vectores de ataque. El primer y más común vector de ataque es el typo-squatting. El typo-squatting es cuando un atacante publica un paquete que tiene un nombre muy similar al de un paquete legítimo y popular. Así que aquí puedes ver que hay dos paquetes con nombres muy similares y uno de ellos es malware y el otro es el paquete real. Pero supongo que sería difícil para ti saber eso sin abrir estos paquetes y ver qué hay dentro. Así que abramos el paquete de malware y veamos qué está haciendo. Aquí puedes ver que nuevamente está utilizando un script de instalación, que es una técnica muy común que utiliza el malware. Y si abres este script de instalación para ver el código, verás que el archivo está altamente ofuscado. Pero puedo decirte que, incluso sin saber exactamente qué hace este código, puedes apostar que no es algo que quieras ejecutar en tu máquina.

El siguiente vector de ataque que vimos se llama confusión de dependencias. Esto está bastante relacionado con el typo-squatting. La confusión de dependencias ocurre cuando una empresa publica paquetes en un registro interno de NPM y utiliza un nombre que aún no ha sido tomado en el registro público de NPM. Y luego, más tarde, un atacante puede registrar un paquete con el mismo nombre que la versión pública y confundir las herramientas internas para que instalen accidentalmente la versión pública. Por eso se llama ataque de confusión de dependencias. Al revisar los paquetes de NPM eliminados recientemente, pudimos encontrar un montón de ataques de confusión de dependencias probables, y la mayoría de estos paquetes tenían código malicioso. Todos estos paquetes tienen nombres que parecen entrar en conflicto con los nombres de los paquetes internos de la empresa. Y aquí puedes ver que muchas organizaciones diferentes, incluidos gobiernos, se vieron afectados por esto. Y aquí hay algunos más, claramente dirigidos a estas empresas específicas en esta lista.

Y finalmente, el tercer vector que vemos mucho son los paquetes secuestrados. Estos son los que generalmente se ven mucho en las noticias. Ya sabes, criminales y ladrones que encuentran formas de infiltrarse en nuestras comunidades e infectar paquetes populares. Una vez que infectan un paquete popular, ya sabes, una vez que lo controlan y pueden publicar en él, robarán credenciales o instalarán puertas traseras o abusarán de los recursos informáticos para la minería de criptomonedas.

Y así, sabes, estas son, sabes, estas ocurren por diversas razones. A veces es porque el mantenedor elige una contraseña débil o reutiliza la contraseña o tal vez el mantenedor tiene malware en sus computadoras portátiles. Esto también no es ayudado por el hecho de que NPM no exige la autenticación de dos factores para todas las cuentas actualmente, aunque están comenzando a exigir esto para las cuentas más populares. Y finalmente, a veces los mantenedores simplemente son engañados y dan acceso a un actor malicioso. Esto se debe en parte al hecho de que los mantenedores están sobrecargados y cuando alguien ofrece ayuda, a veces es difícil decir que no a la ayuda. Así que este también es un gran vector.

Ahora hablemos de algunas tácticas de ataque. Entonces, ¿qué hace realmente este código de ataque? Como mencionamos, los scripts de instalación son un gran vector. La mayoría del malware se encuentra en los scripts de instalación. Y así, esta es una cita de un artículo que mencionamos anteriormente, así que la mayoría de los paquetes maliciosos, en realidad el 56% comienza sus rutinas al momento de la instalación, lo cual puede ser debido a un manejo deficiente del código arbitrario durante la instalación. Entonces, en el administrador de paquetes npm, se permite que los paquetes simplemente digan, `oye, cuando se instala este paquete, queremos ejecutar algún código`. Y así, desafortunadamente, los scripts de instalación tienen algunos usos legítimos, por lo que no podemos desactivarlos. No es un problema fácil de resolver. Así que echemos un vistazo, solo a un ejemplo, otro ejemplo de un script de instalación. Nuevamente, lo verás aquí mismo en el archivo package.json. Muy común. Sí, entonces, el siguiente es el uso privilegiado de API. Vemos paquetes que acceden a la red, acceden al sistema de archivos, y acceden a las variables de entorno. Esto es muy, muy común porque cuando un atacante ejecuta código, lo que quieren hacer generalmente es robar algunos secretos, y necesitan la red para extraer esos secretos. Entonces, este es un ejemplo típico de malware que hace eso. Entonces puedes ver aquí que está haciendo una solicitud HTTP a una dirección IP, y está enviando algunos data. Los data que está enviando son process.env, que contiene todas las variables de entorno en el entorno. Y luego aquí hay realmente otro archivo que incluye, que es una técnica de exfiltración diferente que utiliza DNS en lugar de HTTP. Entonces, la forma en que funciona es que crea un resolvedor DNS, y luego realiza una, recopila las variables de entorno y luego realiza una búsqueda DNS con esas variables como subdominio. Así que es otra forma de sacar los data del sistema. Y finalmente, tenemos el código ofuscado. Así que echamos un vistazo a un ejemplo de esto anteriormente. Entonces, el código ofuscado como este es, obviamente, muy difícil de ver a simple vista qué está haciendo, aunque existen herramientas para intentar desofuscar código como este. También hay otro tipo de ofuscación, que es que los atacantes pueden publicar un código diferente en NPM que en GitHub. Y así, sabes, cuando hacen eso, como mencioné anteriormente, NPM no facilita ver qué código está realmente en el paquete de NPM.

Y así, mucha gente que intenta evaluar un paquete se basará en el código que está en GitHub, y no hay garantía de que ese código sea el mismo. OK, ahora hablemos de cómo puedes proteger tu aplicación. Entonces, sabes, nos hicimos esta pregunta, cuando estábamos trabajando en, mi empresa estaba trabajando en un producto llamado Wormhole, que te permite compartir archivos con cifrado de extremo a extremo. Y nuestro objetivo era intentar construir la forma más segura y privada de enviar archivos. Así que, sabes, hicimos todas las cosas de security habituales que se nos ocurrieron. Sabes, pensamos en security desde el principio del proceso de design. Escribimos pruebas, hicimos revisiones de código, y fuimos bastante cuidadosos con las dependencias que elegimos usar. Pero, sabes, aún sentíamos que podíamos hacerlo mejor. Y así comenzamos a pensar muy cuidadosamente en este problema y en lo que podíamos hacer para mejorarlo.

Entonces, el primer tipo de cosa que recomiendo es que simplemente intentes elegir mejores dependencias. Sabes, si implementas código en producción, eres en última instancia responsable de él. Y sabes, como industria, creo que necesitamos un cambio de mentalidad aquí porque la gente asume que pueden simplemente instalar cosas de internet y que será seguro. Y no siempre es cierto. Y si estás enviando código a producción que incluye código open-source, entonces, en última instancia, ese código es parte de tu aplicación. Y, por lo tanto, eres responsable en última instancia del comportamiento de ese código. Y, ya sabes, la licencia de open-source más popular, la licencia MIT, literalmente dice esto en la licencia. Dice que el código open-source se proporciona tal cual sin garantía de ningún tipo. Y en ningún caso el autor será responsable de cualquier reclamo daño o responsabilidad. Y, ya sabes, aunque esto es legalmente cierto, la mayoría de las personas no piensan en su open-source de esta manera. Y creo que realmente necesitamos un cambio de mentalidad.

Lo otro es que muy pocos de nosotros realmente leemos el código que estamos enviando a producción. Por lo tanto, confiamos en otras heurísticas para ayudarnos a elegir dependencias. Tal vez, sabes, miramos si el código hace el trabajo. ¿Tiene una licencia open-source? ¿Tiene buena documentación? ¿Tiene muchas descargas y estrellas en GitHub? ¿Tiene commits recientes? ¿Tiene tipos? ¿Tiene pruebas? Y realmente no estamos profundizando en el código más allá de esto.

Entonces, lo que eso significa es que no somos conscientes de lo que el código puede estar haciendo. Y así, construimos una herramienta en Socket para ayudar con este problema. Así puedes obtener rápidamente una idea de la seguridad de un paquete. Y así es como se ve. Entonces, puedes ir a Socket y buscar paquetes para averiguar qué comportamiento tiene el paquete. Y en este ejemplo aquí, puedes ver que este paquete contiene scripts de instalación y eso se destaca de manera muy prominente en la página. Es lo primero que ves. Y este paquete también contiene código binario o nativo, lo que significa que no es fácil auditar el código. No es legible para humanos. Y así, ambos problemas se destacan. Y en este caso, no es necesariamente... Esto no es un ataque a la cadena de suministro en ningún sentido, pero es bueno que esto se destaque de manera muy prominente para que puedas tomar una decisión informada si quieres usar este paquete o no. También puedes ver que tenemos puntuaciones de calidad muy útiles que aparecen en la parte superior de la página también.

Ahora, veamos otro ejemplo. Entonces, este paquete aquí, Angular calendar, es bastante útil. Es un componente de calendario que aparece en la página y muestra un pequeño calendario. Pero si profundizas en sus dependencias, descubrirás que algunas de sus dependencias están haciendo cosas bastante invasivas. Así que aquí verás que una de sus dependencias contiene scripts de instalación. También ejecuta scripts de shell y accede al sistema de archivos y a la red. Entonces, esto probablemente no es algo que esperarías que un componente web hiciera, por lo que puede valer la pena investigar un poco más para averiguar qué está pasando aquí antes de usar este paquete. Lo otro que hacemos y que es bastante interesante es resaltar cuando los paquetes hacen estas cosas y ponerlo directamente en línea en el código. Entonces, en este paquete aquí, lo abrí para ver los archivos y pude ver aquí que el módulo accede a la red y también accede a las variables de entorno, y puedo ver las líneas exactas donde el paquete está haciendo cada una de estas cosas. Y así, se vuelve un poco más fácil tener una idea de lo que hace un paquete antes de ejecutarlo. Entonces, si quieres investigar paquetes en Socket antes de usarlos, esta es la URL que puedes usar y te recomiendo encarecidamente que eches un vistazo a algunos paquetes allí y uses esa información para tomar una decisión informada antes de seleccionar un paquete.

De acuerdo, lo otro que puedes hacer es considerar actualizar tus dependencias en el momento adecuado. Entonces, ¿qué quiero decir con esto? Bueno, hay una pregunta sobre qué tan rápido debes actualizar tus dependencias y esta es en realidad una pregunta con la que también luchamos en nuestro equipo. Entonces, si, ya sabes, puedes pensarlo como ¿deberíamos actualizar lentamente o deberíamos actualizar muy muy rápido y de manera agresiva? Si actualizas demasiado lentamente, estás expuesto a vulnerabilidades conocidas y estás ejecutando código antiguo que puede tener problemas, puede tener algunos errores que se han solucionado en la versión más reciente y así que hay algunas desventajas de actualizar demasiado lentamente.

Por otro lado, si actualizas demasiado rápido, te expones a ataques a la cadena de suministro porque ahora estás ejecutando código que puede haber sido publicado, literalmente, ayer o en los últimos días, lo que significa que no has tenido tantos ojos capaces de revisar el código y, por lo tanto, al pensar en la seguridad, debes equilibrar este compromiso y realmente no hay una solución perfecta aquí. Es simplemente un problema difícil.

Otra idea es auditar cada dependencia. Entonces, si estás construyendo una aplicación verdaderamente crítica en términos de seguridad, como lo estábamos haciendo con Wormhole, entonces una opción es leer literalmente cada línea de código de tus dependencias. Así que si nuevamente colocamos esto en un eje que va desde una auditoría completa en un extremo, leyendo cada línea de código, hasta YOLOing en el otro extremo, y con YOLOing me refiero a no hacer nada. ¿Con qué detalle debes auditar tus dependencias? Y lo que ves aquí es que estamos en la misma situación. Tenemos compromisos y realmente no hay buenas soluciones. Hacer una auditoría completa es algo que solo las empresas más grandes y ricas parecen hacer en la práctica. Es mucho trabajo. Por lo general, necesitas tener un equipo de seguridad que revise cada uno de estos paquetes y también debemos aprobarlos uno por uno y agregarlos a una lista de permitidos, lo que es realmente lento y costoso debido al tiempo y el esfuerzo que requiere. Por otro lado, no hacer nada e instalar lo que quieras sin siquiera mirar el código tiene sus desventajas. Significa que estás expuesto a ataques a la cadena de suministro. Es arriesgado. Y, ya sabes, una violación o una mala publicidad en términos de seguridad también puede ser costosa, especialmente a medida que los reguladores comienzan a tomar medidas más estrictas sobre este tema. Y así, este es otro compromiso difícil. ¿Qué haces? Y la mayoría de los equipos, creo, optan por no hacer nada, pero creo que esto es simplemente un problema difícil.

Entonces, una cosa que intentamos hacer cuando estábamos construyendo Wormhole es pensar en un punto intermedio. ¿Hay alguna forma de utilizar la automatización para hacer algo intermedio? Y lo que queremos hacer y lo que terminamos haciendo es utilizar la automatización para evaluar automáticamente todas nuestras dependencias para que podamos utilizar el análisis estático para examinar los paquetes y tratar de encontrar malware, código oculto, errores tipográficos, ataques de suplantación de identidad y cosas por el estilo. Y de esa manera, solo podríamos auditar manualmente los paquetes más sospechosos para que pudiéramos utilizar nuestros recursos limitados del equipo para examinar el código de los paquetes más sospechosos y esa es la forma más impactante en la que podríamos utilizar nuestro tiempo. Y así, esto me parece mucho mejor que un enfoque de todo o nada donde auditas todo o simplemente esperas lo mejor y no miras nada. Y luego, otra cosa que queríamos hacer es asegurarnos de que la información de seguridad se mostrara directamente en las solicitudes de extracción para que los desarrolladores de nuestro equipo tuvieran la capacidad de resolver los problemas de seguridad que veían antes de implementar en producción. Entonces, ¿cómo se ve esto en realidad? Este es el bot que creamos. Se implementa como una aplicación de GitHub que puedes instalar en tu repositorio de GitHub. Y cada vez que ve que se ha modificado el archivo package JSON o el archivo yarn.lock, echará un vistazo a la nueva dependencia que se ha agregado y ejecutará un informe completo de salud sobre esa dependencia y si se encuentran problemas, dejará un comentario con el problema que se descubrió. Y de esa manera, el desarrollador que revisa la solicitud de extracción puede verlo y prestar atención a este posible problema. En esta captura de pantalla, puedes ver que accidentalmente instalé el paquete browser list en lugar de browser's list, lo cual es en realidad un error muy fácil de cometer. Y en realidad, por esa razón, browser list, el tipo de paquete, tiene algo así como 700,000 descargas al año. Así que esto es realmente muy útil. Esto es lo que complementa tu proceso de revisión y es muy económico, ya que solo plantea problemas que realmente valen la pena tu atención y se ejecuta automáticamente. Entonces, si quieres probar esta aplicación, en realidad la hemos publicado para que cualquiera la use.

Es gratuito, por lo que puedes instalar nuestra aplicación de GitHub yendo a socket.dev y te recomiendo que lo pruebes y me digas qué piensas. Tiene muchas características geniales, por lo que realmente puede, ya sabes, bloquear errores tipográficos, como te mostré antes, pero también puede bloquear malware, detectar código oculto, detectar el uso privilegiado de API, como el uso de red del sistema de archivos, procesos secundarios, etc. Y también puede detectar actualizaciones sospechosas, es decir, actualizaciones que cambian significativamente el comportamiento del paquete. Así que tenemos muchas cosas que buscamos en los paquetes. En realidad, tenemos 70 detecciones en cinco categorías diferentes. Tenemos riesgo de cadena de suministro, calidad, mantenimiento, vulnerabilidades conocidas y licencia. Básicamente, escribimos reglas de análisis estático para todas estas detecciones. Puedes pensar en esto como un linter de alguna manera. Analiza el código del paquete y busca estos diferentes problemas. Intentamos enfocar todas las reglas en problemas que realmente quieres saber como usuario del paquete, y no en cosas que requieren mucho conocimiento de los detalles internos del paquete. Entonces, las cosas que encuentra deben ser accionables para ti como desarrollador que elige usar este paquete. Eso es lo que intentamos hacer en el desarrollo de nuestras reglas. Así que sí, si quieres probar esto, si quieres explorar nuestro sitio web y ver estos diferentes problemas, puedes probarlo en socket.dev. Y, ya sabes, lo hemos hecho gratuito para siempre en el código abierto. Y si tienes un repositorio privado, es gratuito mientras estamos en beta. Y, ya sabes, realmente quiero que la gente lo pruebe y comparta sus comentarios con nosotros. Porque este problema de seguridad de la cadena de suministro es grande y solo está creciendo. Y, ya sabes, realmente quiero que la comunidad comparta sus comentarios conmigo sobre esto. Y creo que juntos podemos hacer un buen trabajo mejorando la seguridad de la cadena de suministro en 2022 y hacer que 2022 no sea el año en que se destruya la cadena de suministro, sino más bien el año en que esté protegida mejor que nunca. Así que por favor comparte tus comentarios conmigo. Aquí está mi correo electrónico y mi Twitter. Y también estamos contratando en Socket si estás interesado en trabajar en este proyecto y ayudar a asegurar la cadena de suministro de software. Gracias por tu tiempo.

Entonces, la pregunta fue si uno de tus paquetes tiene un ataque a la cadena de suministro hoy, ¿tienes un proceso que lo detectará y bloqueará? Desafortunadamente, el 40% dice que no. El 33% no lo sabe. Y el 27% dice que sí. Estamos realmente contentos de que aproximadamente un tercio diga que sí, o tal vez un cuarto. ¿Era esto lo que esperabas? Me pregunto qué proceso están utilizando. Tal vez instalaron Socket durante la charla y tal vez lo agregaron a sus repositorios de GitHub para protegerse. O tal vez están utilizando algún otro proceso, como un escáner de vulnerabilidades, y tal vez porque creo que tal vez me preguntarás sobre esto, pero a veces hay un poco de confusión entre el escaneo de vulnerabilidades y la búsqueda de ataques a la cadena de suministro. Pero, ¿quién sabe? Tal vez tengan un proceso. No estoy seguro. Sí, fue un poco sorprendente. Sí, sí. Bueno, veamos en un mes o tal vez dos, cuando las personas hayan tenido la oportunidad de implementar Socket. ¿Cuántas personas seguirán respondiendo que no?

Entonces vamos a pasar a las preguntas del público. La primera es de Cici Miller. ¿Dónde encontraste 50 terabytes de almacenamiento? También quiere esto en su vida. Sí, actualmente estamos utilizando Amazon S3 para almacenar todos los paquetes comprimidos y básicamente hacer un clon completo de NPM. Originalmente, estábamos utilizando Backblaze porque tienen un almacenamiento un poco más barato. Tienen algo similar a S3, pero de todos modos, sí, es fácil. El almacenamiento en la nube es barato. Bueno, relativamente barato, supongo. No es barato si lo estás haciendo como un proyecto secundario, pero para una empresa, es algo asequible. Creo que estamos pagando un par de cientos de dólares al mes o algo así para almacenar todo en S3, así que no es demasiado loco. Para el desarrollo local, tenemos un servidor en nuestro apartamento que almacena el clon completo de todo localmente para poder hacer un desarrollo local rápido, pero no todos los desarrolladores del equipo de Socket tienen un clon completo de NPM localmente para trabajar. Por lo tanto, solo usan un subconjunto más pequeño cuando están desarrollando en Socket. Sí, exactamente, por lo que en el futuro podrías tener empleados remotos que trabajen con el subconjunto. CcMailer también dijo: `No es mi código, no es mi problema`. Se usa tan a menudo como una excusa para los problemas causados. Intento asegurarme de que sea un buen código antes de que llegue allí. No soy perfecto, pero atrapo la mayoría de los problemas temprano. Bueno, solo más una declaración que una pregunta, supongo.

Pero sí, es bueno escucharlo. Iba a decir que creo que la mentalidad de 'no es mi código, no es mi problema' es... Tal vez no entendí lo que estaba diciendo, pero creo que, como dije en mi charla, creo que al final del día, cuando implementas una aplicación, eres en última instancia responsable de todo lo que hace la aplicación. Quiero decir, sí, supongo que podrías decir que no había nada que pudiera haber hecho. No sabíamos que la dependencia iba a comportarse de esta manera. Así que no es mi culpa. Pero creo que ahora que Socket existe y ahora que creo que el problema de los ataques a la cadena de suministro es cada vez más prevalente, no sé si eso es una excusa realmente válida. No sé. Creo que definitivamente hay cosas que puedes hacer para que sea menos probable y al menos examinar los paquetes más sospechosos, los cambios más sospechosos que se realizan en los paquetes y analizarlos más de cerca. Entonces, sí, no sé. Creo que para ser un mejor desarrollador, para ser lo mejor que puedas ser, creo que parte de eso es tratar de pensar en cómo asegurarte de que los paquetes no estén comprometidos o secuestrados y hacer lo que puedas para ayudar. Sí. Sí. Y no es mi código, no es mi problema. Bueno, si estás agregando la dependencia, entonces es un poco tu código, ¿verdad? Entonces, se convierte en tu problema porque tu producto está roto o inseguro.

Entonces, pregunta de AntiTomic. Hola, para nosotros una charla increíble y muy útil. Gracias. También me gusta mucho cómo suena Socket. ¿Qué opinas de soluciones como la auditoría de NPM? ¿Y es mejor usar una solución como Socket y similares?

Bueno, supongo. Sí. Creo que la auditoría de NPM es excelente. Es genial tener informes de vulnerabilidades integrados directamente en NPM. Puede decirte cuando estás instalando paquetes que tienen vulnerabilidades conocidas. Pero diría que muchas personas ignoran la auditoría de NPM porque informa sobre muchas cosas. Debo admitir que muchos de mis proyectos e incluso probablemente Socket mismo tienen algunas vulnerabilidades de bajo impacto que informa la auditoría de NPM, y no tenemos una urgencia inmediata para solucionarlas porque las hemos analizado y hemos dicho, sabes, esto, sí, puedo ver cómo alguien podría usar esto para ralentizar nuestro servidor web, es decir, una denegación de servicio de expresiones regulares lentas es algo común que verás, donde es como, sabes, está alguna expresión regular lenta en el servidor, y alguien podría usar eso para ralentizar tu servidor, hacer que pase tiempo procesando una expresión regular pesada. Pero al final del día, ese tipo de cosas no suelen ser un problema en la práctica, porque, ya sabes, un atacante tiene que encontrarlo, tiene que explotarlo y tiene que usarlo en tu contra. Y probablemente, la mayoría de esas cosas ni siquiera son captadas por un atacante real. ¿Verdad? Pero no estoy diciendo que no debas intentar actualizar y eliminar eso de tu código. Obviamente, eso es bueno, debes hacerlo. Pero lo que quiero decir es que muchas veces, ya sabes, muchas aplicaciones tienen esos problemas, hay tantos de ellos. Y realmente, lo importante es solucionar los problemas de alto impacto y críticos y no preocuparse tanto por los de bajo impacto. Y hay tantos informes que se generan que, creo, si tuviera que decir lo que pienso sobre la auditoría de npm, es genial. Es increíble que esté creando conciencia sobre este problema. Es un poco ruidoso para mi gusto. Y creo que ha habido un poco de discusión en la comunidad sobre si la auditoría de npm es demasiado ruidosa para ser útil. ¿Es demasiado, cómo podemos mejorarla básicamente, para que sea más útil para los usuarios finales? Porque creo que ahora mismo, casi ves en cada instalación que haces que la auditoría de npm se quejará de algo, ¿verdad? Y en algún momento, como humano, simplemente comienzas a tener lo que llaman ceguera a las advertencias o ceguera a las alertas, simplemente ves la misma alerta tantas veces que comienzas a ignorarla, ¿verdad? Así que sí, creo que nuestro objetivo con Socket es, ya sabes, nos enfocamos en los ataques a la cadena de suministro, que son muy diferentes a las vulnerabilidades. Cuando ocurren, son muy malos. Son muy graves, es algo que quieres detectar antes incluso de ejecutar ese código en tu computadora. Y creo que queremos tener menos alertas, menos advertencias que la auditoría de npm. Pero cuando emitimos una advertencia, queremos que sea porque está sucediendo algo muy grave. Y queremos intervenir y proteger las aplicaciones de las personas. Así que sí, creo que pueden funcionar bien juntos. Solo creo que están haciendo cosas diferentes. Sí, no es una competencia. Es que trabajan uno al lado del otro y hacen

Muy bien. Es bueno escucharlo. Así que lo escuchaste aquí primero, si quieres continuar la conversación, puedes hacerlo en este sitio web con un bluebird. Muchas gracias por unirte a nosotros. Espero verte pronto de nuevo. Gracias, Mateen. Adiós.