El Lado Oscuro del Open Source

Primero, un poco sobre mí. Comencé en el código abierto. Trabajé en algunos paquetes bastante populares, incluyendo WebTorrent y StandardJS, y también fui miembro de la junta directiva de la Fundación Node.js. Así que realmente pude ver un aumento masivo en el uso de código abierto dentro de las empresas y en la community. Luego me centré más en la security. Enseñé el curso de web security en Stanford, y ahora estoy trabajando en seguridad de código abierto en Socket.

Muy rápido, solo unas palabras sobre Socket. Socket es una herramienta que ayuda a proteger tu code del de los demás, y ayudamos a los desarrolladores y a los equipos de security a enviar más rápido y pasar menos tiempo en el trabajo ocupado de la security ayudándoles a encontrar, auditar y gestionar software de código abierto de forma segura. Tenemos un montón de empresas que nos utilizan. Muchas de ellas son proyectos de código abierto, y hoy en día protegemos más de un cuarto de millón de repositorios. Así que estoy muy contento de haber podido ayudar a proteger a la community en este grado.

Bien, hablemos un poco sobre nuestras aplicaciones. En los últimos cinco años, la forma en que escribimos software ha cambiado mucho. Ha experimentado un cambio realmente masivo. Hoy en día es muy común ver aplicaciones en las que más del 90% del code proviene de dependencias de código abierto. Esto significa code que tus desarrolladores, tú sabes, tú y tus compañeros de equipo no escribieron. La dependencia promedio de código abierto en realidad tiene 79 dependencias transitorias. Así que en este mundo donde tu aplicación se basa en, ya sabes, miles de dependencias, la security del software no se trata solo de tu code. Se trata de cada pieza de code en la que dependes. Y en esta charla vamos a hablar de las dependencias de código abierto porque somos desarrolladores de JavaScript, pero, ya sabes, esto es en realidad un problema más amplio. Si piensas en el término cadena de suministro de software, eso incluye realmente todo el código de terceros en el que dependes, ya sean APIs, servicios en la cloud, e incluso dependencias como tu sistema operativo, realmente todas las partes y piezas que componen nuestro software es de lo que hablamos aquí cuando hablamos de security de la cadena de suministro. Y desafortunadamente, ya sabes, el ecosistema de código abierto está bajo ataque. Hemos visto un aumento en los ataques a la cadena de suministro de software en los últimos años. Hay titulares con bastante regularidad sobre diferentes violaciones y ataques, y estos ataques afectan a todo tipo de empresas. Ya sabes, realmente cualquier persona que dependa de código abierto, y sé que tú dependes de código abierto, en algún momento se verá afectada por uno de estos ataques solo por la scale de NPM.

¿Cuántos de ustedes han oído hablar del hackeo de SolarWinds? Fue una noticia bastante grande hace unos años. Fue un sofisticado ataque a la cadena de suministro que comprometió a un proveedor llamado SolarWinds, y la forma en que funcionó fue que un atacante agregó código malicioso a uno de los productos de software de SolarWinds, y lo hicieron básicamente ingresando a la red de SolarWinds y agregando su código de ataque al producto de SolarWinds. Y luego, aguas abajo de eso, pudieron ingresar a miles de redes de clientes de SolarWinds, incluidas agencias gubernamentales de EE. UU. y grandes corporaciones. Si bien es bastante difícil determinar los daños monetarios exactos de este ataque, los costos asociados con la investigación, la remediación y las medidas de ciberseguridad aumentadas como resultado de esto probablemente estuvieron en miles de millones de dólares. Eso es SolarWinds. Es una empresa que tiene un equipo de seguridad y mucho esfuerzo para defender sus productos. Ahora hablemos de los paquetes de NPM, que a menudo son mantenidos por individuos o pequeños equipos de voluntarios. A veces, la seguridad de la cadena de suministro de software puede ser algo abstracta, ¿verdad? Es como, ¿de qué estamos hablando aquí? Quería hacer esto realmente concreto para todos y mostrarles realmente cómo se ve un ataque a la cadena de suministro. Aquí hay un ejemplo real. Este es un ataque que detectamos hace unos días. Vamos a discutir, ¿qué está pasando aquí? Permítanme ayudarles un poco. Resaltaré algunas partes del código aquí. ¿Eso ayuda? Ahora, si miras esto, puedes ver que si un desarrollador instala este paquete, este código malicioso se ejecutará inmediatamente en un script de instalación y exfiltrará o robará sus variables de entorno, que pueden incluir, obviamente, secretos, tokens, claves, y luego lo enviará a un servidor controlado por el atacante. Puedes ver esas tres partes allí. Está adquiriendo el paquete de red, está accediendo a las variables de entorno y luego tiene esta solicitud de red obfuscada o oculta en esa tercera línea. Y así es como un ataque a la cadena de suministro de software puede llevar a una violación en una empresa.

Ahora, este paquete probablemente estaba dirigido a Airbnb, dado el nombre del paquete, pero honestamente no tenemos todos los detalles sobre cuál era el objetivo de este paquete, pero el nombre es muy sospechoso, solo diré eso. Y fundamentalmente, el problema aquí es que, como desarrolladores, estamos usando tantos paquetes, pero simplemente no tenemos tiempo para leer cada línea de código en nuestras dependencias. Siempre estamos confiando en otras personas fundamentalmente, y el código abierto se basa en la confianza. Y en su mayor parte, esta confianza está bien colocada. La mayoría de las personas son buenas. Pero hay algunas manzanas podridas. Y desafortunadamente, como comunidad, nos lleva un poco demasiado tiempo encontrar este tipo de paquetes maliciosos hoy en día. En este momento, estamos viendo más de 200 días para detectar un paquete malicioso como comunidad. Y así, ya sabes, esto es bastante malo. Esto es de un artículo de investigación publicado en 2021. Y el otro gran problema es que cuando encontramos estos paquetes maliciosos como comunidad, los informamos y los eliminan, pero a menudo no se catalogan ni se guardan de ninguna manera. No entran en los sistemas típicos de seguimiento de vulnerabilidades como la Base de Datos Nacional de Vulnerabilidades. Simplemente los eliminan y luego nadie sabe si han instalado ese paquete en el pasado.

Estamos tratando de cambiar esto. En Socket, estamos detectando y previniendo más de 100 de este tipo de ataques cada semana. Escaneamos todos los ecosistemas de código abierto más populares, incluyendo NPM, Go, Python y Java. Cuando encontramos un paquete malicioso, lo reportamos al registro de NPM y lo eliminamos para proteger a toda la comunidad. Obviamente, estamos haciendo esto para mantener a todos seguros y porque es lo correcto. Pero Socket también es un producto comercial donde vendemos algunos servicios. Ahora quiero dedicar un tiempo a analizar un reciente ataque a la cadena de suministro que creo que fue particularmente interesante. Este ocurrió en diciembre de 2023, hace solo unos meses. Es posible que incluso hayas oído hablar de esto o visto los titulares. Pero profundicemos en ello. Este es un ejemplo del mundo real. En este ejemplo, hay una empresa llamada Ledger que fabrica una billetera de seguridad de hardware que ayuda a las personas a almacenar sus criptomonedas. Tienen una biblioteca de JavaScript que publicaron en NPM y que fue comprometida en diciembre. La forma en que funcionó fue que los hackers lograron introducir su código en este paquete de NPM y eso afectó a todos los usuarios que dependían de ese paquete. La forma en que funcionó fue que alguien obtuvo acceso a la cuenta de NPM de un antiguo empleado porque cuando dejaron la empresa, la empresa olvidó revocar el acceso de ese antiguo empleado. Entonces, cuando el portátil de ese antiguo empleado se infectó con malware, básicamente los hackers pudieron acceder a ese portátil y utilizar las credenciales de NPM que estaban allí para acceder a la cuenta de NPM de ese empleado. A partir de ahí, los hackers pudieron publicar una versión maliciosa de esta biblioteca. Ese código malicioso, como era de esperar con criptomonedas, estaba diseñado para robar todas las criptomonedas de cualquier persona que estuviera utilizando la biblioteca. Así que hablemos un poco sobre cómo funcionó esto. Creo que tiene algunas lecciones para nosotros como desarrolladores de JavaScript para mejorar la seguridad de nuestras aplicaciones. Así que vamos a revisarlo. Lo primero que notarás al usar este paquete es que si lees el README, los desarrolladores que utilizan esta biblioteca... Debería mencionar rápidamente qué hace realmente la biblioteca.

Entonces, la biblioteca se utilizó, si estás construyendo un sitio web y quieres comunicarte con este dispositivo de hardware, instalarías este paquete NPM para poder interactuar con el dispositivo de hardware de una manera más fluida. Así que hay muchos sitios web por ahí que intentan interactuar con este dispositivo de hardware que estaban usando el paquete NPM para hacerlo.

Y la forma en que usarías el paquete es, el README tenía esta línea en la que se indica agregar este paquete de carga del kit de conexión como dependencia y luego usarlo de la siguiente manera. Así que parece bastante sencillo, ¿verdad? Simplemente importas el paquete y luego llamas a esta función de carga del kit de conexión. Y luego, si te fijas, hay otra parte del README que dice que esto permitirá que tu aplicación descentralizada, que básicamente es tu sitio web, cargue la biblioteca del kit de conexión en tiempo de ejecución desde un CDN para que puedan mejorar la lógica y mejorar el producto sin tener que esperar a que las personas lancen nuevas versiones.

Entonces, de inmediato, esto activa mis alarmas porque vemos aquí que el código en el que dependemos en realidad depende de más código, pero este código adicional está en un CDN. ¿Qué significa eso? Significa que ese es un código que puede cambiar. Está cargando ese código desde un servidor remoto. Así que veamos cómo se ve realmente esto. Si realmente entras en esa función, verás que esta función no contiene la lógica de la funcionalidad real que estoy tratando de usar aquí. Lo que realmente está haciendo es ir a esta URL HTTP con una etiqueta de script y luego ejecutar ese código. Y ese código es cualquier código que se sirva en ese servidor en ese momento. Y así, este código puede cambiar debajo de nosotros. Y lo que esto realmente significa es que este es un paquete que efectivamente evita nuestro archivo de bloqueo. Como nuestro archivo de bloqueo en NPM está diseñado para bloquear el código en el que nuestra aplicación depende para que no cambie de compilación en compilación, ¿verdad? Para que sea determinista. Pero cuando tienes un paquete que simplemente va a cargar lo que sea que esté en esta URL HTTP, tu aplicación va a cambiar debajo de ti. Y eso es exactamente lo que sucedió aquí. Entonces, el atacante pudo introducir su código en ConnectKit, que este CDN aquí comenzó a servir. Y luego todos los sitios web por ahí, que en realidad eran, creo, miles, comenzaron a servir instantáneamente el código malicioso sin una actualización, sin una nueva compilación, sin una nueva instalación de NPM. Simplemente se actualizaron instantáneamente todos los sitios. Así es como funcionan las etiquetas de script. Y eso, por cierto, es por qué las etiquetas de script son tan peligrosas. Estás dando capacidades de ejecución de código remoto a cualquier sitio que uses allí.

Entonces, ¿qué aprendimos de esto? Yo diría que aprendimos varias cosas. Veamos algunas lecciones. Entonces, para los autores, quiero decir, la lección principal es no enlazar directamente a CDNs desde dentro de tus paquetes de NPM porque estarás evitando los archivos de bloqueo de tus usuarios, lo cual no es bueno. Además, relacionado con eso, a veces verás paquetes que usan dependencias HTTP o dependencias Git o incluso una URL de GitHub como una solución temporal para solucionar un error. Verás, como, un fork. Las personas dependerán de una versión bifurcada.

Esto es realmente peligroso porque estás evitando tu archivo de bloqueo y le estás dando al autor de ese paquete la capacidad de cambiar el código por debajo de ti. La otra cosa fue, obviamente, no revocaron el acceso de NPM del empleado aquí, lo cual es un problema grave. Así que aconsejaría a todos auditar regularmente su acceso a NPM y tener una lista de verificación cuando estén desactivando a un empleado para asegurarse de no olvidar un paso como eliminar su acceso a NPM.

Y finalmente, consideraría utilizar un flujo de trabajo de GitHub para que no tengas que dar acceso a los desarrolladores a NPM. Ahora, en el lado del usuario, la lección más importante aquí es no utilizar paquetes que carguen código de forma remota y eviten tu archivo de bloqueo. La única forma de descubrir que un paquete está haciendo algo así es si realmente miras el código. Obviamente, eso es mucho trabajo. Pero tanto como puedas, dedica tiempo a mirar el código en tus dependencias. Comprende lo que hacen tus dependencias. Esto no es solo para seguridad. Esto te convertirá en un mejor programador. Aprenderás sobre diferentes estilos y técnicas de codificación. Y en general, es una buena idea aprender. Pero también descubrirás cuando estés utilizando una dependencia de baja calidad. Y luego, la otra opción es utilizar una herramienta de seguridad que detecte este tipo de riesgos. No solo detectar vulnerabilidades, sino también detectar riesgos en la cadena de suministro y problemas de calidad de código como este. Y como consejo general, utiliza menos dependencias, fija tus dependencias, evita referencias mutables a dependencias que pueden cambiar por debajo de ti.

Entonces, hubo algunas personas que utilizaron una herramienta de escaneo de vulnerabilidades como Snyk que no estaban protegidas contra este ataque. Más de 12 horas después de que este paquete fue comprometido, estas herramientas seguían informando que el paquete no tenía problemas de seguridad conocidos para todos sus clientes. Así que si confías en una herramienta de vulnerabilidad, debes tener en cuenta que tampoco te protegerá de este tipo de ataque. Desafortunadamente, esto es, al menos para mí, muy frustrante porque, por un lado, nuestras herramientas literalmente no detectan los ataques como este que realmente nos importan, estos ataques que afectan al ecosistema. Y sin embargo, a pesar de eso, también nos inundan con alertas. Nos inundan constantemente con alertas sin sentido. El 60% de las personas han dicho que la cantidad de alertas, la fatiga de alertas, ha creado fricción entre sus equipos de desarrollo y sus equipos de seguridad. Y, seguro, todos hemos visto la salida de auditoría de NPM donde instalas un paquete y de inmediato ves que tiene más de cien vulnerabilidades, y luego simplemente encoges los hombros y sigues con tu día. Así que es muy frustrante que nuestras herramientas constantemente nos estén gritando sobre vulnerabilidades de seguridad, pero ni siquiera pueden detectar el tipo de vulnerabilidad que acabamos de descubrir. Y, ya sabes, Danny Abramov escribió una publicación viral famosa hace unos años sobre cómo la auditoría de NPM estaba rota por diseño. Quiero decir, tuvo algunas palabras bastante duras sobre los problemas con la auditoría de NPM. La llamó una mancha en todo el ecosistema de NPM y dijo que estaba completamente rota. Y, aunque yo hubiera elegido palabras diferentes, creo que hay varios problemas con la auditoría de NPM.

Quiero decir, está enviando demasiadas alertas y no suficientes alertas. No quiero centrarme solo en la auditoría de NPM. Esto es cierto para todas nuestras herramientas de informe de vulnerabilidades de seguridad. Por un lado, envía demasiadas alertas sobre cosas que no nos importan, pero también no envía alertas sobre paquetes peligrosos, dependencias maliciosas, ataques de typo squad, etc. Eso es lo que estamos tratando de cambiar con Socket y estamos tratando de brindar esta protección a todo el ecosistema.

Una de las cosas que encontramos que realmente ayuda, y creo que este es un caso de uso muy interesante para la IA, es que podemos identificar amenazas pasando el código fuente a un LLM y luego ese LLM puede generar una explicación en inglés claro de los riesgos del código. Por ejemplo, ese ataque de libro mayor del que acabamos de hablar obtendría esta salida, describiendo el hecho de que hay código ofuscado y probablemente un comportamiento malicioso, y así sucesivamente.

En los últimos minutos, quería mostrarles algunos ataques más para que tengan una idea de otros riesgos de seguridad divertidos de diferentes paquetes de NPM que hemos descubierto. Veamos este aquí. Este es algún código publicado en un paquete de NPM. Ha sido ofuscado, diseñado para ocultar el comportamiento del código. Puedes ver aquí que está descargando algún tipo de archivo ejecutable, lo cual es sospechoso. Y luego aquí, si te desplazas un poco hacia abajo, verás que está cargando algo desde el CDN de Discord. Probablemente esté utilizando un proceso secundario para ejecutar ese archivo ejecutable. Y puedes ver que también hay referencias a otros ejecutables y algunas cosas de HTTPS. Resulta que si tomas este código y lo pones en un LLM, y Socket hace esto, obtendrás esta increíble explicación que te dice cuáles son los problemas con el código. Te dirá que es altamente sospechoso y que tiene ejecución de código arbitrario, descarga de código de fuentes no confiables y es un riesgo de seguridad significativo. Así que creo que esto es bastante interesante. Si no has tenido la oportunidad de jugar con LLMs, realmente creo que van a marcar una gran diferencia en la forma en que hacemos la seguridad porque no son engañados tan fácilmente como un humano y también pueden ejecutarse en más código fuente. Son incansables, a diferencia de un humano que se cansará de revisar el código en algún momento. Y luego quería mostrar otro ejemplo de ofuscación aún más interesante que el último ejemplo. Este es un paquete que encontramos donde recopila un montón de variables de entorno que intenta robar, pero me pareció interesante ver aquí cómo intentaban evadir la detección de ciertas herramientas, y puedes ver aquí que están llamando a esta función de tipo y luego eso está sacando algún método del objeto HTTP que luego ejecuta. Pero profundicemos en la función de tipo y veamos qué está haciendo exactamente. Y simplemente creo que esto es tan genial, lo que hizo este atacante aquí. Permíteme llamar tu atención aquí donde están llamando a la función prop getter y pasando una serie de 0, 1 y 2. Centrémonos solo en 0. Llama a la función prop value, que luego llama a esta operación de filtro, y lo que está haciendo es tratar realmente la función prop getter como una cadena y luego escanear el cuerpo de la cadena de esta función para extraer las líneas que comienzan con slash slash, que son los comentarios. Y luego lo que obtiene es un array con tres palabras, west, question e Ireland.

Entonces, una vez que tiene eso, utiliza estos índices aquí abajo para cortar trozos de estas cadenas, y esos son desplazamientos de bytes en las cadenas. Permíteme mostrarte lo que quiero decir aquí. Así que en realidad está extrayendo entre el rango 2 y 4 de la primera cadena, que son las letras ST. Luego, para la siguiente cadena, toma del 0 al 3, que es QUE. Y luego, para la tercera cadena, Ireland, extrae la R y la E. Entonces, ¿para qué podría ser esto? ¿Por qué estaría cortando estas diferentes cadenas y extrayendo estas diferentes letras? Bueno, te daré una pista. Luego invierte la cadena. Y ahora echa un vistazo al orden allí. ¿Qué deletrea eso? Bueno, tienes R-E-Q-U-E-S-T. Deleta la palabra request. Así que todo este code fue literalmente diseñado para devolver la cadena request. Y si volvemos aquí a este code original, verás que básicamente solo está colocando la palabra request en el archivo. Y así intentaban ocultar el hecho de que estaban haciendo una solicitud HTTP.

Veamos qué dice el LLM, qué dice la IA cuando analiza este código. Resulta que realmente pudo descifrarlo. Así que todo este trabajo que tuve que hacer como humano para entender este código fue descifrado instantáneamente con IA. Dice aquí que este código envía variables de entorno como datos codificados en Base64, e incluso descubrió que esa función de valor de propiedad que acabamos de ver está ofuscada y que todo esto se utiliza para la extracción maliciosa de datos. No sé. Muy interesante, en mi opinión. Creo que es realmente genial.

Los atacantes son muy astutos, pero también lo son los defensores. Y ahora tenemos herramientas poderosas a nuestra disposición para intentar proteger nuestras aplicaciones de este tipo de ataques. Así que, sí, solo quiero dejarte con un último pensamiento. Sabes, las vulnerabilidades tienen un problema. Son muy ruidosas. No detectan realmente los tipos de ataques de los que hemos estado hablando en esta charla. Así que animaría a la comunidad, a todos nosotros, a tener una visión más amplia de lo que significa la seguridad del código abierto. Y realmente hay tantas fuentes diferentes de riesgo y problemas en los paquetes. No se trata solo de la seguridad, incluso. Son riesgos de mantenimiento. Son paquetes no mantenidos. Son paquetes de baja calidad. Hay tantas cosas en las que pensar cuando intentamos construir aplicaciones seguras. Así que, sabes, creo que ampliar tu horizonte y pensar en estas cosas hará que tus aplicaciones no solo sean más seguras, sino también más robustas y mejores en general para los usuarios.

Así que, con eso, gracias por el tiempo. Y espero que te mantengas seguro ahí fuera. Gracias de nuevo. Charla fantástica. Estaba esperando esa. Fue tan buena como esperaba. Así que es fantástico tener a Feros con nosotros hoy. Y va a responder algunas preguntas. Pero antes de responder tus preguntas, veamos qué dice la encuesta. Preguntó si evalúas tus dependencias antes de instalarlas, antes de usarlas.

Y, honestamente, cuando voté, elegí la primera opción porque me pareció muy divertida. Pero de hecho, uso Dependabot de vez en cuando. Pero, sí, es gracioso porque son tan comunes, en realidad, como las herramientas SCA y los verificadores de dependencias. Pero ¿te sorprende ese número, el 58%, que todavía dice, como, improvisemos? YOLO. Solo se vive una vez. Mira, soy un desarrollador. Sé cómo es. Solo quieres sacar la característica. Solo quieres usar el code. Incluso si te importa la seguridad, es tan tentador instalarlo y seguir adelante. No me sorprende este número. Pero estoy decepcionado. Vamos, estoy decepcionado de todos ustedes. Hazlo mejor. Pero sí, también he pecado con eso. A veces me muevo rápido. Solo digo, oh, solo compruébalo. Espero que no haya demasiadas consecuencias. Pero siento que solo puedes hacer eso localmente. Cuando estás en un entorno empresarial, es menos fácil hacerlo.

Pero hagamos algunas preguntas del público. Y, amigos, no olviden que si quieren hacerle preguntas a Faros, este es el momento. Vayan a slido.co y 0404 y hagan sus preguntas porque solo tendrán esta oportunidad para aprovechar su sabiduría.

Entonces, alguien preguntó, ¿cuáles son las diferencias con otros competidores como SNAKE o, supongo, como dije, dependen de otro tipo de herramientas orientadas a la seguridad? Sí, sí, el mercado tiene un montón de este tipo de herramientas de vulnerabilidad. Básicamente, lo que hacen es revisar tus dependencias y determinar si estás utilizando algún paquete que se sabe que es vulnerable. El problema con ese enfoque es que son menos útiles para detectar un ataque a la cadena de suministro del tipo que acabamos de mencionar en la charla. Y del tipo que vimos que ocurrió el viernes, por cierto, del cual sé que vamos a hablar. Pero si no han visto las noticias, hay un paquete llamado xzutils que fue utilizado por SSH. Esto es una de las cosas más aterradoras que he visto.

Pero ese tipo de ataque donde alguien introduce code en un paquete, eso no es algo que las herramientas tradicionales de escaneo de vulnerabilidades puedan encontrar. Y la razón es que esas herramientas simplemente buscan qué paquetes estás utilizando y los comparan con data en una database pública que se llama la Base de Datos Nacional de Vulnerabilidades. En realidad, es administrada por el gobierno federal de Estados Unidos, aunque no lo crean. Y cuando encuentran una coincidencia, esas herramientas básicamente te dicen: `Oye, estás utilizando uno de los paquetes de esta lista`. Y eso es básicamente lo que hacen. Y desafortunadamente, es demasiado reactivo. Estás esperando a que esa database se actualice. Y el otro gran problema es que esa database no está destinada a rastrear ataques a la cadena de suministro y paquetes maliciosos. Está destinada a vulnerabilities. Y hay una distinción entre ellos. Vulnerabilities son errores accidentales cometidos por el mantenedor del paquete o por el contribuyente al paquete. Son accidentes que pueden llevar a problemas de security si un atacante encuentra y explota la vulnerabilidad.

Pero no es una garantía de que vayas a ser explotado si estás utilizando code vulnerable porque alguien tiene que encontrarlo. Alguien tiene que atacarlo. Mientras que un ataque a la cadena de suministro o malware, esto es algo que se agrega intencionalmente code que se activará de inmediato y te atacará. Y para detener eso, en realidad tienes que analizar el code antes de usarlo. Si esperas hasta que lo uses y luego haces una herramienta de escaneo como 24 horas después, es demasiado tarde. Ya has sido atacado. Así que esa es la diferencia clave, somos la primera herramienta que es proactiva. Eso es genial.

Y también el hecho de que, como mencionaste, esos tipos de vulnerabilidades son precisamente eso, de día cero. Aún no están en esa base de datos. Es como si no pudieras saber cuándo van a ocurrir. Pero en esa misma línea, ¿qué piensas sobre la sostenibilidad de los proyectos de código abierto mantenidos por IC? Después de la historia de XE utils. ¿Cómo podemos hacer que sea menos ingrato? ¿Cómo podemos asegurarnos de que los mantenedores realmente quieran seguir manteniendo sus proyectos sin agotarse y todo lo que está asociado con el mantenimiento de código abierto que no está respaldado por la comunidad o por una fundación?

Sí, es una gran pregunta. Mira, pasé como cinco años de mi vida tratando de descubrir cómo financiar el código abierto y hacerlo sostenible. Es un problema muy difícil. Sabes, aquellos que tienen la suerte de trabajar en código abierto con un respaldo como una gran entidad corporativa que te paga por trabajar en código abierto. Ese es el sueño. Es genial. Me siento un poco celoso de esas personas. Pero si miras la mayoría del código abierto, generalmente hay mucho código abierto que usamos que está escrito por una persona aleatoria. Podría haber sido que trabajaron en ello mientras estaban en una empresa. Dejaron la empresa. Siguen manteniéndolo porque sienten la obligación de hacerlo. Hay todo esto... Es realmente interesante que el mundo pasó de tener estos grandes proyectos de código abierto. Tenían cientos de colaboradores trabajando en ellos. Ese era el modelo principal. Y ahora se ha invertido, donde tienes un MPM y ecosistemas más nuevos como Rust. Tienes lo contrario, donde tienes una sola persona con cientos de paquetes que mantienen. Es como una inversión completa. Es genial. Significa que parte de la razón por la que sucedió esto es que las herramientas como GitHub y cosas así se volvieron tan buenas que fue fácil crear nuevos proyectos de código abierto. Y es algo genial. Estamos facilitando que las personas participen y contribuyan y todas estas cosas buenas. Pero el lado negativo es que dependes de todo este código de todas estas personas y definitivamente están bajo una carga. Sí, es un problema.

Quiero decir, eso es lo que sucedió con XC. Y esto ocurre todo el tiempo en MPM también. Quiero decir, en 2017, tan temprano como 2017, hubo un ataque a un paquete llamado Event Stream, donde alguien lo estaba manteniendo. Alguien se acercó de manera muy similar y dijo: `Oye, me encantaría ayudarte. ¿Puedes agregarme como mantenedor?` Y resultó ser, ya sabes, un actor malicioso.

Sí, sí. Eso es bastante aterrador. Es algo aterrador de pensar. ¿Qué ves en el futuro para Socket? ¿Se integrará con las grandes nubes o con los grandes sistemas de control de versiones, como GitHub y otros? ¿Permitirá una mejor seguridad de la cadena de suministro automáticamente? Quiero decir, estaría encantado de asociarme con cualquier gestor de paquetes que quiera hacer esto. Lo que hacemos como equipo hoy en día es que cada vez que encontramos un paquete malicioso, lo informamos al registro de paquetes para que lo eliminen.

Y hacemos eso con todo lo que encontramos. Y así, esos cien paquetes por semana que estamos identificando hoy en día, los estamos eliminando lo más posible. Los eliminamos informándolos y trabajando con los registros, trabajando con GitHub para eliminar ese code y proteger a las personas. Pero es una pregunta válida. ¿Por qué esto no forma parte del registro? Es una buena pregunta. Y, sabes, estaríamos encantados de asociarnos para ayudar con eso.

Y en la misma línea, un poco más sobre el discussion anterior, un poco más sobre el futuro del código abierto. Ahora hay muchas empresas que están cambiando sus licencias y haciendo muchas cosas que son un poco aterradoras en el espacio del código abierto. ¿Cuáles son tus pensamientos sobre el futuro del código abierto y hacia dónde se dirige todo? Sí, sé que es una pregunta muy interesante. Creo que el código abierto significa cosas diferentes para diferentes personas. Exacto. Quiero decir, hay puristas que piensan que el código abierto es esta definición, ¿verdad? OSI. Como, esto es exactamente lo que significa código abierto. Y no deberíamos usar la palabra para significar otra cosa. Desafortunadamente, el lenguaje no funciona así. La gente puede usar palabras y, ya sabes, el lenguaje evoluciona. Y no creo que OSI tenga una marca registrada sobre el término código abierto. Y lo que a menudo vemos es que la gente lo usa de diferentes maneras. Para muchas personas, el código abierto simplemente significa que puedo ver el code. Está en GitHub y puedo leerlo. Significa que hay una community donde puedo abrir una solicitud de extracción y alguien la revisará y tal vez acepten mi contribución. Y hay un ambiente colaborativo para trabajar en este code juntos.

Y luego, en otros casos, significa un tipo de licencia muy específico que te otorga ciertos derechos. Así que realmente tienes que profundizar cuando la gente habla de código abierto. ¿Cómo lo están definiendo realmente? Porque ves todo tipo de cosas diferentes. Ves empresas como Apple que técnicamente son de código abierto porque publican el code, pero no lo alojan en GitHub. Lo ponen en un archivo zip en una página aleatoria de su sitio web que nadie puede encontrar. Y técnicamente, eso es lo que es. Nos lo enviaron, lo compilamos. Sí.

Sí. ¿Es eso código abierto? No lo sé. No se siente como código abierto para mí. No lo es. Pero supongo que técnicamente lo es según la definición legal. Y luego tienes estas otras empresas que dicen: vamos a cambiar la licencia. Pero vamos a darles a casi el noventa y nueve por ciento de las personas que lo usan. Les vamos a dar todos los derechos que realmente les importan, que es ver el code, colaborar en el code, usar el code. Y sí, técnicamente no es, por la licencia, una licencia aprobada por OSI. Pero a la mayoría de las personas probablemente no les importa. Así que no sé. No tengo una opinión fuerte en ningún sentido. Solo creo que siempre tienes que profundizar y descubrir qué significa realmente la gente con código abierto. Y una vez que entiendas su significado, entenderás su posición sobre diferentes cosas como esa.

Sí, absolutamente. Supongo que solo porque estás aquí y eres el experto, ¿qué piensas sobre las divisiones también? Como Valkyrie recientemente en Open Tofu después de Terraform y la división de Redis. Y me pregunto, ¿qué opinas sobre las grandes divisiones de proyectos conocidos que eligen seguir el camino del cambio de licencia? Creo que está bien. Quiero decir, esos proyectos están haciendo lo que tienen derecho a hacer. Están dividiendo el code. Sabes, es genial. Quiero decir, eso es increíble. Quiero decir, las empresas hacen lo que quieren. La community hace lo que quiere. Es genial que tengamos la libertad de hacer estas cosas. Y, ya sabes, quiero decir, creo que obviamente a veces a mucha gente le parece que fue un engaño o una traición de alguna manera en esas situaciones. Pero sé que algunas personas a menudo pueden sentir eso en esas situaciones, aunque no conozco todos los detalles específicos de la comunidad de Redis o cosas así.