Relatórios de vulnerabilidade já não são mais especiais

• Na manutenção de código aberto, issues e PRs em geral podem ser tratados de forma opcional, mas no passado os relatórios de vulnerabilidade eram uma exceção que exigia resposta separada para proteger os usuários
• Essa condição excepcional oferecia insights raros e confidencialidade, dando aos pesquisadores a chance de corrigir antes dos atacantes, e os projetos retribuíam com respostas rápidas, investigação, compartilhamento de progresso e crédito
• Em 2026, tanto mantenedores quanto atacantes podem executar LLMs, então o gargalo deixa de ser encontrar possíveis problemas e passa a ser a triagem de vulnerabilidades reais
• Pesquisadores externos sem relação de confiança têm dificuldade para contribuir de forma significativa nessa triagem, e a relação sinal-ruído entre revisar saídas de LLM e revisar a caixa de entrada de security@ fica parecida
• O tempo dos mantenedores deve ser gasto menos em responder aos relatórios em si e mais em classificação, correções rápidas e prevenção, além de ser necessário encontrar formas de executar análises com LLM no CI

---

Por que relatórios de vulnerabilidade eram uma exceção

• Mantenedores de código aberto que trabalham em público costumam tratar issues, PRs e feedback como presentes, podendo aceitá-los, ignorá-los ou usar apenas uma parte conforme a necessidade
• No passado, os relatórios de vulnerabilidade eram um caso especial que fugia desse princípio
  • Em vez de divulgar imediatamente, pesquisadores de segurança escolhiam o relato privado para dar ao projeto tempo para corrigir primeiro
  • A expectativa comum era que o projeto confirmasse rapidamente o relatório, investigasse, compartilhasse o andamento com quem reportou e, ao final, desse crédito pela descoberta
• Essas expectativas partiam da premissa de que quem reportava não era alguém exigindo correção de bug ou implementação de recurso, mas alguém prestando um serviço ao projeto
  • O valor central era o insight e a confidencialidade, que permitiam distribuir a correção antes que atacantes publicassem um exploit
  • Ignorar um relatório de vulnerabilidade era visto como um sinal de que o projeto não se importava com a segurança dos usuários

A premissa que desmoronou em 2026

• Em 2026, ficou difícil sustentar a premissa que tornava relatórios de vulnerabilidade algo especial
  • LLMs são quase tão bons quanto praticamente qualquer pesquisador de segurança, e qualquer pessoa pode executá-los
  • Os mesmos instrumentos podem ser usados tanto por mantenedores quanto por atacantes
• O que falta não é a capacidade de encontrar problemas potenciais, mas o trabalho de classificação para distinguir quais deles são vulnerabilidades reais
• Pesquisadores externos sem uma relação de confiança prévia têm dificuldade para contribuir de forma significativa nesse processo de classificação
  • A relação sinal-ruído entre revisar resultados de LLM e vasculhar a caixa de entrada de security@ é praticamente a mesma
• A importância de confidencialidade, embargo e coordenação também diminui em relação ao passado
  • Atacantes não precisam esperar uma divulgação pública completa; podem perguntar sobre vulnerabilidades ao seu próprio LLM
  • Ainda assim, é provável que atacantes também enfrentem o mesmo gargalo de classificação dos defensores

Mudança de prioridade para mantenedores

• O período em que relatórios de vulnerabilidade eram especiais pode ter acabado
• O mais importante agora é classificação, correção rápida e prevenção
• É preciso encontrar maneiras de executar análises com LLM no CI
• Esta posição não é a visão oficial da equipe de segurança do Go, mas a opinião pessoal de um ex-líder da equipe de segurança do Go
• Quando o tratamento de relatórios de vulnerabilidade entra em conflito com a aplicação do Code of Conduct, não existe resposta certa
  • É preciso julgar com base na gravidade da conduta, se é uma questão privada ou algo que afeta a comunidade, e nos recursos da equipe que cuida de security@
• As práticas de divulgação pública têm uma história complexa
  • No passado, pesquisadores bem-intencionados chegaram a enfrentar ameaças legais ou processos criminais
  • Na realidade do código aberto em 2026, não há pesquisadores temendo processo criminal por causa de relatórios de vulnerabilidade, e projetos também não devem insinuar processos como alternativa a uma política de reporte documentada
• A suspensão por um mês do canal de relatórios de vulnerabilidade do curl pareceu excessiva à primeira vista, mas já não está claro se responder a relatórios de vulnerabilidade ainda é o melhor uso do tempo para proteger usuários

[GN⁺]

Comentários no Lobste.rs

• Acho que a divulgação precipitada de vulnerabilidades ainda ajuda muito mais os atacantes do que os defensores. Pela minha experiência direta, mesmo usando modelos de ponta, a taxa de falsos positivos às vezes chega perto de 90%
  Além disso, vi a frase “a manutenção e o desenvolvimento sustentáveis de protocolos criptográficos de código aberto são importantes para a ampla adoção da tecnologia blockchain”, e me surpreende que ainda exista gente que acredite em tecnologia blockchain

  • Eu também fiquei confuso sobre por que aquela frase estava ali, mas descobri que era uma mensagem enviada por um dos patrocinadores do Fillippo
    Neste momento, a contribuição mais valiosa que a tecnologia blockchain talvez tenha dado ao mundo seja criar incentivos financeiros fortes para produzir implementações de protocolos criptográficos realmente seguras. Parte disso pode acabar sendo útil para todo mundo também
  • Fiquei curioso sobre o que significa falso positivo aqui. Quer dizer que o modelo afirmou ter encontrado uma vulnerabilidade, mas quando foram verificar não era um problema?
    A esta altura eu achava que encontrar vulnerabilidades e entender código em geral já estivesse bem estabelecido como algo em que LLMs são bons, então queria saber se isso corresponde à realidade. Seria bom se você pudesse explicar um pouco mais do que viu na prática ou indicar algum material de referência. Como eu não uso LLMs, é difícil ter noção do nível atual, então estou sinceramente curioso para saber se preciso rever minhas premissas

• Relatos de vulnerabilidade especiais devem ser tratados como especiais, e o lado defensor precisa criar formas melhores de validação e modelos de ameaça públicos. Assim, as pessoas podem cumprir e verificar padrões mais altos para que um relatório seja reconhecido como excelente

  • No fim, isso talvez seja mesmo onde vamos parar. Em geral, relatórios de vulnerabilidade não são especiais, mas alguns relatórios de alta gravidade ou alta confiabilidade devem ser considerados relatórios especiais

• Concordo que ficou mais fácil encontrar problemas de segurança e que a barreira de entrada diminuiu, então provavelmente há mais ruído nas listas de e-mail de segurança do que antes. Mesmo assim, eu ainda colocaria claramente como prioridade relatórios de bugs de consultorias de segurança com boa reputação como Trail of Bits ou Zellic
  Não só por confiar que eles não enviariam relatórios fracos, mas porque considero a combinação de pesquisadores de segurança de alto nível com LLMs melhor do que simplesmente rodar LLMs no CI

  • Trabalhei recentemente com fornecedores desse tipo, e relatórios fracos ainda aparecem. A qualidade dos relatórios é só mais alta em média
    LLMs podem interpretar errado o modelo de ameaça, independentemente de quem os esteja conduzindo, e podem ser preguiçosos na forma de demonstrar um “exploit”. Se o pesquisador de segurança deixar esses erros passarem, eles acabam chegando até nós, mantenedores. O containerd recebeu relatórios fracos desses fornecedores, de empresas de pesquisa com LLMs, de empresas de modelos de base já conhecidas e também de J Random User da internet
    Outra dificuldade sobre a qual o Filippo não falou o suficiente aqui é a de relatórios duplicados. Se você olhar os advisories recentes do containerd, dá para ver que outro grande problema na triagem e na distribuição de atenção é a duplicação. Por exemplo, demos crédito a 9 pesquisadores/grupos separados, incluindo grupos respeitados como os mencionados antes. Isso mostra que (a) LLMs encontram muitos dos mesmos problemas, não importa quem as use, e (b) um relatório vindo de alguém conhecido não é necessariamente especial. Em contraste, este aqui de fato não teve relatos duplicados, então demos crédito a apenas uma pessoa, e esse relator não era alguém que conhecíamos de antemão nem com quem tínhamos relação