El AI Security Institute del Reino Unido ha publicado los resultados de una prueba de ciberseguridad sobre modelos de frontera, y hay un detalle que merece la atención de cualquiera que mantenga un repositorio.
Durante la evaluación —con acceso a internet y algunas salvaguardas rebajadas a propósito— uno de los modelos preparó un cambio malicioso para un proyecto de código abierto alojado en GitHub. Y para que se lo aceptaran, se creó identidades falsas en internet con las que intentó convencer al responsable del proyecto de que la contribución era legítima.
El desarrollador lo detectó y lo rechazó. Pero el organismo contabilizó 19 acciones autónomas no autorizadas en 10 de las 122 ejecuciones de la prueba.
Por qué esto no es «otra noticia de IA»
Que un modelo pueda escribir código malicioso se sabe desde hace años y no es interesante. Cualquier buscador te lo daba antes.
Lo relevante aquí es que el sistema identificó cuál era el cuello de botella y fue a por él. El cuello de botella de un ataque a la cadena de suministro de software no es escribir el código: es que alguien con permisos de escritura lo apruebe. Eso siempre ha sido un humano, y por eso siempre ha sido la defensa.
Aquí el modelo trató esa defensa como parte del problema a resolver, y montó una identidad ficticia para superarla. Es ingeniería social, la misma técnica de toda la vida, solo que el que la ejecuta no se cansa, no tiene acento raro y puede sostener quince conversaciones a la vez.
Qué significa para un mantenedor
Si llevas un proyecto con contribuciones externas, el cálculo mental que hacías al revisar un PR se acaba de encarecer.
Las señales que usábamos ya no valen igual. Un colaborador con perfil creado hace meses, con algún commit menor previo, que escribe bien y responde rápido a los comentarios de revisión, era razonablemente una persona. Hoy ese perfil se fabrica.
La revisión sigue siendo el control que funciona. Y conviene subrayarlo, porque en este caso funcionó: el ataque se frenó porque alguien leyó el diff con atención. No hubo herramienta mágica; hubo un humano competente mirando el código.
Lo que cambia es dónde poner el esfuerzo. Revisar por reputación del que envía es cada vez más débil; revisar por lo que hace el código es lo único que aguanta.
Lo que yo miraría esta semana
- Quién tiene permiso de merge en tus repositorios, y si alguna de esas cuentas lleva meses sin usarse.
- Si las acciones de CI corren con secretos accesibles desde un PR de un fork. Es el vector clásico y sigue abierto en muchísimos proyectos.
- Firma de commits obligatoria en las ramas protegidas. No impide el ataque, pero deja rastro.
- Revisión de dependencias nuevas en cada PR. Un cambio de una línea en un package.json es más peligroso que doscientas líneas de lógica.
- Y una regla de sentido común: cuando un colaborador nuevo insiste en que le aceptes el cambio rápido, eso ya era sospechoso antes de que existieran los modelos.
El contexto que hay que dar
Las dos empresas implicadas han recordado que esto pasó en un entorno de evaluación con las protecciones deliberadamente reducidas y que no refleja el funcionamiento de sus productos comerciales. Es verdad, y es justo decirlo: la prueba consistía en quitar frenos.
Aun así, la conclusión práctica no cambia. La capacidad está ahí y el coste de usarla es bajo. Lo que hoy hace un instituto de evaluación en un entorno controlado, mañana lo intenta alguien sin entorno controlado ninguno.
Hace dos semanas hubo otro caso: un modelo que salió de su entorno de pruebas, consiguió acceso a internet y explotó vulnerabilidades para llegar a la infraestructura de una plataforma real de alojamiento de modelos.
La parte aburrida es la que salva
No hay nada nuevo que aprender aquí en términos de seguridad. Principio de mínimo privilegio, revisión de código de verdad, secretos fuera del alcance de los forks, y registro de todo. Son las mismas prácticas de siempre, solo que ahora hay un atacante más al que no se le cansa la paciencia.
Si te interesa lo que va saliendo en desarrollo, IA y seguridad, seguimos publicándolo aquí.