Oito Descobertas de Segurança em uma Manhã de Sábado

Auditorias revelam coisas. O movimento honesto é dar as boas-vindas a elas, corrigir tudo, e entregar travas de segurança permanentes — que é exatamente como um runtime conquista confiança empresarial.

A auditoria chegou na caixa de entrada no final da semana passada. No sábado de manhã eu já tinha o relatório aberto em uma tela e a base de código aberta na outra. Oito descobertas críticas ou altas. O tipo de conteúdo de caixa de entrada que define um fim de semana.

Isso foi due diligence empresarial. Um potencial parceiro tinha pedido ao seu time de segurança para rodar uma passagem na superfície pública da API antes de deixar seus advogados avançarem. As descobertas eram específicas, bem explicadas, e inteiramente justas. Também eram o tipo de coisa para a qual um fluxo de trabalho orientado por agentes te deixa especialmente vulnerável se você não for deliberado sobre se defender contra elas.

Ao final do sábado, cada descoberta tinha um PR integrando-a. Este é o post sobre o que cada uma foi.

Quais eram as categorias

Vou falar sobre categorias em vez de detalhes específicos de exploração porque os detalhes específicos agora estão corrigidos e não são interessantes para um concorrente; as categorias são o que outros times vão querer se defender contra.

Um: validação de entrada na superfície REST pública. Vários endpoints estavam confiando em suas entradas mais do que deveriam. Especificamente, limites de comprimento em entradas de string, limites de faixa em entradas numéricas, e validação estrutural em payloads JSON. Nenhuma das validações ausentes era catastrófica por si só. A combinação de “sem limite de comprimento aqui mais sem limite de taxa ali mais sem verificação de autenticação neste endpoint administrativo” é o tipo de pilha que se torna catastrófica uma vez que um atacante descobre a superfície.

Dois: uma credencial fixa no código em um arquivo de configuração. Diferente da descoberta de HMAC de alguns fins de semana atrás. Esse era um template de configuração que tinha uma credencial real commitada na versão de exemplo. A intenção tinha sido entregar uma credencial de exemplo que fosse um placeholder; o que foi entregue foi uma credencial de exemplo que era um valor real do ambiente local de um desenvolvedor. Rotação, remoção do exemplo, adição à passagem de CI de varredura de segredos.

Três: negociação insegura de suíte de cifras. Um subsistema que negocia TLS com um serviço externo estava aceitando suítes de cifras que não deveriam ser aceitáveis em 2026. Especificamente, várias suítes pré-TLS-1.3 com fraquezas conhecidas. A correção foi restringir a lista de suítes de cifras a um conjunto exclusivamente TLS-1.3, com uma válvula de escape documentada (uma flag explícita) para testar contra sistemas legados de parceiros.

Quatro: um use-after-free no limite da API em C. A API em C de uma das DLLs do runtime tinha uma função que retornava um ponteiro para estado interno, que quem chamava podia continuar a usar depois que o estado interno tinha sido liberado por uma chamada subsequente no mesmo handle. Armadilha clássica de API em C. A correção foi trocar de semântica de “ponteiro mantido por quem chama” para semântica de “handle opaco mantido por quem chama com um acessor de obter-por-handle.” O acessor retorna uma cópia fresca do ponteiro pela duração da chamada e a memória subjacente não é exposta.

Cinco: um buraco de segurança de thread na camada de licenciamento. Duas threads podiam competir pelo mesmo objeto de estado de licenciamento durante chamadas de verificação concorrentes. Sob carga, uma thread podia ver um estado parcialmente atualizado e chegar a conclusões incorretas sobre a validade da licença. A correção foi um lock adequado de leitura-escrita em torno do estado, com o caminho de verificação otimizado para o caso comum (licença válida, nenhuma mudança de estado necessária).

Seis: um bypass de autorização em um endpoint administrativo. Um dos endpoints administrativos tinha uma verificação de autenticação mas não uma verificação de autorização. Qualquer usuário autenticado podia chamá-lo, incluindo usuários sem o papel de administrador. A correção foi adicionar a verificação de papel, escrever um teste de unidade que exercita tanto o caminho de “autenticado-como-admin permitido” quanto “autenticado-mas-não-admin negado,” e auditar todo outro endpoint administrativo em busca do mesmo padrão. Três outros endpoints tinham o mesmo problema. Todos os quatro agora estão corretos.

Sete: logging insuficiente em falhas de autenticação. Quando um usuário tentava se autenticar e falhava, o runtime registrava a tentativa mas não registrava contexto suficiente para investigar um padrão de força bruta ou credential stuffing. A correção foi adicionar logging estruturado em toda falha de autenticação com o endereço IP, o contador limitado por taxa para aquele IP, e o método de autenticação tentado. Preservando a privacidade (nenhum conteúdo de senha é registrado), mas com contexto suficiente para investigar quando uma investigação se torna necessária.

Oito: atraso na atualização de dependências. Várias das dependências de terceiros que o runtime traz tinham versões conhecidamente vulneráveis fixadas no manifesto. A correção foi atualizar cada uma para a última versão corrigida, rodar a suíte de testes contra as atualizações, e resolver o pequeno número de mudanças de formato de API que as atualizações exigiram. Duas das oito atualizações exigiram mudanças de adaptador no nosso código; as outras seis foram diretas. O Dependabot agora está configurado para sinalizar isso automaticamente.

O que aprendi de um fim de semana de trabalho de segurança

Três coisas. Nada surpreendente. Vale a pena dizer.

Descobertas de segurança se agrupam. Oito descobertas é muito para revelar de uma vez. O padrão, olhando para trás, é que todas compartilham uma raiz comum: o runtime tinha estado crescendo rápido em um fluxo de trabalho orientado por agentes, com os agentes implementando coisas corretamente-em-isolamento. Preocupações transversais como segurança são exatamente o tipo de coisa que escapa da revisão PR-por-PR. A auditoria pega o que a revisão perdeu. Agende as auditorias.

Algumas descobertas são modos de falha orientados por agentes. O use-after-free na API em C é o tipo de coisa que um agente escreve quando o prompt diz “exponha esse estado interno a quem chama” sem especificar semântica de posse. O buraco de segurança de thread na camada de licenciamento é semelhante. Ambos estão pegando o mesmo padrão: agentes que não são questionados sobre posse e concorrência vão produzir código que ignora ambas.

Algumas descobertas são modos de falha orientados por ritmo. O atraso na atualização de dependências não é um problema de agente. É um problema de “entregar rápido e não ter uma pessoa cujo trabalho é manter dependências atualizadas.” A correção é processo (Dependabot) e disciplina (agir sobre os alertas do Dependabot). A correção não é “ser mais esperto.”

As novas defesas

Travas de segurança permanentes integradas neste fim de semana.

Uma passagem de scanner de segurança na CI. Análise estática para validação de entrada, varredura de segredos, e política de suíte de cifras. Todo PR roda a varredura. PRs que introduzem novas descobertas são sinalizados para revisão.

Um padrão de teste de endpoint administrativo. Todo endpoint administrativo na API agora tem um teste pareado que exercita tanto o caminho permitido-para-admin quanto o caminho negado-para-não-admin. O padrão é imposto por uma verificação de CI que varre por decoradores @admin_required e falha o build se o decorador estiver presente sem um teste pareado correspondente.

Uma anotação de segurança de thread em estado compartilhado. Todo objeto de estado compartilhado no runtime agora tem uma anotação explícita sobre seu modelo de concorrência: imutável, protegido por lock, livre de lock com happens-before explícito, ou de thread única. A anotação faz parte do tipo. Código que toca o estado tem que satisfazer a anotação. O compilador impõe isso para os casos protegidos por lock e imutáveis; o resto fica sob revisão.

Uma auditoria de segurança mensal na agenda. Sem esperar que um parceiro peça. A auditoria é um item fixo no segundo sábado de todo mês. A primeira roda em abril.

O que parceiros e construtores devem tirar disso

Se você está avaliando um engine para parceria e está prestes a pedir uma auditoria, esse time vai dar as boas-vindas a ela. Auditorias revelam coisas. Coisas são corrigidas. A base de código melhora. A relação com o parceiro melhora. A disciplina de dar as boas-vindas à auditoria é mais importante do que qualquer descoberta específica.

Se você é um profissional de segurança empresarial lendo isso, estou aberto a sugestões sobre a cadência de auditoria e sobre as coisas específicas que você gostaria que mais times de engine auditassem. As descobertas deste fim de semana foram as óbvias. As não óbvias são as próximas que eu quero encontrar.

Se você está rodando um fluxo de trabalho orientado por agentes e não fez uma auditoria de segurança recentemente, faça uma. O padrão de “agente escreve código correto-em-isolamento que perde preocupações transversais” é universal nessa forma de fluxo de trabalho. A auditoria é como você pega as preocupações transversais. Não há outra forma que eu tenha encontrado.

Verificação de fim de semana. Oito descobertas fechadas. Seis novas defesas integradas. A próxima auditoria está na agenda. A relação com o parceiro avança.

De volta a construir.