A IA está quebrando duas culturas de vulnerabilidades

• Após a divulgação do Copy Fail, Hyunwoo Kim considerou que a correção existente não era suficiente e compartilhou um patch no mesmo dia, mas o procedimento ao estilo Linux de correções públicas discretas foi exposto por uma descoberta externa, levando ao fim do embargo
• No Linux, especialmente na área de redes, existe a prática de compartilhar o impacto de segurança em uma lista privada e corrigir o bug publicamente e com rapidez, tentando manter em embargo por alguns dias a existência real da vulnerabilidade
• Depois que outra pessoa descobriu a mudança pública, identificou o impacto de segurança e a divulgou, os detalhes completos foram publicados em seguida
• À medida que a IA reduz o custo de avaliar o significado de segurança de cada commit, fica mais fácil encontrar vulnerabilidades em correções discretamente públicas, e a relação sinal-ruído também melhora
• A divulgação coordenada tradicional de 90 dias também está enfraquecendo; neste caso, apenas 9 horas após Kim relatar a vulnerabilidade ESP, Kuan-Ting Chen também a relatou de forma independente, sugerindo que embargos muito curtos podem ser um caminho melhor

---

O choque entre o Copy Fail e a prática de correções de segurança no Linux

• Após a divulgação da vulnerabilidade Copy Fail, Hyunwoo Kim concluiu que a correção existente não era suficiente e compartilhou um patch no mesmo dia
• Kim seguiu um procedimento comum no Linux, especialmente na área de redes
  • compartilhou o impacto de segurança em uma lista privada de engenheiros de segurança do Linux
  • a correção do bug foi conduzida de forma pública, discreta e rápida
  • a intenção era manter em embargo por alguns dias a existência de uma vulnerabilidade grave enquanto apenas a correção em si estava pública
• Depois que outra pessoa descobriu essa mudança, identificou o impacto de segurança e o divulgou
• Como a vulnerabilidade passou a ser considerada já pública, o embargo terminou, e então os detalhes completos foram publicados

A pressão que a IA cria sobre duas culturas de vulnerabilidades

• Cultura de divulgação coordenada

  • Ao encontrar um bug de segurança, ele é informado em particular aos mantenedores, que normalmente recebem um prazo como 90 dias para corrigi-lo
  • O objetivo é fazer com que a correção seja distribuída antes que a vulnerabilidade se torne conhecida

• Cultura de “bug é bug”

  • É uma abordagem especialmente comum no Linux, baseada na premissa de que, se o kernel faz algo que não deveria, alguém pode transformar isso em um ataque
  • Corrige-se o problema o mais rápido possível sem chamar atenção para o fato de ser uma vulnerabilidade
  • Em meio a muitas mudanças acontecendo, espera-se que as pessoas talvez não percebam, deixando tempo para aplicar patches nos sistemas nesse intervalo

• O risco do modelo de correções públicas cresce com a IA

  • Esse modelo nunca funcionou perfeitamente, mas se torna um problema maior à medida que a IA fica melhor em descobrir vulnerabilidades
  • Como há muitas correções de segurança saindo, revisar commits ficou mais atraente, e a relação sinal-ruído aumentou
  • O custo para a IA avaliar cada commit conforme ele aparece está caindo cada vez mais, e sua eficácia está aumentando

• Embargos longos também estão enfraquecendo

  • No passado, como a detecção era lenta, relatar ao fornecedor e abrir uma janela de divulgação de 90 dias significava que era improvável que outra pessoa descobrisse no meio do caminho
  • Agora, grupos apoiados por IA fazem varreduras em massa por vulnerabilidades de software, o que enfraquece essa premissa
  • Neste caso, apenas 9 horas após Kim relatar a vulnerabilidade ESP, Kuan-Ting Chen também a relatou de forma independente
  • Embargos podem criar uma falsa sensação de não urgência e aumentar o risco ao limitar os agentes que poderiam corrigir a falha

• Possíveis caminhos e um teste simples com modelos

  • A solução não é clara, mas embargos muito curtos parecem ser uma boa abordagem e talvez precisem ficar ainda mais curtos com o tempo
  • A IA pode acelerar não só atacantes, mas também defensores, tornando viáveis embargos que antes seriam curtos demais para serem úteis
  • Quando receberam o commit f4c50a403, Gemini 3.1 Pro, ChatGPT-Thinking 5.5 e Claude Opus 4.7 identificaram imediatamente que se tratava de um patch de segurança
  • Quando receberam apenas o diff, sem o contexto do commit, o Gemini teve certeza de que era uma correção de segurança, o GPT considerou isso bastante provável, e o Claude achou mais provável que não fosse
  • Esse teste foi um exemplo muito rápido, executando cada modelo uma vez com o prompt "Without searching, does this look like a security patch?", e é difícil atribuir grande significado à comparação entre os modelos

[fastkoder]

Entre um embargo muito curto e um embargo longo, como inevitavelmente teremos de optar por um “embargo muito curto”, os agentes de IA responsáveis por segurança vão ficar ainda mais ocupados.

[GN⁺]

Comentários do Hacker News

• Essa mudança já vinha sendo anunciada há muito tempo, e as fissuras que vemos agora eram previsíveis bem antes de sabermos o que era um LLM
  O catalisador é o aumento da transparência de software. A adoção de open source e de software com código-fonte disponível cresceu muito, e as ferramentas de engenharia reversa e descompilação também melhoraram bastante. Já faz mais de 10 anos que passou a era em que um software fechado comum de prateleira ficava de forma significativa oculto de atacantes sérios
  Desde o BinDiff, esse problema vem avançando lentamente. Quando você aplica um patch em um software, inevitavelmente acaba divulgando também a vulnerabilidade. Até agora, todos negavam isso porque era preciso algum nível de especialização para perceber que patch equivalia a divulgação de vulnerabilidade, mas a IA acabou com essa desculpa
  Agora, toda vez que algo é mesclado ao Linux mainline, várias organizações estão colocando o diff em um prompt de LLM, avaliando agressivamente se é uma correção de vulnerabilidade e gerando guias de exploração. A maioria dos grandes projetos open source, como nginx, OpenSSL e Postgres, em breve também será tratada assim
  As práticas de divulgação coordenada não foram feitas para esse ambiente e, na verdade, eu diria que já não serviam para ele há 10 anos
  Curiosamente, isso não me incomoda tanto, porque vejo as práticas de divulgação coordenada como algo que sempre aceitou sem questionamento a premissa de que é melhor adiar a divulgação pela conveniência operacional dos administradores de sistema. Há motivos para duvidar dessa premissa. Adiar a divulgação simplesmente retira informação até mesmo de operadores de sistemas que têm opções além de apenas aplicar o patch

  • A observação de que “já faz mais de 10 anos que passou a era em que um software fechado comum de prateleira ficava de forma significativa oculto de atacantes sérios” é quase óbvia, mas a última linha de defesa é não distribuir o software publicamente e depender de uma arquitetura cliente-servidor
    Se vulnerabilidades ficarem mais fáceis de detectar e explorar, esse modelo pode se tornar mais comum. Claro, isso nem sempre é possível
    Nos últimos 11 anos, foi bem irritante ver binários de clientes de jogo ofuscados com ProGuard serem descompilados várias vezes e enviados ao GitHub. Só o código de servidor que não foi distribuído permaneceu privado
    Curiosamente, até começarmos a mudar o protocolo de rede com menos frequência do que semanalmente, não havia problema com atacantes fazendo engenharia reversa disso. Agora, com apoio de LLM, parece que eles também conseguirão acompanhar esse ritmo
  • Sempre entendi o motivo comercial por trás da divulgação coordenada de vulnerabilidades, e no trabalho eu não tinha escolha além de seguir essa política, mas pessoalmente sempre fui a favor da divulgação completa. Eu vinha esperando muito por essa mudança

• Isso parece menos um problema novo causado por IA e mais um problema antigo reembalado como problema de IA
  Muito antes dos LLMs existirem, as pessoas já comparavam diffs de commits do kernel para descobrir quais eram correções de segurança. No momento em que um patch é publicado abertamente, a corrida na prática já começou
  Nem tenho certeza de que reduzir o período de embargo realmente ajude. Organizações capazes de aplicar patches em poucas horas já estão bem; as demais ainda levam dias ou semanas
  Na verdade, quanto menor o custo de gerar exploits, maior a chance de a divulgação coordenada se tornar não menos importante, mas mais importante

  • “As pessoas já comparavam diffs de commits do kernel para descobrir quais eram correções de segurança”, mas isso exigia habilidade e normalmente não era feito de forma consistente ou sistemática. Com IA, qualquer um pode fazer isso em qualquer software
    Sobre “não tenho certeza de que reduzir o período de embargo ajude”, a questão é por que 90 dias e não 2 anos. O argumento do texto é que, com o aumento da frequência de descoberta simultânea, mudaram os fatores que definiam esse equilíbrio. Se várias pessoas fora do embargo vão encontrar exploits de qualquer forma, então o período de embargo não passa de uma ilusão, não de uma janela real
    Concordo que “a geração barata de exploits torna a divulgação coordenada mais importante”. Mas, ao mesmo tempo, isso a torna menos viável. Se até script kiddies conseguem encontrar e explorar zero-days, a capacidade de coordenar entra em colapso
    A cultura white hat sempre teve uma espécie de ética de guilda artesanal. Se essa guilda se desfaz, essa ética também perde o lugar
  • Não acompanhei todo o desenvolvimento do Linux de ponta a ponta, mas não sei se já houve no passado um caso em que um exploit funcional foi divulgado na mailing list antes mesmo de o patch entrar no kernel
    Nunca vi isso e, mesmo considerando o tom um pouco exagerado, agora fico com a impressão de que esse tipo de coisa vai acontecer com frequência graças aos LLMs
  • Torvalds disse que, quando um problema importante é encontrado, não é preciso todo o tumulto que vem depois; basta divulgar o próprio bug [1]
    Por isso, não surpreende que o Dirtyfrag tenha sido divulgado como uma correção no kernel Linux [2]
    [1] https://www.zdnet.com/article/torvalds-criticises-the-securi...
    [2] https://afflicted.sh/blog/posts/copy-fail-2.html
  • Faz sentido ver isso como um problema antigo agravado pela IA
  • Como parece que toda semana estou escrevendo uma variação da mesma coisa, se me permitirem a preguiça vou compartilhar uma versão que escrevi antes
    https://news.ycombinator.com/item?id=47921829

• Temos um grande problema
  Os Estados Unidos estão em guerra, e boa parte do mundo também está vivendo uma guerra em nível de ataques cibernéticos. Isso vale para EUA, UE, grande parte do Oriente Médio, Israel e Rússia
  Serviços importantes como Ubuntu, GitHub, Let’s Encrypt e Stryker foram atacados e ficaram fora do ar por dias, e sistemas hospitalares inteiros também foram parcialmente interrompidos
  Nesse cenário, a IA tornou a geração de ataques muito mais rápida. Mais rápida do que a defesa consegue responder. Antes, ataques zero-day eram raros; agora viraram algo comum
  Vai piorar antes de melhorar, e talvez piore muito mais

  • Não vejo como isso pode melhorar

• A parte que diz “agora há tantas correções de segurança saindo que ficou mais atraente inspecionar commits. A relação sinal-ruído está mais alta” me faz perguntar por quê
  O ponto central é “o custo de a IA avaliar cada commit que passa está ficando cada vez mais barato e eficaz”. Com IA, cai por terra a premissa de que “há mudanças demais para que as pessoas percebam”

• Esse teste rápido não mostra tanta coisa assim. Se você pergunta diretamente “isso é um patch de segurança?”, acaba insinuando e induzindo a IA a produzir uma resposta que concorde com essa premissa
  Uma matriz de confusão seria mais útil. Claro, entendo que o texto não é um post detalhado de teste de capacidades de IA

  • Concordo que isso não serve como grande evidência adicional. Se alguém rodasse o mesmo teste em N commits daquela lista, incluindo este, eu teria muita curiosidade com o resultado
  • Idealmente, precisaríamos do coeficiente phi, ou seja, o MCC, calculado a partir de uma matriz de confusão dos resultados em que o LLM classificasse todos os diffs do kernel com sim/não
    Dá para calcular a partir do número de verdadeiros positivos, verdadeiros negativos, falsos positivos e falsos negativos

• Precisamos de ciclos automatizados de patch e release
  Até agora, dependemos de processos manuais incrivelmente lentos para receber relatos, investigar, validar, corrigir e preparar releases. É comum levar meses para soltar uma versão corrigida. Na era em que atacantes podem despejar novos exploits em poucas horas, isso é lento demais
  Para reduzir o tempo médio até o patch, é preciso melhorar iterativamente os gargalos de toda a cadeia de valor
  Depois de receber um bug report, deveríamos conseguir chegar a um produto corrigido e testável por QA em até 1 hora. Isso precisa ser padronizado ou open source, e usado por toda a cadeia de suprimento de software, do kernel Linux → distribuição → produto que usa a distribuição → usuário. Com IA, não há motivo para não fazer isso; nós é que estamos lentos

• A IA vai reduzir drasticamente a janela de atualização. Em 2026, pensar em cooldown de dependências será o pior caminho; agora precisamos pensar em aquecimento de dependências
  Em breve, a ideia de divulgar vulnerabilidades com segurança em projetos open source vai desaparecer. SaaS centralizado terá uma grande vantagem de segurança nisso

  • SaaS centralizado de código fechado terá uma grande vantagem de segurança
    Uma vulnerabilidade de execução remota de código em uma dependência open source significa que ela fica igualmente vulnerável no momento em que o patch de segurança é publicado, então não entendo por que isso seria controverso
  • Organizações que usam Linux também podem formar uma rede de confiança, em que cada uma gasta um certo custo para usar IA para escanear e corrigir continuamente suas dependências, e depois compartilha patches e resultados de varredura entre si

• A velha frase de Tony Hoare sobre “não haver bugs óbvios” versus “estar obviamente sem bugs” se aplica melhor do que nunca na era dos LLMs

• Pessoalmente, essa explicação que trata bugs simplesmente como bugs soa meio sem sentido, mas sei que no mundo Linux há muita gente que valoriza mais princípios do que questões práticas
  Ainda assim, 90 dias parecem muito tempo
  No fim, talvez as grandes empresas de IA tenham de ajudar o pessoal da infraestrutura central da internet. Rodar a IA mais nova e melhor em coisas como nginx me parece um ganho coletivo para todos nós

• A parte que diz “felizmente, a IA pode acelerar os defensores tanto quanto os atacantes aqui, tornando viáveis até embargos de divulgação que antes seriam curtos demais para servir” é um aspecto importante desse espaço de problema
  O risco de segurança pode acabar virando uma corrida armamentista sobre quem vai gastar mais em custos de token

  • O ponto interessante é que, por isso, código-fonte fechado se torna um ativo ainda maior para os defensores
    O atacante não pode gastar tokens nisso, mas o defensor pode gastar tokens em hardening com base no código-fonte. O atacante fica preso a testes de caixa-preta