Los últimos meses dejaron una sucesión de incidentes de seguridad que, por sí solos, suenan a episodios técnicos de poca prensa, pero que juntos cuentan algo importante. Paquetes de software libre con cientos de millones de descargas semanales, como axios, fueron comprometidos. Una campaña con nombre propio, Shai-Hulud, infectó cientos de paquetes de npm y PyPI a fines de abril, robando credenciales de servidores y de billeteras. RubyGems suspendió temporalmente los registros nuevos por una ola de paquetes maliciosos. Hugging Face, el repositorio central de modelos de inteligencia artificial, vio circular paquetes con nombres parecidos a los originales, descargados cientos de miles de veces. En el kernel de Linux apareció una vulnerabilidad que permitía a un usuario local volverse administrador. Y todo eso convive con la herida abierta del caso XZ de 2024, donde un colaborador con paciencia de años terminó plantando una puerta trasera en un componente que está en casi todo servidor del mundo.
El patrón de fondo es bastante claro y vale entenderlo aunque uno no sea técnico. El software moderno, incluyendo el que usan los bancos, los hospitales y las empresas, no se escribe entero por la empresa que lo vende. Se construye combinando miles de piezas pequeñas hechas por gente de la comunidad open source, distribuidas a través de repositorios públicos. Esa forma de trabajar es una de las grandes razones por las que el software avanzó tan rápido en las últimas décadas. Pero también significa que cada una de esas piezas es una puerta posible. Si un atacante logra hacerse pasar por el autor original de una de ellas, lo que publique va a llegar, sin que nadie lo note, a todos los productos que dependen de esa pieza.
Para el usuario común y para las empresas, el riesgo concreto no es teórico. Cuando uno de estos paquetes maliciosos se cuela en un sistema, lo que suele hacer es robar credenciales, claves de acceso a servicios en la nube, datos guardados en archivos de configuración, o información sensible de los servidores donde corre. Lo más serio es que muchas veces la víctima no se entera. El software sigue funcionando con normalidad y la fuga ocurre en silencio, durante semanas o meses, hasta que algún investigador externo destapa el ataque y recién ahí se reconstruye el alcance. Para una empresa que maneja datos de clientes, esto es exactamente el tipo de problema que no se quiere descubrir tarde.
La buena noticia es que protegerse, sin ser una operación heroica, requiere una disciplina sostenida. Las prácticas son conocidas y razonablemente sencillas. Mantener los servidores y sistemas operativos al día con los parches de seguridad apenas salen. Auditar las dependencias de cada actualización en lugar de aceptarlas a ciegas. Usar autenticación de dos factores con dispositivos físicos en todo lo que tenga acceso a publicar o desplegar código. Aislar bien los entornos donde corre el código de producción. Y revisar periódicamente qué se está usando y de dónde viene. Nada de eso es revolucionario. Lo difícil no es saberlo, es hacerlo todas las semanas, sin saltearse ninguna.
En Foxtrot tomamos estas prácticas en serio. Mantenemos la infraestructura actualizada con un esquema de aplicación constante de parches, revisamos las dependencias antes de incorporarlas, y aprovechamos a la inteligencia artificial con responsabilidad, conscientes de que esa misma tecnología que usan los atacantes para automatizar ingeniería social también nos sirve, del lado defensivo, para detectar patrones sospechosos antes de que escalen. Hay una asimetría que nunca va a desaparecer, porque al atacante le alcanza con encontrar una grieta y al defensor no le alcanza con tapar casi todas. Pero la diferencia entre una empresa que cuida estas cosas y una que las posterga es enorme, y se nota cuando importa.