Agentes de IA baseados no GLM-5.3, modelo da chinesa Z.ai, varreram o código do kernel do Linux e apontaram mais de mil vulnerabilidades no ciclo do Linux 7.2 em relação ao 7.1. O número parece uma boa notícia de segurança. Para quem mantém o projeto, é também um problema novo.
A escala mudou de patamar
O kernel do Linux passa de 40 milhões de linhas de código. Historicamente, cada versão registrava cerca de 500 CVEs, o identificador padrão de vulnerabilidade. Desde maio de 2024, a partir do Linux 6.9, o projeto corrigiu perto de 2 mil falhas, e o ritmo recente se aproxima de 2 mil novas vulnerabilidades por atualização. O volume praticamente triplicou.
Vale entender de onde vem esse salto. Não é que o Linux tenha ficado subitamente mais inseguro. É que a capacidade de encontrar falhas cresceu mais rápido que a capacidade de escrevê-las, e ferramentas automatizadas passaram a varrer código que ninguém revisava havia anos.
A maior parte é inofensiva, e isso é parte do problema
Segundo o levantamento, a maioria dos bugs apontados afeta drivers e recursos já considerados obsoletos, sem impacto prático para quem usa o sistema. Um relatório de falha em driver de hardware que ninguém mais fabrica não protege usuário nenhum.
Mas consome exatamente o mesmo recurso escasso que uma falha crítica: a atenção de um mantenedor humano, que precisa ler, reproduzir, julgar e responder. Linus Torvalds reconheceu que esse volume virou o novo normal do desenvolvimento do Linux e, em seguida, criticou o excesso de relatórios automáticos que soterra os desenvolvedores.
A assimetria que se instalou
Aqui está o ponto que ultrapassa o Linux. Gerar relatórios de bug com IA ficou barato e praticamente instantâneo. Avaliar relatórios de bug continua caro, lento e dependente de gente com contexto profundo do código.
Quando um dos lados de um processo escala mil vezes e o outro não escala nada, a fila estoura. E a fila que estoura é a mesma por onde precisa passar a vulnerabilidade que realmente importa. O risco não é o kernel ficar cheio de bugs conhecidos e não corrigidos: é a falha grave se perder no meio de novecentos avisos sobre drivers mortos.
O que dá para fazer
Projetos de código aberto vêm testando algumas saídas, e nenhuma delas é definitiva:
- Exigir reprodução: aceitar relatório apenas com caso de teste que dispare a falha, o que filtra achado teórico.
- Triagem também automatizada: usar IA para classificar e agrupar relatórios antes de chegarem ao humano, com o risco evidente de o filtro descartar o que importa.
- Identificar a origem: marcar relatórios gerados por ferramenta, para que a fila deles não se misture à de reportes humanos.
- Patch junto com o relatório: se a IA encontra a falha, que proponha a correção. Move parte do custo para quem gerou o volume.
O contexto que não dá para ignorar
Há uma leitura de segurança que fica no ar e merece ser dita sem alarmismo. A mesma capacidade que encontra mil falhas em código aberto para reportá-las encontra mil falhas para não reportar. Na semana passada, a OpenAI classificou como crítico o nível de cibersegurança do GPT-6 Astra justamente por ele conseguir localizar e explorar falhas desconhecidas de forma autônoma, e restringiu o acesso por causa disso.
A diferença entre os dois casos é de intenção, não de capacidade técnica. O código aberto tem, aqui, uma vantagem estrutural que costuma ser subestimada: quando a varredura acontece em público, o defensor enxerga o mesmo relatório que o atacante. Em software fechado, só um dos dois lados está olhando.