Lily mete detección de backdoors en el CI y en la validación de versiones
El sistema bloquea commits maliciosos en la pipeline y frena releases manipuladas o dependencias comprometidas, señalando además la línea exacta que esconde el disparador
Las pipelines de integración continua no ven pasar un backdoor. Ese es el punto de partida de Lily, un sistema automático que sus autores presentan como capaz de bloquear commits maliciosos dentro del CI y de frenar releases manipuladas o dependencias comprometidas antes de que entren en ecosistemas grandes, distribuciones de Linux incluidas. El trabajo está en arXiv y se presentará en ASE 2026, en Múnich.
Un backdoor a nivel de código es un cambio sigiloso que concede privilegios ocultos cuando se cumple un disparador secreto. Lo complicado no es escribirlo, es detectarlo: el código parece limpio hasta que recibe la entrada concreta que lo activa. Los intentos conocidos de inyectarlos en proyectos muy usados, vía commits maliciosos, paquetes de release manipulados o dependencias de terceros comprometidas, se han parado por suerte y revisión manual, no por herramientas.
Qué hace distinto
Lily ataca por dos lados. El primero es el fuzzing compatible con CI, al que añade la capacidad de detectar disparadores de comportamiento sospechoso comparando ejecuciones históricas con las actuales. Es decir, no solo mira el diff: mira cómo se comportaba el código antes y cómo se comporta ahora. Eso da una detección rápida y precisa, apta tanto para el pipeline como para validar actualizaciones.
El segundo combina el análisis del cambio de código con los datos del fuzzing para señalar al mantenedor la región concreta donde vive el backdoor, incluso cuando la actualización toca millones de líneas. Ese detalle importa más de lo que parece: hoy las herramientas de análisis de binarios aguas abajo exigen un esfuerzo manual considerable, y una alerta sin ubicación no sirve de mucho cuando el usuario tiene que revisar el árbol entero.
Los autores listan cinco estrategias con las que un atacante intentaría esquivar el sistema y evalúan las defensas correspondientes. En sus experimentos, con cientos de commits y releases benignos y backdoored, aseguran alta precisión de detección con baja tasa de falsos positivos, identificación fiable del código malicioso y resistencia a intentos adversarios. Añaden que su método habría evitado incidentes reales de backdoor ya conocidos.
El contexto lo recuerda cualquiera que siguiera el susto de xz-utils: el ecosistema abierto se salvó entonces por una casualidad y una revisión a mano.
El resumen que acompaña al paper no incluye repositorio público ni cifras concretas de precisión, y la afirmación sobre incidentes reales es de los autores, no de una evaluación independiente. Tampoco dice cuánto cuesta en tiempo de CI ejecutar el fuzzing en cada commit, que es la pregunta que decidirá si esto se adopta o no. Si funciona como describen, la detección se mueve al momento de la fusión, que es el único punto donde todavía se puede parar algo antes de que llegue a los repositorios de las distribuciones.
