13.000 capturas de pantalla internas terminaron en GitHub público, y ningún atacante las puso allí

Investigadores de seguridad han encontrado más de 13.000 capturas de pantalla internas de más de 300 organizaciones en repositorios públicos de GitHub. Las capturas no fueron robadas. Fueron publicadas por los agentes de programación que las organizaciones estaban utilizando, durante el trabajo ordinario.

El hallazgo, reportado por la firma de seguridad Glow, es una de las filtraciones más instructivas en un tiempo, porque las suposiciones habituales no se aplican. No hubo brecha, ni credenciales comprometidas, ni un insider malicioso. Una herramienta automatizada hizo lo que se le indicó, y lo que se le indicó resultó incluir hacer commit de archivos que nunca debieron haber salido del edificio.

Cómo termina una captura de pantalla en un repositorio público

Los agentes de programación toman capturas de pantalla por razones sensatas. Cuando se le pide a un agente que verifique que un cambio en la interfaz de usuario funcionó, abre un navegador, carga la página, captura una imagen y la compara con el resultado esperado. Esa imagen es evidencia. Muchos agentes la guardan en el directorio de trabajo para que el paso pueda revisarse más tarde.

A partir de ahí, el camino hacia un repositorio público es corto. Si el directorio de trabajo del agente es la carpeta del proyecto, y la carpeta del proyecto es un repositorio de git, entonces una captura de pantalla escrita en disco está a un `git add` de distancia de ser incluida en un commit. Si el agente hace commit y push como parte de su flujo de trabajo normal, y nada filtra los archivos nuevos, la captura de pantalla va al remoto al que apunte el repositorio.

Ahora repite eso en miles de ejecuciones, en cientos de organizaciones, durante meses. Nadie decidió publicar capturas de pantalla internas. El comportamiento predeterminado de las herramientas lo hizo, y ningún paso en la cadena lo estaba verificando.

Por qué esto no es un error pequeño

Una captura de pantalla interna a menudo revela más de lo que la gente espera. Puede mostrar un panel con nombres de clientes, un panel de administración con precios, un entorno de staging, un rastreador de errores o una ventana de chat en la esquina de la pantalla. Puede mostrar el estado de un producto que aún no se ha lanzado. En conjunto, 13.000 imágenes de 300 organizaciones son un mapa de en qué estaban trabajando esas empresas.

Las imágenes también persisten. Un commit enviado a un repositorio público permanece en el historial incluso después de que el archivo se elimine de la versión actual, a menos que se reescriba el historial. Por lo tanto, la exposición no se soluciona con un commit de limpieza posterior, que es el paso que la mayoría de los equipos buscaría primero.

Por qué los agentes empeoran esto

Un desarrollador humano que toma una captura de pantalla para una pull request normalmente la mira antes de adjuntarla. La imagen está justo ahí, y la persona decide si es seguro compartirla. Ese momento de juicio es el filtro, y funciona la mayoría de las veces.

Un agente no tiene ese momento. Optimiza para completar la tarea, y guardar un artefacto es parte de completar la tarea. Nada en el bucle pregunta si el artefacto es sensible, porque nada en el bucle está equipado para saberlo. El agente no está siendo descuidado en el sentido humano. Está haciendo exactamente lo que decían las instrucciones.

Esta es la misma lección que aparece en varias áreas del diseño de agentes. Los permisos que estaban bien para una persona que escribe comandos no están bien para un sistema que actúa a velocidad de máquina y nunca se cansa. Un humano que hace commit de una captura de pantalla una vez a la semana es un desliz. Un agente que lo hace en cada ejecución en toda una flota es un resultado de política.

Cómo se ve la solución

Los controles que habrían evitado esto no son exóticos. Una entrada en `.gitignore` para directorios de capturas de pantalla es la más simple, y solo funciona si alguien la escribe antes de que se ejecute el agente. Un hook de pre-commit que escanea archivos de imagen en ciertas rutas atrapa lo que el archivo de ignore pasa por alto. Dar a los agentes un directorio temporal fuera del repositorio para artefactos temporales elimina el problema en la fuente.

Ninguno de estos depende de detectar que una imagen es sensible. Dependen de decidir, de antemano, a dónde se permite que vaya la salida del agente. Esa es una decisión de diseño, y tiene que ser tomada por el equipo que ejecuta los agentes, porque el agente no puede tomarla.

Por qué los números siguen creciendo

El recuento de 13.000 imágenes de 300 organizaciones no es una cifra fija. Es una instantánea de los repositorios que eran públicos en el momento del escaneo, y el número aumentará a medida que más equipos adopten agentes y se suban más repositorios. Los investigadores escanearon repositorios públicos, lo que significa que el total real, incluidos los repositorios privados donde ocurrió el mismo error, es imposible de conocer desde fuera.

Las organizaciones afectadas no son todas pequeñas. El hallazgo nombra a más de 300 de ellas, lo que abarca desde startups hasta empresas más grandes que utilizan las mismas herramientas de agentes. Esa es la naturaleza de un problema de comportamiento predeterminado: no respeta el tamaño de la empresa, porque cada empresa que usa la herramienta hereda el mismo valor predeterminado.

Lo que el informe no dice

El hallazgo no afirma que ninguna de las imágenes expuestas se haya utilizado maliciosamente, y no hay evidencia de que alguien ajeno a los proyectos las haya revisado a fondo. El daño es potencial en lugar de comprobado: el material era público, y cualquiera podría haberlo mirado. Donde se ha demostrado daño en casos relacionados, como credenciales escritas en un archivo público, el daño es inmediato.

Tampoco nos dice cuántas de las imágenes eran sensibles de manera significativa. Algunas son casi con certeza capturas de pantalla de una página de prueba en blanco. Pero una filtración se juzga por el peor elemento que contiene, no por el promedio, y 13.000 imágenes en 300 organizaciones significa que el peor elemento probablemente sea realmente revelador.

El patrón detrás de esto

El hallazgo de Glow es uno de un grupo de informes similares. Los investigadores han demostrado que los agentes de programación hacen referencia a paquetes de software que no existen, lo que los atacantes pueden explotar registrando esos nombres. Otros han encontrado agentes que escriben credenciales o tokens en lugares donde no deberían. El hilo común es que los agentes producen artefactos como efecto secundario de hacer trabajo, y cada artefacto es una posible filtración.

La lectura tranquilizadora es que esto es solucionable y en su mayoría se reduce a higiene. La lectura menos tranquilizadora es que la industria está desplegando agentes más rápido de lo que está construyendo las barreras de protección en torno a su salida. Una empresa que audita lo que sus agentes leen a menudo no está auditando lo que escriben.

Qué hacer esta semana

Si un equipo está ejecutando agentes de programación contra repositorios, vale la pena hacer las comprobaciones inmediatas. Mira si el directorio de trabajo del agente está dentro del repositorio, si las capturas de pantalla o los registros terminan allí, y si el paso de commit filtra algo. Revisa el historial del repositorio, así como el árbol actual, en busca de archivos de imagen que no deberían ser públicos. Y dales a los agentes una ruta temporal fuera del árbol para cualquier cosa temporal.

Nada de eso requiere nuevas herramientas. Requiere decidir que la salida del agente, al igual que la entrada del agente, es algo que un equipo controla a propósito en lugar de por accidente.