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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.