El Estado de la Seguridad de JavaScript en 2024

Soy Firas, he estado trabajando en código abierto durante unos 10 años, he escrito alrededor de cien paquetes npm diferentes, tal vez algunos de los cuales hayas oído hablar. Web torrent y standard JS, hice algo de trabajo en algunos polyfills que se usaron en Browserify y Webpack y algunos otros empaquetadores también. Luego me moví hacia la seguridad, me interesé mucho en la seguridad web, enseñé un curso en Stanford, y ahora estoy tomando mi interés en código abierto y seguridad e intentando unir los dos con Socket. Así que haré solo unos rápidos 10-20 segundos sobre Socket. Así que ayudamos a proteger tu código, si necesitas obtener una herramienta para verificar vulnerabilidades y dependencias maliciosas, echa un vistazo a Socket, podríamos ayudarte. Tenemos un montón de organizaciones que nos usan, un montón de repos que estamos protegiendo, y luego algunos de nuestros clientes aquí. Así que estoy realmente feliz con cómo hemos podido ayudar a mucha gente con nuestro producto.

Así que hablemos de la seguridad en JavaScript. Entonces, ¿por qué es difícil la seguridad en JavaScript? Creo que la cita que ilustra esto es de Michael Zalewski, quien es el autor de The Tangled Web, que es uno de los primeros libros de seguridad web que leí alguna vez. Y él dice, las aplicaciones web modernas están construidas sobre un enredo de tecnologías que han sido desarrolladas con el tiempo y ensambladas de manera desordenada. Así que cada pieza de la pila de aplicaciones web, desde HTTP hasta los scripts del lado del navegador, viene con consecuencias de seguridad importantes pero sutiles. Y para mantener a los usuarios seguros, realmente tenemos que entender y navegar este panorama. Y si piensas en el trabajo del navegador web, en realidad es una tarea aparentemente imposible. Los sitios, incluso los sitios web maliciosos que visitas, pueden descargar y ejecutar código desde cualquier dirección IP o origen. Pueden generar procesos de trabajo en tu sistema operativo. Pueden abrir sockets, mostrar medios en cualquier cantidad de formatos diferentes, ejecutar código en tu GPU, por el amor de Dios, y guardar y leer datos de tu sistema de archivos. Ahora, ¿dejarías que un sitio web malicioso hiciera esto en tu computadora? Bueno, eso es lo que un navegador web tiene que hacer. Tiene que permitir que eso suceda de manera segura. Así que es realmente asombroso lo robusta que es la web a pesar de la reputación que a veces tiene, especialmente de los detractores. Y así, puede que no tenga un diseño limpio, pero realmente ha evolucionado muchas medidas de seguridad para hacerla realmente robusta a lo largo de los años. Y así, ya sabes, es muy fácil criticar, lamentar y crear escenarios paranoicos sobre los fundamentos de seguridad poco sólidos de la web. Pero la verdad es que toda esa crítica es cierta, y sin embargo, la web ha demostrado ser increíblemente robusta como plataforma. La cuestión es que, como desarrolladores, realmente tenemos que entender todas esas complejidades a menudo para construir sitios web seguros y aplicaciones seguras. Y eso es parte de lo que, ya sabes, el propósito de esta charla es, es solo para aumentar la conciencia. No tengo mucho tiempo. Pero solo para destacar algunas cosas que han cambiado en 2024 y algunas cosas a tener en cuenta para ti.

Entonces, ¿por qué es difícil la seguridad en JavaScript? Nuevamente, haré esa pregunta. Voy a señalar una razón quizás sorprendente, que es que NPM resolvió dependency hell. Entonces, ¿qué es dependency hell? Esta es una imagen que probablemente hayas visto antes. Levanta la mano si has visto esto antes. Es como el meme favorito de todos, ¿verdad? Pero, ya sabes, cuando hablamos de dependency hell, no estamos hablando del montón de paquetes que terminan en tu carpeta de node modules, aunque eso es a menudo lo que la gente quiere decir cuando lo dicen hoy. Pero la definición original era en realidad muy diferente. Y así, para explicar eso, primero voy a, repasemos rápidamente qué son las dependencias transitivas.

Entonces, las dependencias transitivas son cuando instalas un paquete y luego ese paquete depende directamente de otro paquete y así sucesivamente. Y así decimos que el paquete A depende transitivamente del paquete C si hay un camino de dependencias directas a través del árbol. Entonces, ¿por qué es esto importante? Bueno, la definición original de dependency hell que si has estado programando digamos 10 años o más, definitivamente tal vez estés familiarizado con la definición original, que es que ocurre cuando pones tu aplicación en un estado donde no puedes instalar las dependencias. Estás simplemente atascado. Entonces, ¿cómo sucede esto? Bueno, sucede en este ejemplo aquí. Tenemos una aplicación que depende de foo client y bar client. Y cada uno de esos depende de requests, pero de diferentes versiones de requests. Y esto es en realidad cómo funciona Python. Así es como prácticamente todo antes de NPM funcionaba. Entonces, en esta situación, no podemos instalar este árbol de dependencias. El gestor de paquetes simplemente se rendirá. Simplemente levantará las manos y dirá, oh, quieres dos versiones de requests. ¿Cómo podría posiblemente instalar dos versiones del mismo paquete? Esto probablemente te sorprenda mucho si alguna vez has mirado en tu carpeta de node modules. Verás el mismo paquete allí a veces decenas, cientos de veces. No es realmente un problema para NPM. Pero prácticamente todo lo que vino antes de NPM no podía manejar esta situación. Y así, lo que eso significaba era que se volvía muy costoso para un paquete agregar dependencias. Porque si agregas una dependencia ahora en requests, has creado una situación donde ninguno de tus usuarios puede usar requests en una versión diferente en cualquier parte de su aplicación. Y así pensarías como cien veces antes de agregar una dependencia a tu proyecto. Y por eso estos otros ecosistemas que vinieron antes de NPM tenían árboles de dependencias muy pequeños. Muy pocas dependencias en general. Así que NPM simplemente dijo, hey, vamos a instalar todo. Como si quisieras la versión dos, la versión tres, no me importa si quieres cien versiones, simplemente las instalaré todas.

Y eso es realmente genial para la experiencia del desarrollador, porque nunca te encuentras en una situación donde no puedes continuar. Pero terminó realmente, realmente cambiando la forma en que escribimos software. Puedes verlo realmente en los últimos cinco años más o menos, donde hoy es súper común ver aplicaciones donde más del 90% del código en tu aplicación proviene de tus dependencias de código abierto y no del código que escribiste.

Y así... Quiero decir, supongo que debería explicar esa imagen antes de continuar. Pero esto es básicamente Express. Esta es una dependencia. Y cada caja gris es un paquete. Y cada caja morada es un archivo. Y básicamente está desglosando las capas de cada uno de estos paquetes. Un nivel del árbol a la vez. Y puedes ver dentro de cada paquete cuántos más paquetes y cuántos más archivos hay. Es una imagen un poco hipnotizante. Pero esta es solo una dependencia.

Así que aquí hay otra forma de ver esto. Esta es otra herramienta. Me encanta esta herramienta si no la has revisado. Npm.onvaca.com. Esto te muestra el árbol de dependencias. Y es como si las estuviera cargando progresivamente allí. Y esto es, nuevamente, una dependencia. Vemos que la dependencia promedio tiene 79 transitivas. Y cuando hablamos de la seguridad de nuestra cadena de suministro, lo que realmente queremos decir no es solo dependencias, sino en realidad todo de lo que dependes. Podría ser tu sistema operativo, API de terceros, servicios en la nube. Todos estos están involucrados en la seguridad de tu aplicación. Pero nos vamos a centrar en las dependencias aquí, porque es con lo que estoy más familiarizado.

Así que sí, y luego el repositorio promedio de GitHub tiene cientos de dependencias. Vemos algunos clientes nuestros que tienen 10, 20, 50,000 dependencias en toda la organización. Y desafortunadamente, el ecosistema está bajo ataque. Hay una gran cantidad de paquetes siendo secuestrados o teniendo malware añadido a ellos.

Y hemos visto un aumento del 700% en el último año. Y así que este es un problema. Así que esa es una razón. ¿Cuál es otra razón por la que la seguridad en JavaScript es difícil? Bueno, las diez principales vulnerabilidades web están cambiando constantemente. Así que echemos un vistazo a las diez principales de OWASP. Esta es una lista publicada frecuentemente de las diez principales vulnerabilidades web. Y vale la pena mirarla, especialmente porque está cambiando con el tiempo. La versión de 2025 de esto aún no se ha publicado. Pero podemos ver aquí los cambios de 2017 a 2021. Y solo señalaré algunas actualizaciones interesantes.

Así que el número uno, el control de acceso roto ha subido de la quinta posición a ser el primero.

Fallos criptográficos anteriormente se conocían como exposición de datos sensibles. Y eso fue renombrado y ahora se enfoca más en la causa raíz, que suele ser algún tipo de fallo criptográfico. La inyección ha bajado del número uno al número tres. Eso es principalmente, creo, debido a la adopción de frameworks. Cosas como React hacen que este problema desaparezca, prácticamente. A menos que te esfuerces por meterte en problemas. Y luego hay algunos nuevos.

Como el diseño inseguro es uno nuevo. Y los componentes vulnerables y desactualizados fueron renombrados para reflejar que no solo nos importan las vulnerabilidades. En realidad nos importa la salud de todo nuestro árbol de dependencias. Y creo que eso está apareciendo como número seis ahora mismo.

Así que en interés del tiempo, voy a repasar algunos puntos interesantes sobre estos bastante rápido, porque quiero asegurarme de que dejemos tiempo para las cosas divertidas que tengo al final. Pero el control de acceso roto, esto es cuando, ya sabes, piensa en cosas como tal vez tienes un botón de administrador en el cliente, y realmente no estás implementando una verificación en el backend para asegurar que solo los usuarios autorizados puedan acceder a él. Tenemos cosas como referencias directas a objetos inseguras, que son cuando no estás validando en el lado del servidor que los permisos son correctos. Si cosas como, ya sabes, manipulación de cookies, manipulación de JWT, necesitas asegurarte de que los usuarios no puedan entrar y cambiar esas cosas. Incluso en cores, asegúrate de no aceptar solicitudes de API de cualquier interfaz web en la web, lo cual, ya sabes, mucha gente pone la estrella, la estrella de cores allí para resolver sus problemas, pero, ya sabes, hay implicaciones para eso. Así que, ya sabes, revisa tus puntos finales de API, asegúrate de negar por defecto, asegúrate de que las cosas estén, ya sabes, autenticadas correctamente. Otro consejo, asegúrate de no servir tu carpeta .git. En realidad hay algunas cosas interesantes que puedes hacer rastreando las carpetas .git de las personas y extrayendo todo su código fuente. Así que podrías querer verificar que no estás haciendo eso.

Registrar fallos de control de acceso y notar cuando los usuarios han estado intentando iniciar sesión en la misma cuenta cientos o millones de veces, eso será una forma de saber que, ya sabes, podrías necesitar agregar un límite de tasa. Fallos criptográficos. Así que estas son cosas como, ya sabes, ¿estás usando HTTPS? ¿Estás usando algoritmos criptográficos seguros? Asegúrate de no registrar tus claves de API en tus repositorios. No envíes claves de API por Slack u otros mecanismos. Asegúrate de no usar math.random como una fuente segura de entropía. No lo es. Math.random no es seguro. Y obviamente, ya sabes, no uses funciones hash obsoletas como SHA-1. Honestamente, probablemente ni siquiera deberías estar haciendo autenticación tú mismo, francamente. Podrías querer simplemente usar un proveedor para esto porque hay mucha sutileza para hacer esto correctamente. Y luego creo que el mayor consejo aquí es realmente contratar a un pen tester. Esto es como una persona de seguridad que vendrá y tratará de romper tu aplicación y te enviarán un informe al final con todos los problemas que necesitas arreglar. Esto puede costar entre 10 y 20K y es una muy buena inversión.

Inyección. Así que no tengo mucho que decir sobre esto. Creo que frameworks como React han solucionado prácticamente este problema para nosotros. XSS no es realmente algo de lo que debas preocuparte si no estás haciendo un esfuerzo por usar cosas como dangerously set inner HTML.

Una de las cosas que diré es que si eres un autor de framework o un autor de biblioteca, deberías aprender del método de nombrado en React. Me encanta el nombre dangerously set inner HTML porque te hace cuestionar lo que estás haciendo 10 veces antes de hacerlo. En otras bibliotecas de plantillas que vinieron antes, como Pug o solía llamarse Jade, usan un hash para inyectar variables y un signo de exclamación para hacerlo de manera insegura, y es realmente fácil no notar la diferencia entre esos dos caracteres en una revisión de PR, pero es fácil notar algo que se llama peligroso. Un gran reconocimiento a esto. Si no has visto esto, esta es una variable en el código fuente de React o al menos solía ser, y de hecho, esto es bueno. Esto es realmente un buen nombrado. Realmente apoyo esto.

Así que diseño inseguro. Así que esto es un poco sobre las decisiones de diseño que tomamos a un nivel alto de cómo construimos nuestra aplicación. La clave aquí es que incluso si tienes bibliotecas seguras en cada etapa, si las juntas de una manera insegura, estás un poco perdido. Así que solo entiende que el diseño en sí mismo tiene que tener sentido. Un ejemplo sería hacer validación de formularios del lado del cliente. No importa qué tan buena sea la validación, es del lado del cliente. No vas a poder hacer eso seguro. Y luego, al pensar en este tipo de diseño seguro, solo te animaría a pensar en la seguridad desde el principio, tener conversaciones al respecto, asegurarte de que estás pensando en la experiencia del desarrollador dentro de tu empresa. Debería ser fácil para los desarrolladores hacer lo correcto. No deberían tener que recordar un montón de cosas. Lo fácil debería ser lo correcto. Y queremos herramientas que empoderen a los desarrolladores para ser autosuficientes y tomar sus propias decisiones. No queremos cosas que bloqueen al desarrollador o que desencadenen algo que el equipo de seguridad tenga que venir y revisar. Queremos construir herramientas que ayuden a los desarrolladores a hacer mejor su trabajo y poner información al alcance de sus manos.

Genial, y luego el último que voy a cubrir de OASP es solo componentes vulnerables y desactualizados. Y este es solo pensar básicamente en tus dependencias, tus dependencias de NPM. Los fallos en tus dependencias pueden ser de dos tipos. Son accidentales, lo que significa que hubo un error de codificación que crea un error de seguridad en tu aplicación, o podrían ser intencionales. Y estamos viendo muchos más de los intencionales en los últimos años.

Así que eso sería como algo así como una puerta trasera o algún código intencionalmente malicioso. Y voy a mostrarte algunos ejemplos aquí en un minuto que son, que podrían hacer que tus ojos se abran. Así que la forma de prevenir estos es que debes tener un inventario de qué dependencias estás usando.

Necesitas recopilar esta información de alguna manera. Obviamente, Socket puede ayudarte a hacer esto, pero necesitas saber qué estás usando y luego necesitas escanear ese inventario y entender cuáles de esas dependencias son vulnerables y cuáles son maliciosas, y necesitas tener algún plan para solucionar eso. Ahora, ups, presioné el botón equivocado. Bien, sí, solo para hacer esto realmente concreto, porque muchas veces cuando hablamos de seguridad de dependencias, puede ser realmente abstracto.

Así que solo voy a mostrarte algo que detectamos en las últimas semanas en Socket. Este es un código que se agregó a una dependencia, y solo voy a resaltar algunas partes para ti. Como puedes ver en la primera línea, estamos adquiriendo HTTPS para hacer una llamada de red. En la segunda línea, estamos obteniendo las variables de entorno, que son todas tus claves API, tus tokens, y luego en la tercera línea, este código las está enviando a este dominio que ha sido ofuscado aquí. Básicamente, si ejecutas esta dependencia, todas tus claves API se envían a un atacante tan pronto como ejecutas el paquete, buen trabajo.

Así que el problema fundamental aquí es que no se puede esperar que los desarrolladores lean cada línea de código en sus dependencias. Como, ninguno de nosotros está haciendo esto, aunque sentimos que tal vez, algunos de nosotros sentimos que deberíamos. Y así, esto es un problema. Solo quiero mostrarte algunos ejemplos en las últimas semanas de algunas dependencias interesantes que hemos identificado que solo te dan una idea del tipo de peligro que está ahí fuera en NPM si no tienes cuidado.

Así que este es uno divertido. Cuando instalas este paquete, hará curl a tu archivo de contraseñas a esa URL. Eso es agradable. Y esto es lo que nuestro herramienta, Socket, devolverá cuando analices este paquete. Te dirá que va a exfiltrar tus datos como ves allí. Pero usualmente no es tan simple. Usualmente es un poco más complicado. Así que aquí hay otro ejemplo de algo que detectamos recientemente. Esto es divertido. ¿Qué hace esto? Bueno, resulta que, a pesar de sus intentos de ofuscar el código, hay en realidad algunas cadenas aquí que son un poco sospechosas. Download.exe, eso no suena bien. Discord. No sé cuántos de ustedes usan Discord, pero déjenme decirles, si están usando un paquete y no tiene nada que ver con Discord y la cadena Discord aparece en el paquete, probablemente no es lo que quieres. Vemos a muchos atacantes básicamente robando datos y enviándolos a canales de Discord donde se reúnen. Así que usan la API de Discord para exfiltrar los datos. Y de todos modos, esto aquí, como puedes ver, está descargando un archivo ejecutable, ejecutándolo y luego es básicamente un virus que va a ejecutarse en tu máquina. Y luego te mostraré otro ejemplo aquí. Este es un nivel más profundo de ofuscación. Este realmente fue fascinante para mí cuando llegó. Así que este es un paquete donde miras esto, no parece tan raro, pero señalaré una cosa que es un poco interesante. Así que está haciendo HTTP y luego referenciando el resultado de esta función tipo.

Y al principio pensé, ¿qué está haciendo? Quiero decir, eso parece realmente extraño. Así que miré la función type y la función type es realmente extraña. Tiene estos comentarios aleatorios como West, question, e Ireland. Así que lo rastreé y me llevó un tiempo. Pero básicamente lo que está haciendo es llamar a PropGetter con el primer número allí, cero. Eso llama a PropValue, pasando la función PropGetter. Así que es una función que se pasa a sí misma a PropValue. Y luego pasa a través del número. Y luego PropValue elimina las líneas de comentarios y luego extrae las palabras, West, question, e Ireland. Y luego usa estos índices para cortar caracteres de las palabras. Y entonces lo que está haciendo es que ves 2 a 4 es ST, y luego 0 a 3 es QUE, y 1 a 3 es RE. Y luego toma esos y los invierte y los une. ¿Y qué hace eso? ¿Alguien puede adivinar qué es eso? Request. Así que está formando la cadena request. Y básicamente está llamando a una solicitud HTTP. Todo eso solo para ocultar el hecho de que está haciendo una solicitud HTTP. Así que esto es para eludir algunas herramientas que están buscando este patrón específico. Y es bastante aterrador. Pero nuestra herramienta lo detectó. Así que escribió este buen resumen. Esto es generado por LLM. Esto es usando IA, para escribir estos resúmenes. Y descubrió que está enviando variables de entorno sensibles a un atacante malicioso. Así que sí.

Así que me estoy quedando sin tiempo aquí. ¿Puedo pasarme un poco? ¿O tenemos un límite estricto aquí? ¿Pasarme? De acuerdo. La audiencia ha hablado. Sin embargo, no quiero afectar la transmisión. Está bien. De acuerdo. Genial. Increíble. Así que tal vez cuente una historia más aquí. Este es un incidente de 2017 que creo que es uno de los ataques más interesantes a NPM. Y es... Me gusta porque es lo que realmente me motivó a querer iniciar Socket como empresa. Así que lo contaré porque creo que es realmente interesante.

Hay un mantenedor llamado Dominic Tarr. Fue un prolífico autor temprano de NPM. Publicó más de 500 paquetes, de hecho. Y muchos de ellos no estaban tan bien mantenidos, porque era tan prolífico. Y uno de sus paquetes recibió una solicitud de función. No es tan raro. Esto sucede todo el tiempo. Y entonces... Y luego un mantenedor se ofreció... Lo siento. Básicamente, un voluntario se ofreció y dijo, oye, sabes, realmente no estás aceptando ningún PR en los últimos dos años. ¿Puedo ser mantenedor de este proyecto? Y Dominic dijo, claro. Ni siquiera estoy trabajando en esto más. Puedes quedarte con el paquete. Y le cedió la propiedad a esta persona al azar que le envió un correo electrónico. Esto tenía, como, 600,000 descargas cada semana. Así que era realmente popular.

Y lo que sucedió fue que... Pasó como un mes, y luego alguien notó una advertencia de deprecación que comenzaba a imprimirse por esta biblioteca. Y lo rastrearon hasta esta función, que estaba deprecada en Node. Y este fragmento de código que fue añadido al paquete. Ahora, todo esto está minificado. Es difícil ver lo que está haciendo. Pero si lo desminificas, puedes ver que hay... Hay como una carga útil de código encriptado que se está desencriptando usando una cadena. Y la cadena que está usando es el campo de descripción en la aplicación de nivel superior. Eso es lo que se está usando para desencriptar esta cadena y luego ejecutar esa cadena. Y lo que eso significa es que cuando este paquete se ejecuta dentro de una aplicación específica, esta aplicación aquí esa cadena, una billetera de Bitcoin segura, se usaría para desencriptar ese código y luego ejecutar ese código. Pero en las aplicaciones de todos los demás, tu aplicación, mi aplicación, todas nuestras diferentes aplicaciones, eso fallaría al desencriptar, porque no es esa cadena. Y así, esto solo estaba atacando esta aplicación de Electron. Y en las aplicaciones de todos los demás, no haría nada. Así que fue muy sigiloso, nadie realmente lo notó. Este módulo se integró en su producto, se envió a todos sus usuarios, y comenzó a robar criptomonedas de las personas. Directamente de la billetera. Así que realmente fue un desastre.

Así que, como pueden ver aquí, finalmente lo descubrieron. Esta fue la respuesta de Dominic, con la cual simpatizo totalmente. Básicamente dijo, mira, este tipo me envió un correo electrónico, quería mantenerlo, se lo di. No obtengo nada de mantener esto, ni siquiera lo uso, no lo he usado durante años, así que eso fue lo que hice. Así que eso es lo que puede pasar. Entonces, los paquetes maliciosos, realmente le toma mucho tiempo a la comunidad encontrarlos hoy en día. 209 días hasta que se descubren los paquetes. Y el 20% de estos duran más de 400 días. Así que estamos encontrando alrededor de cien de estos tipos de ataques cada semana con el escáner que hemos desarrollado. Así que es bastante.

Así que sí, creo que básicamente, ya sabes, la seguridad es, la seguridad de JavaScript es muy, muy difícil. Y una gran razón es que las herramientas que estamos usando simplemente no están diseñadas para detectar este tipo de cosas, y sin embargo nos están ahogando en alertas. Así que tenemos a muchas personas que simplemente, ya sabes, miran NPM audit, ven esto, ¿cuántos de ustedes han visto la salida de NPM audit y simplemente han dicho lo que sea? Como que no me importa, ¿verdad? Todos hacemos eso. Ya sabes, hay esta cosa famosa de Dan Abramov donde llamó a NPM audit una mancha en todo el ecosistema de NPM porque la forma en que fue diseñado está rota, y estoy totalmente de acuerdo con él. Creo que el problema con estos tipos de escáneres es doble. Uno, nos envían demasiadas alertas, más del 80% son falsos positivos o no son problemas reales. Y muchas veces el código vulnerable ni siquiera se ejecuta. O hay problemas en las dependencias de los desarrolladores que tampoco se ejecutarán en producción. Así que un problema es que es solo ruido. Y el otro problema es que ni siquiera detectan los peores ataques reales. No detectan las cosas que acabamos de repasar juntos, esos ejemplos de código malicioso. Ni siquiera tienen un mecanismo para encontrar eso. Así que todo el asunto está un poco desordenado, en mi opinión. La imagen del riesgo del código abierto es en realidad muy amplia y no se trata solo de vulnerabilidades. En realidad se trata de todos estos otros aspectos de si un paquete es bueno, si un paquete está mantenido, si es estable, si es fiable, y así sucesivamente.

Así que sí, en interés del tiempo, voy a adelantarme porque estoy yendo un poco más allá aquí. Pero solo terminaría con que la seguridad de JavaScript es difícil por un montón de razones. Y mi consejo final para ustedes es pensar en la seguridad desde el principio en su diseño. Tengan conversaciones al respecto. Cuanto antes puedan detectar problemas, les ahorrará mucho más tiempo que intentar añadirlo más tarde.

Utiliza frameworks y bibliotecas para cualquier cosa que sea sensible a la seguridad o asegúrate de que realmente sabes lo que estás haciendo. Sugiero cualquier cosa con auth o crypto o código de escape, cosas así. Usa una biblioteca. Y asegúrate de estudiar el OWASP top 10. Son solo 10 vulnerabilidades. Como, puedes leerlo en una hora y simplemente entender que las 10 principales vulnerabilidades web, serás un desarrollador mucho mejor si puedes entender las 10 principales. Y también, a medida que estas cambian con los años, estarás por encima de tus compañeros y podrás ayudarlos a mejorar.

Y luego, ya sabes, asegúrate de entender tus dependencias de código abierto. Usa algún tipo de herramienta moderna para escanearlas. Y asegúrate de que lo que sea que estés haciendo en tu empresa no esté destruyendo completamente la experiencia del desarrollador y haciendo que no sea divertido escribir código en tu empresa usando herramientas realmente malas que, ya sabes, te van a ralentizar. Así que, ese es mi consejo para ti. Gracias por tu tiempo y mantente seguro. Gracias.

Bien. Quiero decir, están llegando. Así que, voy a esperar hasta que se llene un poco más. Así que, comenzaste esto en 2017. 2020, en realidad. Bien. Pensé que tú... Bien. 2020. Fue cuando tuve la idea. Fue ese ataque de 2017, pero en realidad me tomó unos años para comenzar. Así que, te inspiraste en 2017, podría decir. Sí, exactamente. En tus viajes desde 2017 y especialmente desde 2020, ¿miras hacia atrás a un pre-2017, sabes, algunos momentos en los que piensas, oh, probablemente hice esto mal y hice aquello mal o algo así? ¿Tienes algún tipo de recuerdos? Sí. Eso es interesante. Creo que lo más importante es que siempre me importaron mis dependencias, probablemente más que a la mayoría de las personas. Siempre abría mi carpeta de Node modules y la miraba y pensaba, ¿qué es todo esto? Así que creo que probablemente soy raro en ese sentido.

Pero creo que lo que me asombra de la forma en que todos hacemos las cosas, y ciertamente cómo lo hacía antes de involucrarme realmente en este tema, es que todos simplemente instalamos código aleatorio de internet que no leímos. Y simplemente lo ejecutamos. ¿Y funciona en su mayoría? ¿Qué tan loco es eso? Descargas cosas aleatorias que ni siquiera verificaste, es código ejecutable, y luego simplemente lo ejecutas. Es realmente una locura. Es simplemente una locura que hagamos eso constantemente. Y en su mayoría está bien. Solo hay unas pocas excepciones que lo arruinan para todos, pero la mayoría de las personas son buenas.

Bien. Tengo una pregunta muy popular aquí. Socket versus Dependabot. Quiero decir, realmente no hay comparación. Esto es... Puedo hablar de eso, sí. Probablemente estén pensando en cómo se comparan. Sí, eso es lo que estoy pensando. Sí, sí. Entonces, Dependabot es una especie de buena base. Lo que no hace es ningún tipo de detección avanzada de ataques a la cadena de suministro de software que cubrimos. Entonces, si tienes una dependencia que ha sido comprometida, que tiene malware, que va a robar tus claves y ese tipo de cosas, Dependabot realmente no tiene un mecanismo para detectar eso. Tiene menos cobertura. Y parte de la razón de eso es que, no estoy criticándolos, pero ellos y todas las otras herramientas que vinieron antes, incluyendo NPM Audit y todo lo demás, están muy enfocadas en vulnerabilidades. Y hemos dicho, mira, las vulnerabilidades son importantes, pero el problema es, como dije, hay demasiadas. Hay mucho con lo que la gente tiene que lidiar. Y además de eso, están perdiendo los ataques más aterradores. Como si tienes un paquete que has estado usando y ha sido secuestrado por alguien y se ha añadido malware y lo actualizas, Dependabot y todo lo demás realmente no pueden detectar eso. Así que, en realidad, lo que hacemos es, cada dependencia, la descargamos, abrimos el tarball, miramos dentro, miramos todo el código, averiguamos qué está haciendo. Incluso usamos IA para revisar cada línea de ese código y preguntarle, ¿qué está haciendo este código, a dónde va, y luego hacemos una determinación sobre el comportamiento del paquete. Así que, en realidad, tuvimos un cliente una vez que estaba usando Dependabot y Socket juntos y un PR fue abierto por Dependabot y decía, actualiza a esta nueva versión. Y luego Socket entra un minuto después y deja un comentario justo debajo del Dependabot y dice, espera un minuto, no fusiones este PR, en realidad es malicioso. Y así fue la batalla de los bots.

Fue bastante divertido.

Bien. Hablando de IA, acabas de mencionar, una pregunta aquí de Roger. ¿Qué piensas del impacto que tiene la IA en el campo de la seguridad? Quiero decir, va a tener un gran impacto. Creo que, ya sabes, por supuesto, hay mucho bombo en este espacio y durante la mayor parte de los últimos 10, 15, 20 años, cada vez que alguien ha dicho IA y seguridad, siempre ha sido humo y espejos y completamente exagerado y nunca real. Pero creo que eso está cambiando con la última iteración de LLMs. Ya sabes, hay todas las cosas obvias, la gente construyendo chatbots y cosas así, como, oh, puedes hablar con tu, ya sabes, repositorio y cosas así. Eso es interesante, pero creo que la verdadera pieza subestimada de los LLMs es que realmente pueden hacer, como, análisis. Así que pienso en ellos como, hoy están al nivel de un estudiante universitario, tal vez, ya sabes, tal vez un poco mejor, tal vez un poco peor. Pero puedes pensar en ellos como, como una fuerza laboral gratuita para enviar a hacer tu voluntad. Y para lo que lo usamos es, ya sabes, ninguno de nosotros está leyendo nuestra carpeta de módulos Node, Así que simplemente dejemos que los bots lean la carpeta de módulos Node y busquen cosas. Básicamente, esa es la forma de pensarlo. Es un ejército masivo de, como, trabajadores robot de bajo costo que simplemente pueden ir y hacer nuestra voluntad por nosotros. Y así, esa es, como, la única forma en que realmente, realmente está ayudando. El otro gran impacto que está teniendo es en todas estas herramientas de copilot que estamos usando para escribir código. Diría que el mayor riesgo al usarlas hoy es que han sido entrenadas en mucho código vulnerable, como todo en Stack Overflow y, ya sabes, estos viejos blogs. Y así estamos viendo casos donde, ya sabes, la IA está recomendando que instales dependencias que no son seguras en absoluto, como que no se han actualizado en cinco años. Simplemente son populares. Simplemente son populares, o eran populares hace cinco años en el blog en el que la IA fue entrenada. Sí. O incluso hemos visto casos donde alucina nombres de paquetes que no existen.

Así que estas son todas diferentes fuentes de riesgo al usar IA, donde queremos tener, como, al menos otra capa para verificar lo que está generando. Bien. Estamos 30 segundos por encima, pero quiero hacer esta última pregunta porque siento que fue una buena. ¿Cómo deberíamos... Oh, no, no, no. ¿Qué pasó con eso? Bien. ¿Qué está haciendo Socket para abordar el problema del ruido en las alertas de seguridad? Es una gran pregunta.

Creo que lo primero es simplemente enfocarse en las cosas que son más severas. Así que si, ya sabes, miras las cosas de las que estábamos hablando en esta presentación, casi todas esas cosas van a ser más altas que la, como, vulnerabilidad más alta. Me gusta pensar en ello como, ya sabes, una vulnerabilidad es como dejar tu puerta principal sin llave. Así que probablemente no sea una gran idea hacer eso para siempre, pero puedes hacerlo por un mes y estar bien, ya sabes. Si alguien no está probando tu puerta principal, vas a estar bien. Eso es lo que es una vulnerabilidad.

Mientras que un ataque a la cadena de suministro o un paquete malicioso, eso es como alguien irrumpiendo en tu puerta principal, ¿verdad? Y así, la mejor manera de abordar el problema del ruido es simplemente priorizar esos correctamente y decir, me voy a enfocar en las cosas más importantes primero. Y voy a despriorizar todo lo demás.

Genial. Genial. Muchas gracias. Hubo muchas preguntas. Así que voy a decir esto. Si quieres seguir en contacto con Frost, por favor, creo que va a, ya sabes, la sección de preguntas y respuestas en la sala junto al otro área en esa especie de estructura de vidrio.