Incidentes en repositorios de modelos y paquetes

Un repositorio público de paquetes o de modelos cambia todos los días: salen versiones nuevas, se corrigen errores, se reentrena un modelo con datos más recientes. Casi todo eso es normal. Lo que convierte un cambio en incidente no es que haya cambiado algo, sino que el cambio no encaja con la historia del proyecto: lo publica una cuenta que nunca había publicado, se publica por un camino distinto del de siempre (a mano, sin la atestación de procedencia que traían las versiones anteriores), aparece un script que se ejecuta al instalar cuando antes no lo había, o el artefacto crece mucho sin que las notas ni el repositorio de código lo expliquen.

Los casos públicos de los últimos años se repiten con pocas variantes: la cuenta de quien mantiene el paquete pasa a otras manos y desde ella sale una versión con algo de más; aparece un nombre casi idéntico a uno conocido esperando a que alguien se equivoque al escribirlo; un modelo se sube con el nombre de una organización que no es la suya. MITRE ATLAS recoge el compromiso de la cadena de suministro de sistemas de aprendizaje automático como técnica propia, y en OWASP Top 10 para aplicaciones con LLM la cadena de suministro tiene su entrada.

Por eso la primera lectura de un caso es la del historial público del artefacto, evento por evento, con la cuenta que hizo cada cosa.

El historial de un paquete trae más que versiones: registra inicios de sesión, cambios del correo de recuperación y propietarios que se agregan o se quitan. Leídos juntos cuentan una historia. Una cuenta que inicia sesión desde un dispositivo y un país que nunca había usado, cambia el correo de recuperación y a los pocos minutos agrega un propietario recién creado no se parece a un mantenedor que invita a un colega.

Lo que importa para el caso es qué cuenta publicó la versión que no corresponde y cuándo.

Saber que una versión es mala no dice todavía si llegó a tu casa. Para eso se cruza el historial público con el registro de compilaciones de la empresa: qué compilación resolvió qué versión y cuándo se desplegó. La primera compilación que la trajo marca el inicio posible de la exposición; el despliegue marca el inicio real en producción.

Nadie en Cuchuco decidió instalar la versión nueva. Entró sola porque el manifiesto del servicio no fijaba una versión: declaraba un rango que acepta cualquier versión compatible que se publique, y el servicio no tenía archivo de bloqueo que congelara la resolución. Cada compilación preguntaba al registro qué era lo más reciente dentro del rango y se lo llevaba.

El servidor de informes descarga un modelo de resumen de un repositorio público de modelos, y ese modelo también cambió de revisión pocos días antes. Con un incidente en curso es tentador meter todo cambio en el mismo saco. El criterio es el de la tarea 1: si el cambio encaja con la historia del proyecto, no es un incidente, aunque deje ver un hueco de diseño.