¿Estamos condenados para siempre a la seguridad de la cadena de suministro de software?

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

La adopción de software de código abierto continúa creciendo y crea importantes preocupaciones de seguridad, desde ataques a la cadena de suministro de software en los registros del ecosistema de lenguajes hasta preocupaciones de seguridad de aplicaciones nativas en la nube. En esta sesión, exploraremos cómo los desarrolladores son objetivo como vehículo para la distribución de malware, cuánto dependemos de los mantenedores de código abierto para lanzar correcciones de seguridad oportunas y cómo la carrera hacia la nube crea nuevas preocupaciones de seguridad para que los desarrolladores las enfrenten, a medida que los recursos informáticos se convierten en infraestructura como código.

This talk has been presented at TestJS Summit 2021, check out the latest edition of this JavaScript Conference.

FAQ

Es importante porque el software de código abierto es cada vez más utilizado en las aplicaciones, y los incidentes de seguridad recientes muestran cómo los desarrolladores pueden ser un objetivo para la distribución de malware y puertas traseras. Mantener la seguridad en estas plataformas es crucial para proteger tanto a los desarrolladores como a los usuarios finales.

En el incidente de Event Stream, un actor malicioso se involucró en el proyecto y, tras ganar confianza, introdujo una dependencia maliciosa que posteriormente fue utilizada para agregar una puerta trasera en nuevas versiones del paquete. Esto afectó a millones de descargas, incluyendo aplicaciones de billetera Bitcoin que contenían malware.

Una pobre higiene de seguridad puede llevar a que los paquetes sean fácilmente comprometidos. Por ejemplo, contraseñas débiles pueden permitir a los atacantes obtener control sobre los paquetes, afectando a millones de descargas y poniendo en riesgo a numerosos proyectos.

Una respuesta tardía en la mitigación de vulnerabilidades puede exponer a los sistemas a riesgos significativos. La investigación indica que los mantenedores de paquetes de JavaScript y Python tardan casi 100 días en promedio para comenzar a mitigar vulnerabilidades recién publicadas, lo que puede no ser suficientemente rápido para prevenir explotaciones.

La investigación reveló que las credenciales débiles eran un problema significativo, con el investigador de seguridad obteniendo acceso publicado al 14% de los módulos en el ecosistema de NPM, lo cual es alarmante dado el volumen de descargas y la dependencia de estos módulos.

Una puerta trasera es un método que permite a los atacantes acceder a un sistema o datos de manera oculta, generalmente insertada maliciosamente en el software. Puede ser utilizada para robar información, instalar más malware o controlar remotamente el sistema afectado.

Liran Tal
Liran Tal
17 min
18 Nov, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla aborda la importancia de la seguridad del software y los riesgos asociados con las cadenas de suministro de software de código abierto. Destaca historias del mundo real de la participación de los desarrolladores en incidentes de seguridad y enfatiza la necesidad de confiar en el software que utilizamos. La charla también aborda las vulnerabilidades y los ataques dirigidos que surgen de la creciente dependencia del software de código abierto. Explora los riesgos de seguridad en las dependencias de código abierto, los ecosistemas de código abierto y el futuro del software de código abierto. Además, ofrece información sobre cómo elegir el mejor software de escaneo de vulnerabilidades y promover prácticas de seguridad en la cadena de suministro.

1. Introducción a los riesgos del suministro de software

Short description:

En esta parte, discuto la importancia de la seguridad del software y los riesgos asociados con las cadenas de suministro de software de código abierto. Comparto historias del mundo real sobre la participación de los desarrolladores en incidentes de seguridad y enfatizo la necesidad de confiar en el software que utilizamos. Además, destaco la creciente dependencia del software de código abierto y las vulnerabilidades y ataques dirigidos que conlleva. También menciono el ensayo de Ken Thompson sobre la confianza en la confianza y cómo los desarrolladores han sido objetivo para distribuir código malicioso. Por último, menciono el incidente de Event Stream como ejemplo de un ataque dirigido a los desarrolladores en el ecosistema de JavaScript.

¿Estamos condenados para siempre por los riesgos del suministro de software? Si se unieron a esta charla, significa que se preocupan por el software security y eso es genial. Sobre todo, probablemente tengan curiosidad, al igual que yo, ¿cómo afectan los riesgos del suministro de software de código abierto a todos nosotros? Tú, yo, todos aquí.

Así que quería comenzar esto con historias interesantes, como, tómate un momento para reflexionar sobre esta imagen, lo que estás viendo en tu pantalla en este momento. ¿Qué te viene a la mente? ¿Es una perspectiva futurista del mundo, como los robots? ¿Están levantándose y convirtiéndose en una parte clave de nuestras vidas? Tal vez sean otras cosas, como cuánto aprende realmente el robot y carga todo eso en la cloud. ¿Sabes dónde se almacena? ¿Se almacena de forma segura? ¿Qué sucede cuando alguien puede hacer algo malicioso con esos data? Sobre todo, ¿qué sucede si alguien piratea e interactúa con mi hijo? Este es mi hijo, por así decirlo. Y qué sucede cuando tiene lugar esa interacción, cuando alguien puede comprometer eso? Entonces, sí, ahí es donde comenzamos, ya sabes. Estas son algunas de las cosas que me mantienen despierto por la noche.

Hoy me gustaría compartir con ustedes algunas historias del mundo real de cómo los desarrolladores desempeñan un papel fundamental en incidentes de seguridad recientes y crecientes. Y también, ya saben, ¿por qué deberían preocuparse por la seguridad del software, la seguridad del software y los riesgos del suministro de software? Y también, dejarlos pensar en quién realmente confían.

Entonces, en caso de que tuvieran alguna duda, estamos viendo cada vez más software de código abierto siendo desarrollado. Año tras año, ¿verdad, los repositorios de software de código abierto están creciendo con más y más software de código abierto y eso es más huella de software. Lo que sucede es que las aplicaciones que construimos están creciendo cada vez más en su dependencia del software de código abierto, no solo el hecho de que estamos usando software de código abierto, sino que las propias aplicaciones también están utilizando cada vez más eso. Entonces, más de nosotros, básicamente, ingenieros de software, ahora estamos acostumbrados a la forma en que las personas trabajan en código abierto, como abrir problemas y convertirnos en mantenedores de código abierto. Cada vez más de nosotros somos mantenedores de software de código abierto y ese crecimiento del software de código abierto no viene sin riesgos, ¿verdad? Por eso estamos todos aquí, porque nos importa.

Continuamente estamos presenciando el crecimiento de vulnerabilidades de seguridad del software de código abierto en estos ecosistemas, como NPM y Java y otros y esto podría ser cualquier cosa desde informes de vulnerabilidades basados en CVE que cuando instalas un software obtienes esa instalación que dice, sabes, hay 1,000 vulnerabilidades allí. ¿Qué sucede cuando eso ocurre? También los propios incidentes de paquetes maliciosos y diferentes ataques dirigidos a los desarrolladores porque nosotros, como desarrolladores, confiamos en paquetes de software de código abierto y también somos objetivo y llegaremos a eso ahora mismo.

Retrocedamos, en primer lugar, en el tiempo para tener una idea temprana de cómo un desarrollador percibió los riesgos del software de código abierto. Entonces, en 1984, el ganador del Premio Turing Ken Thompson escribió un breve ensayo titulado Reflexiones sobre la confianza en la confianza, en el que describe cómo agregó una puerta trasera al programa de inicio de sesión de Unix en C y luego continuó y agregó una puerta trasera al compilador de C y luego agregó una puerta trasera más con sus cadenas de ataques en el compilador que compila el programa de C que compila el compilador. Correcto, así que en su documento aquí sobre Reflexiones sobre la confianza en la confianza, él explica cómo se puede enseñar al software a aprender rasgos específicos y transmitirlos. Entonces, realísticamente, es muy, muy difícil encontrar las huellas de cosas como caballos de Troya y puertas traseras a menos que hayas escrito realmente todo desde cero. Y me refiero a todo, como el compilador, el enlazador, la CPU, la pantalla en la que estás viendo algo, el teclado, todo. Es muy difícil confiar en un ecosystem. Entonces, como aprendimos de la historia del caballo de Troya de Thompson, esto se remonta a 1984, los desarrolladores han sido objetivo como vehículo para distribuir puertas traseras maliciosas y otro tipo de malware durante mucho tiempo.

Exploraremos algunos de estos incidentes. Estoy seguro de que probablemente hayan oído hablar de algunos de ellos. En 2018, el ecosystem de JavaScript presenció su primer ataque dirigido de alto impacto a mantenedores y desarrolladores por igual donde trabajan en código abierto en el ecosystem en sí y realmente han sido el objetivo del ataque, el vehículo también para distribuir JavaScript malicioso código para todos nosotros que usamos ese software. Y así, el ataque también apuntó a los desarrolladores que usan software de código abierto, específicamente una aplicación de billetera Bitcoin. Y este fue el conocido incidente de Event Stream. Event Stream existía en el registro de NPM desde 2011, durante mucho tiempo, como pueden ver. Prácticamente no recibió ninguna nueva versión en los últimos dos años. Pero obtuvo millones de descargas por semana.

2. Riesgos de seguridad en dependencias de código abierto

Short description:

Alguien ofrece inesperadamente ayuda con un proyecto y abre una solicitud de extracción. Sin que el mantenedor original lo sepa, la persona de confianza introduce una dependencia con una puerta trasera. La dependencia luego se incluye en nuevas versiones del software, comprometiendo su seguridad. Este incidente ocurrió con el paquete Event Stream, lo que resultó en la distribución de una aplicación de billetera Bitcoin infectada con malware durante tres meses.

De la nada, alguien se ofrece a ayudar y dice: 'Quiero ayudar'. Se involucran en el proyecto, ayudan y abren una solicitud de extracción como normalmente se hace en el software de código abierto. Una de esas solicitudes de extracción introdujo la dependencia. En ese momento, esta persona era de confianza. Por lo tanto, recibieron un tipo diferente de acceso al repositorio y publicaron nuevos paquetes y nuevas versiones de ese paquete, y así sucesivamente. Más tarde, cuando agregaron esa dependencia, ahora esa dependencia existe en un estado diferente y pudieron agregar una puerta trasera a esa nueva versión que lanzaron. Y ahora, las nuevas versiones de Event Stream que usan esa dependencia la incluyen, y obtienen esa dependencia con la puerta trasera que el mantenedor original de Event Stream no conocía. No sabían que esto estaba sucediendo y no pueden controlarlo. Porque así es como funcionan los gestores de paquetes de software en ecosistemas específicos como NPM y otros. Esto resultó en dos versiones de la aplicación de billetera Bitcoin infectada con malware durante tres meses, hasta que descubrimos esto, este es el caso de Event Stream.

3. Seguridad y vulnerabilidades de código abierto

Short description:

Un artículo de investigación académica encontró que el 61% de los paquetes de código abierto en NPM se consideran abandonados. Incidentes similares a la historia de Event Stream ocurrieron con Electronative Notify, donde se lanzó una nueva versión con malware. A menudo se pasa por alto la seguridad de nuestra infraestructura de desarrollo, como las instancias en la nube y las herramientas de integración continua. Un investigador de seguridad irrumpió en el repositorio de GitHub de Microsoft Visual Studio Code, destacando la necesidad de comprender el estado actual de la seguridad de código abierto. Los mantenedores de Python y JavaScript tardan un promedio de 100 días en comenzar a mitigar una vulnerabilidad de seguridad recién publicada. El estudio de caso de Marked, una popular biblioteca de Markdown, revela los desafíos que enfrentan los mantenedores de código abierto al abordar las vulnerabilidades de seguridad. No se puede ignorar la cuestión de la confianza y la necesidad de mitigaciones y controles en el software de código abierto.

Ahora, un artículo de investigación académica publicado en 2019 investigó estas propiedades de los ecosistemas de software basados en lenguajes, y encontró que más de la mitad, el 61% de los paquetes de código abierto en NPM podrían considerarse abandonados porque no recibieron ninguna versión en los últimos 12 meses. Eso es exactamente lo que sucedió con la historia de Event Stream. Y como si no hubiéramos aprendido nada de este incidente, un año después, ocurre una acción similar, Electronative Notify, y ocurre un incidente similar. En resumen, en un momento determinado, este paquete existente de Electronative Notify, que no es malicioso, se agrega como una dependencia a un proyecto diferente, esta cosa de EasyDEX GUI. Más tarde, el desarrollador que es dueño de Electronative Notify lanza una nueva versión que ahora incluye un malware, una puerta trasera. Lo que sucede es que el proyecto Electronative Notify ahora está incrustado en una aplicación diferente, esta cosa de EasyDEX, que ahora obtiene una nueva versión de Electronative Notify con la versión maliciosa y lanza nuevas versiones. ¿Suena similar? Exactamente lo que sucedió antes. ¿Cuánto pensamiento realmente estamos dando a la seguridad de nuestra propia infraestructura de desarrollo? Por ejemplo, recursos como las instancias en la nube y su herramienta de integración continua. En enero de 2021, un investigador de seguridad irrumpió en el repositorio de GitHub de Microsoft Visual Studio Code. Básicamente, esto le proporciona cualquier capacidad, como acceso de lectura y escritura, para modificar el código del muy querido IDE VS code que muchos desarrolladores aman. Pero debido a la inyección de comandos que este investigador pudo explotar, pudo darle un vector de ataque para crear inyección de código. Ahora, al abrir una solicitud de extracción, todo lo que tenía que hacer era abrir una nueva solicitud de extracción de código, este investigador ahora puede ejecutar código en los propios ecosistemas de CI de VS code sin estar autenticado ni autorizado. Todo esto realmente le proporciona la capacidad de crear, enviar o, si lo desea, generar shells inversos remotos en los servidores de CI que ejecutan código. Y a partir de eso, poder empujar y tener acceso de escritura al propio repositorio. Afortunadamente para nosotros, todos nosotros aquí en este ecosistema, este investigador informó responsablemente la falla a Microsoft antes de que cualquier otra persona pudiera haber obtenido acceso. Pero tienes que preguntarte, ¿cuánto sabemos sobre el estado actual de la seguridad de código abierto? ¿Qué implica realmente? Entonces, en un esfuerzo por explorar la conciencia de seguridad de las comunidades de código abierto de Python y JavaScript, un grupo de investigadores investigó cómo los mantenedores trabajan en la comunidad de código abierto y cómo lanzan correcciones relacionadas con las vulnerabilidades de seguridad. Una de las preguntas de investigación fue qué tan rápido los mantenedores mitigan una vulnerabilidad de seguridad recién publicada. Una vez que se publica, una vez que hay un CDE, la investigación encontró que lleva casi 100 días en promedio para que tanto los mantenedores de JavaScript como de Python comiencen a mitigar una vulnerabilidad. Tienes que preguntarte si esto es lo suficientemente rápido. Y esto es un poco diferente entre las diferentes comunidades porque para Python, se ha remediado mucho más rápido en comparación con JavaScript, que se tomó su tiempo desde 2018 hasta ahora para ser un poco más maduro y consciente de los riesgos de seguridad. Como estudio de caso exacto de esto, podemos referirnos a Marked. Es una biblioteca, las propias vulnerabilidades de seguridad de Marked de hace varios años. Ahora, lo que sucedió es que Marked es una biblioteca de Markdown. Es un analizador para, ya sabes, JavaScript y Node.js, y es muy popular, con millones de descargas por semana. Un día, un investigador de seguridad simplemente aparece, abre una solicitud de extracción de código para solucionar una vulnerabilidad. Entonces, todo lo que tienes que hacer es fusionarlo, básicamente, como puedes ver aquí. Pero, como sucede con el software de código abierto, los mantenedores realmente están tratando de hacer lo mejor posible, pero no están contratados ni legalmente obligados a brindar soporte. Entonces, yo como mantenedor, tú, todos los demás, realmente estamos tratando de hacer lo mejor posible en el tiempo de lo que podemos hacer. Pero esta vulnerabilidad se mantuvo ahí durante un año, sabiendo exactamente lo que está sucediendo con esto, y esta vulnerabilidad de seguridad en sí misma se hizo pública durante más de un año. Cuando todos dependemos tanto del software de código abierto, no podemos ignorar la pregunta de, ya sabes, ¿en quién confiamos? ¿Cuáles son las mitigaciones y controles que tenemos para hacer frente a los riesgos involucrados? En 2017, un investigador de seguridad que trabajaba con la Fundación Node.js realizó una investigación en la que quería explorar y evaluar el estado de las credenciales débiles de NPM en el registro de NPM. Su trabajo reveló verdades devastadoras sobre los desarrolladores y su falta de higiene de seguridad.

4. Riesgos de seguridad en los ecosistemas de código abierto

Short description:

Un investigador de seguridad obtuvo acceso al 14% de los módulos del ecosistema de NPM, incluyendo paquetes ampliamente utilizados. Las contraseñas inseguras elegidas por las cuentas de los mantenedores conocidos fueron un problema importante. A pesar de la disponibilidad de autenticación de dos factores, solo un pequeño porcentaje de los mantenedores de paquetes de NPM lo ha habilitado. Los seres humanos suelen ser el eslabón más débil en la cadena de seguridad. La utilidad sudo tenía una vulnerabilidad de seguridad que pasó desapercibida durante 10 años. Todos jugamos un papel en el ecosistema de código abierto, donde el 90% de nuestro código de aplicación es de código abierto. Los registros de código abierto pueden ser vulnerables a paquetes maliciosos y la eliminación de paquetes puede causar problemas generalizados. Las empresas y organizaciones deben comprender mejor cómo manejar el software y los registros de código abierto.

Lo que quiero decir con esto es que este investigador de seguridad logró obtener acceso publicado al 14% de los módulos del ecosistema de NPM. Esto es mucho. Algunos de estos módulos se descargaron millones de veces, decenas de millones de veces a la semana. Y siguen siendo una parte clave esencial de este próspero ecosistema de JavaScript, del cual también formo parte. Por lo tanto, esto es muy preocupante para mí también.

El problema radicaba en las contraseñas inseguras elegidas por las cuentas de los mantenedores conocidos, como la palabra `contraseña` literalmente para una de las cuentas que ejecutaba millones de descargas para uno de sus paquetes. Entonces, si puede sucederles a ellos, también puede sucederles a otros paquetes. Si nuestros paquetes de código pueden llegar a millones de desarrolladores, ¿no deberíamos tener más protecciones en su lugar como ciudadanos de las comunidades de código abierto? ¿No deberíamos hacerlo mejor en cuanto a la higiene de nuestras cuentas? Así que podrías imaginarlo.

Pero en NPM, el registro más grande de software de código abierto, aunque la autenticación de dos factores se habilitó desde 2017, solo el 7.1% de los mantenedores de paquetes de NPM han habilitado la autenticación de dos factores. Pensarías que hemos mejorado hasta ahora, pero un año después, en 2020, otra idea interesante que obtenemos sobre lo que ha estado sucediendo es que solo ha aumentado en un 2%. Solo el 9% de las cuentas de desarrolladores en NPM en 2020 han habilitado la autenticación de dos factores. Deberíamos hacerlo mejor.

Como dice el experto en ciberseguridad Bruce Schneier, y ha dicho y escrito en su libro `Secrets and Lies`, los seres humanos a menudo representan el eslabón más débil de la cadena. Piénsalo mientras avanzas y reflexiona sobre este término. Dado suficientes ojos, todos los errores son superficiales. Como un término acuñado por Linux, respaldado por Eric Raymond en su trabajo `La Catedral y el Bazar` en 1999. Exploró las diferencias de cómo el desarrollo de software toma diferentes direcciones entre el código abierto y las empresas. Y una de las cosas fue que si todos lo están mirando, ya sabes, encontraremos los problemas o muchas personas que están mirando este código. ¿Realmente lo encontraremos? Porque en enero de 2021, se descubrió que sudo, la utilidad común instalada en muchas distribuciones de Linux, tenía una vulnerabilidad de seguridad. Específicamente, permitía que cualquier usuario sin privilegios obtuviera acceso de root simplemente por la configuración predeterminada de sudo. Ahora, esto fue tan desalentador como una vulnerabilidad porque estaba a la vista de todos. Durante 10 años completos, esto simplemente apareció allí. Ahora, no podemos negar ser parte de estos ecosistemas de código abierto como consumidores, contribuyentes o incluso como mantenedores para algunos de nosotros. Todos desempeñamos algún papel en un mundo donde el 90% de nuestro código de aplicación son componentes de software de código abierto. Hemos llegado a un punto en el que, ya sabes, damos por sentado el código abierto, ¿verdad? Los registros de código abierto son abiertos por naturaleza. Cualquiera puede ingresar y publicar sus nuevos paquetes, incluso los maliciosos, ya sabes, podríamos sorprendernos, tal vez no se detecten. Nos hemos acostumbrado a esto, ya sabes, abrir y emitir el código fuente de un proyecto o pedir ayuda, pedir una función, ya sabes, pedir que alguien repare nuestro error, con suerte. Pero importamos esos proyectos de código abierto a nuestros proyectos, ¿y entendemos lo que está sucediendo en ese momento? Porque los registros de código abierto son abiertos por naturaleza, pero no estarán ahí todo el tiempo. ¿Qué sucede cuando los mantenedores eliminan sus paquetes y dependencias? Y esta es una historia que sucedió exactamente y para un paquete que fue muy crucial en los ecosistemas, pero causó una interrupción generalizada de los sistemas de integración continua en todas partes. Entonces, al menos, nos enseñó que las empresas y organizaciones que fueron víctimas de este ataque no entendían cómo manejar el software de código abierto y los registros mismos tampoco lo sabían.

5. Riesgos y preguntas en el software de código abierto

Short description:

El software de código abierto plantea riesgos en términos de actividades y activos maliciosos. Los ecosistemas de NPM y PyPI han visto un aumento en la publicación de paquetes maliciosos. La investigación de Alex Berchan demuestra cómo los atacantes explotan fallas de diseño y errores humanos para infiltrarse en corporaciones. El futuro del software y el uso de software de código abierto plantean preguntas sobre la confianza y la seguridad.

Se preguntaban cómo esto podría ser posible y no ser posible. ¿Qué tipo de actividades y activos maliciosos podemos rastrear hasta el software de código abierto? Una y otra vez, encontramos más paquetes maliciosos que afectan al ecosistema de NPM, generando errores tipográficos y otros. Pero no son solo un problema exclusivo de NPM, del ecosistema de JavaScript, porque PyPI también ha visto miles de paquetes publicados a la fuerza en masa para agregar paquetes maliciosos.

Para mostrarnos aún más cómo los atacantes pueden aprovechar el software de código abierto a su favor, Alex Berchan publicó su investigación en febrero de 2021 sobre cómo explotó fallas de diseño en los gestores de paquetes y errores humanos y registros para infiltrarse en corporaciones como Apple, Microsoft y otros. Y todo esto está sucediendo en el código abierto.

Y me gustaría dejarles con algunas preguntas. ¿Tendremos menos o más software en el futuro? ¿Utilizaremos más software de código abierto en el futuro? ¿En quién confías y qué puedes hacer al respecto? Gracias por asistir a mi charla. Mi nombre es Iran Tal, soy un defensor del desarrollo en Snyk donde construimos una plataforma de seguridad para ayudar a los desarrolladores a construir de manera segura con software de código abierto. Gracias a todos por unirse a mi charla. Que tengan una buena conferencia.

6. Importancia de la seguridad y incidentes recientes

Short description:

Esa fue una sesión maravillosa. La seguridad es importante para el desarrollo web. Trojan source y event stream son ataques recientes en el ecosistema de la cadena de suministro de NPM. CodeCuff es un problema de seguridad relacionado con Docker. Trojan source es un artículo académico que describe cómo se puede inyectar código malicioso en proyectos de código abierto. CodeCov tuvo un incidente de seguridad grave debido a una imagen de Docker filtrada. Los incidentes de seguridad y la seguridad de la cadena de suministro son generalizados. La seguridad es una parte esencial del desarrollo de software.

Esa fue una sesión maravillosa. Estoy muy contento de que Liran haya traído este tema hoy porque security es algo muy importante para el desarrollo web. Y sí, gracias por eso.

Entonces veamos los resultados de la encuesta. Y como podemos ver aquí, parece que la gente ha oído mucho más sobre Trojan source que cualquiera de las otras opciones que dejaste allí. ¿Cuál es tu comentario al respecto, Liran?

Sí, tiene mucho sentido porque supongo que se ha hablado mucho de Trojan source recientemente. Eso es más reciente que los demás, pero son diferentes tipos de ataques. Y por eso les di ese tipo de muestra de lo que están viendo. Que es mucho de las cosas de los medios. Pero por ejemplo, un event stream, que, ya sabes, si no lo conocías antes, ahora probablemente deberías saberlo porque lo mencioné en mis diapositivas justo en esta charla. Es uno de los ataques más sofisticados que hemos visto en el ecosistema de la cadena de suministro para NPM, el event stream. Y recientemente eso fue en 2018, pero ahora hemos tenido recientemente, hace aproximadamente un mes, el UA parser agent y COA, y otros paquetes que probablemente fueron secuestrados y agregados, tenían malware y ransomware de criptomonedas. Así que eso sucedió bastante recientemente, pero Trojan source, curiosamente, ha llegado a las noticias. CodeCuff. ¿Has oído hablar de CodeCuff antes, porque es algo relacionado con Docker? No lo han hecho. ¿Te gustaría hablar de ellos?

Sí, hablaré brevemente porque, de nuevo, son todo tipo de cosas diferentes como Trojan source es de un artículo de investigación académica que causó muchas cosas. Y Trojan source en realidad no es un incidente, es más como un artículo académico que describe cómo se pueden inyectar códigos maliciosos en proyectos de código abierto, utilizando caracteres invisibles y cosas así. Como los caracteres originales del código único que cambian la apariencia del texto. Pero aún así, el compilador no tiene problemas con esto porque el código está bien. Y curiosamente, eso se solucionó muy fácilmente, o diría muy rápidamente, al menos, abordando el problema tanto en GitHub como en Snyk, muchas organizaciones actuaron rápidamente para solucionar esto y resaltar ese tipo de problemas. Así que ese es un caso muy particular. CodeCov, por otro lado, lo hemos visto suceder con los incidentes de seguridad del cargador bash, que robaron tokens y cosas así. Muchas personas usan el paquete NPM para eso o la acción de GitHub para obtener cobertura de código, lo cual es muy, sentado en esta conferencia, como una conferencia de testing, pero el origen de ese incidente, por qué sucedió, se debe simplemente a la imagen de Docker que se construyó para la cadena de herramientas de CodeCov que en realidad estaba filtrando, tenía algunas capas internas que filtraron claves privadas que permitieron a alguien cuando lo vieron y sabían dónde cambiar archivos, cómo cambiarlos. Esto continuó durante cuatro meses hasta que se descubrió. Así que también es un problema muy grave. Y fue abordado, ya sabes, muy bien por el equipo de CodeCov con mucha transparencia y respuesta a incidentes en esto. Así que, felicitaciones a ellos por manejar esto, pero simplemente muestra cómo, ya sabes, los incidentes de seguridad y la seguridad de la cadena de suministro están en todas partes. Así que eso es como. Simplemente muestra lo importante que es la security. Y tenemos algunas preguntas.

7. Choosing the Best Vulnerability Scanning Software

Short description:

Para determinar el mejor software de escaneo de vulnerabilidades, considere el análisis de composición de software (SCA) que examina los archivos de sus gestores de paquetes y realiza un seguimiento de las vulnerabilidades basadas en las versiones. Es importante tener flujos de trabajo centrados en los desarrolladores para ayudar a solucionar problemas y una base de datos confiable de vulnerabilidades. Estos rasgos hacen que un software sea mejor.

Y el primero es de Jim Nuro. ¿Es una solución mejor software de escaneo de vulnerabilidades? No sé si entendí exactamente la pregunta. ¿Lo entendiste? ¿Es una solución mejor software de escaneo de vulnerabilidades? Bueno, hay algunos. No discutiré todo el espectro de software de prueba de seguridad. Hay muchos, pero probablemente quieras tener el SCA porque usamos mucho software de código abierto. SCA significa análisis de composición de software. Básicamente, examina los archivos de tus requisitos, ya sabes, archivos de gemas de Ruby, todos los paquetes y todos los archivos relacionados con los gestores de paquetes. Verifica cuáles tienen vulnerabilidades según las versiones y luego realiza un seguimiento en una base de datos de vulnerabilidades. Ahora, eso es importante tenerlo porque confiamos mucho en el software de código abierto y puedes ver muchos de estos incidentes relacionados con las dependencias de código abierto. Entonces, ¿qué es mejor, verdad? Es un poco como, ya sabes, es muy similar a, lo que funciona realmente bien para ti y eso es súper importante. Pero diría que hay dos cosas que harían que un software sea mejor. Para mí, cuando se trata de vulnerabilidades, una es que debe tener en cuenta los flujos de trabajo relacionados con los desarrolladores. No solo mostrarte el problema sino ayudarte realmente a solucionarlo y ayudar a los desarrolladores a remediar los problemas. Y la otra es una base de datos de vulnerabilidades muy, muy buena porque si tienes algo que simplemente funciona pero no cubre realmente muchas de las vulnerabilidades o no las cubre a tiempo o tiene muchas falsas alarmas, todas esas cosas que simplemente agregan ruido y al final terminarás frustrado y no lo usarás. Estos son dos rasgos y características en los que me fijaría en un software que haga eso.

8. Envisioning the Future and Developer Tools

Short description:

La fundación de seguridad de código abierto está trabajando en las mejores prácticas y herramientas para abordar los problemas de manipulación de paquetes. Proyectos como SIG store se centran en la autenticidad y la integridad para hacer que los paquetes sean más seguros. Sin embargo, resolver este problema puede dar lugar a nuevas amenazas. La implementación de herramientas como Dependabot puede ayudar a automatizar las correcciones de vulnerabilidades, pero es importante gestionar la cantidad de solicitudes de extracción para evitar abrumar al equipo. Snyk ofrece herramientas orientadas a los desarrolladores y permite a los usuarios limitar el número de solicitudes de actualización para una mejor gestión.

Genial. Aquí hay otra pregunta, que es ¿cómo te imaginas el futuro? ¿Te imaginas tu propia utopía para la security de paquetes? Es interesante. Sí, pero ¿podrías repetirlo? Es una visión de lo que No entendí bien esa parte. ¿Cómo te imaginas el futuro? ¿Te imaginas tu propia utopía para la security de paquetes? Ah, ya entendí. Bien. Te diré cómo se ve el ecosystem en este momento desde mi participación en muchos grupos de trabajo y foros de security y cosas así. Actualmente se está realizando mucho trabajo en la SSF abierta que es la fundación de seguridad de código abierto, recientemente creada. La idea principal es que hay muchas best practices. Primero, necesitamos que los desarrolladores, ingenieros y el equipo de operaciones de seguridad sepan qué hacer para seguir las mejores prácticas y cómo hacerlo. Por eso estoy dando estas charlas, para ayudar a los desarrolladores a escribir publicaciones de blog sobre las prácticas recomendadas y todas esas cosas. Así las personas pueden mejorar sus habilidades. Eso es la mitad del problema. La otra mitad es el uso de herramientas y definitivamente se está trabajando en proyectos como SIG store y otros que se centran en la autenticidad, la integridad y todo lo relacionado con el paquete para hacerlo más seguro y esperemos que haga nuestras vidas más seguras pero estoy bastante seguro de que veremos más amenazas una vez que resolvamos este problema, ¿verdad? Es como una bola rodante. Sí, sí. Antes de pasar a la siguiente pregunta, quiero hacer una pregunta sobre una experiencia anterior en la que implementé Dependabot de GitHub en una base de código JavaScript. Básicamente, envía automáticamente solicitudes de extracción para corregir problemas de vulnerabilidad y cosas así. ¿Tienes algún comentario al respecto y con qué frecuencia, porque al principio fue divertido porque había demasiadas solicitudes de extracción y teníamos que limitar cuántas queríamos revisar cada semana para poder trabajar en otras cosas también. En algún momento, se convirtió en un número que podíamos gestionar, pero me gustaría escuchar tu opinión al respecto. Sí, creo que es un buen ejemplo. Si Dependabot de NPM funciona para ti, eso es bueno. Eso significa que tal vez estás satisfecho con eso y está bien. Te diré cuáles son las herramientas más orientadas a los desarrolladores y eso es lo que estamos haciendo en Snyk. Una de las cuestiones que mencionaste, que te preocupa porque te inunda con cientos o decenas de solicitudes de extracción. En Snyk, puedes decir: `Oye, sabes qué, quiero limitar mis solicitudes de actualización de paquetes a, digamos, cinco. No sé qué número tenga sentido para tu equipo, pero digamos que son cinco. Entonces, Snyk sabe que no abrirá más solicitudes de extracción de actualización si ya hay cinco abiertas, aunque siempre se abrirá la solicitud de security para mantenerte seguro y protegido. Deberías actualizar lo antes posible.

9. Promoting Supply Chain Security Practices

Short description:

Actualizar rápidamente a veces puede ser arriesgado, ya que puede introducir versiones maliciosas. Snyk tiene herramientas orientadas a los desarrolladores para un entorno seguro y cómodo. Han analizado incidentes de seguridad anteriores y han determinado un cronograma óptimo para introducir nuevas versiones de paquetes. Promover las prácticas de seguridad de la cadena de suministro implica crear conciencia, discutir con colegas y seguir las mejores prácticas. El blog de Snyk y varias herramientas proporcionan recursos valiosos. Cuanto más hablemos y usemos estas herramientas, mejor podremos promover la seguridad de la cadena de suministro.

Pero todo el alboroto general, como el alboroto de la solicitud completa sobre abrir más y más y más solo para mantenerse actualizado. Siempre limitamos eso hasta cierto punto. Y eso ayuda a tu equipo a tener ese control de cómo hacer las cosas. Suena como una pequeña característica, pero es exactamente esa mentalidad de desarrollador primero que tiene Snyk, que es, ya sabes, gratuito y de código abierto con la CLI y las herramientas. Entonces, eso realmente se dirige a los desarrolladores en términos de cómo deberían trabajar en un entorno muy seguro y cómodo.

La otra... Totalmente de acuerdo, sí. Claro, sí. El otro aspecto es, por ejemplo, estábamos analizando algunos incidentes de seguridad en el pasado. Y una de las cosas que aprendimos es, que también se relaciona con lo que dijiste, con muchas actualizaciones de paquetes que te inundan. Y a veces, actualizar muy, muy rápido en realidad es malo, ¿verdad? Porque si esto está ahora en la versión tres, cinco, dos, lo que sea, es la versión más nueva que tienes, y alguien te dice que actualices Dependabot o algo más, actualizaste esto y luego, dos semanas después, descubres que te actualizaste demasiado rápido. Y ahora esta es una versión maliciosa, como UA parser COV, etc. Actualizar muy, muy rápido en realidad te pone en una posición de riesgo. De hecho, ya hemos hecho esto, incluso hace, creo que dos años, como en 2020, incluso tal vez en 2019, donde analizamos algunos de los incidentes de seguridad anteriores que ocurrieron, y descubrimos cuál es un cronograma óptimo donde introduciremos una nueva versión de paquete, que no sea demasiado pronto, pero tampoco demasiado tarde. Y creo que eso es como 20 o 21 días. Entonces, si hay un nuevo paquete, no te lo diremos hasta 20 o 21 días. Y después no puedes, lo haremos. Entonces, eso es como, ya sabes, hay cierta seguridad en eso. Eso es genial. Eso es genial.

Y la última pregunta, ¿cómo podemos promover mejor las prácticas de seguridad de la cadena de suministro? Buena pregunta. Sabes, es mucho. Ayúdame a crear conciencia, ya sabes, hablar de ello con tus amigos, con tus colegas, seguir las mejores prácticas. Hay un montón de información en el blog de Snyk. Si buscas en Google las mejores prácticas para NPM o Noders Java, encontrarás un montón de cosas que hemos escrito, como hojas de trucos y PDF y todo, desde las herramientas que estamos construyendo. Y la idea es realmente ayudarte. Y, ya sabes, yo mismo soy desarrollador. Escribo todas estas herramientas, incluso escribí un complemento de ES linked para detectar y prevenir ataques de código fuente troyano, que muchas personas aquí dijeron que conocían, así que, ¿por qué no usarlo? Estamos haciendo mucho en términos de activismo para promover la conciencia de la seguridad de la cadena de suministro, la seguridad de código abierto en general. Y, ya sabes, cuanto más hablemos de ello, cuanto más usemos las herramientas, cuanto más asumamos la responsabilidad de lo que usamos y la debida diligencia que hacemos, es un paso más para promover la idea en general y avanzar en esta historia. Sí, una última pregunta de mi parte, ¿qué recursos recomiendas para leer sobre pruebas de seguridad? Hay bastantes.

10. Using OS for Developers

Short description:

OS tiene una serie de hojas de trucos, incluyendo OSASVS y Proactive Controls, que están orientadas a los desarrolladores. Sin embargo, la documentación y la terminología pueden resultar abrumadoras para los desarrolladores que no están familiarizados con los conceptos de seguridad.

Quiero decir, OS es bastante bueno en términos de, como tienen una serie de hojas de trucos, que recomiendo encarecidamente. Si te gustan las hojas de trucos de Google OS, podrás crear una página de inicio con un montón de ellas. Está el OSASVS y que es como, y los Proactive Controls que son, los Proactive Controls están muy orientados a los desarrolladores. Diría que la única especie de advertencia con OS es que todavía está muy orientado a la seguridad. Así que, como está dirigido más hacia las personas de seguridad, no hacia los desarrolladores en cierto sentido, como la documentación, la forma en que se construyen las cosas, la terminología. Así que puede resultar muy abrumador cuando lo lees como desarrollador y ves, como lees en la pantalla, como CVEs, CVSS Core, como muchas cosas que es posible que no conozcas y que te alejarán. Así que quiero decir, pero aún así OS es un lugar realmente genial para encontrar información. Promocionaré de nuevo el blog de Snyk porque es un recurso realmente bueno y estamos realmente orientados a los desarrolladores en todo lo que hacemos desde la escritura hasta todos los recursos. De hecho, si vas a learn.snyk.io, también verás un producto reciente que lanzamos, como un recurso educativo gratuito para desarrolladores o cualquier otra persona que quiera aprender sobre cosas de desarrolladores. Y tenemos cursos cortos que puedes hacer, como vulnerabilidades de deserialización en Java o cosas en JavaScript, para ese tipo de contaminación. Supongo que nunca has visto eso. De hecho, hacemos una demostración en vivo, como interactiva donde puedes hackear una aplicación. Te mostramos qué está mal y por qué, es muy, muy orientado a los desarrolladores y me encanta. Es una de mis cosas favoritas que hemos hecho recientemente. Así que creo que eso debería ayudarte a empezar bastante rápido. Sí, ya he tomado notas de ellos. Así que muchas gracias por tu tiempo. Gracias por compartir tus conocimientos con nosotros aquí. Genial, gracias por tenerme. Lo apreciamos. Gracias a ti también, y que todos se mantengan seguros y protegidos.

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

Solicitudes de Red con Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Solicitudes de Red con Cypress
Top Content
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Pruebas de ciclo completo con Cypress
TestJS Summit 2022TestJS Summit 2022
27 min
Pruebas de ciclo completo con Cypress
Top Content
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
Desarrollo Efectivo de Pruebas
TestJS Summit 2021TestJS Summit 2021
31 min
Desarrollo Efectivo de Pruebas
Top Content
This Talk introduces Test Effective Development, a new approach to testing that aims to make companies more cost-effective. The speaker shares their personal journey of improving code quality and reducing bugs through smarter testing strategies. They discuss the importance of finding a balance between testing confidence and efficiency and introduce the concepts of isolated and integrated testing. The speaker also suggests different testing strategies based on the size of the application and emphasizes the need to choose cost-effective testing approaches based on the specific project requirements.
Playwright Test Runner
TestJS Summit 2021TestJS Summit 2021
25 min
Playwright Test Runner
Top Content
The Playwright Test Runner is a cross-browser web testing framework that allows you to write tests using just a few lines of code. It supports features like parallel test execution, device emulation, and different reporters for customized output. Code-Gen is a new feature that generates code to interact with web pages. Playwright Tracing provides a powerful tool for debugging and analyzing test actions, with the ability to explore trace files using TraceViewer. Overall, Playwright Test offers installation, test authoring, debugging, and post-mortem debugging capabilities.
Todos pueden escribir pruebas fácilmente
TestJS Summit 2023TestJS Summit 2023
21 min
Todos pueden escribir pruebas fácilmente
Playwright is a reliable end-to-end testing tool for modern web apps that provides one API, full isolation, fast execution, and supports multiple languages. It offers features like auto-weighting, retrying assertions, seamless testing of iframes and shadow DOM, test isolation, parallelism, and scalability. Playwright provides tools like VS Code extension, UiMode, and Trace Viewer for writing, debugging, and running tests. Effective tests prioritize user-facing attributes, use playwright locators and assertions, and avoid testing third-party dependencies. Playwright simplifies testing by generating tests, providing code generation and UI mode, and allows for easy running and debugging of tests. It helps in fixing failed tests and analyzing DOM changes, fixing locator mismatches, and scaling tests. Playwright is open source, free, and continuously growing.

Workshops on related topic

Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
React Summit 2023React Summit 2023
151 min
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
Top Content
Featured Workshop
Josh Justice
Josh Justice
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()?
En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor.
Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos
Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Masterclass Práctica: Introducción a Pentesting para Aplicaciones Web / APIs Web
JSNation US 2024JSNation US 2024
148 min
Masterclass Práctica: Introducción a Pentesting para Aplicaciones Web / APIs Web
Featured Workshop
Gregor Biswanger
Gregor Biswanger
En esta masterclass práctica, estarás equipado con las herramientas para probar efectivamente la seguridad de las aplicaciones web. Este curso está diseñado tanto para principiantes como para aquellos que ya están familiarizados con las pruebas de seguridad de aplicaciones web y desean ampliar su conocimiento. En un mundo donde los sitios web juegan un papel cada vez más central, asegurar la seguridad de estas tecnologías es crucial. Comprender la perspectiva del atacante y conocer los mecanismos de defensa apropiados se han convertido en habilidades esenciales para los profesionales de TI.Esta masterclass, dirigida por el renombrado entrenador Gregor Biswanger, te guiará a través del uso de herramientas de pentesting estándar de la industria como Burp Suite, OWASP ZAP y el marco profesional de pentesting Metasploit. Aprenderás a identificar y explotar vulnerabilidades comunes en aplicaciones web. A través de ejercicios prácticos y desafíos, podrás poner en práctica tu conocimiento teórico y expandirlo. En este curso, adquirirás las habilidades fundamentales necesarias para proteger tus sitios web de ataques y mejorar la seguridad de tus sistemas.
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Masterclass de Pruebas de API con Postman
TestJS Summit 2023TestJS Summit 2023
48 min
Masterclass de Pruebas de API con Postman
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman.
Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Monitoreo 101 para Desarrolladores de React
React Summit US 2023React Summit US 2023
107 min
Monitoreo 101 para Desarrolladores de React
Top Content
WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend.
Nivel de la masterclass: Intermedio
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
Top Content
Workshop
Gleb Bahmutov
Gleb Bahmutov
Esta masterclass te enseñará los conceptos básicos para escribir pruebas end-to-end útiles utilizando Cypress Test Runner.
Cubriremos la escritura de pruebas, cubriendo cada característica de la aplicación, estructurando pruebas, interceptando solicitudes de red y configurando los datos del backend.
Cualquiera que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir adelante.