El Lado Oscuro del Open Source

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Únete a Feross, CEO de Socket, en un emocionante viaje al lado oscuro del software de código abierto. Acompáñanos mientras exploramos los riesgos invisibles que acechan en las dependencias de software cotidianas. Observa de primera mano cómo las soluciones impulsadas por IA, específicamente los modelos de lenguaje grandes, nos ayudan a combatir las dependencias maliciosas dentro del ecosistema npm. Equípate con el conocimiento y las herramientas para proteger tu base de código en esta batalla en constante evolución.

This talk has been presented at Node Congress 2024, check out the latest edition of this JavaScript Conference.

Feross Aboukhadijeh
Feross Aboukhadijeh
37 min
04 Apr, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla explora el lado oscuro del código abierto, centrándose en los ataques a la cadena de suministro y la necesidad de mejorar las medidas de seguridad. Destaca los peligros de cargar código externo y la importancia de mitigar los riesgos de la cadena de suministro. La charla también discute el uso de IA y LLMs en el análisis de código para mejorar la seguridad. Enfatiza los desafíos de mantener proyectos de código abierto mantenidos por IC y el futuro de la seguridad de la cadena de suministro. Por último, se mencionan las variaciones en las definiciones de código abierto y el empoderamiento de la comunidad de código abierto.
Available in English: The Dark Side of Open Source

1. The Dark Side of Open Source

Short description:

Bienvenidos a la charla sobre el lado oscuro del código abierto. Exploraremos el código malicioso y las amenazas en los ecosistemas de NPM y JavaScript. Tengo experiencia en código abierto y ciberseguridad, y ahora trabajo en seguridad de código abierto en Socket. Socket ayuda a los desarrolladores y equipos de seguridad a encontrar, auditar y gestionar software de código abierto. Hoy en día, más del 90% de las aplicaciones dependen de dependencias de código abierto, lo que hace que la seguridad de la cadena de suministro sea crucial. El ecosistema de código abierto está bajo ataque, con ataques a la cadena de suministro de software que afectan a empresas de todo tipo.

♪♪ ♪♪ Hola a todos. Soy Firas, y bienvenidos a esta charla sobre el lado oscuro del código abierto. Estoy muy emocionado de compartir con ustedes algunas de las partes menos exploradas del código abierto. Vamos a profundizar en algunos ejemplos de code malicioso y les daremos una idea de algunas de las amenazas que existen en los ecosistemas de NPM y JavaScript. Así que empecemos.

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.

2. Supply Chain Attacks and the Problem of Trust

Short description:

El hackeo de SolarWinds fue un sofisticado ataque a la cadena de suministro que comprometió a SolarWinds y afectó a miles de redes. Los paquetes de NPM, a menudo mantenidos por individuos o equipos pequeños, también pueden ser vulnerables a ataques a la cadena de suministro. Presentaré un ejemplo real de un ataque reciente que exfiltró variables de entorno. Como desarrolladores, confiamos en el código abierto, pero lleva demasiado tiempo detectar paquetes maliciosos y a menudo no se catalogan para futuras referencias.

¿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.

3. Detectando y Previniendo Ataques a la Cadena de Suministro

Short description:

Socket está detectando y previniendo ataques a la cadena de suministro en varios ecosistemas de código abierto, incluyendo NPM, Go, Python y Java. Discutamos un reciente ataque a la cadena de suministro que involucró a Ledger, una empresa que produce billeteras de seguridad de hardware para criptomonedas. El ataque comprometió una biblioteca de JavaScript publicada en NPM, resaltando la necesidad de mejorar las medidas de seguridad. La biblioteca permitía a los sitios web interactuar con el dispositivo de hardware y requería la instalación de un paquete de carga del kit de conexión. El README mencionaba cargar la biblioteca del kit de conexión desde un CDN, lo que planteaba preocupaciones sobre las dependencias del código.

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.

4. Los Peligros de Cargar Código Externo

Short description:

Si estás construyendo un sitio web y quieres interactuar con un dispositivo de hardware, instalarías el paquete NPM. El paquete requiere agregar un paquete de carga del kit de conexión como dependencia y usarlo para importar y llamar a la función de carga del kit de conexión. Sin embargo, la biblioteca del kit de conexión se carga en tiempo de ejecución desde un CDN, lo que permite cambios en el código. Esto evita el archivo de bloqueo y puede llevar a que se sirva código malicioso a los sitios web que usan el paquete. Los autores deben evitar enlazar directamente a CDNs en los paquetes de NPM y usar dependencias HTTP o Git que eviten el archivo de bloqueo.

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.

5. Mitigación de Riesgos en la Cadena de Suministro

Short description:

Bypassing el archivo de bloqueo y no revocar el acceso de NPM de los empleados son riesgos de seguridad graves. Auditar regularmente el acceso a NPM y utilizar flujos de trabajo de GitHub en lugar de dar acceso a los desarrolladores a NPM puede mitigar estos riesgos. Al utilizar paquetes, evita aquellos que carguen código de forma remota y eviten el archivo de bloqueo. Dedica tiempo a comprender el código en tus dependencias y considera el uso de herramientas de seguridad que detecten riesgos en la cadena de suministro y problemas de calidad de código. Además, utiliza menos dependencias, fíjalas y evita referencias mutables. Las herramientas de escaneo de vulnerabilidades pueden no proteger contra todos los tipos de ataques, lo que causa fatiga de alertas. La herramienta de auditoría de NPM ha sido criticada por no detectar ciertas vulnerabilidades y tiene varios problemas.

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.

6. Mejorando la seguridad con LLMs

Short description:

Las herramientas de informe de vulnerabilidades de seguridad a menudo envían demasiadas alertas sobre problemas insignificantes, al tiempo que no alertan sobre paquetes peligrosos y otros riesgos de seguridad. Socket utiliza IA para identificar amenazas mediante el análisis de código fuente y proporciona explicaciones en inglés claro sobre los riesgos. Al utilizar LLMs, que no son fácilmente engañados y pueden analizar más código fuente, podemos mejorar en gran medida la seguridad. Ejemplos de código ofuscado y técnicas de evasión ingeniosas demuestran el valor de LLMs en la detección de comportamientos sospechosos y riesgos de seguridad significativos.

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.

7. Obfuscando una solicitud HTTP

Short description:

El código corta diferentes cadenas, las invierte y deletrea la palabra 'request'. Esta ofuscación se utilizó para ocultar una solicitud HTTP.

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.

8. El poder de la IA en el análisis de código

Short description:

El LLM y la IA pudieron descifrar el código, identificando su propósito como la extracción maliciosa de datos. La seguridad del código abierto va más allá de las vulnerabilidades y es importante considerar los riesgos de mantenimiento, los paquetes no mantenidos y los paquetes de baja calidad al construir aplicaciones seguras. Mantente seguro y sigue evaluando tus dependencias.

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.

9. Desarrolladores y Evaluación de Dependencias

Short description:

A menudo, los desarrolladores priorizan sacar características rápidamente en lugar de la seguridad. La prevalencia de las herramientas de verificación de dependencias y las herramientas SCA es divertida, pero no sorprende que el 58% aún elija improvisar y no evaluar a fondo sus dependencias.

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.

QnA

Supply Chain Attacks and Vulnerability Tools

Short description:

Las herramientas tradicionales de vulnerabilidad son menos efectivas para detectar ataques a la cadena de suministro. La Base de Datos Nacional de Vulnerabilidades, administrada por el gobierno federal de Estados Unidos, solo rastrea vulnerabilidades, no ataques a la cadena de suministro. Para prevenir ataques a la cadena de suministro, se debe realizar un análisis de código de manera proactiva antes de su uso.

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.

Sustaining IC Maintained Open Source Projects

Short description:

Mantener la sostenibilidad de los proyectos de código abierto mantenidos por IC es un problema desafiante. Mientras que algunos individuos afortunados cuentan con el respaldo de empresas, la mayoría de los proyectos de código abierto son mantenidos por personas aleatorias que pueden no tener los recursos o la motivación para continuar. El panorama del código abierto ha cambiado, con mantenedores más pequeños responsables de mantener numerosos paquetes. Este cambio ha sido facilitado por herramientas mejoradas y plataformas como GitHub, lo que facilita que surjan nuevos proyectos. Sin embargo, esta dependencia de los mantenedores individuales plantea sus propios desafíos y cargas.

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.

Futuro de Socket y Seguridad de la Cadena de Suministro

Short description:

Los ataques a la cadena de suministro en proyectos de código abierto, como XC y Event Stream, resaltan la necesidad de mejores medidas de seguridad. La integración con plataformas importantes como GitHub y la colaboración con gestores de paquetes pueden mejorar la seguridad de la cadena de suministro. El equipo de Socket informa activamente y ayuda a eliminar paquetes maliciosos para proteger a los usuarios.

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.

Perspectivas del Código Abierto y el Camino a Seguir

Short description:

La identificación y eliminación de paquetes maliciosos es un esfuerzo continuo. La pregunta de por qué esto no forma parte del registro es importante, y Socket está dispuesto a asociarse para abordar este problema. El futuro del código abierto es complejo, con diferentes interpretaciones y definiciones en evolución. El código abierto puede significar visibilidad del código, colaboración comunitaria o licencias específicas. Es crucial comprender el contexto al hablar de código abierto, ya que abarca diversas perspectivas y prácticas.

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í.

Explorando las Variaciones y Divisiones del Código Abierto

Short description:

La definición e interpretación del código abierto puede variar. Algunas empresas cambian las licencias, pero siguen brindando los beneficios principales que los usuarios valoran. Comprender el contexto y el significado detrás del código abierto es crucial. Dividir proyectos y cambiar las licencias es una elección válida, pero en algunos casos puede generar sentimientos de traición.

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í.

Empoderando a la Comunidad de Código Abierto

Short description:

La capacidad de la comunidad para ejercer sus poderes de código abierto y tomar decisiones es crucial. Dejemos que el mercado determine el valor de las diferentes versiones, ya sean lideradas por la comunidad o por empresas. Agradecimiento por la visión del orador y su participación en la discusión.

Y eso probablemente sea válido. Sabes, sí, sí. No sé, no conozco todos los sentimientos y todas las diferentes partes involucradas allí. Pero en general, diría que es increíble que la community esté tomando el control de la situación. Y eso es genial. Sí, así es como se supone que funciona el código abierto. Sí. Sabes, si no te gusta hacia dónde se dirige la dirección, bueno, entonces tienes que usar tus poderes de código abierto, los derechos que tienes para hacerlo. Y si la empresa no quiere hacerlo para las contribuciones futuras, entonces dejemos que el mercado decida, ¿sabes? ¿Qué quieren usar? ¿Quieren usar la versión de la community o la empresa está proporcionando suficiente valor adicional para justificar la licencia no de código abierto? Veamos, ¿sabes? Sí, absolutamente. Supongo que eso es todo. OK, esa fue una discussion realmente fantástica, como siempre, para nosotros aquí. Sabes, una gran persona para aprovechar. Y creo que tu visión en el mundo del código abierto es fantástica. Muchas gracias por estar con nosotros y tu fantástica charla fue realmente maravillosa. Genial. Sí. Gracias por tenerme. Fue muy divertido.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Flat Routes – Una Evolución en el Enrutamiento
Remix Conf Europe 2022Remix Conf Europe 2022
16 min
Remix Flat Routes – Una Evolución en el Enrutamiento
Top Content
Remix Flat Routes is a new convention that aims to make it easier to see and organize the routes in your app. It allows for the co-location of support files with routes, decreases refactor and redesign friction, and helps apps migrate to Remix. Flat Folders convention supports co-location and allows importing assets as relative imports. To migrate existing apps to Flat Routes, use the Remix Flat Routes package's migration tool.
Cómo hacer un juego web tú solo
JS GameDev Summit 2023JS GameDev Summit 2023
27 min
Cómo hacer un juego web tú solo
This talk guides you on how to make a web game by yourself, emphasizing the importance of focusing on tasks that interest you and outsourcing the rest. It suggests choosing a game engine that allows distribution on the web and aligns with your understanding and enjoyment. The talk also highlights the significance of finding fun in the creative process, managing scope, cutting features that don't align with the game's direction, and iterating to the finish line. It concludes by discussing the options for publishing the game on the web and leveraging unique web features.
Cómo Construir Tu Propio Proyecto de Código Abierto
React Advanced 2022React Advanced 2022
16 min
Cómo Construir Tu Propio Proyecto de Código Abierto
Hello my friend, in this talk, I wanna share with you how to build your own open source project. Building an open source software project can be challenging. I receive a lot of things randomly in a day, like thank you messages for making my life easier, which motivates me. To choose an open source project to work on, pick one you use every day. Your software is being used when people report issues and send pull requests.
Despliegue Atómico para Hipsters de JavaScript
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
Despliegue Atómico para Hipsters de JavaScript
This Talk discusses atomic deployment for JavaScript and TypeScript, focusing on automated deployment processes, Git hooks, and using hard links to copy changes. The speaker demonstrates setting up a bare repository, configuring deployment variables, and using the post-receive hook to push changes to production. They also cover environment setup, branch configuration, and the build process. The Talk concludes with tips on real use cases, webhooks, and wrapping the deployment process.
Tu Ritmo con GraphQL
GraphQL Galaxy 2022GraphQL Galaxy 2022
31 min
Tu Ritmo con GraphQL
The Talk discusses the value proposition of GraphQL and its ability to solve common pain points in API development. It highlights the importance of making informed decisions when choosing GraphQL clients, servers, and schema builders. The Talk also emphasizes the need to focus on the best developer experience in the present rather than seeking a perfect long-term solution. Additionally, it mentions the future of the Urkel GraphQL client and the reasons for dropping ReScript support. Overall, the Talk provides insights into the current state and future trends of GraphQL development.
Aplicaciones React (+Native) full-stack y seguras con tRPC.io
React Advanced 2021React Advanced 2021
6 min
Aplicaciones React (+Native) full-stack y seguras con tRPC.io
Top Content
Alex introduces tRPC, a toolkit for making end-to-end type-safe APIs easily, with auto-completion of API endpoints and inferred data from backend to frontend. tRPC works the same way in React Native and can be adopted incrementally. The example showcases backend communication with a database using queries and validators, with types inferred to the frontend and data retrieval done using Prisma ORM.

Workshops on related topic

Masterclass: Integrando LangChain con JavaScript para Desarrolladores Web
React Summit 2024React Summit 2024
92 min
Masterclass: Integrando LangChain con JavaScript para Desarrolladores Web
WorkshopFree
Vivek Nayyar
Vivek Nayyar
Sumérgete en el mundo de la IA con nuestro masterclass interactivo diseñado específicamente para desarrolladores web. "Masterclass: Integrando LangChain con JavaScript para Desarrolladores Web" ofrece una oportunidad única para cerrar la brecha entre la IA y el desarrollo web. A pesar de la prominencia de Python en el desarrollo de IA, el vasto potencial de JavaScript sigue siendo en gran medida inexplorado. Este masterclass tiene como objetivo cambiar eso.A lo largo de esta sesión práctica, los participantes aprenderán cómo aprovechar LangChain, una herramienta diseñada para hacer que los modelos de lenguaje grandes sean más accesibles y útiles, para construir agentes de IA dinámicos directamente dentro de entornos JavaScript. Este enfoque abre nuevas posibilidades para mejorar las aplicaciones web con funciones inteligentes, desde el soporte al cliente automatizado hasta la generación de contenido y más.Comenzaremos con los conceptos básicos de LangChain y los modelos de IA, asegurando una base sólida incluso para aquellos nuevos en IA. A partir de ahí, nos sumergiremos en ejercicios prácticos que demuestran cómo integrar estas tecnologías en proyectos reales de JavaScript. Los participantes trabajarán en ejemplos, enfrentando y superando los desafíos de hacer que la IA funcione sin problemas en la web.Este masterclass es más que una experiencia de aprendizaje; es una oportunidad de estar a la vanguardia de un campo emergente. Al final, los asistentes no solo habrán adquirido habilidades valiosas, sino que también habrán creado funciones mejoradas con IA que podrán llevar a sus proyectos o lugares de trabajo.Ya seas un desarrollador web experimentado curioso acerca de la IA o estés buscando expandir tus habilidades en áreas nuevas y emocionantes, "Masterclass: Integrando LangChain con JavaScript para Desarrolladores Web" es tu puerta de entrada al futuro del desarrollo web. Únete a nosotros para desbloquear el potencial de la IA en tus proyectos web, haciéndolos más inteligentes, interactivos y atractivos para los usuarios.
Node.js: Aterrizando tu primera contribución de código abierto y cómo funciona el proyecto Node.js
Node Congress 2023Node Congress 2023
85 min
Node.js: Aterrizando tu primera contribución de código abierto y cómo funciona el proyecto Node.js
Workshop
 Claudio Wunder
Claudio Wunder
Esta masterclass tiene como objetivo brindarte un módulo introductorio sobre los aspectos generales del código abierto. Sigue a Claudio Wunder de la Fundación OpenJS para que te guíe sobre cómo funciona el modelo de gobierno de Node.js, cómo se toman decisiones de alto nivel y cómo hacer tu primera contribución. Al final de la masterclass, tendrás una comprensión general de todos los tipos de trabajo que hace el proyecto Node.js (desde la clasificación de errores hasta decidir los próximos 10 años de Node.js) y cómo puedes formar parte del panorama más amplio del ecosistema JavaScript.

Las siguientes tecnologías y habilidades suaves podrían ser necesarias:
- Comprensión básica de Git e interfaz de GitHub
- Conocimiento de inglés profesional/intermedio para la comunicación y para permitirte contribuir a la organización Node.js (ya que todas las contribuciones requieren comunicación dentro de los problemas y solicitudes de GitHub)
- La masterclass requiere que tengas una computadora (de lo contrario, se vuelve difícil colaborar, pero las tabletas también están bien) con una configuración de IDE, y recomendamos VS Code y recomendamos la extensión GitHub Pull Requests & Issues para colaborar con problemas y solicitudes directamente desde el IDE.

Se cubrirán los siguientes temas durante la masterclass:
- Un repaso de algunas características de la interfaz de GitHub, como los proyectos de GitHub y los problemas de GitHub
- Repasaremos los conceptos básicos del código abierto y seguiremos la Guía de código abierto
- Repasaremos Markdown
- Cubriremos el gobierno del código abierto y cómo funciona el proyecto Node.js y hablaremos sobre la Fundación OpenJS
- Incluyendo todas las formas en que uno puede contribuir al proyecto Node.js y cómo se pueden valorar sus contribuciones
- Durante esta masterclass, cubriremos problemas de nodejs/nodejs.dev, ya que la mayoría de ellos son de nivel básico y no requieren conocimientos profundos de C++ o de Node.js.
- Dicho esto, aún recomendamos a los asistentes entusiastas que deseen desafiarse a sí mismos a los "Good First Issues" de nodejs/node (repositorio principal) si lo desean.
- Permitiremos a cada asistente elegir un problema o trabajar junto con otros asistentes para abordar problemas juntos mediante la función de Pair Programming a través de la característica de VS Code Live Share
- También podemos hacer salas de descanso en Zoom para las personas que deseen colaborar juntas
- Claudio estará allí para brindar apoyo a todos los asistentes y, por supuesto, responder cualquier pregunta sobre problemas y desafíos técnicos que puedan enfrentar
- Las tecnologías utilizadas en nodejs/nodejs.dev son React/JSX, Markdown, MDX y Gatsby. (No se necesita ningún conocimiento de Gatsby, ya que la mayoría de los problemas son agnósticos a la plataforma)
- Al final de la masterclass, recopilaremos todos los colaboradores que hayan abierto con éxito una solicitud de extracción (incluso si es un borrador) y reconoceremos su participación en las redes sociales.
Managers Are From Mars, Devs Are From Venus
TechLead Conference 2024TechLead Conference 2024
111 min
Managers Are From Mars, Devs Are From Venus
Workshop
Mo Khazali
Mo Khazali
Una Guía para Desarrolladores sobre Cómo Comunicar, Convencer y Colaborar Efectivamente con los Stakeholders
Es una historia tan antigua como el tiempo: la colaboración entre desarrolladores y stakeholders de negocios ha sido durante mucho tiempo un desafío, con una falta de comunicación clara que a menudo deja a ambas partes frustradas. Los mejores desarrolladores pueden comprender profundamente las necesidades de sus contrapartes de negocios, comunicar efectivamente la estrategia técnica sin perder a la audiencia no técnica y convencer al negocio de tomar las decisiones correctas. Trabajando en una consultoría, he fallado y tenido éxito en arquitectar y “vender” visiones técnicas, aprendiendo muchas lecciones en el camino.Ya sea que trabajes en una empresa de productos, seas consultor/freelancer, o quieras aventurarte más allá de ser solo un desarrollador, la capacidad de convencer y comunicar claramente con los stakeholders puede diferenciarte en la industria tecnológica. Esto se vuelve aún más importante con el auge de GenAI y el mercado de desarrolladores cada vez más competitivo, ya que la resolución de problemas y la comunicación efectiva son clave para posicionarte.En esta masterclass, compartiré ejemplos del mundo real, tanto buenos como malos, y te guiaré a través de poner la teoría en práctica mediante dojos.
Cómo crear experiencias de edición que tu equipo amará
React Advanced 2021React Advanced 2021
168 min
Cómo crear experiencias de edición que tu equipo amará
Workshop
Lauren Etheridge
Knut Melvær
2 authors
El contenido es una parte crucial de lo que construyes en la web. Las tecnologías web modernas aportan mucho a la experiencia del desarrollador en términos de construir sitios impulsados por contenido, pero ¿cómo podemos mejorar las cosas para los editores y creadores de contenido? En este masterclass aprenderás cómo usar Sanity.io para abordar la modelización de contenido estructurado, y cómo construir, iterar y configurar tu propio CMS para unificar los modelos de datos con experiencias de edición eficientes y agradables. Está dirigido a desarrolladores web que desean ofrecer mejores experiencias de contenido para sus equipos de contenido y clientes.