Ciberseguridad

Así se cuela el código malicioso en el software que ya usas

Susan Hill

Un ataque a la cadena de suministro no entra a la fuerza en el software que usas. Envenena una de las piezas con las que está hecho ese software y espera a que el proceso normal de actualización lo lleve hasta tu computadora. La aplicación se instala sin problemas, la firma sigue siendo válida y la actualización llega por el canal oficial. El código malicioso viaja con ella. Esa inversión es lo que vuelve tan eficaz la técnica: convierte la confianza que mantiene al software funcionando en el punto que se aprovecha.

Casi nada de lo que corres hoy lo escribe por completo la empresa cuyo nombre ves en la pantalla. Una sola aplicación puede arrastrar cientos o miles de paquetes de código abierto, cada uno mantenido por desconocidos y cada uno con más paquetes detrás. Los desarrolladores rara vez leen ese código; confían en el registro del que vino y en el número de versión que trae. Quien se cuela en cualquier eslabón de esa cadena alcanza de golpe a todos los que están más abajo, y por eso una sola pieza envenenada puede afectar a decenas de miles de proyectos antes de que alguien lo note.

Las vías de entrada se agrupan en unos pocos patrones. El typosquatting coloca un paquete malicioso con un nombre a una tecla del original y espera el error. La confusión de dependencias aprovecha cómo las herramientas resuelven los nombres y las engaña para que tomen un paquete público en lugar del privado de la empresa. El secuestro de cuentas se apodera de las credenciales de un responsable real y reparte malware como si fuera una actualización de rutina; a principios de 2026, el muy usado paquete axios alcanzó a publicar una versión comprometida luego de que la máquina de su responsable principal fuera vulnerada mediante ingeniería social. Y el envenenamiento de la cadena de armado ataca los sistemas automáticos que ensamblan y publican el software, donde un solo paso corrompido alcanza a todos los proyectos que dependen de él.

La cadena de armado se volvió el blanco más codiciado precisamente porque está por encima de todo lo demás. Cuando el popular componente de GitHub Actions tj-actions/changed-files fue comprometido en 2025, los atacantes reescribieron sus etiquetas de versión para apuntar a código malicioso y sacaron secretos de los registros de compilación de más de veinte mil repositorios: claves de acceso, tokens y claves privadas, todo impreso en texto plano. Una campaña posterior, que los investigadores llamaron Megalodon, convirtió GitHub Actions en una puerta trasera que se propagó sola y alcanzó 5.561 repositorios en unas seis horas. La máquina que construye tu software se puede subvertir con la misma facilidad que el software mismo.

Las herramientas que los desarrolladores usan a diario también están en la zona de impacto. GlassWorm, detectado por primera vez a fines de 2025, se propagó por extensiones de Visual Studio Code en las tiendas de OpenVSX y Microsoft. Ocultaba su carga con caracteres Unicode invisibles, de modo que las líneas maliciosas resultaban literalmente ilegibles en el editor y pasaban la revisión humana. Una vez instalado, robaba credenciales de npm, GitHub y Git y las usaba para infectar más paquetes y extensiones de forma automática, el rasgo que define a un gusano. Como los editores actualizan las extensiones en segundo plano y en silencio, las víctimas recibían las versiones envenenadas sin hacer clic en nada. Otra extensión envenenada de VS Code sirvió para robar cerca de 3.800 repositorios internos del propio GitHub.

Lo que vuelve tan difícil atrapar estos ataques es que cada paso, por separado, parece legítimo. El paquete está firmado. La actualización viene del registro real. La cuenta del responsable es auténtica. Las defensas tradicionales buscan archivos ya conocidos como dañinos y malware evidente, pero los ataques a la cadena de suministro se esconden dentro de código de confianza, esperado y muchas veces invisible, que llega justo cuando y como el software debe llegar. Peor todavía: el consejo de seguridad de siempre, actualizar de inmediato, es el mecanismo del que depende el atacante. Por primera vez, instalar la última versión no es, sin matices, la opción segura.

Los defensores fueron coincidiendo en unas pocas prácticas que sí funcionan. Los archivos de bloqueo fijan cada dependencia a una versión exacta y verificada, así el instalador descarga solo lo revisado y no lo más reciente. Desactivar los scripts de instalación automáticos corta la vía más común por la que un paquete malicioso ejecuta código apenas aterriza. Fijar las GitHub Actions a un hash de confirmación concreto, en lugar de a una etiqueta móvil, anula el truco de reescribir etiquetas. Un inventario de componentes del software, la lista detallada de todo lo que hay dentro de una compilación, permite saber en minutos si uno quedó expuesto cuando se revela el siguiente incidente. Muchas de las organizaciones que se salvaron de los ataques recientes no hicieron nada exótico: compilaban a partir de un archivo de bloqueo confirmado y trabajaban tras un proxy de registro que ponía en cuarentena los paquetes recién publicados.

Para quienes no programan, la protección es sobre todo indirecta, pero la lección no lo es. La cadena de suministro del software es hoy un campo de batalla de primer orden, y son las empresas que fabrican las aplicaciones de tu celular y tu laptop las que deben protegerla. La respuesta razonable no es el pánico ni el viejo reflejo de actualizar todo apenas aparece un aviso. Es preferir el software de equipos que publican qué entregan y cómo lo construyen, y tomar la idea de fuente de confianza como algo que hay que ganarse en cada eslabón, no como una propiedad que baja sola por la cadena.

La respuesta del sector está tomando forma alrededor de la procedencia: una prueba criptográfica de dónde salió un fragmento de código y cómo se construyó, verificada de forma automática antes de instalar nada. Es la misma idea que aseguró el tráfico web hace una generación, aplicada ahora a la cadena de armado del propio software. Hasta que esa prueba sea universal, cada instalación sigue siendo un acto de confianza en personas que nunca vas a conocer.

Discussion

There are 0 comments.