Auditoria de segurança com IA: como o Datasette usou três modelos e dois revisores humanos nas versões 1.0a39 e 0.65.4

Fala aí, beleza? O Datasette acabou de soltar duas versões de correção de segurança depois de uma auditoria rodada com três modelos de fronteira, e a parte mais interessante não é o que quebrou, é COMO os mantenedores organizaram o trabalho

O Datasette é a ferramenta de publicação e exploração de dados em SQLite, distribuída no PyPI como datasette e mantida no repositório oficial no GitHub. Em 11 de setembro de 2026 o projeto publicou a 1.0a39, da série alfa atual, e a 0.65.4, da família estável 0.65.x. Quem conduziu a auditoria foram Alex Garcia e Simon Willison, e o processo que eles usaram é o tipo de coisa que dá pra adaptar em qualquer repositório, mesmo que teu projeto não tenha nada a ver com SQLite

Como a auditoria foi conduzida: três modelos e um repositório privado

O gatilho veio de fora: issues reportadas pelo pesquisador Sevban Dönmez motivaram uma auditoria completa do código

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

A partir daí, Alex Garcia e Simon Willison rodaram uma auditoria extensa do Datasette usando Claude Fable 5.1, GPT-5.6 e GPT-6 Astra. Três modelos diferentes, agentes de código distintos, tudo tocado em um repositório privado compartilhado entre os dois mantenedores

Segundo o relato dos próprios mantenedores, depois da auditoria foi quase uma semana colaborando e revisando as correções antes de publicar qualquer coisa

Repara na ordem das coisas, porque ela importa: auditoria primeiro, correções depois, publicação por último. Enquanto o bug existe e não tem patch, o trabalho fica fora do alcance de quem está lendo teu repo público

O processo de dois revisores: quem escreve o teste não escreve a correção

Essa é a parte que vale copiar

Para a maioria das issues, um dos dois criava os testes automatizados que evidenciavam o problema e o outro implementava a correção. Simples assim. O resultado é que dois humanos distintos olharam cada achado, além dos agentes de código rodando modelos diferentes

E por que isso funciona tão bem? Porque separa duas perguntas que normalmente se misturam na cabeça de quem corrige sozinho

A primeira é: esse problema existe mesmo? Quem escreve o teste precisa provar o bug em código executável. Se não dá pra escrever um teste que falha na versão atual, ou o achado não é real, ou não foi entendido direito

A segunda é: essa correção resolve? Quem implementa o patch tem um alvo objetivo, o teste do colega passando, em vez de um parágrafo de texto gerado por um modelo dizendo que talvez exista uma falha

Isso ataca direto o ponto fraco de usar IA pra caçar vulnerabilidade: modelo inventa bug com a mesma segurança com que encontra bug de verdade. O teste que falha ANTES do patch é o filtro. Achado que não vira teste vermelho não vira commit

O uso de modelos diferentes no mesmo código segue a mesma lógica de diversificar o olhar, e vale lembrar que modelos diferentes dão respostas diferentes pro mesmo pedido, o que aqui é vantagem e não defeito

O que foi corrigido nas versões 1.0a39 e 0.65.4

Segundo o blog oficial do projeto, as releases reúnem correções reportadas por pesquisadores externos e outras encontradas na auditoria extensa. A maioria afeta instâncias hospedadas na internet pública que dão a usuários autenticados acesso a dados privados

O changelog da 1.0a39 concentra correções de permissão:

• checagens de permissão de tabela e view passam a considerar que nomes no SQLite não diferenciam maiúsculas de minúsculas
• ver uma tabela de índice de busca full-text passa a exigir permissão sobre a tabela de origem
• tabelas de estatísticas do SQLite (sqlite_stat1 a sqlite_stat4) passam a ser negadas por padrão
• a exibição do schema da tabela passa a obedecer a permissão view-table
• filtros com ?_through= exigem permissão para ver a tabela intermediária
• APIs de chave estrangeira e relações de entrada respeitam view-table
• endpoints de linha checam permissão antes de resolver chaves primárias

Já as correções de construção de SQL e de cache estão presentes nas duas releases:

• escape corrigido de identificadores SQL para nomes de colunas de chave primária vindos de schemas não confiáveis, incluindo busca de linha e paginação
• detecção de índice de busca full-text passa a usar SQL parametrizado e trata caracteres curinga em nomes de tabela literalmente
• respostas dinâmicas privadas e personalizadas passam a usar Cache-Control: private, no-store
• o carregamento de extensões do SQLite é desabilitado depois que as extensões passadas via --load-extension são carregadas

Olha o padrão que se repete nessa lista: quase tudo é permissão sendo checada no lugar errado, tarde demais ou com a comparação errada. É exatamente o tipo de bug sutil que passa batido em code review humano de rotina, porque o código parece certo lendo linha a linha

Você precisa atualizar? Quem é afetado e como fica a atualização

O recado do projeto é direto: aplique as correções se você roda uma instância de Datasette na web pública, em especial se essa instância mistura tabelas públicas e privadas

Se teu Datasette roda só na tua máquina ou dentro de uma rede fechada sem usuários autenticados de fora, o risco é outro. Ainda assim, 1.0a39 e 0.65.4 seguem sendo as versões mais recentes de cada linha, a alfa e a estável 0.65.x, conforme o PyPI em 13/09/2026

O pacote é distribuído no PyPI como datasette. A documentação oficial de instalação indica instalar o Datasette e suas dependências com pip, e o comando datasette install aceita a opção -U, --upgrade para atualizar pacotes para a versão mais recente

O caminho completo pra cada tipo de ambiente está documentado na própria página de instalação da documentação oficial

E já que o assunto é instância exposta na internet, vale conferir também como está a parte de fora do app: auditoria e logs de segurança na VPS é a outra metade da história quando o serviço está público

O que dá pra copiar desse processo no seu projeto

O que os mantenedores publicaram foi o formato de colaboração que usaram, e esse esqueleto é bem reproduzível em qualquer repositório:

1. Delimite o escopo antes de soltar o agente. Auditoria aberta do tipo "procure vulnerabilidades" devolve uma pilha de genérico. Fatia por superfície: autenticação, permissões por objeto (tabela, registro, projeto), rotas públicas contra rotas privadas, construção de SQL, headers de cache em resposta autenticada. O erro comum deste passo é pedir tudo de uma vez e depois não conseguir triar a saída
2. Registre cada achado como issue separada. Um achado, uma issue. Achado que descreve três coisas ao mesmo tempo vira patch confuso e teste impossível de escrever
3. Feche cada issue com um teste de regressão que falha antes da correção. Esse é o artefato central. Roda o teste na versão vulnerável e ele reprova, roda na corrigida e ele passa. Se não dá pra escrever esse teste, para e questiona se o bug existe
4. Separe quem escreve o teste de quem escreve o patch. Foi assim que os mantenedores do Datasette trabalharam na maioria das issues, garantindo dois humanos por achado. Se tu tá sozinho no projeto, dá pra aproximar disso usando agentes com modelos diferentes em cada etapa, sabendo que a revisão humana continua sendo tua
5. Mantenha o trabalho em repositório privado até a correção sair. A auditoria do Datasette aconteceu em repositório privado compartilhado. Descrição detalhada de falha em issue pública antes do patch é receita pronta pra quem quiser explorar
6. Anote o que foi descartado e por quê. Falso positivo triado sem registro volta na próxima rodada e tu refaz o mesmo trabalho do zero

Na hora da triagem, a pergunta que economiza tempo é sempre a mesma: qual usuário, com qual permissão, consegue ver o quê que não deveria? Se o achado não responde isso em uma frase, provavelmente é ruído

Pra começar do zero na comparação entre modelos pra tarefas de código, este vídeo do canal coloca dois deles lado a lado:

Os limites: auditoria com IA não substitui pentest nem revisão humana

Os mantenedores foram claros: os modelos ajudaram a encontrar bugs muito sutis, e eles afirmam que passarão a incorporar auditorias de segurança por modelos de fronteira em todo o trabalho de desenvolvimento daqui pra frente

Mas repara no que veio junto: pelo relato deles, quase uma semana de colaboração e revisão humana depois da auditoria, e um processo desenhado justamente pra ter dois humanos olhando cada achado

Ou seja, o modelo é o cara que levanta a hipótese, não o cara que fecha o caso

O risco de rodar isso sem estrutura é conhecido. Modelo produz vulnerabilidade inventada com texto convincente, e se tu aceita o achado sem teste reprodutível acaba fazendo patch em bug que nunca existiu, mexendo em código de permissão que estava certo. Nesse jogo, patch errado em autorização é tão ruim quanto o bug

E isso aqui não é pentest. Não é revisão de segurança especializada, não é auditoria de terceiro independente. É mais uma camada, que parece valer muito a pena, rodando ANTES e junto das outras

Conclusão

Se tu tem uma instância de Datasette exposta na web pública, principalmente misturando tabelas públicas e privadas, atualizar é a tarefa do dia

E se tu não usa Datasette, a lição que sobra é de graça: adota a regra do teste que falha antes do patch no teu próprio repositório. Achado de segurança que não vira teste vermelho não vira commit, seja ele reportado por humano ou cuspido por um agente

Pra acompanhar os detalhes, o changelog das versões e o blog oficial do projeto são as fontes que valem, e a lista de correções da 1.0a39 e da 0.65.4 é uma ótima leitura pra entender onde permissão costuma vazar em app de dados

Até o próximo post! 😀