Controles de seguridad en la cadena de suministro de JavaScript

Y ahora... Bueno, gracias a todos por acompañarme hoy. Mi nombre es Yaron Tal y soy un defensor del desarrollo en Snyk. Voy a hablar sobre varias historias que ocurren en el ecosistema de JavaScript, en el cual estoy involucrado en varias partes a través de mi trabajo en Snyk, tratando de ayudar a los desarrolladores, a ti y a mí, a todos nosotros, a construir software seguro, enviarlo, ya sea en tu CI o IDE o lo que sea.

Es una forma realmente genial de interactuar y comprometer a los desarrolladores. Pero a través de ese trabajo, también hago muchas cosas con una comunidad, que es a través del proyecto de seguridad de OS, o tal vez a través de cosas como la seguridad de la fundación de Node, triaje de vulnerabilidades y mucho trabajo en torno al código abierto. Y eso me ayuda a tener una imagen clara de lo que está sucediendo, hacia dónde van las cosas.

Entonces, dicho esto, hoy me gustaría compartir con ustedes algunas historias del mundo real y contarles cómo los desarrolladores como ustedes desempeñan un papel fundamental y clave en el ecosistema de seguridad e incluso en los incidentes de seguridad que han ocurrido recientemente. También, cuál es el estado actual de la seguridad y la seguridad de la cadena de suministro en el código abierto y el ecosistema de JavaScript.

Ahora, me doy cuenta de que esto probablemente todos lo relacionan de una manera muy emocional, ¿verdad, cuando haces un npm install? ¿Sí? Así que estoy aquí para decirles que está bien. Estás sintiendo algo que todos nosotros sentimos antes de hacer un npm install, y esta charla en su conjunto básicamente tratará sobre por qué te sientes así, pero también te dará algunas medidas preventivas, algunos controles de seguridad que puedes tener y agregar mañana en tu equipo para poder mitigar los riesgos en torno a las cosas que suceden allí.

Así que ese sentimiento que tienes, si puedes relacionarte con eso, se basa en una investigación científica fundamental. Uno de esos casos hace un par de años nos mostró cómo cuando instalamos el paquete promedio de npm, depositamos mucha confianza en los mantenedores y las dependencias de terceros que estamos trayendo. Al instalar el paquete promedio de npm, probablemente estás confiando en alrededor de 79 dependencias de terceros y 39 mantenedores. Eso es mucho. Eso significa que probablemente habrá mucho ruido y potencialmente dolor para tal vez también remediar algunas de estas cosas. Pero esta es la verdad de las cosas.

Y también estoy aquí para decirles que esta no es una preocupación nueva. De hecho, todo este asunto de dónde depositamos nuestra confianza como desarrolladores y cuánto debemos confiar, qué debemos confiar exactamente, es algo de lo que se ha hablado hace casi 40 años. Esta persona llamada Ken Thompson, es un desarrollador galardonado con el premio Turing, y en realidad fue a crear este ensayo llamado Reflexiones sobre la confianza en la confianza. Recomiendo encarecidamente leerlo, pero solo te daré la idea de lo que realmente significa.

Esta persona se fue y dijo: quiero mostrarte lo que significa confiar en las personas. Y luego agregó una puerta trasera al programa de inicio de sesión de Unix. Pero, por supuesto, la gente revisa el código, ¿verdad? En el código abierto. Entonces, continuó esta cadena agregando la puerta trasera al compilador que luego compila el programa de inicio de sesión y luego lo inyectará. Pero bueno, la gente también revisa el código del compilador. Bueno, ¿cómo se compilan los compiladores? Necesitas un punto de entrada para empezar. Y así que en realidad fue y agregó esa puerta trasera.

Eso es algo que Rojan quería mostrarnos como un experimento de cómo funciona esto. Lo agregó al compilador que luego compila el programa de inicio de sesión de Unix. Entonces, si revisas el programa de inicio de sesión de Unix y si revisas el compilador, en ese punto ya no lo verás. Porque aún necesitas un compilador binario para luego compilar todo eso. Y ahí es donde ocurren las cosas. Ahí es donde se inserta la puerta trasera.

Una visión muy interesante que revela cómo el software tiene características y cómo las transmite a otros programas específicos de los que se genera. Así que recomiendo encarecidamente leer esto. Pero nos muestra por qué la confianza es importante y cuánto más debemos avanzar para depositar esa confianza en algún lugar.

Aún así, el Open Source es genial. Y no podemos negar el hecho de que para construir software hoy en día, necesitamos usar software de Open Source, incluso cuando tal vez el programa que construimos no sea Open Source en sí mismo, tal vez la mitad de él o lo que sea. Pero esa es un poco la realidad. Y por supuesto, ¿por qué no? ¿Por qué no usar software de Open Source, verdad? Porque en realidad lo que realmente queremos no es reinventar la rueda. Queremos usar el trabajo que han hecho personas geniales, y luego podemos tomar ese trabajo y usarlo para practicar. Y esta es una gran herramienta de productividad.

Así que a estas alturas, estoy bastante seguro de que estamos alcanzando esa marca de dos millones en NPM. No sé. Es asombroso para nosotros, para todos ustedes aquí, ayudándonos a promover el software de Open Source. Pero al mismo tiempo, debemos entender y reconocer este regalo que se nos ha dado, que el Open Source ha sido dado al mundo, y lo que realmente significa. Entonces, todos esos paquetes, son esencialmente el suministro. Esto es parte de la historia de la seguridad de la cadena de suministro. Y es relativamente fácil pensar para nosotros que todas esas seguridades de la cadena de suministro pueden ser dependencias de NPM. Pero en realidad no es solo eso. De hecho, si retrocedemos hasta los conceptos básicos de cómo se construye el software, podemos ver que tenemos varios puntos de conexión a lo largo del camino. Entonces, eres un desarrollador, estás construyendo algo, tal vez lo estás subiendo a GitHub. Esa es básicamente tu control de origen, luego se desencadena una compilación, luego hay alguna salida de eso. Tal vez eso es esencialmente un paquete o tal vez se está lanzando a algún CDN o lo que sea. Y estás usando algún software de Open Source a través del proceso de compilación. Entonces, todo eso es básicamente cómo estamos construyendo software. Pero aquí están los puntos de integración de lo que la seguridad de la cadena de suministro significa en el nivel más básico.

Esencialmente, cualquiera de estos puntos de intersección puede insertar código malicioso, como hemos visto. Por ejemplo, el compromiso hipócrita de Linux que ha estado ocurriendo, creo que fue el año pasado con un incidente de una universidad que lo había insertado para hacer el punto de, ya sabes, Ken Thompson, si quieres relacionarlo con eso. Y comprometer el control de origen es algo que está sucediendo. Por ejemplo, el control de código fuente de PHP no se gestionaba en GitHub y alguien pudo acceder a los servidores Git de PHP y potencialmente modificar el código. Eso son millones de servidores que se ejecutan en Internet y obteniendo, ya sabes, las puertas traseras o los troyanos de eso. Y hay más y más, alguien puede modificar nuestro código, su compilación podría estar comprometida, tal vez no estamos, ya sabes, construyendo esas acciones de GitHub correctamente con las mejores prácticas. Tal vez estás usando una dependencia defectuosa como hemos visto con EventStream. Tal vez, el resultado real de lo que construyes, lo que tus consumidores realmente obtienen, en realidad no pasa por los procesos formales de CI/CD, lo cual es una historia de seguridad muy relacionada para nosotros en el ecosistema porque CodeCup fue parte de este problema donde el binario fue cambiado detrás de escena. Todo esto es cómo se está construyendo el software hoy en día y esta es toda la historia de seguridad de la cadena de suministro. El paquete de NPM es parte de ello, pero no es todo. Aún así, creo que estamos viendo que los desarrolladores están siendo objetivo en este momento y desde hace algunos años, si no más, como vehículos de distribución de malware o simplemente como objetivos de ataques dirigidos para robar todos nuestros tokens para NPM y para GitHub y para todo lo demás porque lo que tenemos en nuestras computadoras portátiles son, bueno, tenemos secretos para producción, ¿verdad?, y claves de acceso para entornos de preparación y todas esas cosas. Entonces, si instalas un paquete de NPM, eso es como si hiciera algo malo, deberías preocuparte por eso. Dicho esto, esta especie de introducción, vamos a hablar sobre algunas medidas preventivas, como qué puedes hacer, qué podemos hacer como controles de seguridad para este ecosistema. Comenzando con algo que he hecho en el pasado, que es la manipulación de archivos de bloqueo y Myle, que ha estado aquí abriendo la sesión hoy sobre Yarn 4, ha hablado de esto y de los aspectos de seguridad de los gestores de paquetes y cómo se está mitigando ahora. En 2019, revelé investigaciones sobre posibles problemas de seguridad con los archivos de bloqueo y tiene que ver con los archivos de bloqueo en Yarn y NPM y lo que sea, básicamente cómo se gestionan. Así que tomemos un enfoque práctico y veamos qué significa esto realmente. Esta es una captura de pantalla de cómo abrí una solicitud de extracción a un repositorio. Estoy bastante seguro de que todos pueden reconocer lo que está sucediendo aquí. Básicamente, no hay ningún cambio de código que haya propuesto, pero esta solicitud de extracción aún incluye un paquete malicioso. Aquí hay un troyano oculto en esta solicitud de extracción. Y este es todo el código de la solicitud de extracción, solo esto. Package JASON y el archivo de bloqueo. Entonces, ¿qué está pasando realmente allí? Porque parece que esto no es un tipo de ataque de usurpación de identidad porque esos nombres de paquetes son legítimos. Las versiones coinciden. Y si estuvieras ejecutando algo como sneak en una integración de git, te diría que al hacer una solicitud de extracción, realiza una verificación y ninguna de estas bibliotecas y versiones específicas introduce nuevas vulnerabilidades. Entonces, en esencia, todo parece estar bien aquí, ¿verdad? Bien. Bueno, aquí hay un archivo de bloqueo de yarn, que todos ignoramos amablemente, ¿verdad? Porque, ¿quién quiere revisar este código? Yo no. Así como no quiero revisar las expresiones regulares, ¿verdad? Esto no se supone que sea legible por humanos ni consumible por humanos. Aún así, esto representa una amenaza. Veamos qué es. Expandí esto y, ya sabes, este es mi archivo de bloqueo.

Y si comenzaras a revisar esto, y puedes ver que hay un cambio de línea de aproximadamente 5,000 o lo que sea, esto es bastante largo. Así que desplazaré un poco hacia abajo y trataré de revisarlo juntos. Desplazarse, desplazarse, desplazarse. De acuerdo. ¿Lo ves? ¿Ves el problema? Aún no. Casi. Ahí vamos. De acuerdo. Todo lo que necesito hacer cuando doy esa solicitud de extracción a un proyecto es utilizar esta función realmente genial de los gestores de paquetes en, ya sabes, como npm y Yarn, que básicamente nos permite instalar paquetes de cosas realmente extrañas como un gist de GitHub. Como el tarble, básicamente los commits principales de un repositorio de control de origen. Así que puedo hacer eso. Una vez que tenga la verificación de integridad y todo lo demás esté correcto, puedo seguir adelante y empujar esto en mi solicitud de extracción o puedo cambiar la fuente de ms, no de npm, sino de mi propio GitHub, e instalarlo, y estoy diciendo que este es un paquete malicioso porque una vez que lo instales, puedo introducir algunos scripts de post-instalación que ejecutarán algunos comandos y puedo instalar lo que quiera en tu máquina. ¿Cómo mitigamos esto? Aquí es donde revelé esta investigación y se me ocurrió la idea de realizar un análisis de calidad del archivo de bloqueo. Así que una de esas cosas, todos usamos linters para diferentes cosas, como JS lint para la calidad de tu código y código limpio o lo que quieras usarlo, lo cual es genial. Este es otro que probablemente deberías considerar agregar porque esencialmente te brinda la capacidad de decir que tu archivo de bloqueo debe tener políticas de confianza específicas. Por ejemplo, incluso sin relación con el origen de donde proviene algo, el host permitido aquí. Pero tal vez algún software se esté instalando desde una conexión HTTP que permite a las personas realizar ataques de intermediario. Así que quieres tener esta política de confianza y así es como lo haces. Úsalo en tu CI o tus charlas previas a la copia o lo que estés usando, pero esencialmente quieres tener más medidas de mitigación. Además de tal vez usar esto, debes tener en cuenta dos cosas aquí, ¿verdad? En primer lugar, probablemente no quieras permitir ni recibir contribuciones a los archivos de bloqueo debido a este problema porque, realísticamente, ninguno de nosotros va a revisar realmente esas líneas de código de un archivo de bloqueo. Así que no abramos esta puerta en primer lugar. Y también en lo que respecta a cómo gestionamos las dependencias, básicamente quieres poder delegar toda esta gestión de dependencias a algunos bots porque son buenos en eso y pueden, ya sabes, generar esas solicitudes de extracción automáticas para nosotros. Así que eso es otra cosa que debemos tener en cuenta.

Continuando. La ejecución arbitraria de comandos para todos nosotros. Eso es como una característica de los gestores de paquetes. Es increíble. Veamos. NPM install callers. Voy a copiar y pegar eso en mi terminal pero... Sí. Tal vez debería tomar unos segundos antes de ejecutar ese comando. Y debería hacerlo, porque esto realmente sucede. NPM, como gestor de paquetes, permite que cualquier dependencia a lo largo del árbol, sin importar cuán grande o pequeña sea, ejecute comandos antes o después de que algo en ese árbol se instale. Y así, si continuara e hiciera NPM install callers en el día, cuando realmente se envió una versión maliciosa de callers al registro de NPM, estaría exponiéndome a paquetes maliciosos o tal vez a módulos comprometidos, mantenedores y cosas así. Así que esto realmente sucedió. En enero de 2022, en caso de que te lo hayas perdido, si hubieras instalado NPM callers, eso es algo que habría sucedido.

Pero profundicemos un poco para comprender qué está sucediendo. Y callers ha sido saboteado por su propio mantenedor para ejecutar algo, no entraré en detalles, pero eso ha estado sucediendo, puedes ver que no ha tenido ninguna descarga en los últimos dos años. No, como, lo siento, no ha tenido nuevas versiones en los últimos dos años. Pero de repente se ha lanzado una nueva versión de parche, y en este momento, muy, muy rápidamente, solo en los últimos siete días, ha obtenido alrededor de 100K de descargas para usuarios finales que descargan esta versión. ¿Qué está pasando con esta versión que todos esos 100,000 usuarios han estado descargando, tal vez tú y yo? Veamos.

Básicamente, ese código saboteado introduce una denegación de servicio en este paquete. Si has utilizado callers de alguna manera, es posible que tu aplicación se haya roto debido a esto. También puedes ir y ver el repositorio de GitHub, donde sugieren a las personas que participen y sugieran formas más eficientes de hacer bucles infinitos. Muy recomendado. Open source, ¿verdad? Increíble. Recibimos muchos comentarios al respecto. Y podrías pensar, como callers, no lo estoy usando en mi proyecto, como, nunca lo he visto, ¿verdad? Excepto que estás en el ecosistema de JavaScript. No lo estás usando. Hasta donde sabes. Pero ¿has verificado si alguna de tus dependencias lo está utilizando? Bueno, aquí tienes un ejemplo, un ejemplo real de por qué esto es tan impactante. Si estuvieras utilizando AWS CDK de Amazon, habrías sido, ya sabes, objetivo de esto. Porque AWS CDK lo utiliza no solo. Muchos otros paquetes también lo utilizan. Algunos de ustedes pueden conocer, como Salesforce, como una herramienta de prueba, como un framework de testing. Todos ellos utilizan este paquete en algún lugar del árbol. Y si lo hubieras tenido, habría roto tus flujos de trabajo. Todo el árbol de dependencias es realmente grande. Y callers es impactante. No entraré en detalles. Pero te diré que este es un problema muy grave que ocurrió en el ecosistema. Entonces, ¿qué podemos hacer para mitigar esto? Una de las primeras cosas es, por supuesto, si haces una instalación de NPM, por favor, por favor, por favor agrega --ignore-scripts. Agrega esos guiones, posiblemente a cada comando de NPM que ejecutes, o a tu archivo NPM o C. Nadie puede ejecutar comandos arbitrarios en tu máquina. El inconveniente es que podría romper algunas cosas, como si estás instalando Node sass o algo así, podría necesitar ejecutar alguna compilación nativa. Podría romperse.

Entonces, necesitas encontrar una solución para estos problemas. Pero la mayoría de nosotros probablemente no necesitemos confiar en todo y en todos por defecto, lo cual es una inseguridad. ¿Qué tal evitar actualizaciones ciegas?

Otra cosa que he estado viendo, sabes, al hablar con desarrolladores todo el tiempo. Como, tienen en su CI cosas como ejecutar una actualización de NPM, ejecutar un comando de verificación de actualización de NPM, y básicamente lo están ejecutando en CI, porque quieren poder en CI siempre actualizar a la última versión y probar que ninguno de los paquetes en los que dependen haya roto su código. Lo cual, quiero decir, es comprensible por qué lo hacen, pero te expone nuevamente a una gran cantidad de problemas que podrían estar sucediendo. Incidentes de seguridad como confusiones de dependencias y un montón de otras cosas, como, por qué querrías estar ahí. Si hubieras hecho eso en tu CI y ese CI se estuviera ejecutando en esos días en los que callers estaba fuera, donde NodeIPC estaba fuera, todos esos incidentes de seguridad, estarías obteniendo automáticamente esas versiones maliciosas. Entonces, ¿por qué querrías hacerte esto a ti mismo?

Entonces, necesitas pensar en cómo hacer esto bien, ¿verdad? No con una actualización, sino con contexto. Lo cual significa, por favor, nuevamente, usa esos bots automatizados. Puedes usar GitHub o sneak, lo que quieras. Pero úsalos para agilizar esas actualizaciones de paquetes. No a través de un método que les dé acceso completo a tu máquina. De hecho, algunos de ellos pueden protegerte. Por ejemplo, con sneak, lo que hemos hecho es realizar actualizaciones de NPM para tus paquetes. No solo por razones de seguridad, sino también porque están desactualizados. Pero cuando lo hacemos, si Node IPC o callers 141 acaban de salir ayer, no te damos inmediatamente esas actualizaciones. De hecho, hemos investigado una serie de incidentes de seguridad que ocurrieron en el pasado. Y lo que estaba sucediendo allí y cuánto tiempo le llevó al ecosistema solucionarlos. Y es por eso que tenemos este retraso inherente de aproximadamente 21 días antes de sugerir una nueva versión actualizada del paquete. Entonces, si algo malicioso está sucediendo en este momento, no recibirás ese paquete malicioso al día siguiente, antes de que todos hayan tenido tiempo de react a esto.

El número cuatro es lo que ves no es lo que ejecutas. Es uno de mis favoritos. Sé cuántos de ustedes han oído hablar del ataque de origen troyano. Pero vamos a analizar un poco de código. Aquí hay un poco de código que tomé de un middleware de Fastify. Es como un ejemplo de Node JS. Puedes echarle un vistazo por un segundo, mirarlo y decirme dónde ves la vulnerabilidad. ¿Está en el primer párrafo, en el segundo párrafo, en el tercer párrafo, está todo bien? Por supuesto, ustedes son desarrolladores, ¿qué estoy pensando? Solo lo resaltaré y lo encontrarás de inmediato.

¿Lo encontraste? Bien. Veamos qué está pasando. De hecho, este código tiene un problema. El problema no está en el código en sí. El problema está en cómo está escrito el código. No estoy hablando de errores lógicos o malas comprobaciones. Lo que estás viendo aquí no es lo que el compilador o el intérprete de JavaScript van a ver. De hecho, si quiero enfocarme en esto y darte una forma diferente de ejecutarlo, puedo copiarlo y pegarlo en VS Code, ejecutarlo, aquí tienes un ejemplo. Mismo código. ¿Qué cambió? Nada. Si lo ejecuto, me dirá que eres un administrador. ¿Pero por qué? Esto es semánticamente incorrecto. ¿Por qué sucede esto? Sucede porque lo que no estás viendo, lo que tu IDE no te está diciendo y cuando revisas tal vez un código fuente en GitHub, lo que no estás viendo es esto. No ves que tiene caracteres de control en UDF que en realidad están cambiando la forma en que se muestran las cadenas. Y lo que estás viendo en realidad es un comentario oculto dentro del código. Y eso cambia toda la lógica de cómo funciona el código. Incluso si recibes esto como una contribución de código y lo apruebas porque está bien. Pero nos estábamos perdiendo todo esto. Afortunadamente, esta investigación sobre ataques de origen troyano, que ocurrió en el último año, se ha divulgado de manera responsable. En este momento, si revisas cosas en, ya sabes, VS Code, si usas, por ejemplo, la extensión Speak, o si revisas código en GitHub, todas esas ya han adoptado, cuando suceden cosas así, te muestran un mensaje de advertencia en la parte superior que te dice que potencialmente hay, ya sabes, caracteres de control aquí, echa un vistazo a esto, y hacen que sea visible. Pero antes no era así, y solo descargué una versión antigua de Atom de hace un año y te mostré la copia exacta de cómo funciona esto.

Entonces, algunas ideas para mitigarlo. Ahí vamos. Me gusta ese perro. En general, me gustan los perros, así que encaja. Entonces, los ataques de origen troyano, ¿verdad? Tenemos algunas formas de mitigarlos y, básicamente, lo que queremos hacer es poder mitigarlos lo más rápido posible. Nuevamente, ya tienes esto en los IDE de VSCode y cosas así. Y puedes hacer esto y usar eso o puedes usar un complemento de ESLint que escribí y no importa qué versión de VS Code estés usando, versiones o IDE, simplemente los detectará y te informará sobre esto.

A continuación, evitando la confusión de dependencias. Vamos a ver qué significa realmente esto.

Lo explicaré rápidamente hacia el final. Esta ha sido una investigación que ha estado en marcha en el ecosistema durante bastante tiempo y muchos probadores de penetración reales la han utilizado para intentar ingresar a los sistemas internos de las empresas debido a la forma incorrecta en que gestionan las dependencias y la configuración a su alrededor.

Hay mucho de esto, no entraré en cómo funciona todo esto, pero básicamente la confusión de dependencias se origina cuando los paquetes privados alojados internamente por una empresa no se encuentran en el registro de NPM. Ese espacio está abierto y disponible para que cualquiera se registre y luego una mala configuración podría permitir que alguien tome ese espacio de nombres, agregue código malicioso como un comando de instalación de NPM y lo ejecute en tu máquina. ¿Cómo se mitiga esto? Bueno, hay muchas herramientas bastante simples hoy en día. Pero si haces cosas como, nuevamente, actualizar NPM o gestionar manualmente tus dependencias, hay muchas posibilidades de que seas vulnerable a esos ataques de confusión de dependencias. Así que, nuevamente, no hagas esto. Ves que es un tema recurrente en diferentes tipos de ataques. Mitigar esto es bastante fácil si quieres usar una de esas herramientas. Así que la creamos en ese momento. Se llama Snyk. La idea es que escanea tu archivo package JSON. Incluso escanea tus commits de Git para entender cuándo insertaste un paquete privado y cómo se relaciona eso en términos de tiempo con lo que está en NPM. Te dará este tipo de advertencias donde potencialmente estás vulnerable o tal vez hay una forma sospechosa de algún paquete que existe. Pero no estamos seguros si es malicioso o no.

Con todo eso dicho, muchas gracias. Vamos a tiempo. Gracias a todos por venir a mi charla y espero que todos escriban código seguro. APLAUSOS. Muchas gracias. Creo que todos estaban tomando notas. ¿Verdad? De lo contrario, compartiré las diapositivas después. Gracias. Preguntando por un amigo. Comparte las diapositivas. Si aún tienes preguntas, colócalas en Slido para que pueda leerlas desde la pantalla aquí. Entonces, para elegir una, ¿qué piensas sobre la seguridad introducida por características como MPM ignora los scripts cuando un módulo de nodo puede acceder a DFS en cualquier momento durante – en tiempo de ejecución? Sí. Excelente pregunta. Hay algunas discusiones al respecto.

En realidad, se ha hecho: la Fundación Node, o hoy la Fundación OpenJS, tiene un grupo de trabajo de seguridad en el ecosistema, por lo que también podrías unirte a eso, y todo eso se gestiona de manera muy transparente y abierta en GitHub, por lo que realmente puedes unirte a las discusiones, las llamadas mensuales, etc. Ahora hay una discusión reciente sobre establecer un modelo de amenazas para las aplicaciones de Node, algo así como esto está relacionado con toda la demostración versus Node.js, en términos de aspecto de seguridad. Así que se está discutiendo allí. Una de mis ideas, por supuesto, sería genial si hay una forma de que podamos, en esencia, ser capaces de compartimentar o departamentalizar todas las capacidades de tal vez módulos específicos, tal vez toda la aplicación o lo que sea, pero esta es una amenaza real de todos modos, independientemente de NPM. Y así, esto es algo bueno que todavía necesitamos solucionar. Muy bien, y ¿Snyk planea...? Vaya, las cosas se están moviendo. ¿Se puede usar Snyk para automatizar las comprobaciones de seguridad en CI/CD? Sí, eso es algo bastante genial donde si simplemente... Así que no lo dije antes, pero Snyk es gratuito, puedes usarlo con la seguridad y lo que quieras. Y básicamente, cuando conectas tu repositorio de git con Snyk, esa será probablemente la experiencia más productiva que puedas tener, porque en ese punto, no necesitas ejecutarlo en CI tú mismo. Agregamos los ganchos de comprobación, escaneamos específicamente las nuevas vulnerabilidades, si las solicitudes de extracción existentes agregan vulnerabilidades existentes o no, si quieres que falle, supervisaremos la aparición de nuevas vulnerabilidades, por lo que todo el proceso y no necesitas... Hay una CLI y demás, pero no necesitas todo eso, también automatizaremos las solicitudes de extracción para solucionar problemas por ti, por lo que esa será una integración ideal. Buena pregunta también. Me perdí algo de tu presentación, no sé, la llamada de XKCD sobre las dependencias que son gestionadas por una sola persona en Nebraska por años. Eso es para una charla diferente sobre el mantenimiento de código abierto... Creo que también está relacionado con la seguridad, ¿verdad? Además de verificar nuestro código y asegurarnos de que no estemos haciendo nada menos inteligente, también debemos apoyar el código abierto de manera que sea más sostenible. ¿Qué piensas al respecto? Debemos hacerlo, debemos hacerlo. Quiero apoyar el código abierto de cualquier manera que pueda, así que estoy a favor de eso. ¿Snyk tiene un programa especial para los mantenedores de código abierto, para que puedan obtener créditos o algo así? Sí, de hecho, acabamos de concluir en mayo, algo así como esta campaña de amor de Snyk JS donde investigamos muchas de las dependencias de JavaScript que usamos y fuimos al perfil de GitHub de ellas y las patrocinamos. Eso es lo que hicimos. Eso es realmente emocionante. Gracias. ¿Dónde podemos obtener más información al respecto? Solo busca en Google Snyk JS love, creo que lo encontrarás. Genial, muchas gracias por tu charla. Gracias a las personas que hacen preguntas. Vamos a... Hay un stand de Snyk, puedes venir y preguntarme en el stand. Sí, y hablando del stand, también te unirás a la pequeña caja negra donde puedes hacer más preguntas, ¿verdad? Oh, cierto. Sí, sí. Porque en realidad, tal vez nuestras personas remotas también estén ansiosas por hacerte preguntas. Espero que no estén ansiosas. Así que definitivamente únete a eso. Bueno, tal vez no ansiosas, pero aún interesadas. Así que por favor únete también al stand de preguntas y respuestas allí. Sí.