Dependencias y seguridad: ¿Dónde está el riesgo?

venida a Vale, para iniciar como Dios manda. Vamos a darle sus shots para que se le quite la en plural.

[Música]

[Música] Listo. Y el título de la charla es, a ver, para mí interferir ahí, eh, dependencias y seguridad, ¿dónde está el riesgo? Entonces, un aplauso, por favor, muchachos. Hola, hola a todos. Muy buenas tardes. Eh, ¿sí se ve bien la pantalla o cambia un poquito la resolución? Eh, sí, se ve bien. Ah, super bien. Eh, pues bueno, muy buenas tardes a todos. Espero que hayan comido muy bien. Provechito. Buen apetit. Eh, ojalá que todo esté chido y que se está pasando increíble en este evento. Yo me estoy pasando increíble, honestamente. Torreando con amigos nuevos, viejos, todo voy a todo dar. Eh, estoy un poquito nervioso y es que esta charla yo ya le he dado antes

eh, en otros lugares, pero decidí cambiarlo un poquito para actualizarla a mi actualizarla lo que estamos viendo en estos momentos. Eso por un lado. Por otro lado, la primera vez que di esta charla estaba medio borracho, por eso el tema de pedir los dos shots de mezcal, porque siento que así estuvo mucho mejor, ¿verdad? Porque si no va a estar muy aburrido. O sea, hablar de dependencias y de código y infraestructuras es chido, güey. O sea, no jackas nada, ¿no? O sea, neta, ponte pilas. Eh, entonces, pues vaya. Eh, es un poquito del background. Yo soy Eric, para los que no me conocen. Trabajo en Lift. Ahí está mi siso. Say heim heim. Eh, en caso de quieran platicar con con

él acerca de lo que hacemos enft y eh también soy organizador de que es otra conferencia de seguridad allá en Guadalajara, por si quieren caernos el próximo año allá en marzo. Se va a poner bien perro. Este, pero todo lo que diga en este momento no tiene nada que ver con la empresa que me da de comer ni con la organización a la que yo ayudo y pertenezco como voluntario. Va. Todas mis opiniones y cosas que puse aquí son cosas personales, este, y tal vez no tan personales, pero bueno, nada de lo que diga acá, este, me representa a los que me dan de comer. ¿De qué va a tratar estra? Bueno, primero, ¿de qué no va a tratar? No va a

tratar acerca de hacking, lo siento, no soy offensive tester, retimer ni similar. Si quieren aprender hacking, pues busquen algún purple, red, black, green, lo que sea, hat, que les enseñe cómo hackear. Este, todos somos kids en un momento de la vida. Eh, tampoco les voy a enseñar cómo programar bien. Un detalle, ¿qué pasa siembla? ¿Alguien sabe qué tenemos que hacer si se empieza a mover un poquito la tierra? Guardar la cama. Okay, no corro, un grito, un empujo, tiene sentido no tomar mezcal. Okay, apuntado. Va. Eh, pues bueno, no vamos a hablar tampoco de seguridad física y qué hacer en caso de que se caiga un edificio Fingers Cross. Tampoco les voy a enseñar a programar bien. Este, me encantaría,

pero pues no no tengo chance de hacerlo. Eh, para eso pues simplemente valide sus entradas y salidas y chequen que sus desarrolladores validen entradas y salidas, por favor. Gracias. Eh, y finalmente, antes no hablaba acerca de otros problemas de seguridad en otras dependencias porque estaba enfocada a dependencias de código. Pero, ¿qué creen? Ahora sí les voy a hablar acerca de por qué hace un año, ah, ¿quién vino el año pasado? ¿Se acuerdan qué estaba pasando con Crowst año pasado? Estuvo muy divertido. Estuvo triste, aburrido de que no fuera pues tal cual un ataque, sino simplemente fue un developer y no probó bien y el pipeline tampoco probaba bien y pues todo se fue al [ __ ] ¿no? Este, pero pues es una

dependencia que tenemos este y que teníamos Crowstrike rompiendo el internet, ¿no? Entonces voy a hablar acerca de cómo es que pues esas cosas pueden romper lo que hacemos justamente de las que dependemos. Y tampoco les voy a dar un pequeño pich de ventas, eh, porque la neta no me pagan. Entonces, ¿para qué voy a andarles vendiendo herramientas chidas? No, que sí hay unas herramientas muy chidas para esto. Pero bueno, ¿de qué sí les voy a hablar acerca de cadena de suizo del software, es decir, de dependency gel? Sí, es cierto, o sea, todo el software que se crea es dependencia de la dependencia, dependencia dentro de dependencia. eh de la academia de suministro de infraestructura tecnológica. Es decir,

eh no crean que nada más lo que hacen los developers es culpa de ellos que sea vulnerable y culpa de tomar malas decisiones. Este eh es son temas que van pues cómo funciona una cadena de suministro general donde pues tú dependes de otros proveedores, recursos y demás para construir lo que sea que estás construyendo. Análisis de riesgos. Sí, voy a hablar eh poquito de por qué es que tendrían que fijarse un poquito más en qué está haciendo cada uno de esos changos, changas y changues alrededor de la empresa con las decisiones que están tomando y los riesgos externos. O sea, la verdad es que no todo lo que hacen los desarrolladores y la demás gente que se dedica a desarrollar

software y producto, pues es culpa de ellos que sean vulnerables o o tal vez sí, ¿no? No sé. Eh, muy bien. Eh, me voy a ir un poquito rápido porque la verdad es que si me cuero me voy a tardar un chorro, entonces voy a empezar a moverle más rápido. ¿Qué es la cadena de suministro? Eh, si todos somos obreros y nos dedicamos a crear productos de tecnología, entonces la materia prima eh de la obra, es decir, eh pues la arena, la grava, el cemento, todo eso es parte de su cadena de suministro y pues uno no va a una montaña, a un cerro a picar piedra para obtener esa piedra, ¿no? y la compras alguien. Entonces, tú

proveedor es la cadena de suministro también y las herramientas que compras con las que empiezas a construir son tu caderno de suministro y el transportista. Es tu cad suministro. Fíjense en el transportista porque ese es bien importante y ahorita en 3 segundos lo vamos a ver. Eh, ¿quién? Pues todos los que básicamente laboran y trabajan para construir algo, este, en el caso de construcción, construcción, este hermoso edificio que ya tiene tantos hermosos años y que en serio estoy pensando se va a caer o no, este son parte de la cadena de suministro. En el caso del software, tu cara de suministro es lo que utilizas para desarrollar este eh el el ambiente integrado de desarrollo, este los

compiladores, los tters, eh las herramientas que utilizas para configurar tu terminal, eh la construcción de vaquetas. Regularmente los programadores no compilan localmente y bueno, ¿quién sí compilara localmente? Madres, okay, nadie quiere decir, no son de En fin. Entonces, la manera en que construyes el código de las herramientas para construir también son tu cen suministro. El bactora sí se va a caer esto. Bueno, eh, el dichoso CD y D box es parte de tu canción suministro. Lasciones que tomas ahí son importantes. Eh, las dependencias de código, que es lo que ya sabemos de lo que vamos a explicar un ratito, las dependencias de sistema operativo, las imágenes que utilizas, esos contenedores, o parte de tu sumilistro, eh, y inserte la

inteligencia artificial de moda que estén utilizando. También es por parte muy importante de su car de suministro, ¿no? Entonces, la car de suministros son un montón de cosas que honestamente eh tendríamos que tener un análisis de riesgo para cada una de ellas y aparte de hacer un análisis de riesgo de cada una de ellas, tenemos que hacer un análisis de riesgo de todo ese riesgo en conjunto, ¿va? O sea, no se trata nada más de decir de que, ah, sí, es que yo corro, eh, sudo DNF y ya con eso ya chingué. Ah, perdón, mi francés, eh, por si ti hablar un poquito afrancesado cuando cuando tomo mezcl, eh, entonces sí, o sea, no es una sola

cosa que tenemos que hacer para reducir el riesgo, no son varios, porque el riesgo está en mucho chorro de la Eh, entonces aquí yo voy a empezar a saltar un poquito a eh en dónde hay dependencias de código. En el caso pues justamente de los desarrolladores que utilizan un chorro dependencias de código. Ah, y a ver, una pregunta, ¿por qué los developers no programan todo o no programan chido o no programan seguro? A ver, Alex, cuéntame. Eh, tiempo en entrega sería todo desde cero, es lo fácil de utilizar y si hay funciones muy especializadas que el fabricante con un pedazo de abajo. Entonces, o sea, los desarrolladores no pueden construir todos desde cero, ¿no? O sea, necesitan consumir herramientas

de otros para poder hacer sus otros y muchas veces esos otros a pesar de que sí se fijan en la seguridad o no, eh pues van a [ __ ] Nosotros queremos, yo programé muchas veces durante toda mi vida y sigo programando y sigo mandando cosas que son inseguras, a veces menos ya le echo muchas ganas y trato de que me ayude la inteligencia artificial para hacerlo no tan feo, pero es es complicado, ¿no? Es complicado. Entonces, dependemos de muchas dependencias. ¿Y cuántas dependencias hay? Este no, este no. ¿Cómo está? Este, aquí es.

En el caso de Java, por ejemplo, hay eh no se ve absolutamente nada. Eh, G Unit es la herramienta que se utiliza por excelencia para hacer pruebas unitarias en Java y se descarga eh millones y millones y millones de veces y estas eh métricas pues obviamente son métricas que van caminando constantemente, ¿no? Entonces eh la cadena de suministro en el caso de Java, en el caso de Maven, pues incluye sí o sí y J Unit si es que se tienen pruebas unitarias. Si alguien llegara a hackear Y Unit, ¿cuántas cosas se hackearían? un no. Eh, un caso similar o peor aparece con no. ¿Por qué? Porque no. Este es eh lo das. ¿Alguien sabe qué

hace lo das? ¿Alguien aquí ha programado o programa todavía? Ándale. ¿Sabes qué hace lo das? ¿Sabes qué hace lo das? ¿no? Okay. Load dash es una biblioteca en JavaScript que sirve para hacer cosas muy básicas, pero así muy básicas de copiar pegar concatenar sintaxis etcétera. Entonces, en lugar de que las personas muy listas que crearon JavaScript, este, agregaran esas funciones, dejaron que la comunidad las creara. Y la comunidad hizo una biblioteca que se llama Low Dash, que ahora ya es un monstruo que hace un millón de cosas y tiene una vulnerabilidad en específico que se llama Prototype Pollution, que es superclicada de explotar pero todos la tienen. Entonces, si alguien sabe explotar Protect Pollution, pues

explótela, ¿no? Porque ahí está en todos los sitios web que existen en el mundo habidos y por haber. Y en el caso de Python, que justo la compañera acá hace Python, yo también hago Python. Este eh si quisiéramos darle en la torre al mundo de desarrollo en Python, eh al parecer lo que tenemos que hackear sería Cloudf, eh después Acme la no sé qué es. Eh el bot de Cloudfare y voto no que voto tre es la biblioteca para poder conectarse a los iPadas de Aw. Entonces, todas estas son paquetes superpopulares que eh estamos utilizando todo el tiempo los que dedicamos a hacer cosas tecnología y que desarrollamos de alguna manera o de otra y que pues son un riesgo porque

pueden tener cosas las que v hablar al ratito que son vulnerabilidades y cómo podemos analizar de qué está hecho el software, ¿no? Este, ¿cómo voy? Eh, se me voy a curar. Eh, bueno, muy rápidamente estos se llaman dependency crees de dependencias. Eh, es una eh un concepto ya bastante viejito en el tema de la construcción de lenguajes de programación y básicamente es una cosa así super horrible que se ve más o menos ah así en Python. Este es un proyecto open source en el que contribuyo, que se llama cartography, este, y básicamente te dice, "Ah, tú necesas eh PGWT, que a su vez depende de eh cryptography versión tal. Necesitas request que a su vez

dependense depende de URL versión tal ta." Entonces, saber de qué está hecho tu software es importante, muy importante, porque si no no sabes en dónde están tus riesgos. Básicamente eh para los casos de los que desarrollan y manejan infraestructura de contenedores, los contenedores tienen capas este así como de frío, ¿no? Así como de vamos a poner justo hablando del tema de construcción, pues vamos a poner primero eh la arena y después encima vamos a poner eh los pilotes y después ya vamos a empezar a poner capas de grava, etcétera, etcétera, etcétera. Entonces, los contenedores eh tienen distintas capas y cada capa se puede construir de una capa o de una fuente este exterior, por decirlo así. Entonces, eh si no sabemos

de qué están hechos o qué capas tenemos en nuestros contenedores, nos metemos en un verdadero show y en un relajo bien divertido. Hay maneras muy fáciles de obtenerlo. Eh, hay una herramienta muy chida, ya bastante viejita que se llama DI, bueno, no viejita, pero pues que tiene ya rato, que se llama DIE, que te dice justamente qué capas hay. Y el mismo Docker, este, el mismo cliente de Docker local también te puede generar esa esa historia, ¿no? Y a lootr voy a hablar acerca de cómo también te puede generar qué vulnerabilidades hay en cada una de esas capitas. Está chido, ¿eh? Y pues bueno, ustedes quieren hablar de hacking, la neta, ¿no? Seamos sinceros. Entonces, ¿en dónde fue un

problema esto de explotar la cadena de suministro? Eh, pues el Líbano, esto pasó hace un año, sí, ya. Ay, madre, mucho tiempo, ¿eh? El grupo de Jesbol y walki a una empresa que ya la había comprado antes. O sea, no es como que decidieron, ay, sí, me voy a ahorrar unos cuantos dolaritos y comprárselas a alguien más, ¿no? O sea, era la misma empresa que ya había comprado, pero pues el gobierno israelí intercepta esos lotes. Ya ven por qué el transporte es importante. Este, pongan TPS en todas sus comunicaciones. les agregan explosivos y les ponen un pequeño switch para detonarlos. se una noticia así super machín en todo el mundo de que por medio de la cadena de

suministro pues hicieron un impacto que a lo mejor no retrasó o les afectó en la guerra, pero que mediáticamente estuvo bien heavy, ¿no? Este y pues ese tipo de ataques, de hecho, los actores o los gobiernos es muy común que los intenten o que los hagan con cierta medida de éxito, ¿no? Y ahora nosotros estamos hablando de software, no estamos hablando de de esa cosa intangible que tenemos que está corriendo el y que está corriendo el proyector y que está corriendo los carros y que ya están todos. Eh, este es un problema mundial, está en el was top 10 de la última versión del 2021 y muy probablemente va a estar en el top 10

2025. Ya va a salir el top 10 2025. ¿Cuántos años tenemos haciendo el top 10? Ya, ya más de 10. Ah. Y sigue estando en SQ injection. [Música] miedo.

Entonces, bueno, en los Was Top 10 dice que te tienes que fijar en qué componentes tienes, es decir, en tu canal de suministro para ver cuáles son vulnerables. O sea, el consenso de la industria con datos, con datos, fíjense, o sea, esto no está inventado así por cualquier [ __ ] Este, todo el consenso de la industria ha demostrado otra vez, no sea nada, que tenemos que seguir teniendo mucho cuidado en cómo consumimos y qué vulnerabilidades hay para construir nuevos software, para construir nuevas aplicaciones, ¿no? Entonces, esto está en el 2021, va a estar seguramente en el 2025, eh, y pues tendremos que hacer algo para para remediarlo, ¿no? Esta es una pequeña historia que seguramente ya la mayoría

de ustedes saben. Eh, ¿quién si está familiarizado con el caso de Solar Wins? Ay, la mitad sí, la mitad no. A ver, los que sí saben, ¿sí fue un pedo pedo o fue un perito? Fue emocionante. Okay. ¿Quién estabas de Incident Response en Solar Wins? [Música]

fue una cátedra de carrera de suministro justamente. O sea, hagan de cuenta que lo que pasó ahí es que para los que no saben de este lado es que eh Solar Wins básicamente es una empresa que hacía un software, se llama Orion y ese Orion sea para funcionaba para la gestión de redes, ¿va? Entonces, en esa gestión de redes, la herramienta pues la compraban muchos clientes, incluido el gobierno federal de Estados Unidos, el Departamento de Defensa, la Secretaría del Tesoro, etcétera, etcétera, etcétera. Y alguien que no sabemos quién fue o no nos quieren decir este o ya nos dijeron y nos hemos de la vista gorda, eh pudo infiltrar un cambio en el software, pero no en el código, sino en

el paquete, o sea, encontró la manera de ese de esa herramienta ya ese binario que se iba a desplegar, que iba a estar corriendo en los playas de de hardware para las redes, eh tuviera un pequeño que le iba a poder dar acceso a todo el tráfico de red que pasaba por ahí y de hecho sí funcionó y sí lo hizo. Entonces, todo ese tráfico de red eh básicamente pudieron tener acceso este ente que no sabemos quién fue este hasta que no se apagaron esos esos aplianas o ese software o se parchó. Entonces, mientras tanto, imagínense a toda la comunidad de ciberseguridad del mundo pensando, ¿qué hago? ¿Por qué desconecto la red? desconecto el cable, corto el

enchufe, apago los servidores o o qué hago, ¿no? Eh, entonces a partir de ese problema, el gobierno de Estados Unidos se lo toma muy en serio eso del problema de la cadena de suministro y emite una ley. Esa ley básicamente va a obligar a casi casi todos los proveedores del gobierno gringo y en general como sentario para el resto de la industria de que hagamos este análisis de la cadena de suministro constantemente con una cosa que se llama SBOMS, que al ratito les voy a platicar si es que me da tiempo. Eh, Lock for Shell. ¿Alguien de ustedes manejó Lock for Shell? A mí eso me tocó y estuvo divertido. Este, Java It's everywhere. Java Rons in 3 billion devices.

O sea, eso significa que Java está en todos lados. O sea, seguramente su carro tiene llag. Eh, quién sabe por qué, ¿no? Eh, la neta es que la mayoría de la industria financiera en el mundo usa Java y muchos empresas usan Java y usamos Java, Google usa Java, todos usan Java. Entonces, eh y a pesar de que no uses Java, tú compras eh servicios como Jira. ¿Quién utiliza Jira en su chamba? Aunque Kira corre en Java. Entonces, hay muchas herramientas que están hechas en Java que se venden a un montón de de clientes, ¿no? Entonces, Lock for Share era una vulnerabilidad en Java que estaba superfácil de explotar, pero así s superfácil de explotar. Entonces, el

problema es que estaba en una biblioteca tan tan viejita que tenía dos mantengers, o sea, dos personas eran responsables de la seguridad. Ah, no saqué ese meme, pero todos se lo saben, ¿no? De que ah, el internet, una persona que contruye el open source mantiene todo el maldito internet. Ah, pues eso fue lo que pasó. Tal cual. O sea, eh había una vulnerabilidad de un código que pues no era malicioso, pero pues que alguien lo metió sin querer este y que eh pues se encontró que era vulnerable, que permitía ejecución remota de código con algo superfácil, nada más con tratar de loguear algo y listo. Y y prácticamente todo se loguea en en el mundo corporativo, Java, etcétera.

Entonces, pues nada, o sea, estuvimos como locos buscando dónde estaba Java y dónde estaba esa versión específica de la biblioteca de Java, ¿no? Y era un pedo porque, o sea, tú piensas como empresa que desarrolla tecnología que sabes con qué estás tratando, pero la neta es que no sabes, no sabes dónde demonio estás utilizando esas cosas. Eh, y ya nada más les platico otra otras dos explotaciones. Eh, la que se me hace más divertida es XZ utils. Eh, XZ utils, y esto es un buen partag de transitividad. Eh, dependencias transitivas. Hay dos tipos de dependencias en el desarrollo, ¿no? Las directas y las transitivas. Las directas es, yo quiero utilizar low dash versión 1. Las transitivas es low dash

utiliza el internet para poder funcionar porque así funciona JavaScript. Entonces, eh XZ utilcia transitiva de Open SSH. ¿Quién ha hecho un SSH algún server alguna vez? Seguramente ha utilizado XZ tips y no lo sabe porque va a saberlo, ¿no? O sea, poco ustedes quieren saber cómo comprimir información de manera eficiente, ¿no? No, realmente no les interesa. El chiste es de XZ, el equipo porque fue un equipo que pudo inyectar un XZ utils durante 3 años estuvieron como buenos espías este haciendo ingeniería social y viendo la manera de poder convencer a los mantenedores, a los contribuidores de esa herramienta Existan dos changos en el mundo. O sea, les ponemos la responsabilidad a dos personas en el mundo de la seguridad,

eh, la transmisión segura de acceso remoto a los servidores. No son mala onda. Mínimo paguen eh Wikipedia, una cosa así. Eh, el chiste es que bueno, 3 años hacen esta campaña, logran inyectar Malw nuevamente en el paquete, no en el código fuente. Entonces es la distribución la que es eh tiene ese malware y si no es porque un developer de postgris, un developer de posgris eso lo que todos ustedes y yo no podimos hacer, que fue encontrar un malware antes de que realmente tuviera impacto, porque el CPU este estaba consumiéndose mucho. Gracias a ese developer que trabaja allí en Microsoft fue que no se expandió este paquete malicioso por todo el internet, ¿no? ¿Cuántos paquetes

creen que realmente están exponiéndonos y realmente si son maliciosos y están ahí en el internet? Mejor no pensemos en eso, no pensemos en cosas bonitas. Este y pues bueno, Polyfield fue un caso eh similar, ese nada más fue una librería de JavaScript que pudieron eh tomar control del dominio y la reemplazaron y entonces pues la neta solo querían poder minar criptos de cierto grupo específico de usuarios, ¿no? Entonces no fue tan feo, pero pues aún así no nos cayó. Eh, y bueno, hablando de técnicas que justamente hay para explotar, ya les hablé acerca de inyectar cosas en los paquetes. Este, les hablé de vulnerabilidades de código que sin querer meten los developers, sin saberlo. Y hay otra muy común que es el

tema de los typos en los nombres de paquetes. Entonces, si yo utilizo una biblioteca que se llama Loadash, pero le pongo una H men este, pues alguien puede subir ese paquete lo das y eh si yo lo descargo, se pueden ejecutar scripts localmente en mi compo o en mi ambiente de integración continua que pues van a ser vulnerables con ese malware que se inyecte. De hecho, les quería hacer un ejemplo, pero la neta no me dio tiempo eso de tener la dependencia a comer me hace tener que trabajar mucho este y preparar esta charla, pues está bien. Pero bueno, imagínense que alguien sube ese low das incluye malware y no ya también este no está inyectando malware como una

dependencia eh en esta casa seguramente directa. Y esto es el pan de cada día en npm y noche y es pero así pan de cada día, así bien machue nada más lo encuentr este ya no me sirve. Este sí este es un ejemplo de Maven. Este es el planeta. Entonces hay un montón de probabilidades en JavaScript. Sí, ya sabemos. Pero eh lo que yo realmente les quiero enseñar es a ver si se abre con el link eh eh que todos los días todos todos los días aparece nuevo Marvel en JavaScript, básicamente. O sea, son horas de verdad, horas en las que ah una nueva dependencia con Marvel, ah una nueva dependencia con Marvel, o sea, neta no no paran de, o sea, estos

desarrolladores porque también son desarrolladores de Marw, eh, o sea, también tienen buenas prácticas y malas prácticas. Entonces, ellos, la neta es de que sí son bien activos. Ellos, yo creo que les pagan un montón. Ay, no, este no todavía. Eh, ¿dónde está el? Ah, miren, aquí está este. Entonces, hay un catálogo eh de ejemplos justamente de Malware y que GitHub pues mantiene porque tenemos, insisto, constantemente nuevos paquetes con árbol. Les quería enseñar es como que hace 6 horas salió uno nuevo, pero bueno, el internet no me está ferando muy chido. Ah, más bien internet. Ah, es por eso este No estoy nervioso, ¿eh? No esté nerviosos.

Ya y ahorita les enseño que, o sea, Marw JavaScript hay todos los días, ¿no? Eh, entonces pues si en su empresa desarrollan cosas de JavaScript o tienen clientes que desarrollen cosas de JavaScript y quieren ver qué tan jodidos están, pues háganle una pequeña auditoría de todas las opiniones. Aquí está, miren. apenas de ayer. Qué triste. Yo pensé que íbamos a tener cambios apenas y de horas, pero bueno. O sea, curiosamente los atacantes que buscan atacar esto buscan mucho hacer cosas de criptos, o sea, como que busquen atacar o a clientes de empresas de criptomonedas o a empresas de criptomonedas directamente. Ya es otra de las cosas que les quiero platicar. O sea, si creen ustedes que son tan

importantes como para que un desarrollador de Marw piensen en ustedes de cómo explotarles este su computadora personal o su tablet o similar, no son tan importantes, amigos. hacen muchas veces esto se hace como muy eh hacia un objetivo en específico, ¿no? Entonces, pues no se explota eh la vulnerabilidad o nos explota este malware y no nos afecta a nosotros, pero puede afectar a esos objetivos que sí están buscando. Si alguien conoce el caso de no cry, sino tunet, fue un caso de esos, ¿no? Estuvo bien chido. Este y bueno, vulnerabilidades conocidas. Este, se lo voy a decir rápido, o sea, todo el código es vulnerable porque tiene dependencias y todas las dependencias tienen vulnerabilidades. O sea, todo va

a ser vulnerable en algún momento. Todo, todo, todo. Nada más deja que algo pase el suficiente tiempo y alguien tiene la suficiente motivación y va a la vulnerabilidad, ¿no? Eh, y el código open source no es más seguro. Ese es un mito que se tiene. O sea, la gente cree que, ah, es que es open source. Sí, claro. Ha estar bien chido, ¿no? Ha estar así como que con gente bien profesional haciéndolo, ¿no? O sea, yo hago pense. Este, lo único bueno es que si hay muchos ojos revisarity

database que estuvo a punto de cerrarse porque el gobierno gringo no la quería seguir manteniendo. pagan un laboratorio este eh para mantener esa base de datos de vulnerabilidades y es super importante el trabajo que hacen en ese laboratorio para la base de datos de vulnerabilidades y ya no vamos a tener base de datos de vulnerabilidades. Este, entonces el la Unión Europea decide sacar su nueva base de datos de vulnerabilidades, ¿no? Es eh lo mismo, pero más barato, esperemos, ¿no? Porque si no, imagínense cuánto lean de gastar los los europeos en lugar de estar comprando armas, ¿no? Pobrecitos. Este, entonces ya tenemos un nuevo estándar de base de datas de vulnerabilidad que como dato curioso está más chido una

compañera estar utilizándola para obtener vulnerabilidades por producto específicamente así como que ah, dame vulnerables de este producto y se lo da más chido que la NBD. Este, las vulnerabilidades son fáciles de explotar. ¿Quién de aquí ha explotado una vulnerabilidad de un CB? O sea, no no que haya hecho el reset o si han hecho el reset, chido, pero o sea que que ah, este se ve lo va a explotar. ¿Fue muy fácil o muy difícil? Más o menos. ¿Tú hiciste el exploit o tú te basaste en uno existente? Entonces, puedes agarrar código de un exploit existente, puedes tú crear tu propio exploit, tienes que tener entendimiento de cómo funciona ese código en ese caso de esa dependencia. Y

luego hay un montón de condiciones que de repente tienen que hacer, o sea, eh rezar tres padres de estos 10 ave María, este eh hacerle un sacrificio a Tulu, este bailar con un pie este en medio de la luna roja cuando sacrificas una vaca este roja. Este, ¿ven? Está muy buena. Busquen así, luna roja, luna roja, vaca roja, eh, y así ya jala el exploit. Entonces son muchas condiciones de repente las que se entienden. Hay cosas como Lock for Share que explotan en tres patadas. Hay cosas como Spring for Share que ese se lo voy a enseñar a super rapidito. Este la neta lo chido de ese es que pues sí tenía código que era

super común. Yo programillaba por muchos años y estas eh 10 líneas de código eran así caras de la misma, o sea, cosas que cualquier developable

eh remotamente, ¿no? Entonces estuvo estuvo gacho este de modo que sí hay casos que son muy fáciles, pero no son la mayoría. Eh, infectando sistemas de integración continua. Ah, este sí se los quiero enseñar. Está bien padre. ¿Quién conoce a Kent Thomson?

¿Quién más conoce a Kent Thomson? Okay, King Thomson es uno de los creadores del sistema operativo Unix, o sea, algo antes de de Linux. Este y Kent Thompson, como pues era una persona muy lista y se borría muy fácilmente, creó el primer virus, básicamente. Entonces, lo que hizo fue, bueno, a esto que ahora le llamaremos a lo mejor distinto, pero pues él puso virus o alguien le puso virus, entonces es un virus en el compilador de Unix. Entonces, eso significaba que todo lo que compilara esa versión del compilador de Unix iba a tener virus que después iba a estar. Entonces, cuando tú volvías a compilar otra cosa, no iba a reconocer ese virus. O sea, básicamente era un

metamálo. Estaba hermoso, o sea, hermoso, hermoso, hermoso. Eh, y todo por un pequeño microcódigo que pues la neta era imperceptible a menos que supieras binario, básicamente que pudieras leer el ensamblador. Entonces, Ken Thomson le pone una receta muy chida a los que después quieren construir eh herramientas o formas en las que pueden inyectar los sistemas de integración continua, ¿no? Entonces, pues es el primer factor y está en el compilador. Eh, y pues eso después va a replicar y replicar y replicar porque pues cada que es eh algún sistema de desarrollo, integración continua y demás, puede tener vulnerabilidades, perdón, más que vulner bueno, sí, puede tener vulnerabilidades que alguien más quiera escultar o tener algún tipo de malw que alguien más te

quiera montar, ¿no? Y ya en 15, por ejemplo, no es que le valga madre, pero así como que pues es es tu pedo, gey, no es mío. O sea, ya tú tienes que ver cómo te arreglas en tu seguridad. Eh, honestamente, GitHs, que es otro otro ambiente, otra herramienta de integración continua, también puede tener vulnerabilidades. Y una que les quiero enseñar rápida es el tema de este, cómo tú puedes eh exfiltrar eh cómo puedes exfiltrar tokens de GitHub. Si creas un token este eh y creas una GitHub action, que si alguien consume esa GitHub action tuya, puedes básicamente mandar ese token que le da acceso temporal a tu código fuente que estás utilizando tú para construir

cosas. Este y pues en ese periodo cortito de tiempo alguien puede descargarlo y bajarlo. Y esta es una de las 1200 vulnerabilidades que pueden hacer existir en GitHub Actions. Hay prácticas de GitHub actions, como por ejemplo, o sea, no dejes que se esté actualizando el GitHub action constantemente. Pinéalo a un hash en específico, una versión específico que neta tú como persona de seguridad revisas y digas, "Ah, no, sí, esta no tiene cosas feas, ¿no?" Entonces, eh Ghovns puede tener muchas, muchas, muchas vulnerabilidades, muchas falas. Eh, ah, este está bien padre. ¿Puedo platicar? Me chance de platicar aquí. Este, herramientas que instalan herramientas. Eh, si un developer quiere programar chido en la terminal, instala un eterm con colores acá bien cool,

buena onda y que se ven así bien nice, bien chidos, este, el pex es que si se pone a buscar mattutorials.com, how to develop on e o how to set on, le pueden aparecer Google Ads, Google Ads que los llevan a Malware. Y ese malware este está por acá. Este, y la neta, la neta, la neta, eh, pues los developers no son con gente muy consciente a veces, amigos, la verdad es de que sí pueden caer en cosas como esta, ¿no? Entonces, un pequeño script que se instale localmente, que les baje este las el usuario y la contraseña y de autenticación y que incluso instale un un RAT en su máquina de desarrollo, ¿no? Entonces, it happens. Ha pasado. No me

pregunten por qué lo sé, simplemente lo sé. Este y pues este hay actores como Cater Spider que buscan hacer este tipo de cosas. Oh, esta me la enseñó mi siso que anda por allá. Este, las extensiones del código de Chrome, eso también son su cadena de suministro, porque todos sus developers van a utilizar Google Chrome. Entonces, eh, Google Chrome tiene ciertas protecciones para eh pues que puedas o no hacer ciertas cosas con la extensión, pero la realidad es de que no es suficiente, ¿no? Entonces, pues esto no se los va a revelar un escáner tan fácilmente. Eh, tengan mucho cuidado en qué están instalando eh con extensiones de Chrome, por favor, porque ya hay varios ataques

que han sido también por ahí y a el New Kid on the blog. Yo creo que ya con esta me despido porque chance a preguntas. ¿Quién de aquí programa sin algún tipo de agente o cosa de ella y que le haga? ¿Quién de aquí programa utilizando algún tipo de sin miedo? Neta, todos somos todos, o sea, y para ya vamos a ir, o sea, es más, aunque no quieran, lo van a tener que hacer porque ya las tours lo van a integrar de una manera tan nativa que no van a tener otra opción. Entonces eh pues hasta que el arquitecto de la Matrix pueda eh aprender cómo eh construir un mundo perfecto en donde vivamos este cómodamente

eh sufriendo y todo, pero pues cómodamente, eh pues la verdad es de que vamos a utilizar ella y por un buen rato y hay un montón de riesgos y digo ha habido muchas charlas muy interesantes al respecto de cómo protegerse, de cuáles son los vectores de ataque y demás en el besites. Eh, pero la verdad es de que, o sea, si los englobamos en en esos cuatro ejemplos, los asistentes de código, es decir, eh Git Pilot, Cursor, eh este ahorita no me acuerdo cuál otro, eh generan código vulnerable. ¿Por qué generan código vulnerable? ¿De dónde aprenden esos modelos a desarrollar código? De ustedes, de mí, de todos. O sea, realmente el la mayor cantidad de código

en el mundo es vulnerable, tiene fallos de seguridad, eso está probobado, hay estadísticas, hay datos al respecto. Entonces, si utilizaron ese set de pruebas para entrenarse, por supuesto que el código va a ser vulnerable. Y por ahí busquen al Jim Manico, es una persona de seguridad super chida que te da así como que consejos para cómo decirle a los agentes que generen código seguro, pero pues no todos somos Gin Manico, entonces vamos a generar y tener código vulnerable, ¿no? It's gonna happen. Eh, va a pas eh si utilizamos este tipo de herramientas y hay cosas que están haciendo los proveedores para mejorarlas, pero va a pasar. Los MCP Servers, hijos, este siempre está fuerte. Eh, ¿quién ha leído más o menos

cómo funciona el Model Contex Protocol? El MSP. ¿Cómo funciona ese chunchi? Un Jason. Ajá. Ajá. Configuras herramientas para tener inputs de de APIs. Ajá. y ya le pasa eso como promps, ¿no? Al al alm e esto me lo enseñó un compañero, o sea, ¿qué diferencia? Muchas gracias. Este, ¿qué diferencia el prompt que pone un humano del prompt que pone el MCP Server para el modelo per sé? O sea, ¿qué evita que el NCP Server no tenga en su configuración pros maliciosos que lo esté inyectando y tú lo estás utilizando pensando que es un MCP server chido y realmente te está inyectando cosas, ¿no? y cosas que hasta pueden hacer common injection, o sea, la mayoría de la investigación cae de de

los MCP servers vulnerables es para lograr remote code execution. Y hay un montón de ejemplos de remote code execution con MCP Servers, este los bots, o sea, tal cual. háblale a un este a un chatt, a un eh cloud, a un lo que sea. Este y eh hay un montón de riesgos que ya el Was Top 10 de LLMs nos platica de ellos. Y yo les quiero hablar de uno específico que vi el año pasado que me encantó. Este, tú puedes tener eh respuestas de paquetes que son falsos, que son alucinaciones. Entonces, estos paquetes que son alucilaciones, ¿alguien puede darse cuenta que son alucinaciones? y sube el paquete. Entonces suben el paquete y pum, ya

entraron a tu cadena de suministro, todo, porque tú le creíste al bendito robot, el choro que te estaba contando de un paquete que ni siquiera existía, ¿no? Entonces, la neta, la neta esa se me hizo super cool, superdivtido, una manera muy interesante de atacar por medio de la cadena de suministro. Y finalmente los agentes inteligentes. Eh, en el futuro ya no vamos a programar cosas, vamos a dejar que los agentes programen cosas y es cuando el arquitecto va a construir este mundo perfecto para nosotros, ¿no? Y nos va a conectar la matrix. Este, cuando pase eso de que los agentes creen todo el código y hablen entre ellos y demás, la posibilidad de que la cagen es

gigantesca. O sea, van a tener alucinaciones, va a poder hacer data filtration, data leads, etcétera, etcétera, etcétera. Y como pues todos utilizamos la inteligencia artificial, los inteligentes, la verdad es de que es muy probable que seamos inyectando un montón de vulnerabilidades hardware y demás cosas por ahí. Y finalmente, eh pues la verdad es que todos los proveedores que tienen, llámese eh AWS, llámese Ital Ocean, llámese Google Cloud, llámense lo que sea, también pueden tener vulnerabilidades en su infraestructura. Los proveedores de de SAS, o sea, todas las herramientas de la nube también pueden tener problemas y fallas de seguridad y entonces todos ellos son también parte de su cadena de suministro. Entonces es muy importante que estén evaluando cada uno de ellos

con el riesgo de cada uno de ellos esté cayendo, porque la tendencia ahorita es que justamente más que alguien explote los productos en la tecnología que se desarrollan, donde estén trabajando con sus clientes, sino más bien exploten a los proveedores que les dan servicio y por ahí les metan un gol y prevenir riesgos es que no puede, no, no es cierto. pueden este no usar dependencias, o sea, si entre menos dependan, pues menos van a tener una superficie que no. Eh, obviamente estaría muy padre, pero pues como nos dijo ya Alex, no hay manera, ¿no? O sea, vamos a tener que seguir utilizando dependencias. Entonces, aceptando de que de alguna manera u otra vamos a ser eh

vulnerables. Entonces, pues ahora sí, anuncio de vendors, hay un chingo de vendors que en el caso de eh problemas de seguridad de código, pues ya nos dan soluciones para hacer actualizaciones y análisis, escaneos y demás. eh de las miles y miles y miles de vulnerabilidades que van a aparecer en su código o el código del código del código del código que se utiliza también para containers. Los software bill of materials, que es lo que el gobierno gringo impulsó este te dicen estos te dicen nada más de qué está hecho tu software, pero no te dicen realmente cómo remediar los problemas. Este, son cosas como esta que eh pueden leer. Ah, este, ¿qué te dicen? Ah, pues la receta

de cocina de los ingredientes fue esta y esta y esta y esta y esta, ¿no? Eh, no te dice cómo arreglarlo, no te dice qué fallas tienes, pero te dice por lo menos la receta. Para el caso de respuesta incidentes es interesante saberlo. ¿Por qué? Porque si estuvieras, imagínense, el SBOM de todos tus proveedores de SAS y el SGOM de todos tus componentes este de infraestructura y de código y demás, podrías relativamente rápido identificar en dónde tenías ese ah este tu ah muchas cosas de aquí las iba a decir, pero bueno, son los ah los costs, esos están chidos, eh, tengo por acá uno abierto justo del proyecto que que yo este que yo contribuyo

y que ya está mejor. Ya somos 8 c antes éramos como cuatro o seis. Este que no se ve absolutamente nada ahí, pero si pudieran leer básicamente dice que las KitKoptions que utilizamos están pineadas a ciertas versiones de hash, ¿no? Y utilizamos este un proceso de P reviews que evita de que alguien inyecte cositas. Entonces, pues nada, eh es una manera de que vea si un proyecto Open Source tiene alguna buena práctica de seguridad con el pastello. Eh, repositores prevos dependencia, eso no lo sab decir, pero básicamente pones algo intermedio y entonces ya ah si hay una vulnerabilidad la encuentras antes, ¿no? Antes de que la dependencia en sí pase a a los desarrolladores o a tu

sistema de interción automotivo. Actualizaciones automátas de código están bien chidas, pero la neta siempre se rompe cada que haces alguna actualización. Entonces, pues háganlas, o sea, las tienen que hacer, es la verdad, este, pero pues las van a hacer con cuidadito y cuidando que no se rompan las cosas y actualizan su sistema operativo y mantengan los controles que realizados. Este, no más dejen se les enseño rápido. Este, tengo información rápido, rápido, rápido, rápido. Hay una cosa que se llaman bistroles o este sleep containers o app armor que si lo pueden utilizar en los contenedores que están construyendo, que están utilizando allá en su empresa, sería super chido porque agregan justamente una capa de seguridad que no importa tanto, incluso

cta containers que eso lo dieron la box la ante pasada este no importa tanto que justo los containers tengan cosas malas o vulnerabilidades. ¿Por qué? porque te dan una capa de aestisamiento de protección extra. Y pues ahora sí ya es todo. No me fui rápido, perdón. Este, lo siento, me faltó más alcohol, no fui gracioso, disculpen, no se ríeron nada. Espero no se hayan dormido tanto. Este, y pues muchas gracias.

Muchísimas gracias y bueno, tenemos unos minutos para abrir discusión de preguntas y respuestas. Entonces alcen la manita para llevarles el tiro de todos modos voy a seguir por acá estar cheleando y todo en la fiesta entonces creo que vamos a platicar de esta de otras cositas. ¿Qué onda? Eh, basado en tu pregunta inicial de eh ¿por qué los desarrolladores no desarrollan código seguro? ¿Qué procesos recomiendas o cómo abordarías tú del llegar a una empresa en donde los desarrolladores solo van a sprint on screen y solo les importa sacar funcionalidades y cosas así? eh cómo logras hacer el cambio de paradigma dentro del equipo de desarrollo gerencial para que se puedan implementar estas buenas prácticas que pues nos

explicas, ¿no? O sea, el con base en tu experiencia, ¿cómo llegas con los desarrollos y les dices, "Oye, es que llevas desarrollando 10 años mal o 10 años de forma insegura?" que ya dijimos que es inseguro, pero pues, o sea, sin que les duele el ego y sin que digan, "No, yo llevo 10 años haciéndolo así, pues eso ya es dependencia, o sea, el código de dependencia y cosas por el estilo, o sea, ¿cómo lo abordas desde tu eh experiencia profesional? Gracias. Haces la chamba, automatiza un chorro de cosas, ten muy buenas relaciones con todas las personas, o sea, el tener un stakeholder importante, chido, que entienda lo que le estás diciendo es es supercrucial.

Eh, la chamba, eh habla con ellos en buena onda, simpático, pues eh demuéstrales el riesgo. Es así como que no es que esta cosa es vulnerable, es que esta cosa gey yo exploté. Ah, no [ __ ] Entonces, o sea, tener muestra evidencia así contundente de que es una falla real, de que es un riesgo real, con ese análisis de riesgos chidos, con buenas formas de comunicación y la mayor cantidad de cosas que puedes automatizar, mucho mejor. Gracias. Eh, tenemos un batch de hack GDL, este, que por ser el primero en preguntar lo ganaste. Felicidades, [Aplausos]

s. ¿Quién más tiene preguntas? Alcen la manita, recuerden, para poder ubicarlos. Acá levantaron primero. Eh, en la mecánica de que todo es al final una dependencia, ¿cómo lidiarías o qué recomendarías para eh no arrastrar eh compatibilidades hacia atrás? Muchas veces el desarrollo Sol también se afecta por el de es que tengo que ser compatible con 20 versiones hacia atrás de clientes, navegadores, este sistemos operativos. La la Sí, el Power Compatibility le dan la torre a todos. Java sigue siendo mega vulnerable en parte por ese mecanismo de serización que tiene que tiene el backwar compatible con el código de Java 1.4, Java en la 23. Entonces eh sí ir buscar como que una migración a versiones que ya no sean, tomar una

decisión difícil, estratégica con el mantenedor de un producto de de un software, este que no es una decisión que seguridad toma. muy importante este decisión que toman pues los stakehorders, los dueños de el software, el producto, el servicio y demás de pues hasta este punto vamos a aguantar y de aquí para adelante vamos a tener que irnos actualizando, ¿no? Este o las carrils exteriores, o sea, es como que bueno, yo ya sé que soy vulnerable. Esta historia se las quería platicar tiempo. Básicamente eh están dos personas en un table hablando acerca de seguridad. Este, tal vez no era necesario eso último que dije, pero le pregunta un consultor al cliente, "Oye, pues, ¿por qué no actualizan sus

servidores? son supervulnerables. Mira, tener abajo el server me cuesta tanto, pagar el ciberseguro me cuesta tanto, mejor sigo pagando el ciberseguro, ¿no? Entonces, tener, no estoy diciendo que hagamos eso en ningún modo, pero tener protecciones alrededor pues que sirve para mitigar el pero sí tratar de ir actualizando aunque sea de despacito y una edición dura que no más. Muchas gracias. Siguiente. ¿Quién alza la mano de este lado? Eh, hola. ¿Cómo lidias con las vulnerabilidades transitivas? O sea, cuando tienes eh la vulnerabilidad está en la librería que implementa la librería que tú implementas, el triaje, el análisis de riesgos, básicamente. O sea, tú tienes número uno, poder identificarlas. O sea, si no tienes manera de saber este es

transactivo o este es directo, estás en el hoyo. Entonces, tienes que tener alguna manera de poder identificar cuál es cuál. Eh, número dos, eh, hacer un análisis real de, okay, cuál es el riesgo de las seguridades transitivas, porque realmente las seguridades, perdón, las vulnerabilidades transitivas son un poquito más difíciles de explotar. No estás usando directentamente el código que es vulnerable, sino un código que a su vez utiliza otro código que es vulnerable. Entonces regularmente caen muchas en casos de que como es transitiva no se va a explotar. Lock for SHF era loestro era transitiva y superpetable, pero no siempre es así. Eh, entonces hacer ese análisis con ese entendimiento de que es directa y transitiva eh y eh idealmente tener

formas de mantener todo actualizado de forma automática es lo lo mejor. Perfecto, gracias. Entre más tiempo te tardes, más desmadre. S. Siguiente pregunta. ¿Alguien que tenga una pregunta más? que hable ahora calle para siempre. Mi origalle para siempre. ¿Hay algún estándar que se ha evaluado? Bueno, que lo evalúe las librerías que se utilizan como para poder tener esta seguridad de si son seguras y se pueden utilizar. Obviamente se pueden vulnerar, pero si durante un tiempo, durante este tiempo son completamente seguras. completo completo, ¿no? Pero por ejemplo lo que les mencioné de Open SSF, Open Source Security Foundation, Scorecards, creo son un buen este termómetro para el caso, por ejemplo, de containers. De hecho, les quería hablar también de ese,

pero se me olvidó. Este, Docker está haciendo una labor similar para poder este decir ah, este, ¿qué calificación tiene? Ah, ya no see. Ah, ya se qué chido este, calificación tienen los containers. Entonces, más que un estándar per sé, son esfuerzos que están haciendo varias organizaciones, a veces en conjunto, a veces separadas para poder tener como que esa calificación. No es un ah no es un sello de calidad de Sí, esto esto es 100% seguro, pero es un termómetro. Entonces, scorecards como Scout, como Open CCF pueden dar también. Ya va el siguiente listo. Pues agradecemos mucho Eric por su charla y por la por su conocimiento.