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

Rate this content
Bookmark

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.

17 min
18 Nov, 2021

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.

Available in English

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

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.