Software Libre Bajo Asalto

una platica por @jailandrade

"El software libre no es solo codigo. Es una decision politica."

Antes de empezar

Unas preguntas antes de comenzar

¿Cuantos han leido TODO el codigo de sus dependencias?

¿Confias en codigo que nunca has visto?

¿Tu app es tuya... o de tus dependencias?

¿Cuantos de aqui estudian Seguridad y cuantos Ingenieria de Software?

"Si no tienes respuesta a las primeras 3 preguntas, esta charla es para ti."

Open Source no es lo mismo que Software Libre

Una distincion que importa

Software Libre — Richard Stallman, 1983: la libertad como principio etico. El codigo es un bien comun.

Open Source — 1998: mismo codigo, lenguaje mas aceptable para empresas y corporaciones.

La diferencia no es tecnica. Es filosofica.

Uno es un movimiento etico. El otro es un modelo de desarrollo.

"Open source no es un movimiento etico... es una estrategia de desarrollo que las empresas aprendieron a explotar."

El open source no se rompio de repente

Lleva mas de 25 años acumulando deuda estructural

Pero solo hablaremos desde que estoy en la Industria y el Ecosistema

2010: confianza ciega

2015: dependencia masiva

2020: ataques dirigidos

2025: automatizacion del ataque

"Nadie nota cuando algo se rompe lentamente."

2010–2014

El Open Source es confiable… hasta que dejamos de asegurarnos que lo es

La idea dominante de la epoca:

"Si es open source, alguien ya lo reviso"o "Si es open source, es gratis y solo eso importa"

Realidad: nadie lo estaba revisando sistematicamente.

"Si es open source, alguien ya lo reviso. El problema: ese alguien no existia."

Caso: Heartbleed

Dos años expuesto. Nadie lo sabia.

OpenSSL cifraba la mitad del internet. En 2012, un voluntario introdujo un bug de 50 lineas.

Con una peticion de 64 bytes podias extraer 64KB de memoria del servidor: contraseñas, llaves privadas, tokens de sesion activos.

Cuando se descubrio en 2014, habia estado activo en produccion por dos años en millones de servidores.

La libreria que protegia el internet: mantenida por voluntarios, sin presupuesto, sin auditorias.

OpenSSL
"El problema no era el bug… era que nadie estaba mirando."

2014–2018

Dependencias explotan (npm, pip, etc.)

Con npm y los ecosistemas modernos:

  • Las apps pasan a tener cientos o miles de dependencias
  • Cada dependencia depende de otras
  • Nadie audita la cadena completa
npm PyPI / pip
"Construimos imperios sobre cimientos que nadie eligio con cuidado."

Caso: left-pad

11 lineas de codigo rompieron internet

Marzo 2016. Un desarrollador recibio una demanda legal y decidio borrar todos sus paquetes de npm en protesta.

Uno de ellos era left-pad: 11 lineas para rellenar strings con espacios a la izquierda.

En minutos: Babel, React, cientos de proyectos de produccion fallando en todo el mundo. Los equipos no podian ni hacer deploy.

Un solo desarrollador habia roto el ecosistema entero. Sin malicia. Solo borrando su codigo.

npm
"Dependiamos criticamente de codigo trivial."

El problema de "cualquiera puede publicar"

Friccion casi nula en los registros de paquetes

  • Sin verificacion fuerte de identidad
  • Sin reputacion real
  • Sin auditoria de contenido

Esto abre la puerta a los ataques de supply chain que explotarian despues.

Usar npm es como construir una casa con piezas que encontraste en la calle... y esperar que ninguna explote.

npm PyPI
"Cualquiera puede publicar. Y eso es exactamente el problema."

2016–2020

El factor humano: maintainers

  • Proyectos criticos mantenidos por 1 o 2 personas
  • Sin pago
  • Sin soporte institucional
  • Burnout y abandono como resultado inevitable
"El eslabon mas debil de la cadena no era el codigo. Era la persona."

Caso: event-stream

No hackeas el codigo. Hackeas a la persona.

2018. El maintainer de event-stream llevaba años manteniendo un paquete con millones de descargas semanales. Sin pago. Sin apoyo.

Alguien se ofreció a "ayudar". El maintainer, agotado, acepto y le transfirió el control del repositorio.

Semanas despues, el nuevo "colaborador" habia introducido malware en el paquete. Target especifico: wallets de Bitcoin de una app concreta.

Nadie reviso el codigo nuevo. El CI paso sin problema. El malware llego a produccion.

npm
"No hackeas el codigo… hackeas a la persona."

Incentivos rotos

Falta de sostenibilidad en el ecosistema

Las empresas usan software libre pero no contribuyen.

Los maintainers trabajan gratis.

Esto genera:

  • Abandono de proyectos
  • Decisiones riesgosas bajo presion
  • Takeover de proyectos por actores maliciosos
"Las empresas tienen los beneficios. Los maintainers tienen el trabajo."

El problema tambien es politico

Corporaciones, poder y liderazgo

Amazon, Google y Microsoft construyen negocios de miles de millones sobre software mantenido por voluntarios. Extraen valor sin devolver de manera proporcional.

Las mismas corporaciones que mas se benefician del OSS son las que mas presionan por cambiar licencias cuando les conviene.

Y dentro del movimiento: debates sin resolver sobre etica, gobernanza y quien tiene el derecho de decidir el rumbo.

"Las reglas del juego las escriben quienes tienen el poder economico... no quienes escriben el codigo... Desafortunadamente"

2018–2022

Ataques dirigidos y sofisticados

Los atacantes dejan de apuntar al codigo directamente.

Apuntan a la cadena de suministro.

"El objetivo ya no es tu software… es tu pipeline."

Casos: UA-Parser-JS y SolarWinds

Ataques invisibles en versiones oficiales

UA-Parser-JS: malware en versiones oficiales, robo de credenciales

SolarWinds: no es OSS puro, pero valida el modelo — atacan la cadena de suministro, no el objetivo final

npm GitHub
"No atacaron el software. Atacaron la cadena que lo entrega."

Confianza implicita en maintainers

El problema de los pipelines automatizados

  • Si el maintainer publica, se instala automaticamente
  • El CI/CD lo despliega sin intervencion humana
  • No hay un checkpoint humano real
GitHub Actions / CI
"Cuando nadie revisa, cualquiera puede colar cualquier cosa."

2022–2024

La IA acelera el caos

La IA recomienda librerias, a veces inexistentes o maliciosas.

Esto crea:

  • Paquetes falsos (hallucinated packages)
  • Typosquatting masivo

Bots que crean repos, hacen PRs y simulan contribuciones.

Se diluye la confianza en identidades humanas.

"La IA no creo el problema. Solo lo hizo mucho mas rapido."

2023–2026

Crisis estructural

Worms en npm que publican paquetes e infectan dependencias automaticamente.

Ya no necesitas hackers expertos para atacar el ecosistema.

Si hoy hicieras npm install en tu proyecto, hay una probabilidad real de que estes ejecutando codigo que nunca nadie reviso.

"El ataque ya no necesita un atacante humano."

Cambio de licencias

Open source ya no siempre es open

Las empresas cambian las reglas del juego:

  • MongoDB migra a SSPL
  • Redis adopta licencias restrictivas
MongoDB Redis
"Open source ya no siempre es open."

Complejidad incontrolable y abandono silencioso

Dos problemas que se refuerzan

Nadie entiende el sistema completo. Las dependencias son demasiado profundas para auditarlas.

Proyectos criticos sin mantenimiento siguen instalandose como si nada, sin alertas claras.

Esto elimina cualquier posibilidad de auditoria o seguridad real.

"Lo que nadie entiende, nadie puede proteger."

No todos los problemas duelen igual

Jerarquia de riesgo real

Tier 1 — Criticos: Supply chain attacks, maintainers quemados. Pueden comprometer produccion hoy.

Tier 2 — Serios: IA/bots en el ecosistema, dependencias excesivas. Escalan rapido, difíciles de detectar.

Tier 3 — Estructurales: Cambios de licencia, complejidad, cultura de velocidad. Erosionan el ecosistema a largo plazo.

"No todo duele igual. Pero todo esta conectado."

Problemas transversales

Constantes desde 2010

  • Confianza implicita: "si funciona, lo uso"
  • Falta de ownership: nadie es responsable del todo
  • Incentivos rotos: las empresas ganan, los maintainers no
  • Seguridad reactiva: se arregla despues del desastre
  • Cultura de velocidad por encima de calidad
"Estos no son bugs del ecosistema. Son features de como lo construimos."

Entonces, ¿que hacemos?

De la critica a la accion

No hay soluciones magicas.

Hay trade-offs y mejores practicas reales.

Cada problema tiene respuestas concretas a nivel individual, de equipo y de industria.

Nos unimos a XalapaCode para estar mas enterados y saber que hacer

"La pregunta correcta no es que tan roto esta. Es que vamos a hacer hoy."

Supply Chain Attacks: que hacer

Verificar antes de instalar

Nivel individual: revisar que el repositorio este activo y tenga un maintainer real. Usar lockfiles. No usar latest a ciegas.

Nivel equipo: integrar herramientas SCA (Software Composition Analysis) en el CI. Ejemplos: Snyk, Dependabot.

Nivel avanzado: firmar dependencias y verificar integridad. Concepto clave: Sigstore.

Snyk GitHub Dependabot pnpm (lockfiles)
"No confies en el codigo… verifica quien lo publico."

PRs basura y bots: que hacer

Cultura de revision seria

  • Regla: no merge si no lo entiendes
  • Revisiones obligatorias, minimo dos personas
  • Limitar el tamano de los PRs
  • Bloquear merges automaticos en codigo critico
  • Valorar claridad por encima de velocidad, contexto por encima de volumen
"Si no puedes explicarlo, no deberias mergearlo."

Maintainers quemados: que hacer

El sostenimiento del ecosistema es responsabilidad colectiva

Nivel empresa/organización: pagar por el OSS que usas. Plataformas: Open Collective, GitHub Sponsors.

Nivel desarrollador: contribuir con docs, issues bien escritos, bug fixes pequenos.

Nivel estrategia: evitar dependencias con un solo maintainer y cero financiamiento.

Open Collective GitHub Sponsors
"Si tu negocio depende de una libreria, deberias invertir en ella."

Dependencias como caja negra: que hacer

Reducir y auditar

Reducir dependencias. Preferir librerias maduras con menos magia.

Practica concreta: "dependency budget". Ejemplo: maximo 10 dependencias externas por servicio critico.

Auditoria basica: leer al menos el entry point y los scripts de instalacion de cada dependencia critica.

"Cada dependencia es codigo que no controlas."

Cambios de licencia: que hacer

Revisar antes de adoptar

Revisar la licencia antes de adoptar cualquier dependencia critica: MIT, Apache 2.0, GPL son generalmente seguras. SSPL merece atencion especial.

Estrategia: evitar el lock-in abstrayendo dependencias criticas.

Ejemplo: si usas MongoDB, tener un plan B con PostgreSQL.

MongoDB PostgreSQL Redis
"No solo importas codigo… importas condiciones legales."

Complejidad incontrolable: que hacer

Preferir la simplicidad deliberada

Preferir menos layers, menos frameworks innecesarios.

Regla practica: si no puedes explicarlo en 5 minutos, es demasiado complejo.

Documentacion interna obligatoria con diagramas simples.

"Si no puedes explicarlo en 5 minutos, es demasiado complejo para ser seguro."

Seguridad reactiva: que hacer

Seguridad desde el inicio, no como parche

Incorporar threat modeling basico desde el diseno.

Pipeline minimo no negociable:

  • Lint
  • Tests
  • Escaneo de seguridad de dependencias

Revisar dependencias antes de cada release importante.

"La seguridad no es un parche… es un proceso."

Identidad falsa y confianza rota: que hacer

Verificar quien contribuye realmente

Revisar el historial y la actividad real de los contributors antes de darles acceso.

Nivel avanzado: usar firmas de commits con GPG para verificar identidad criptograficamente.

GPG GitHub
"Open source funciona con confianza… pero la confianza se puede falsificar."

Cultura "move fast": que hacer

Cambiar las metricas que importan

No medir el exito en lineas de codigo escritas.

Medir estabilidad, incidentes prevenidos, deuda tecnica reducida.

"Ir rapido no sirve si rompes produccion."

Resumen: problema y respuesta

  • Supply chain → verificar y firmar
  • PRs basura → cultura de revision
  • Maintainers → funding directo
  • Dependencias → reducir y auditar
  • Licencias → revisar antes de adoptar
  • Complejidad → simplificar deliberadamente
  • Seguridad reactiva → proceso continuo
  • Identidad falsa → verificacion criptografica
"Cada decision tiene consecuencias. Algunas las pagamos hoy. Otras, las pagara alguien mas."

El open source no esta bajo ataque

Ya fue comprometido

Llevamos más de 15 años instalando dependencias como si nada.

Confiando en codigo que nadie revisa, mantenido por personas que nadie paga, bajo licencias que cualquiera puede cambiar.

El problema no es el open source.

El problema somos nosotros como industria. Pero principalmente los grandes jugadores.

"La pregunta no es si el ecosistema tiene problemas. La pregunta es si nosotros vamos a cambiar como lo usamos."

Muchas gracias por quedarse a la plática