Fechar o Código-Fonte Não Trava a IA. Auditar Primeiro, Sim.
Quando uma startup em rápido crescimento fechou o código para escapar aos ataques de IA, interpretou mal a ameaça. O perigo que tentava evitar pouco tem a ver com quem consegue ler o código-fonte e tudo a ver com código que nunca foi auditado. É esse raciocínio, não o caso isolado, que corre o risco de se espalhar.
Uma suposição silenciosa sustenta o parque tecnológico da maior parte das empresas: como ainda não aconteceu nada de mau, o código deve estar bem. Duas demonstrações da última década deviam pôr fim a essa ideia. Em 2016, o Cyber Grand Challenge da DARPA colocou sete sistemas autónomos num palco da DEF CON e fê-los encontrar, provar e corrigir vulnerabilidades em binários compilados, sem código-fonte e sem qualquer humano no processo. Oito anos depois, em novembro de 2024, o agente Big Sleep, da Google, encontrou uma falha de segurança de memória até então desconhecida e explorável no SQLite, que os seus investigadores classificaram como a primeira descoberta deste tipo feita por um agente de IA em software real. Nenhum dos dois resultados é uma promessa para o futuro: ambos já aconteceram.
O que se segue é previsão, e assinalo-o como tal. O custo de apontar esta capacidade a código antigo e nunca auditado está a cair para perto de zero. Aplicações web legadas, routers impossíveis de atualizar, firmware de dispositivos IoT, controladores industriais, até microcódigo: tudo o que continua a funcionar sem ser tocado há anos, simplesmente porque ninguém teve motivo para lá olhar. Agora olhar ficou barato, e uma década de risco acumulado e nunca examinado começa a parecer algo que um atacante motivado consegue percorrer em dias, não em anos.
A reação inicial, pelo menos num caso visível, foi transformar a própria abertura do código na ameaça. Se os atacantes conseguem apontar um modelo a todos os repositórios públicos e colher falhas em escala, argumenta-se, então a visibilidade é que é a superfície de ataque, logo há que fechar as portas. Foi exatamente isso que fez a Cal.com, que fechou o seu código comercial depois de o seu diretor executivo argumentar que os atacantes de IA exploram a transparência do código-fonte. Por agora lê-se como um caso isolado, não como uma tendência. O receio é compreensível, mas o problema está no raciocínio, porque é o raciocínio, e não a empresa em si, que outros negócios estão prestes a copiar.
Esconder o código-fonte protege mesmo contra atacantes de IA?
Comece-se pelo mecanismo. Um atacante precisa de comportamento que consiga sondar, e o código-fonte é apenas o caminho mais rápido para compreender esse comportamento. Binários fechados descompilam-se. Imagens de firmware desmontam-se e emulam-se. Ferramentas de fuzzing disparam milhões de entradas malformadas contra um serviço em funcionamento e registam o que falha, sem nunca ver uma única linha de código-fonte. A investigação de vulnerabilidades é anterior ao código aberto e passou décadas a trabalhar às cegas contra sistemas proprietários, por isso o que a IA muda é o alcance desse ofício mais antigo, e esse alcance estende-se sobretudo a binários e firmware, não apenas a repositórios públicos.
Vale reconhecer a versão honesta do argumento a favor do código fechado, porque é real: a obscuridade aumenta, de facto, o custo marginal para o atacante. Ler código-fonte é mais rápido e mais limpo do que reconstruir a lógica a partir de um descompilador ou inferi-la a partir de uma pilha de falhas produzidas por fuzzing, por isso, para um bypass de autenticação ou uma falha de injeção, retirar o acesso ao código-fonte compra, de facto, um verdadeiro prémio de tempo. Duas coisas estragam a troca. O prémio não para de encolher à medida que os modelos melhoram na análise de binários e firmware, exatamente a fronteira que o Cyber Grand Challenge da DARPA já demarcava em 2016, quando o sistema vencedor trabalhava diretamente sobre binários compilados, sem qualquer código-fonte. E paga-se esse prémio afastando os investigadores bem-intencionados que poderiam ter chegado à falha antes de um atacante o fazer, o que significa que o atraso comprado é precisamente o único bem de que um parque tecnológico ainda por auditar já tem em excesso.
Assim, fechar o código-fonte retira uma conveniência ao atacante, mas abdica de algo real para quem defende: os muitos olhos. Código aberto é código auditável e, quando o auditor pode ser um modelo a correr em escala, o valor defensivo de um código legível aumenta, em vez de diminuir. A troca elimina um risco que já estava a encolher e cria outro que está a crescer.
A variável sobre a qual todos discutem, a visibilidade, não é, de todo, a exposição. A exposição está em o código nunca ter sido auditado. Um repositório privado cheio de falhas nunca examinadas está quase tão vulnerável como um público, exceto pela hipótese de um investigador bem-intencionado chegar à falha antes de um atacante mal-intencionado.
A capacidade é simétrica, por isso a velocidade é a única vantagem
Eis a parte incómoda. A deteção de vulnerabilidades assistida por IA não escolhe lados. O mesmo modelo que revela a falha na árvore de dependências de uma empresa revela-a também a quem primeiro o apontar para lá, pelo que o panorama estratégico se resume a uma única alavanca: o tempo. A vantagem duradoura pertence a quem auditar primeiro um sistema, porque a primeira análise competente transforma um risco desconhecido em correção ou em exploração, consoante quem está ao teclado no momento em que a falha é encontrada.
É por isso que adiar é a opção cara. Tratar a auditoria adversarial por IA como algo a contratar no próximo ciclo orçamental parte, silenciosamente, do princípio de que o adversário segue o mesmo calendário, e não segue. A postura sensata é correr já a auditoria sobre o próprio código, as próprias dependências e os próprios dispositivos ligados, partindo do princípio de que alguém o pode fazer e, mais cedo ou mais tarde, fará. Ajudamos clientes a integrar exatamente este tipo de garantia com supervisão humana na forma como os sistemas agénticos são concebidos e operados, porque é a auditoria que faz a defesa, e nenhuma política sobre o código-fonte a substitui.
E se não for possível auditar tudo?
Correr a auditoria primeiro pressupõe que isso é possível, e muitas organizações não conseguem. Se uma empresa tem quatrocentas imagens de firmware que nunca vai reconstruir, ou uma frota de equipamentos cujos fabricantes já desapareceram, uma corrida decidida pelo tempo é uma corrida que se perde nalgumas frentes antes sequer de começar, e fingir o contrário é como o teatro de segurança consegue orçamento.
Por isso, a triagem tem de ser honesta. Ordenar por alcance multiplicado pelo raio de impacto, não pelo desconforto que cada sistema provoca. Tudo o que está exposto à internet, ou a um salto de distância da autenticação, vai para a frente da fila, porque é também aí que chega primeiro a análise de um atacante. Para o que não se consegue corrigir, é preciso abandonar a ideia de que aplicar patches é o único controlo disponível: isolar esses dispositivos em segmentos que não alcancem a internet nem os ativos mais valiosos, filtrar o tráfego de saída e instrumentá-los, para que uma exploração que não se conseguiu evitar seja, pelo menos, uma que se consegue ver. Algumas destas corridas vão-se perder, por isso vale a pena investir na deteção e resposta que decidem o custo real de uma corrida perdida. Onde for possível avançar primeiro, a auditoria ganha sozinha; onde não for possível, a contenção e a monitorização é que sustentam o peso, e um sincero «não conseguimos auditar isto» devia desencadear um controlo compensatório, não um encolher de ombros.
Porque não se pode avaliar isto a partir de um comunicado de um fornecedor
Nada disto significa engolir a publicidade sem questionar. Os fornecedores anunciam agora quantas falhas fundamentais um modelo afinado para segurança já encontrou, e esses totais são praticamente impossíveis de verificar de forma independente. Quando a Anthropic falou sobre as alegadas descobertas do seu modelo, só conseguiu divulgar uma fração, porque a maioria das falhas continuava por corrigir, o que torna a confirmação independente genuinamente difícil. Um número em destaque não diz quanto do trabalho foi feito pelo modelo e quanto foi feito pelos humanos que o orientaram, nem se as falhas eram reais, inéditas ou sequer exploráveis na prática. Em vez disso, deve exigir-se uma metodologia, uma amostra reproduzível de descobertas e prova de que foi o modelo, e não o analista, a fazer a descoberta. Quem avalia a capacidade pelo comunicado de imprensa está a pagar por uma história, um cuidado que vale a pena aplicar a todos os discursos de vendas de IA de segurança que aparecerem este ano.
Como é, na prática, o parque tecnológico das empresas
A vaga de divulgações críticas não vai cair de forma uniforme. Vai concentrar-se nos sistemas que ninguém quer tocar: o firmware de um dispositivo lançado em 2014 que nunca mais vai ser atualizado, o serviço interno cujo autor saiu da empresa há três reestruturações, a dependência enterrada seis níveis abaixo num lockfile. As equipas de engenharia, já reduzidas pelo mesmo aperto de custos que abandonou estes sistemas à sua sorte, herdam um fosso de auditoria cada vez maior com cada vez menos mãos para o fechar.
O problema em si não é novo, o que mudou foi apenas o preço. As falhas latentes sempre ficaram anos por tocar até um investigador as tornar práticas, tal como Dan Kaminsky transformou fragilidades conhecidas de envenenamento de cache de DNS num ataque demonstravelmente prático, em muitas implementações ao mesmo tempo. O que a IA faz a este processo de descoberta é o que a linha de montagem fez à indústria: industrializa-o.
Tirando o debate entre código aberto e fechado, a instrução é simples. Fazer o inventário de tudo o que está em produção, incluindo o firmware e as dependências que nunca foram lidas. Apontar o mesmo tipo de ferramentas que um atacante usaria contra o próprio parque tecnológico, sob controlo humano, e corrigir o que aparecer antes que outro o faça primeiro. A questão do código aberto contra o fechado é um debate de política que se pode ter com calma; a auditoria é a parte que decide se a empresa continua de pé. Vale a pena integrar isto na estratégia tecnológica da empresa agora, enquanto encontrar as próprias falhas primeiro ainda é uma vantagem disponível.
Perguntas frequentes
O código aberto é menos seguro do que o fechado agora que a IA consegue analisar código?
Não de forma linear. Os atacantes continuam a conseguir extrair vulnerabilidades de binários e firmware fechados através de descompilação, fuzzing e emulação, por isso esconder o código-fonte aumenta o custo do ataque e compra tempo, mas não elimina a exposição. A exposição é o código não auditado, e o código aberto pelo menos mantém-no legível para as ferramentas defensivas e os investigadores que possam chegar à falha primeiro.
Como começar uma auditoria de segurança de código com IA no próprio parque tecnológico?
Comece por um inventário que inclua as dependências e qualquer firmware de dispositivos ligados, porque é aí que se concentram as falhas nunca tocadas. Depois, corra a deteção adversarial de vulnerabilidades sobre o próprio parque tecnológico, com supervisão humana, dando prioridade aos sistemas expostos à internet ou próximos da autenticação, e trate qualquer descoberta como algo a corrigir antes que seja divulgada noutro lugar. Onde um sistema realmente não puder ser corrigido, opte por conter e monitorizar.
Posso confiar no número de falhas que um fornecedor diz que o seu modelo de segurança encontrou?
Não apenas com base no número em destaque. Muitos desses totais são impossíveis de verificar de forma independente e não se pode atribuir o mérito ao modelo em vez de aos investigadores que o orientaram. Peça uma metodologia reproduzível, uma amostra das descobertas reais e prova de que foi o modelo a fazer a descoberta antes de avaliar a capacidade.
Relacionado
- O Prêmio da Soberania: por que a IA soberana corporativa está vencendo pelo acesso, não pela velocidade
- Washington Classificou o Seu Próprio Laboratório de IA Como Risco de Segurança Nacional. Isto Muda o Sentido da Dependência de um Fornecedor de IA
- Porque falham os pilotos de IA nas empresas: o problema é a confiança, não a capacidade
- Security & Trust
Escrito por uma persona editorial de IA do sistema editorial proprietário da Abyshire e revisto pela nossa equipa.