Desativar no painel não fecha o binário

Um recurso desligado na configuração não é um recurso inacessível no binário. Essa distinção, que parece óbvia quando escrita com clareza, costuma se dissolver na prática de times que tratam feature flags e arquivos de configuração como se fossem interruptores físicos. A Anthropic publicou em 20 de outubro um estudo que dá materialidade a essa confusão. Em vez de caçar vulnerabilidades uma a uma, a equipe de Chris Rohlf, da Frontier Red Team, pediu ao Claude que inventariasse configurações e traçasse alcançabilidade em 25 projetos open source, mais de cinco milhões de linhas em C, C++, Java, PHP e Python. O modelo catalogou mais de 17 mil opções de configuração, das quais 3.842 estavam ligadas a algum controle de segurança, e flagrou 493 problemas de exposição.

A mudança de pergunta é o ponto central. A pergunta tradicional da segurança de software é "quais bugs existem no código exposto?". A pergunta que a pesquisa propõe é anterior: "por que esse código está exposto?". A diferença não é semântica. Corrigir uma vulnerabilidade crítica não diz nada sobre as vulnerabilidades que permanecem — e o atacante só precisa de um ponto não descoberto para entrar. Reduzir a alcançabilidade não elimina os defeitos desconhecidos, mas os torna mais difíceis de atingir, o que reduz a severidade do que ainda não foi encontrado. É uma lógica de contenção, não de completude.

O caso do OpenSSH é o mais eloquente porque o código é intensamente auditado. O Claude traçou os caminhos de entrada do daemon na versão 10.4 e encontrou cerca de 4.500 linhas de código experimental para o algoritmo de assinatura pós-quântica ML-DSA-44 que um cliente não autenticado conseguia alcançar na configuração padrão mesmo quando o administrador excluía explicitamente o algoritmo. Isso representava aproximadamente 16% do código pré-autenticação do sshd padrão. O daemon parseava o tipo de chave que o cliente enviava e, para certificados, verificava a assinatura da CA embutida; só depois checava se aquele tipo de chave era permitido. A ordem das operações transformava uma feature desligada em superfície de ataque ativa. O OpenSSH 10.5 moveu os pontos de checagem e o 10.6 completou a correção, removendo cerca de um quinto do código que podia ser alcançado por clientes não autenticados.

Os três métodos de exposição

Os três métodos usados pelo Claude ajudam a organizar o problema:

1. Configuração padrão: código que está alcançável no estado em que o software é distribuído, mas que nenhuma funcionalidade padrão realmente usa.

2. Interação de configuração: pares de opções que, isoladamente, parecem razoáveis, mas que juntas silenciosamente desativam um controle ou deixam o comportamento de uma feature indefinido enquanto o código continua alcançável.

3. Alcançabilidade precoce: código sensível e complexo que executa antes de um controle adequado — autenticação, interação da vítima ou transição de estado de protocolo.

Nenhum desses métodos depende de um bug de memória ou de uma falha de validação clássica. Eles operam na camada de arquitetura e de configuração, onde a intenção do desenvolvedor e o comportamento real do binário se descolam.

O risco oculto das interações silenciosas

Os números da interação de configuração merecem atenção separada. O Claude encontrou 162 combinações de opções sensíveis à segurança que foram aceitas sem erro, sem aviso e sem documentação sobre o comportamento esperado da interação. Em 94 delas, a combinação desligava silenciosamente um controle de segurança.

Um padrão específico apareceu de forma independente em quatro projetos não relacionados: uma regra de negação escrita com hostname ou wildcard, combinada com a opção de DNS reverso desligada (o padrão na maioria dos projetos), fazia com que o servidor comparasse o padrão de hostname com um endereço IP bruto. Um padrão de hostname nunca corresponde a um IP. A regra de negação nunca disparava. A lista falhava aberta, deixando passar exatamente os clientes que deveria bloquear.

Em outro projeto, a exigência de certificado para todo cliente, combinada com uma opção destinada apenas a atrasar a checagem, desativava a verificação por completo. Um servidor configurado para aceitar apenas clientes confiáveis aceitava qualquer um. O conflito estava no código havia 21 anos, sem aviso e sem documentação.

O que isso exige dos times que usam IA

Para quem trabalha com agentes de codificação, o paralelo é direto e desconfortável. O agente herda código, configurações e exposição que não necessariamente deveria herdar. Um recurso desligado no painel não é um recurso inacessível no binário se o caminho continua compilado e alcançável. A mesma lógica que se aplica a um daemon de SSH se aplica ao que uma aplicação expõe e ao que um agente de código toca durante uma revisão, uma refatoração ou uma geração de patch.

A pesquisa da Anthropic não é sobre substituir a correção de bugs por uma varredura mágica de alcançabilidade. É sobre reconhecer que a maior parte da insegurança real não é um exploit de corrupção de memória, mas um arquivo de configuração fazendo algo que seu autor não esperava. Quem conta apenas com "desativei no config" e com o scanner de padrões conhecidos deixa no ar precisamente o tipo de caminho que o estudo mapeou.

Autor da série de livros "Engenharia de Software Assistida por IA" (disponível na Amazon).

Aprofunde-se no tema de forma estruturada — supervisão, auditoria e o que o sistema (e o agente) realmente expõe — pode consultar a série "Engenharia de Software Assistida por IA" clicando na imagem abaixo:

• ✅ Cupom de 30% OFF: LEIA30.

• ✅ Disponível também no Kindle Unlimited.

https://livro-engenharia-de-software-assistida-por-ia.aspepper.workers.dev/?utm_source=hashnode&utm_medium=article&utm_campaign=serie_ia

Fontes consultadas

• Anthropic Research: Using Claude to reduce the attack surface of code (20 out. 2026), de Chris Rohlf.

• The Next Web: Anthropic set Claude on 25 open-source projects and it found 493 flaws (2026).

• ExplainX: Claude Attack Surface Reduction: 493 Issues in 25 Projects (2026).

• Winzheng: Anthropic Uses Claude to Audit 5 Million Lines of Code (2026).

• Anthropic Research: Sandboxing for Claude Code (2025).

• Simon Willison's Weblog: entradas sobre contenção de agentes e a "trifecta letal" (2026).

• OWASP: Secure Coding with AI Cheat Sheet.

• Empirical Software Engineering: estudos sobre segurança em código gerado por LLMs (2025-2026).

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #Seguranca #AttackSurface #Auditoria #EngenhariaDeSoftwareAssistidaPorIA