¿Sabes qué está pasando realmente en tu carpeta node_modules? Los ataques a la cadena de suministro de software han explotado en los últimos 12 meses y solo están acelerándose en 2022 y más allá. Profundizaremos en ejemplos de recientes ataques a la cadena de suministro y qué pasos concretos puedes tomar para proteger a tu equipo de esta amenaza emergente.
Puedes consultar las diapositivas de la charla de Feross aquí.
This talk has been presented at Node Congress 2022, check out the latest edition of this JavaScript Conference.
FAQ
Firas es un mantenedor de código abierto, fundador de WebTorrent y StandardJS, y ha sido voluntario en la junta directiva de Node.js. Además, enseña sobre seguridad web en la Universidad de Stanford y es fundador de una startup llamada Socket.
UAParserJS es un proyecto creado por Faizal Salman que analiza las cadenas de agentes de usuario. Se volvió muy popular, alcanzando 7 millones de descargas semanales y siendo utilizado por casi 3 millones de repositorios de GitHub.
En octubre de 2021, el paquete uaparser.js fue comprometido y se publicaron tres versiones maliciosas que contenían malware. Este malware ejecutaba acciones malintencionadas en las máquinas de los usuarios que instalaron estas versiones.
Los principales vectores de ataque incluyen el typo squatting, la confusión de dependencia y los paquetes secuestrados. Estos métodos permiten a los atacantes distribuir código malicioso a través de paquetes que parecen legítimos o comprometiendo paquetes populares.
La cultura de confianza y las políticas de contribución liberales en el código abierto han acelerado la aparición de ataques, ya que los atacantes explotan esta confianza para distribuir malware y comprometer la cadena de suministro de software.
Firas sugiere adoptar un enfoque más cauteloso al seleccionar dependencias, realizar auditorías y utilizar herramientas de análisis automático para evaluar la seguridad de las dependencias antes de integrarlas, y mantener un balance entre actualizar rápidamente y asegurarse de que las nuevas dependencias sean seguras.
Socket es una startup fundada por Firas que se enfoca en proteger el ecosistema de código abierto al detectar y bloquear dependencias maliciosas, ofreciendo herramientas que permiten a los desarrolladores evaluar la seguridad y el comportamiento de los paquetes antes de utilizarlos.
La charla discute la importancia de la seguridad de la cadena de suministro en el ecosistema de código abierto, destacando los riesgos de confiar en el código de fuente abierta sin una revisión de código adecuada. Explora la tendencia de los ataques a la cadena de suministro y la necesidad de un nuevo enfoque para detectar y bloquear dependencias maliciosas. La charla también presenta Socket, una herramienta que evalúa la seguridad de los paquetes y proporciona automatización y análisis para proteger contra malware y ataques a la cadena de suministro. Enfatiza la necesidad de priorizar la seguridad en el desarrollo de software y ofrece ideas sobre posibles soluciones como los reinos y las banderas de línea de comando de Deno.
Hola y bienvenidos. Gracias por venir a mi charla. Es una jungla ahí fuera. Mi nombre es Firas, y soy un mantenedor de código abierto. Empecé WebTorrent y StandardJS. He estado haciendo código abierto desde 2014. 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. Permíteme contarte una historia. El 13 de enero de 2012, un desarrollador llamado Faizal Salman publicó un nuevo proyecto en GitHub. Se llamaba UAParserJS, y analizaba las cadenas de agentes de usuario. Durante los siguientes 10 años, Faizal continuó desarrollando el paquete, y eventualmente creció hasta 7 millones de descargas por semana, siendo utilizado por casi 3 millones de repositorios de GitHub. Ahora, permíteme contarte una historia diferente. El 5 de octubre de 2021, un hacker ofrecía vender la contraseña de una cuenta de NPM que controlaba un paquete con más de 7 millones de descargas semanales. Dos semanas después, uaparser.js fue comprometido, y se publicaron tres versiones maliciosas. Se añadió malware a estos paquetes que se ejecutaría inmediatamente cada vez que alguien instalara una de las versiones comprometidas. Ahora, echemos un vistazo a lo que hace ese malware. Utiliza un script de preinstalación que se divide en función del sistema operativo del objetivo. En Mac, no pasa nada, pero los usuarios de Windows y Linux no tienen tanta suerte.
Hola y bienvenidos. Gracias por venir a mi charla. Es una jungla ahí fuera. ¿Qué está pasando dentro de tu carpeta modules? Mi nombre es Firas, y soy un mantenedor de código abierto. Empecé WebTorrent y StandardJS. He estado haciendo código abierto desde 2014. 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 empezar, permíteme contarte una historia. El 13 de enero de 2012, hace más de 10 años, un desarrollador llamado Faizal Salman publicó un nuevo proyecto en GitHub. Se llamaba UAParserJS, y analizaba las cadenas de agentes de usuario. Mucha gente encontró útil este proyecto. Y así, durante los siguientes 10 años, Faizal continuó desarrollando el paquete, con la ayuda de muchos contribuyentes de código abierto. Publicó 54 versiones, a medida que el paquete crecía en popularidad. Eventualmente llegó a 7 millones de descargas por semana. Finalmente fue utilizado por casi 3 millones de repositorios de GitHub. Ahora, permíteme contarte una historia diferente. El 5 de octubre de 2021, en un notorio foro de hackers rusos, apareció esta publicación. Un hacker ofrecía vender la contraseña de una cuenta de NPM que controlaba un paquete con más de 7 millones de descargas semanales. Su precio de venta era de $20,000 por esta contraseña. Ahora, aquí es donde las dos historias se cruzan. Dos semanas después, uaparser.js fue comprometido, y se publicaron tres versiones maliciosas. Se añadió malware a estos paquetes que se ejecutaría inmediatamente cada vez que alguien instalara una de las versiones comprometidas. Así que, ahora echemos un vistazo a lo que hace ese malware. Este es el archivo JSON del paquete para la versión comprometida. Y verás que utiliza un script de preinstalación. Esto significa que ese comando se ejecutará automáticamente cada vez que se instale este paquete. Así que, ahora veamos qué hace ese script. Lo primero que verás es que se divide en función del sistema operativo del objetivo. En Mac, no pasa nada, lo cual es una suerte para los usuarios de Mac, pero
2. Ataque de Paquete Malicioso
Short description:
Y verás aquí que se ha generado un símbolo del sistema para cada una de estas plataformas utilizando child process.exe. Ahora, echemos un vistazo a lo que hace el script pre-install.sh. Obtiene el país del usuario y procede a descargar un archivo ejecutable. Este programa es un minero de Monero utilizado para minar la criptomoneda Monero. En Windows, el script descarga un archivo DLL que roba contraseñas de más de 100 programas diferentes y del administrador de credenciales de Windows. Este paquete se publicó durante unas cuatro horas, comprometiendo a aquellos que lo instalaron durante ese tiempo. Más de 700 paquetes han sido eliminados de NPM por razones de seguridad en los últimos 30 días. La tendencia de los ataques al ecosistema abierto y la confianza entre los mantenedores se está acelerando. 2022 será el año de la seguridad de la cadena de suministro. El sistema de descargar código de Internet y ejecutarlo con todos los permisos es arriesgado, pero es un milagro que haya funcionado en su mayoría durante tanto tiempo.
Los usuarios de Windows y Linux no tienen tanta suerte. Y verás aquí que se ha generado un símbolo del sistema para cada una de estas plataformas utilizando child process.exe. Así que, ahora echemos un vistazo a lo que hace el pre-install.sh script. La primera línea obtiene el país del usuario y determina si el usuario es de Rusia, Ucrania, Bielorrusia o Kazajstán, y almacena esa información en una variable. Ahora, si el usuario proviene de uno de esos países, entonces el script se detiene sin hacer nada más. Sin embargo, si vienes de cualquier otro país, entonces el script procede a descargar un archivo ejecutable desde esta dirección IP, marca ese archivo como ejecutable y luego lo ejecuta. Y ahora, basándonos en estos indicadores de línea de comandos, puedes ver aquí que este programa es un minero de Monero, que se va a utilizar para minar la criptomoneda Monero para el atacante. Ahora, este es el script en Windows. Es muy similar. Así que comienza con la descarga de ese mismo o similar minero de Monero, pero también descarga un archivo DLL y lo ejecuta. Y luego aquí puedes ver que simplemente inicia el minero de Monero y registra el archivo DLL en Windows.
Ahora, ¿qué hace este archivo DLL adicional? Bueno, roba contraseñas de más de 100 programas diferentes en la máquina Windows, así como todas las contraseñas en el administrador de credenciales de Windows. Así que, vaya, este es un malware realmente desagradable. Y, sabes, cualquiera lo suficientemente desafortunado como para ejecutar esto perdió todas sus contraseñas y tuvo que hacer, sabes, una especie de reinicio completo de sus cuentas en línea. No es un momento divertido. Así que, este es el resultado. Así que, este paquete se publicó durante unas cuatro horas. Y la comunidad de código abierto fue bastante diligente y lo reportó, y el mantenedor también fue bastante diligente. Y así que, sabes, cualquiera que lo instalara durante la ventana de cuatro horas fue comprometido, pero fue eliminado relativamente rápido. Cualquier compilación de software realizada en proyectos sin usar un archivo de bloqueo fue comprometida. Y cualquiera que tuviera la mala suerte de actualizar a esta nueva versión del paquete o tal vez quien fusionó un PR de bot para actualizar a esta nueva versión durante este tiempo habría sido también comprometido. Así que, esto fue una gran noticia en el mundo de JavaScript, y supongo que ya habrás oído hablar de este ataque. Pero esto es realmente solo la punta del iceberg. Así que, hemos estado rastreando paquetes que se eliminan de NPM por razones de seguridad, y hemos visto más de 700 paquetes eliminados por razones de seguridad en los últimos 30 días. Y creo que esta tendencia se está acelerando a medida que los atacantes se aprovechan del ecosistema abierto y la confianza que los mantenedores tienen entre sí y las políticas de contribución liberales que todos hemos adoptado en la era moderna del código abierto. Así que, creo que 2022 será el año de la seguridad de la cadena de suministro, ya que la conciencia de este problema está llegando a primer plano. Así que, una pregunta que podrías hacerte es, ¿por qué está ocurriendo esto ahora? Quiero empezar señalando que lo que estamos intentando hacer aquí es algo loco. Estamos intentando descargar código de Internet, escrito por individuos desconocidos que no hemos leído, que ejecutamos con todos los permisos en nuestros portátiles y servidores, donde guardamos nuestros datos más importantes. Así que, esto es lo que hacemos todos los días cuando usamos NPM install. Y solo tengo que decir realmente rápido que personalmente creo que es un milagro que el sistema funcione. Y que ha continuado
3. Código Abierto y Riesgos de Seguridad
Short description:
El 90% del código de tu aplicación proviene del código abierto, lo que nos permite construir aplicaciones web potentes rápidamente. Sin embargo, la abundancia de dependencias transitivas y la falta de revisión de código crean riesgos de seguridad. La carpeta de módulos Node es una colección masiva de paquetes, y la visualización de Webpack muestra la complejidad. Rara vez las personas leen el código que ejecutan, y npm no facilita la revisión de paquetes. Confiando en la ley de Linus, confiamos en que otros encontrarán problemas de seguridad, pero esto puede llevar a que el malware pase desapercibido durante meses. Estos hallazgos resaltan la importancia de la seguridad de la cadena de suministro en el ecosistema de código abierto.
ha funcionado en su mayoría durante tanto tiempo. Es un testimonio, creo, de lo buenos que son la mayoría de las personas. Pero desafortunadamente, no todos son buenos. Así que, profundicemos en por qué esto está sucediendo ahora. La primera razón es que el 90% del code de tu aplicación proviene del código abierto. Así que, realmente estamos parados sobre los hombros de gigantes. Y el código abierto es la razón por la que podemos poner en marcha una aplicación en horas y días en lugar de semanas o meses. Y es la razón por la que no necesitamos ser expertos en criptografía o en zonas horarias o en el DOM virtual para construir una potente aplicación web moderna. También es la razón por la que tu carpeta de modules Node es uno de los objetos más pesados del universo. Otra razón es que tenemos muchas, muchas dependencias transitivas. La forma en que escribimos software ha cambiado. Usamos las dependencias de forma mucho más liberal. Y así, instalar incluso una sola dependencia a menudo conduce a muchas, muchas dependencias transitivas que también entran. Un artículo de 2019 en la conferencia Usenix encontró que instalar un paquete promedio introduce una confianza implícita en 79 paquetes de terceros y 39 mantenedores, creando una superficie de ataque sorprendentemente grande. Y así, lo que tenemos aquí es una visualization que mi equipo en Socket creó que te muestra cómo se ve Webpack. Si te adentras en la carpeta de modules Node y realmente miras lo que hay dentro. Cada caja gris representa un paquete y cada caja morada representa un archivo o archivos dentro de un paquete. A medida que quitas cada capa del árbol de dependencias, encontrarás más paquetes dentro del paquete de nivel superior hasta que llegues al fondo. Este es simplemente un número insano de archivos y simplemente muchos modules volando por aquí. La siguiente razón es que realmente nadie lee el code. Hay algunas personas que lo hacen, pero en general, la gente no mira el code que están ejecutando en sus máquinas. Una gran razón es que npm realmente no facilita esto. Si vas a la página del paquete para UAParser.js y haces clic en la pestaña explorar aquí, verás que ni siquiera puedes ver los archivos de este paquete, por lo que la gente tiene que recurrir a hacer clic en el enlace de GitHub e ir a verificar GitHub y esperar que el code en GitHub coincida con el code que está en npm, lo cual no es necesariamente cierto. Pero está bien. Está bien. Podemos confiar en la ley de Linus de que, dado suficientes ojos, todos los errores son superficiales. Así que, si hay un problema de security en un paquete o malware en un paquete, podemos confiar en que otros lo encontrarán, ¿verdad? Pero si todos hacen eso, entonces ¿quién está encontrando el malware? Y así, tal vez esta es la razón por la que en promedio un paquete malicioso está disponible durante 209 días antes de que se informe públicamente. Esto proviene de un artículo de investigación de Ohm et al. Así que, son 209 días durante los cuales el comando incorrecto de npm puede terminar extremadamente mal. Y encuentro este número personalmente muy impactante. Un artículo de 2021 en NDSS, una prestigiosa conferencia de security, también encontró resultados similares, incluyendo que el 20% de estos malware persisten en los gestores de paquetes durante más de 400 días y tienen
4. Herramientas Populares y Ataques a la Cadena de Suministro
Short description:
Las herramientas populares dan una falsa sensación de seguridad al escanear solo las vulnerabilidades conocidas, dejándote vulnerable. Es crucial distinguir entre vulnerabilidades y malware. Las vulnerabilidades pueden ser de bajo impacto y pueden enviarse a producción temporalmente. Sin embargo, el malware, introducido intencionalmente por los atacantes, siempre conduce a consecuencias negativas. El desarrollo rápido aumenta el riesgo de ataques a la cadena de suministro. Necesitamos un nuevo enfoque para detectar y bloquear dependencias maliciosas. Comprender la mecánica de los ataques a la cadena de suministro es esencial. Los vectores de ataque, como el typo squatting, engañan a los usuarios para que ejecuten código malicioso.
más de 1.000 descargas. Y la cuarta razón es que las herramientas populares dan una falsa sensación de security. Muchas herramientas populares escanean en busca de vulnerabilities conocidas. Así que, en 2022, creo que esto ya no es suficiente. No podemos simplemente escanear en busca de vulnerabilities conocidas y detenernos ahí. Y sin embargo, eso es lo que hacen los productos de security de la cadena de suministro más populares, dejándote vulnerable.
La cuestión es que puede llevar semanas o meses descubrir, reportar y detectar una CVE o vulnerabilidad conocida con las herramientas. Y por lo tanto, simplemente no es lo suficientemente rápido. Por lo tanto, puede valer la pena tomar un minuto aquí para distinguir rápidamente entre vulnerabilities conocidas y malware porque son muy diferentes. Las vulnerabilities son introducidas accidentalmente por los mantenedores, por los buenos, y tienen diferentes niveles de riesgo. Así que, a veces está bien enviar intencionalmente una vulnerabilidad conocida a producción si su impacto es bajo. Incluso si tienes vulnerabilities en producción, es posible que no sean descubiertas o explotadas antes de que actualices a una versión corregida, por lo que generalmente tienes algo de tiempo para abordar este tipo de problemas.
Ahora bien, el malware, por otro lado, es bastante diferente. El malware es introducido intencionalmente en un paquete por un atacante, casi nunca el mantenedor, y siempre terminará mal si envías malware a producción. No tienes unos días o semanas para mitigar el problema. Realmente necesitas detectarlo antes de instalarlo en tu portátil o en un servidor de producción. Pero en la cultura actual de desarrollo rápido, una dependencia maliciosa puede ser actualizada y fusionada en un tiempo muy corto. Y por lo tanto, 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 mirar el code. Y por lo tanto, realmente creo que necesitamos un nuevo enfoque para detectar y bloquear dependencias maliciosas. Pero antes de entrar en eso, profundicemos un poco más en cómo funciona realmente un ataque a la cadena de suministro y su mecánica.
Así que, descargamos todos los paquetes de NPM, y pasamos unas semanas investigando. La descarga fue de 100 gigabytes de metadatos y 15 terabytes de tarballs de paquetes. Y 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. Estos son los que encontramos. Así que, hay vectores de ataque, que es más o menos cómo el atacante te engaña y te hace ejecutar su code en primer lugar. Y luego, hay tácticas, que son lo que el code de ataque hace realmente o las técnicas que el atacante usa para ocultar su code. Así que, hablemos de los vectores de ataque. El primer vector de ataque y el más común es el typo squatting. El typo squatting es cuando un atacante publica un paquete que tiene un nombre muy similar a un paquete legítimo y popular. Y así, puedes ver aquí, hay dos paquetes aquí con nombres muy similares y uno de estos es malware y uno de estos es el paquete real, pero supongo que sería difícil para ti saber eso sin abrir realmente estos paquetes para ver qué hay dentro.
5. Paquete de Malware y Confusión de Dependencia
Short description:
Abramos el paquete de malware y veamos qué está haciendo. Utiliza un script de instalación, que es una técnica común para el malware. El código está fuertemente ofuscado, pero definitivamente es algo que no querrías ejecutar. Otro vector de ataque es la confusión de dependencia, donde las herramientas internas instalan accidentalmente versiones públicas de paquetes. Encontramos muchos ataques de confusión de dependencia probablemente maliciosos con código malicioso, afectando a varias organizaciones.
Entonces, abramos el paquete de malware y veamos qué está haciendo. Como puedes ver aquí, de nuevo, 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 mirar el code, encontrarás que el archivo está fuertemente ofuscado. Pero puedo decirte, incluso sin saber exactamente qué está haciendo este code, puedes apostar que esto no es algo que quieras ejecutar en tu máquina. El siguiente vector de ataque que vimos se llama confusión de dependencia. Entonces, esto está bastante relacionado con el typosquatting. La confusión de dependencia 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. Entonces, más tarde un atacante puede venir y registrar un paquete con el mismo nombre que la versión pública y confundir las herramientas internas, de modo que las herramientas internas instalarán accidentalmente la versión pública. Por eso se llama ataque de confusión de dependencia. Entonces, mirando a través de los paquetes de NPM recientemente eliminados, pudimos encontrar un montón de ataques de confusión de dependencia probables, y la mayoría de estos paquetes tenían código malicioso en ellos. Entonces, todos estos paquetes tienen nombres que parecen entrar en conflicto con los nombres de paquetes internos de la empresa. Puedes ver aquí un montón de diferentes organizaciones, incluyendo gobiernos, que fueron afectados por esto. Y aquí hay un montón más, claramente apuntando a estas empresas específicas aquí
6. Paquetes Secuestrados y Tácticas de Ataque
Short description:
Los paquetes secuestrados son un vector común para que los criminales se infiltren en las comunidades e infecten paquetes populares. Las tácticas de ataque incluyen malware en scripts de instalación y uso de API privilegiadas para robar secretos. Los scripts de instalación tienen usos legítimos, lo que dificulta su desactivación. Un ejemplo de uso de API privilegiadas es hacer solicitudes HTTP para exfiltrar datos, mientras que otra técnica utiliza DNS para la exfiltración.
en esta lista. Y finalmente, el tercer vector que vemos mucho son los paquetes secuestrados. Entonces, estos son los que usualmente ves en las noticias bastante a menudo. Entonces, criminales y ladrones encuentran formas de infiltrarse en nuestras comunidades e infectar paquetes populares. Una vez que infectan un paquete popular, una vez que obtienen el control de él, y pueden publicarlo, robarán credenciales o instalarán puertas traseras o abusarán de los recursos informáticos para la minería de criptomonedas. Y entonces, estos suceden por varias razones. Entonces, a veces es porque un mantenedor elige una contraseña débil o reutiliza una contraseña o tal vez el mantenedor obtiene malware en sus laptops. Esto también no es ayudado por el hecho de que NPM no impone 2FA para todas las cuentas actualmente, aunque están empezando a imponer esto para las cuentas más populares. Y finalmente, a veces los mantenedores simplemente se dejan engañar y dan acceso a un actor malicioso. Esto se debe en parte al hecho de que los mantenedores están sobrecargados de trabajo y cuando alguien ofrece una mano amiga, a veces es difícil decir no a la ayuda. Así que este también es un gran vector. Así que ahora hablemos de algunas tácticas de ataque. Entonces, ¿qué hace este ataque code? Como mencionamos, los scripts de instalación son un gran vector. La mayoría del malware está en los scripts de instalación. Y entonces esta es una cita de un paper que mencionamos antes. Entonces, la mayoría de los paquetes maliciosos, en realidad el 56% comienzan sus rutinas al instalarse, lo que podría deberse a un manejo deficiente de code arbitrario durante la instalación. Entonces, en el gestor de paquetes npm, se permite a los paquetes decir, oye, cuando este paquete se instala, queremos ejecutar algún code. Y entonces, desafortunadamente, los scripts de instalación tienen algunos usos legítimos. Así que no podemos simplemente desactivarlos. No es un problema fácil de resolver. Entonces, echemos un vistazo a solo un ejemplo. Otro ejemplo de un script de instalación, de nuevo, lo verás aquí mismo en el archivo package.json, muy común. Lo siguiente es el uso privilegiado de la API. Entonces, vemos paquetes accediendo a la red, accediendo al sistema de archivos y accediendo a las variables de entorno. Esto es muy, muy común porque cuando un atacante ejecuta code, lo que quiere hacer es robar algunos secretos y necesitan la red para exfiltrar 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 resulta que está enviando es process.env que contiene todas las variables de entorno en el entorno. Y luego aquí está en realidad 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 esto funciona es que crea un resolutor de DNS, y luego hace... Recopila las variables de entorno,
7. Código Ofuscado y Discrepancia de Código
Short description:
El código ofuscado es difícil de entender a simple vista, pero existen herramientas que pueden ayudar a desofuscarlo. Los atacantes pueden publicar un código diferente en npm que en GitHub, lo que dificulta la evaluación de los paquetes basándose en el código de GitHub.
y luego realiza una búsqueda DNS con esas variables como subdominio. Así que es simplemente otra forma de sacar los data del sistema. Y finalmente, tenemos el code ofuscado. Así que echamos un vistazo a un ejemplo de esto antes. Así que el code ofuscado como este es obviamente realmente difícil de ver a simple vista lo que está haciendo, aunque existen herramientas para intentar desofuscar code como este. También hay otro tipo de ofuscación, que es que los atacantes pueden publicar un code diferente en npm que en GitHub. Y entonces, ya sabes, cuando hacen eso, como mencioné antes, npm no facilita ver qué code está realmente en el paquete de npm. Y entonces, muchas personas que intentan evaluar un paquete se basan en el code que está en GitHub y no hay garantía de que ese code sea el mismo.
8. Protegiendo Tu Aplicación
Short description:
Hablemos de cómo puedes proteger tu aplicación. Trabajamos en un producto llamado Wormhole, con el objetivo de construir una forma segura y privada de enviar archivos. Implementamos medidas de seguridad, como la consideración temprana de la seguridad, pruebas, revisiones de código y una selección cuidadosa de las dependencias.
Bien, ahora hablemos de cómo puedes proteger tu aplicación. 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 hicimos todas las cosas de security que se nos ocurrieron. Pensamos en la security temprano en el proceso de design. Escribimos pruebas, hicimos cumplir las revisiones de code, y fuimos bastante reflexivos sobre las dependencias que elegimos usar. Pero, ya sabes, todavía sentíamos que podíamos hacerlo mejor. Y entonces empezamos a pensar realmente en este problema y en lo que podríamos hacer para mejorarlo.
9. Elegir Dependencias y Evaluar la Seguridad
Short description:
Elige mejores dependencias y asume la responsabilidad del código que envías a producción. La popular licencia MIT destaca la necesidad de un cambio de mentalidad en cómo vemos el código abierto. Confiar en heurísticas para seleccionar dependencias significa que podemos no estar conscientes de su verdadero comportamiento. Socket proporciona una herramienta para evaluar la seguridad de los paquetes, destacando los scripts de instalación y el código binario/nativo. También están disponibles las puntuaciones de calidad. Por ejemplo, el paquete Angular Calendar tiene dependencias invasivas.
Entonces, la primera cosa que recomendaría es que simplemente intentes elegir mejores dependencias. Sabes, si envías code a producción, eres finalmente responsable de ello. 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 van a ser seguras. Y no es necesariamente cierto. Y si estás enviando code a producción que incluye código abierto code, entonces realmente ese code es parte de tu aplicación. Y así tú eres finalmente responsable del comportamiento de ese code. Y, sabes, la licencia de código abierto más popular, la licencia MIT, literalmente dice esto en la licencia, dice que el código abierto code se proporciona tal como está sin garantía de ningún tipo y en ningún caso el autor será responsable de cualquier reclamación, daños o responsabilidad. Y así, sabes, mientras esto es legalmente cierto, la mayoría de las personas no piensan en su código abierto de esta manera. Y creo que realmente necesitamos un cambio de mentalidad. La otra cosa es que muy pocos de nosotros realmente leemos el code que estamos enviando a producción. Y así confiamos en otras heurísticas para ayudar a seleccionar dependencias. Entonces tal vez, sabes, miramos si el code hace el trabajo? ¿Tiene una licencia de código abierto? ¿Tiene buenos docs? ¿Tiene muchas descargas y estrellas de GitHub? ¿Tiene commits recientes? ¿Tiene tipos? ¿Y tiene pruebas? Y realmente no estamos abriendo el code para ir mucho más allá de esto. Entonces lo que eso significa es que no estamos conscientes de lo que el code puede estar haciendo. Y así, construimos una herramienta en Socket para ayudar con este problema. Así que puedes rápidamente echar un vistazo y tener una idea de la seguridad de un paquete. Y así es como se ve. Así que puedes ir a Socket y buscar paquetes para averiguar qué comportamiento tiene el paquete. Y así en este ejemplo aquí, puedes ver que este paquete contiene scripts de instalación. Y eso se destaca muy prominentemente en la página. Así que es lo primero que ves. Y este paquete también contiene binario, sabes, o código nativo code, lo que significa que no es fácil auditar el code. No es como un legible por humanos. Y así ambos de estos problemas son destacados. Y en este caso, no es necesariamente esto no es un ataque a la cadena de suministro por ningún medio. Pero es agradable que esto se destaque muy prominentemente para que puedas tomar una decisión informada si quieres usar este paquete o no. También puedes ver que tenemos muy útiles puntuaciones de calidad que aparecen en la parte superior de la página también. Ahora, echemos un vistazo a otro ejemplo. Así que este paquete aquí, Angular Calendar, es un paquete 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, en realidad encontrarás que algunas de sus dependencias están haciendo cosas bastante invasivas
10. Gestión de Dependencias y Seguridad
Short description:
Una de sus dependencias contiene scripts de instalación, ejecuta scripts de shell y accede al sistema de archivos y a la red. Investiga los paquetes en Socket antes de usarlos para tomar una decisión informada. La actualización de las dependencias requiere encontrar el equilibrio adecuado entre las vulnerabilidades conocidas y los ataques a la cadena de suministro. Auditar cada dependencia es una opción para las aplicaciones críticas de seguridad, pero conlleva compromisos y desafíos.
cosas. 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. Probablemente esto no es algo que esperarías que un componente web estuviera haciendo. Por lo tanto, puede valer la pena investigar un poco más para averiguar qué está pasando aquí antes de usar este paquete. Lo otro que hacemos que es bastante genial es que podemos resaltar cuando los paquetes hacen estas cosas, y poner eso directamente en línea en el code. Así que en este paquete aquí, lo abrí para echar un vistazo a los archivos. Y pude ver aquí que el módulo está accediendo a la red, así como accediendo 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 hace un poco más fácil tener una idea de lo que un paquete está haciendo antes de ejecutarlo. Así que 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. Bueno, lo otro que puedes hacer es pensar en actualizar tus dependencias al ritmo adecuado. ¿A qué me refiero con esto? Así que hay una pregunta sobre, como, qué tan rápido deberías actualizar tus dependencias. Y esta es en realidad una pregunta con la que luchamos en nuestro equipo también. Así que si, puedes pensar en si deberíamos actualizar lentamente, o deberíamos actualizar realmente, realmente rápido y agresivamente? Si actualizas demasiado lentamente, estás expuesto a vulnerabilidades conocidas. Y estás ejecutando code que es antiguo y que sabes, puede tener problemas, puede tener algunos bugs que se han corregido en la versión más nueva. 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 code que puede haber sido publicado, sabes, literalmente ayer o, o en los últimos días, lo que significa que no ha habido tantos ojos capaces de mirar el code. Y así, sabes, si piensas en seguridad, tienes que equilibrar, sabes, este, este compromiso, y realmente no hay una solución perfecta aquí. Es simplemente un problema difícil.
Otra idea es auditar cada dependencia. Así que, sabes, si estás construyendo una aplicación verdaderamente crítica para la seguridad, como lo estábamos haciendo con wormhole, entonces, sabes, una opción es literalmente leer cada línea de code de tus dependencias. Así que si, de nuevo, ponemos esto en, en un eje de comenzar desde una auditoría completa por un lado, leyendo cada línea de code hasta YOLOing por el otro lado, y, sabes, por YOLOing, me refiero a, ¿como hacer nada? ¿Qué tan de cerca deberías auditar tus dependencias? Y lo que ves aquí es que estamos en la misma situación. Tenemos compromisos y realmente no hay buenas, no hay buenas soluciones. Así que hacer una auditoría completa es algo que sólo las empresas más grandes y ricas parecen hacer en la práctica. Es mucho trabajo. Normalmente necesitas tener un equipo de seguridad mirando cada uno de estos paquetes, y también tenemos que aprobarlos uno a uno y añadirlos a una lista de permitidos, lo cual es realmente lento. Y esto es caro sólo por el tiempo y el esfuerzo que requiere. Por otro lado, no hacer nada y simplemente instalar lo que quieras sin, incluso mirar el code, tiene sus desventajas. Así que significa que eres vulnerable a la cadena de suministro
11. Automatización y Aplicación de GitHub
Short description:
Es arriesgado. Y la mayoría de los equipos están del lado de no hacer nada. Utilizamos la automatización para evaluar las dependencias y auditar manualmente los paquetes más sospechosos. La información de seguridad se muestra directamente en las solicitudes de extracción, empoderando a los desarrolladores para resolver problemas de seguridad antes del despliegue. Nuestra aplicación de GitHub ejecuta un informe de salud completo sobre las nuevas dependencias, dejando comentarios sobre cualquier problema descubierto. Mejora el proceso de revisión y sólo plantea problemas que merecen atención. Prueba nuestra aplicación gratuita de GitHub en Socket.dev para bloquear typosquats, malware, código oculto, uso privilegiado de API, y detectar actualizaciones sospechosas.
ataques a la cadena de suministro. Es arriesgado. Y una violación o mala prensa de security puede ser costosa, especialmente a medida que los reguladores empiezan a tomar más en serio este problema. Y entonces este es otro difícil compromiso. ¿Qué haces? Y la mayoría de los equipos, creo, están del lado de no hacer nada, y, pero creo que este es simplemente un problema difícil. Así que una cosa que intentamos hacer cuando estábamos construyendo Wormhole es pensar en, un término medio. ¿Hay una forma de usar automation para hacer algo en el medio? Y lo que queremos hacer y lo que hemos, lo que terminamos haciendo es usar automation para evaluar automáticamente todas nuestras dependencias. Así que podríamos usar análisis estático para revisar los paquetes e intentar encontrar malware, code oculto, typos, ataques de suplantación de identidad, y este tipo de cosas. Y de esa manera podemos auditar manualmente sólo los paquetes más sospechosos. Así que podríamos gastar nuestros limitados recursos del equipo mirando el code para los paquetes más sospechosos. Y esa es la forma más impactante en que podríamos gastar 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 lo otro que queríamos hacer es asegurarnos de que la información de security se mostrara directamente en las solicitudes de extracción para que los desarrolladores de nuestro equipo estuvieran empoderados para resolver los problemas de security que veían antes de que se desplegaran en producción. Entonces, ¿cómo se ve esto en realidad? Así que este es el bot que creamos. Está implementado como una aplicación de GitHub que puedes instalar en tu repositorio de GitHub. Y cada vez que ve que el archivo package json o el archivo yarn.lock ha sido modificado, tomará un vistazo a la nueva dependencia que se ha añadido y ejecutará un informe completo de health contra esa dependencia. Y si se encuentran problemas en ella, dejará un comentario con lo que sea el problema que se descubrió. De esta manera, el desarrollador que revisa la solicitud de extracción puede mirar y tener su atención atraída hacia este posible problema. En esta captura de pantalla aquí, puedes ver que accidentalmente instalé el paquete browser list en lugar de browser list, que es en realidad un error muy fácil de cometer. Y por esa razón, el paquete de typo tiene algo así como 700,000 descargas al año. Así que esto es realmente, realmente útil. Este es el tipo de cosa que mejora tu proceso de revisión. Y es de muy bajo costo ya que sólo plantea problemas que realmente merecen tu atención. Y se ejecuta automáticamente. Así que si quieres probar esta aplicación, la hemos publicado para que cualquiera la use. Es gratis. Así que puedes instalar nuestra aplicación de GitHub simplemente yendo a Socket.dev. Y te recomiendo que lo pruebes y me digas qué te parece. Tiene un montón de características geniales. Así que en realidad puede bloquear typosquats, que como acabo de mostrarte antes, pero también puede bloquear malware, detectar code oculto, detectar el uso privilegiado de API, como el uso de sistema de archivos de red, proceso hijo,
12. Análisis de Paquetes y Retroalimentación
Short description:
Tenemos 70 detecciones en cinco categorías diferentes: riesgo de la cadena de suministro, calidad, mantenimiento, vulnerabilidades conocidas y licencia. Nuestras reglas de análisis estático se centran en problemas accionables que los usuarios del paquete necesitan conocer. Prueba Socket.dev para explorar estos problemas y proporcionar retroalimentación. Nuestro objetivo es mejorar la seguridad de la cadena de suministro en 2022 y protegerla mejor que nunca. Comparte tus comentarios conmigo a través de correo electrónico o Twitter. También estamos contratando en Socket si estás interesado en asegurar la cadena de suministro de software.
etc. Y también puede detectar actualizaciones sospechosas. Así que estas son actualizaciones que cambian significativamente el comportamiento del paquete. Así que tenemos un montón de cosas que buscamos en los paquetes. De hecho, tenemos 70 detecciones en cinco categorías diferentes. Así que tenemos riesgo de la cadena de suministro, calidad, mantenimiento, vulnerabilidades conocidas y licencia. Y escribimos, básicamente, estas son todas las reglas de análisis estático que escribimos. Puedes pensar en esto como un linter de alguna manera. Así que está mirando el código del paquete y luego buscando estos diferentes problemas. Intentamos enfocar todas las reglas en problemas que son algo que tú, como usuario del paquete, realmente quieres saber, y no cosas que requieren mucho conocimiento de los detalles internos del paquete. Así que las cosas que encuentra deben ser accionables para ti como el desarrollador que elige usar este paquete. Y eso es lo que intentamos hacer en nuestro desarrollo de reglas aquí. Así que sí, si quieres probar esto, si quieres explorar nuestro sitio web y mirar estos diferentes problemas, puedes probarlo en socket.dev. Y lo hemos hecho gratuito para el código abierto para siempre, y si tienes un repositorio privado, es gratis mientras estamos en beta, y realmente quiero que la gente nos dé una oportunidad y comparta sus comentarios con nosotros, porque este problema de seguridad de la cadena de suministro es grande y sólo está creciendo. Y 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 haciendo de 2022 no el año en que la cadena de suministro es destruida, sino el año en que está protegida mejor que nunca. Así que por favor comparte tus comentarios conmigo. Ahí 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. Hey, gracias por unirte a nosotros. Me alegra estar aquí, y no quise asustarte. Hay mucho que hacer, hay muchas soluciones, así que no estaría demasiado asustado. Creo que podemos resolver el problema, espero. Espero, bueno, la mayoría de la gente está muy preocupada y quiere hacer más. Bueno, es bueno. Me siento feliz de que la gente quiera hacer más, pero deberían hacer más. Bueno, pueden hacerlo con Socket.dev. ¿Cómo te sientes acerca de esto? Esta desviación, 70% y luego 27% moderado, y 3%, nada en absoluto? Estoy realmente gratamente sorprendido de que tengamos tantos desarrolladores que están preocupados por el problema. Ahora, no sé cuánto influyó mi charla en su votación mientras estaban viendo. Probablemente estaba ayudando a empujar este número hacia arriba con todos los ejemplos que estaba repasando de malware y ataques a la cadena de suministro que han ocurrido en NPM. Pero creo que es alentador que la gente quiera hacer más y que en realidad hay algunas cosas que pueden hacer para ayudar con eso, incluyendo instalar Socket o probar nuestras herramientas.
13. Diferenciando a Socket de Otras Herramientas de Seguridad
Short description:
Existen múltiples escáneres de seguridad, pero lo que distingue a Socket es su capacidad para escanear un paquete analizando su código real y determinando sus capacidades. Socket va más allá del escaneo básico de vulnerabilidades y protege contra malware y ataques a la cadena de suministro. Este enfoque garantiza que los usuarios estén conscientes de los riesgos potenciales antes de instalar un paquete.
Sí. Entonces, la primera pregunta es mía. Hay múltiples escáneres de security. Sé de memoria, tenemos StackHawk y tenemos Sneak. ¿Qué distingue a tu producto? Sí. Entonces, creo que lo principal a tener en cuenta al evaluar herramientas como esta es si te protegerán solo de vulnerabilities así como de malware y ataques a la cadena de suministro. Entonces, es casi como un estándar. Diría que hay herramientas para buscar vulnerabilities. Eso es lo que hace NPM audit. Eso es lo que hace Dependabot. Hay muchas cosas por ahí que hacen este tipo de, diría, escaneo básico de vulnerabilidades. La verdadera amenaza que hemos visto en el último año es de este nuevo tipo de ataque, ataques a la cadena de suministro que generalmente implican que un paquete sea secuestrado y se agregue code por un mal actor. Y hay este período en el que antes de que se descubra, cualquiera que instale ese paquete secuestrado va a tener su computadora comprometida. Y si tienes realmente mala suerte, esto no se descubre durante un par de semanas y llega a producción. Y esto ha sucedido en muchos casos en el pasado. Y entonces creo que la forma en que queremos distinguir a Socket de todo lo demás que hay por ahí es ¿qué puedes hacer realmente para escanear un paquete mirando no a alguna database para decir, ¿ha encontrado un investigador de security un problema con esto y ha escrito un informe sobre ello hace un par de semanas, la pregunta es realmente, ¿qué va a hacer este paquete? ¿Cuáles son sus capacidades? ¿Va a hablar con la red y va a leer archivos y vamos a analizar el code real en el paquete antes de que lo instales para responder a esas preguntas? Y eso es realmente la diferencia. Y ahí es donde creo que necesitamos ir con todas las herramientas en este espacio de security.
14. Desafíos con los Enfoques Existentes
Short description:
Un mantenedor que agrega malware o código malicioso a su propio paquete representa un desafío significativo para los enfoques existentes como la firma de código y las bases de datos de vulnerabilidades. El incidente resalta la necesidad de analizar el código real para entender su comportamiento. Leer todo el código en las dependencias es un proceso que consume mucho tiempo, por lo que los escáneres de seguridad pueden ser útiles.
Y un poco relacionado. Entonces, no recuerdo el nombre del paquete, pero había un paquete realmente popular, y hace un mes o dos, el autor lo retiró de GitHub y dijo, liberar a Aaron Swartz, algo así. ¿Recuerdas de lo que estoy hablando? Entonces sí, esto también será detectado porque tienes un cambio significativo en el code ¿verdad? Así que también detectará esos problemas. Sí. No es suficiente, este es un ejemplo perfecto en realidad, donde muchas de las estrategias que otras empresas y otros equipos que están tratando de resolver este problema están tomando no habrían realmente detectado este problema porque aquí es donde tienes a un mantenedor ellos mismos agregando malware o mal code a su propio paquete. Y entonces confiar en cosas como la firma de code, por ejemplo, no habría hecho realmente nada en este caso porque el propio mantenedor habría tenido las llaves para firmar su code. O si estás mirando una base de datos de vulnerabilidades database, esto no va a estar en una base de datos de vulnerabilidades. Y entonces, lo siento, estoy recibiendo una llamada telefónica ahora mismo. Sí. Entonces de todos modos, creo que ese incidente fue realmente muy ilustrativo de los desafíos con los otros enfoques y por qué realmente lo que quieres hacer es entrar en el code real y mirar lo que está haciendo. Sí. Solía trabajar en una empresa de tecnología médica. Y entonces siempre era el escenario si haces una actualización, entonces realmente tendrías que leer todo el code que era nuevo. Y sí, así que traté de evitar cualquier dependencia porque bueno, es demasiado trabajo leer todo lo que es nuevo en todas tus dependencias.
15. Realms y las Banderas de Línea de Comando de Deno
Short description:
Los realms son una propuesta interesante que potencialmente podrían sandboxear el código y hacer cumplir restricciones de comportamiento en tiempo de ejecución para los paquetes. Las banderas de línea de comando de Deno, aunque a nivel de proceso, proporcionan algunas ideas interesantes. Sin embargo, son menos efectivas para detener los ataques a la cadena de suministro.
Entonces sí. Pero sí, tener escáneres de seguridad ayudaría mucho. La primera pregunta es de Will Shadow ¿abordará realmente algunos de estos problemas? Creo que los realms son una propuesta interesante. Y creo que han estado haciendo un buen progreso a través del comité de standards. Aunque realmente no lo estoy siguiendo muy de cerca. Así que puede que no sea la mejor persona para hacer esta pregunta, pero mi entendimiento es que debería haber alguna forma de usar esta característica, esta característica de realms para sandboxear code. Y sé que es realmente difícil hacer que un sandbox funcione de manera realmente confiable, pero si esta característica funciona de la manera que creo que lo hace y si hay un montón de asteriscos adjuntos a esta declaración, eventualmente podríamos ser capaces de usar una característica como esta para ir más allá de simplemente analizar un paquete y decir, OK, esto va a hablar con la red o esto va a hablar con el sistema de archivos. Pero en realidad, en tiempo de ejecución, ser capaz de decir para un paquete, este paquete declara que nunca necesita hablar con la red y de hecho vamos a hacer cumplir eso en tiempo de ejecución. Vamos a asegurarnos de que no haga XYZ comportamiento que no necesita. Y así, si de repente empieza a hacer eso, entonces seríamos capaces de bloquearlo. Creo que también es interesante mirar a deno y ver cómo hacen sus banderas de línea de comando donde para aquellos que han jugado un poco con deno, tiene esta idea de permitir fs, permitir net que puedes pasar en la línea de comando que es bastante interesante. Aunque eso es más bien para todo un proceso y no en una base por paquete, lo que lo hace menos útil para detener los ataques a la cadena de suministro, porque generalmente tienes que permitir la red si quieres construir un servidor web. Y así no te da mucha protección si una de esas dependencias se ve comprometida. Pero
16. Asegurando Dependencias y Priorizando la Seguridad
Short description:
Hacer que los ingenieros se preocupen por asegurar las dependencias es un problema difícil. Siempre hay deuda técnica y una lista de tareas pendientes para enviar funciones. Sin embargo, como artesanos, deberíamos enorgullecernos del software que creamos y asegurarnos de que no comprometa los datos del usuario. Con las herramientas adecuadas, como Sockett, asegurar las dependencias puede ser más fácil e incluso agradable. La seguridad debe ser priorizada sobre otros aspectos del desarrollo, como las configuraciones de línea de comandos y las animaciones.
es un lugar interesante para partir. Sí. Bien. Gracias. Tenemos un minuto más. Así que es de una colina al bosque. ¿Qué sugerirías para hacer que los ingenieros se preocupen por asegurar nuestras dependencias? Siento que porque nadie lee el code, etc, sólo se preocuparán cuando algo ya salga mal. No, es un problema realmente difícil. Quiero decir, es realmente difícil porque, ya sabes, los ingenieros ya tienen mucho que hacer. Siempre hay deuda técnica que solucionar. Hay mucho atraso y sólo estamos tratando de enviar funciones y hacer nuestro trabajo. Y así es añadir otra cosa al plato de los desarrolladores es pedir mucho. Creo que un argumento que haría a esos desarrolladores para convencerlos de que se preocupen es que, en última instancia, somos artesanos y tenemos que ser, supongo, artesanos. Nosotros realmente tenemos que preocuparnos por el trabajo que estamos creando. Y deberíamos tener orgullo en el software que creamos y que enviamos a producción. Y parte de eso es realmente asegurarnos de que el code que enviamos se comporta como se espera y no compromete nuestros data de usuario o compromete a nuestros usuarios de ninguna manera. Y así, es realmente parte de la responsabilidad de ser un ingeniero. Y con las herramientas adecuadas, y estoy sesgado pero creo que Sockett está tratando de hacer un buen trabajo aquí, puedes hacer que no sea tan difícil y tan oneroso para el desarrollador y hacerlo algo que es divertido de hacer como parte del proceso de desarrollo.
Sí. Bueno, en realidad, security, si lo piensas, debería ser después quizás accessibility. No, tal vez incluso antes de accessibility. Es lo más importante. Es más importante que tus elegantes configuraciones de línea de comandos. Es más importante que tus animations de 60 FPS. Es lo más importante. Sí, eso también es una respuesta, creo. Bueno, se nos acabó el tiempo para preguntas y respuestas, pero Feroz va a estar en una sala de conferencias en el chat espacial. Así que, puedes hacer clic en el enlace en la línea de tiempo de abajo. Feroz, muchas gracias por asustarnos y entretenernos. Ha sido un placer tenerte. Sí, gracias Mateen. Aprecio las buenas preguntas y ha sido un honor estar aquí. Así que, muchas gracias. Lo aprecio. Bien, adiós. Adiós.
There is a need for a standard library of APIs for JavaScript runtimes, as there are currently multiple ways to perform fundamental tasks like base64 encoding. JavaScript runtimes have historically lacked a standard library, causing friction and difficulty for developers. The idea of a small core has both benefits and drawbacks, with some runtimes abusing it to limit innovation. There is a misalignment between Node and web browsers in terms of functionality and API standards. The proposal is to involve browser developers in conversations about API standardization and to create a common standard library for JavaScript runtimes.
ESM Loaders enhance module loading in Node.js by resolving URLs and reading files from the disk. Module loaders can override modules and change how they are found. Enhancing the loading phase involves loading directly from HTTP and loading TypeScript code without building it. The loader in the module URL handles URL resolution and uses fetch to fetch the source code. Loaders can be chained together to load from different sources, transform source code, and resolve URLs differently. The future of module loading enhancements is promising and simple to use.
This talk covers various techniques for getting diagnostics information out of Node.js, including debugging with environment variables, handling warnings and deprecations, tracing uncaught exceptions and process exit, using the v8 inspector and dev tools, and generating diagnostic reports. The speaker also mentions areas for improvement in Node.js diagnostics and provides resources for learning and contributing. Additionally, the responsibilities of the Technical Steering Committee in the TS community are discussed.
Passwords are terrible and easily hacked, with most people not using password managers. The credential management API and autocomplete attribute can improve user experience and security. Two-factor authentication enhances security but regresses user experience. Passkeys offer a seamless and secure login experience, but browser support may be limited. Recommendations include detecting Passkey support and offering fallbacks to passwords and two-factor authentication.
Deno aims to provide Node.js compatibility to make migration smoother and easier. While Deno can run apps and libraries offered for Node.js, not all are supported yet. There are trade-offs to consider, such as incompatible APIs and a less ideal developer experience. Deno is working on improving compatibility and the transition process. Efforts include porting Node.js modules, exploring a superset approach, and transparent package installation from npm.
Today's Talk is about logging with Pino, one of the fastest loggers for Node.js. Pino's speed and performance are achieved by avoiding expensive logging and optimizing event loop processing. It offers advanced features like async mode and distributed logging. The use of Worker Threads and Threadstream allows for efficient data processing. Pino.Transport enables log processing in a worker thread with various options for log destinations. The Talk concludes with a demonstration of logging output and an invitation to reach out for job opportunities.
¿Alguna vez has tenido dificultades para diseñar y estructurar tus aplicaciones Node.js? Construir aplicaciones que estén bien organizadas, sean probables y extensibles no siempre es fácil. A menudo puede resultar ser mucho más complicado de lo que esperas. En este evento en vivo, Matteo te mostrará cómo construye aplicaciones Node.js desde cero. Aprenderás cómo aborda el diseño de aplicaciones y las filosofías que aplica para crear aplicaciones modulares, mantenibles y efectivas.
Platformatic te permite desarrollar rápidamente APIs GraphQL y REST con un esfuerzo mínimo. La mejor parte es que también te permite aprovechar todo el potencial de Node.js y Fastify cuando lo necesites. Puedes personalizar completamente una aplicación de Platformatic escribiendo tus propias características y complementos adicionales. En el masterclass, cubriremos tanto nuestros módulos de código abierto como nuestra oferta en la nube:- Platformatic OSS (open-source software) — Herramientas y bibliotecas para construir rápidamente aplicaciones robustas con Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (actualmente en beta) — Nuestra plataforma de alojamiento que incluye características como aplicaciones de vista previa, métricas integradas e integración con tu flujo de Git (https://platformatic.dev/). En este masterclass aprenderás cómo desarrollar APIs con Fastify y desplegarlas en la nube de Platformatic.
La autenticación sin contraseña puede parecer compleja, pero es simple de agregar a cualquier aplicación utilizando la herramienta adecuada. Hay múltiples alternativas que son mucho mejores que las contraseñas para identificar y autenticar a tus usuarios, incluyendo SSO, SAML, OAuth, Magic Links, One-Time Passwords y Authenticator Apps. Mientras abordamos los aspectos de seguridad y evitamos errores comunes, mejoraremos una aplicación JS de pila completa (backend Node.js + frontend React) para autenticar a los usuarios con OAuth (inicio de sesión social) y One Time Passwords (correo electrónico), incluyendo:- Autenticación de usuarios - Gestión de interacciones de usuarios, devolviendo JWTs de sesión / actualización- Gestión y validación de sesiones - Almacenamiento seguro de la sesión para solicitudes de cliente posteriores, validación / actualización de sesiones- Autorización básica - extracción y validación de reclamaciones del token JWT de sesión y manejo de autorización en flujos del backend Al final del masterclass, también exploraremos otros enfoques de implementación de autenticación con Descope, utilizando SDKs de frontend o backend.
Construyendo un Servidor Web Hiper Rápido con Deno
WorkshopFree
2 authors
Deno 1.9 introdujo una nueva API de servidor web que aprovecha Hyper, una implementación rápida y correcta de HTTP para Rust. El uso de esta API en lugar de la implementación std/http aumenta el rendimiento y proporciona soporte para HTTP2. En este masterclass, aprende cómo crear un servidor web utilizando Hyper en el fondo y mejorar el rendimiento de tus aplicaciones web.
La autenticación sin contraseña puede parecer compleja, pero es fácil de agregar a cualquier aplicación utilizando la herramienta adecuada. Mejoraremos una aplicación JS de pila completa (backend de Node.JS + frontend de React) para autenticar usuarios con OAuth (inicio de sesión social) y contraseñas de un solo uso (correo electrónico), incluyendo:- Autenticación de usuario - Administrar interacciones de usuario, devolver JWT de sesión / actualización- Gestión y validación de sesiones - Almacenar la sesión para solicitudes de cliente posteriores, validar / actualizar sesiones Al final del masterclass, también tocaremos otro enfoque para la autenticación de código utilizando Flujos Descope en el frontend (flujos de arrastrar y soltar), manteniendo solo la validación de sesión en el backend. Con esto, también mostraremos lo fácil que es habilitar la biometría y otros métodos de autenticación sin contraseña. Tabla de contenidos- Una breve introducción a los conceptos básicos de autenticación- Codificación- Por qué importa la autenticación sin contraseña Requisitos previos- IDE de tu elección- Node 18 o superior
Cómo construir una aplicación GraphQL fullstack (Postgres + NestJs + React) en el menor tiempo posible. Todos los comienzos son difíciles. Incluso más difícil que elegir la tecnología es desarrollar una arquitectura adecuada. Especialmente cuando se trata de GraphQL. En este masterclass, obtendrás una variedad de mejores prácticas que normalmente tendrías que trabajar en varios proyectos, todo en solo tres horas. Siempre has querido participar en un hackathon para poner algo en funcionamiento en el menor tiempo posible, entonces participa activamente en este masterclass y únete a los procesos de pensamiento del instructor.
Comments