13.000 capturas de tela internas acabaram em repositórios públicos do GitHub, e nenhum invasor as colocou lá

Pesquisadores de segurança encontraram mais de 13.000 capturas de tela internas de mais de 300 organizações em repositórios públicos do GitHub. As capturas não foram roubadas. Foram publicadas pelos agentes de programação que as organizações estavam usando, durante o trabalho normal.

A descoberta, reportada pela empresa de segurança Glow, é um dos vazamentos mais instrutivos dos últimos tempos, porque as suposições habituais não se aplicam. Não houve violação, nenhuma credencial comprometida e nenhum insider malicioso. Uma ferramenta automatizada fez o que lhe foi dito, e o que lhe foi dito acabou incluindo o commit de arquivos que nunca deveriam ter saído do prédio.

Como uma captura de tela acaba em um repositório público

Os agentes de programação tiram capturas de tela por motivos sensatos. Quando se pede a um agente que verifique se uma alteração na interface funcionou, ele abre um navegador, carrega a página, captura uma imagem e a compara com o resultado esperado. Essa imagem é uma evidência. Muitos agentes a salvam no diretório de trabalho para que a etapa possa ser revisada depois.

A partir daí, o caminho até um repositório público é curto. Se o diretório de trabalho do agente é a pasta do projeto, e a pasta do projeto é um repositório git, então uma captura de tela gravada em disco está a um `git add` de ser commitada. Se o agente faz commit e push como parte do seu fluxo de trabalho normal, e nada filtra os novos arquivos, a captura de tela vai para qualquer remote que o repositório aponte.

Agora repita isso ao longo de milhares de execuções, em centenas de organizações, durante meses. Ninguém decidiu publicar capturas de tela internas. O comportamento padrão das ferramentas fez isso, e nenhuma etapa da cadeia estava verificando.

Por que isso não é um erro pequeno

Uma captura de tela interna costuma ser mais reveladora do que as pessoas esperam. Ela pode mostrar um painel com nomes de clientes, um painel administrativo com preços, um ambiente de staging, um rastreador de bugs ou uma janela de chat no canto da tela. Pode mostrar o estado de um produto que ainda não foi lançado. No agregado, 13.000 imagens de 300 organizações são um mapa do que essas empresas estavam desenvolvendo.

As imagens também persistem. Um commit enviado a um repositório público permanece no histórico mesmo depois que o arquivo é excluído da versão atual, a menos que o histórico seja reescrito. Portanto, a exposição não é resolvida por um commit de limpeza posterior, que é a etapa que a maioria das equipes tentaria primeiro.

Por que os agentes pioram isso

Um desenvolvedor humano que tira uma captura de tela para um pull request normalmente a olha antes de anexá-la. A imagem está ali, e a pessoa decide se é seguro compartilhá-la. Esse momento de julgamento é o filtro, e ele funciona na maioria das vezes.

Um agente não tem esse momento. Ele otimiza para concluir a tarefa, e salvar um artefato faz parte de concluir a tarefa. Nada no ciclo pergunta se o artefato é sensível, porque nada no ciclo está equipado para saber. O agente não está sendo descuidado no sentido humano. Ele está fazendo exatamente o que as instruções diziam.

É a mesma lição que aparece em várias áreas do design de agentes. Permissões que eram adequadas para uma pessoa digitando comandos não são adequadas para um sistema que age na velocidade da máquina e nunca se cansa. Um humano que faz commit de uma captura de tela uma vez por semana é um deslize. Um agente fazendo isso a cada execução em toda uma frota é um resultado de política.

Como é a correção

Os controles que teriam evitado isso não são exóticos. Uma entrada no `.gitignore` para diretórios de capturas de tela é a mais simples, e só funciona se alguém a escrever antes de o agente ser executado. Um hook de pre-commit que procura arquivos de imagem em determinados caminhos captura o que o arquivo de ignore deixa passar. Dar aos agentes um diretório de rascunho fora do repositório para artefatos temporários elimina o problema na origem.

Nenhum deles depende de detectar que uma imagem é sensível. Eles dependem de decidir, antecipadamente, para onde a saída do agente pode ir. Essa é uma decisão de design, e precisa ser tomada pela equipe que opera os agentes, porque o agente não pode tomá-la.

Por que os números continuam crescendo

A contagem de 13.000 imagens de 300 organizações não é um número fixo. É um instantâneo dos repositórios que eram públicos no momento da varredura, e o número vai aumentar à medida que mais equipes adotarem agentes e mais repositórios forem enviados. Os pesquisadores varreram repositórios públicos, o que significa que o total real, incluindo repositórios privados onde o mesmo erro aconteceu, é impossível de conhecer de fora.

As organizações afetadas não são todas pequenas. A descoberta nomeia mais de 300 delas, o que abrange startups e empresas maiores que usam as mesmas ferramentas de agentes. Essa é a natureza de um problema de comportamento padrão: ele não respeita o tamanho da empresa, porque toda empresa que usa a ferramenta herda o mesmo padrão.

O que o relatório não diz

A descoberta não afirma que qualquer uma das imagens expostas tenha sido usada maliciosamente, e não há evidências de que alguém fora dos projetos as tenha vasculhado. O dano é potencial e não comprovado: o material era público, e qualquer pessoa poderia ter olhado. Onde o dano foi demonstrado em casos relacionados, como credenciais escritas em um arquivo público, o prejuízo é imediato.

Também não nos diz quantas das imagens eram sensíveis de alguma forma significativa. Algumas são quase certamente capturas de tela de uma página de teste em branco. Mas um vazamento é julgado pelo pior item nele, não pela média, e 13.000 imagens em 300 organizações significam que o pior item provavelmente é de fato revelador.

O padrão por trás disso

A descoberta da Glow é uma entre um conjunto de relatos semelhantes. Pesquisadores mostraram que agentes de programação fazem referência a pacotes de software que não existem, o que invasores podem explorar registrando esses nomes. Outros descobriram agentes escrevendo credenciais ou tokens em lugares onde não deveriam. O fio condutor é que os agentes produzem artefatos como efeito colateral do trabalho, e todo artefato é um possível vazamento.

A leitura tranquilizadora é que isso é corrigível e se resume principalmente a higiene. A leitura menos tranquilizadora é que o setor está implantando agentes mais rápido do que está construindo as salvaguardas em torno de suas saídas. Uma empresa que audita o que seus agentes leem muitas vezes não está auditando o que eles escrevem.

O que fazer esta semana

Se uma equipe está executando agentes de programação contra repositórios, as verificações imediatas valem a pena. Veja se o diretório de trabalho do agente está dentro do repositório, se capturas de tela ou logs acabam ali e se a etapa de commit filtra alguma coisa. Verifique o histórico do repositório, bem como a árvore atual, em busca de arquivos de imagem que não deveriam ser públicos. E dê aos agentes um caminho de rascunho fora da árvore para qualquer coisa temporária.

Nada disso exige novas ferramentas. Exige decidir que a saída do agente, assim como a entrada do agente, é algo que uma equipe controla de propósito, e não por acidente.