Linus Torvalds, criador do kernel Linux, diz que a lista de e-mail de segurança do projeto está "quase totalmente ingerenciável, com duplicação enorme devido a pessoas diferentes encontrando as mesmas coisas com as mesmas ferramentas." A causa é a pesquisa de vulnerabilidades AI-assisted produzindo uma mangueira de relatórios de baixa qualidade — mantenedores sobrecarregados passam horas triando duplicatas e falsos positivos antes de chegar a problemas reais. helpnetsecurity reportou a história em 18 de maio. A mesma dinâmica aparece no artigo da ArsTechnica desta semana sobre negócios de bug-bounty bombardeados com AI slop. Superfície diferente, mesma mecânica: as mesmas ferramentas que defensores usam para escanear seu próprio código, atacantes e caçadores de bounty usam para inundar os canais de divulgação de vulnerabilidades.
A mudança estrutural que isto representa é o colapso de sinal-para-ruído na infraestrutura de relato de vulnerabilidades. Pré-LLM, um relatório de segurança a um mantenedor era um artefato caro — alguém com habilidade gastava horas produzindo um. Mantenedores triavam por qualidade de sinal. Pós-LLM, o custo de geração caiu em ordens de magnitude enquanto o custo de revisão se manteve constante. Os fluxos de trabalho de mailing list e plataforma de bug-bounty foram projetados assumindo que a assimetria de custo favorecia o sinal; agora estão invertidos. A "duplicação devido a pessoas diferentes encontrando as mesmas coisas com as mesmas ferramentas" de Torvalds é exatamente isso — múltiplos remetentes rodando os mesmos scanners AI off-the-shelf contra o mesmo kernel e fazendo surgir os mesmos outputs, frequentemente sem entendimento suficiente para deduplicar.
Empareje isto com a cobertura de hoje sobre Synack, Lyrie, MetaBackdoor e TeamPCP. Synack reportou AI comprimindo a janela de exploit — adversários weaponizam CVEs em horas. Lyrie envia sondagem autônoma do lado defensor. MetaBackdoor mostra ataques training-time contornando defesas do lado conteúdo. TeamPCP demonstra roubo de chaves supply-chain via Trivy. O problema de ruído é a quinta camada: mesmo se ferramentas defensivas, velocidade de atacante, ameaças training-time, e integridade supply-chain fossem todas tratadas, a infraestrutura de relato em si está atualmente sendo sobrecarregada. Para builders que mantêm projetos open-source, seu canal de relato de vulnerabilidade é agora um problema de custo de triagem, não um problema de custo de descoberta.
Segunda-feira: se você mantém um projeto open-source com relato público de vulnerabilidades (security@seuprojeto.org, GitHub Security Advisories, programa HackerOne), configure um filtro de triagem que requer aos relatadores demonstrar que rodaram o exploit produzido, não apenas o output do scanner. "Mostre-me o PoC funcionando, não o achado do scanner" é o filtro mais barato. O problema da mailing list de Torvalds sugere que as normas de divulgação GPG-assinadas existentes não filtram o suficiente. Para programas bug-bounty, considere intake em camadas — créditos pagos de triagem condicionados a relatórios previamente aceitos, ou penalidades de rejeição em submissões AI-slop. A pergunta mais profunda: em que ponto a norma de divulgação de segurança open-source precisa ser redesenhada em torno da nova assimetria de custo? Torvalds chamando a lista de segurança do kernel de ingerenciável é o canário; o resto do mundo open-source baterá no mesmo muro.