Os relatos de vulnerabilidade já não são especiais
Escala e Natureza do Spam de Relatos de Vulnerabilidade
- Muitas empresas agora recebem vários relatos não solicitados por semana/dia, muitas vezes claramente gerados por IA, de baixa qualidade ou próximos de extorsão.
- Padrões comuns: problemas triviais de CSS/UI, achados “críticos” mal classificados ou relatar comportamento intencional como vulnerabilidades.
- Mantenedores e equipes de segurança relatam burnout e consideram encerrar ou restringir programas (por exemplo, banir relatos escritos por IA, exigir PoCs em vídeo, adicionar tokens ocultos no estilo “turtle123”).
Bug Bounties, Incentivos e Risco Legal
- Sugestões para desencorajar spam: pequenas taxas por relato (possivelmente não reembolsáveis), micro-pagamentos para formulários de contato ou regras rígidas.
- Preocupações: incentivos desalinhados (empresas podem rejeitar bugs válidos para evitar pagar), complexidade contábil/jurídica de manter taxas e efeitos inibidores, porque pagamentos podem desanonimizar pesquisadores e aumentar a percepção de risco de prisão.
- Alguns pesquisadores relatam ter sido ignorados ou receberem recompensa baixa mesmo por issues não triviais do tipo DoS/RCE.
Fadiga de CVE e Inferno de Dependências
- Muitos reclamam de excesso de CVEs, especialmente classificações de alta severidade para issues de baixo impacto (por exemplo, ReDoS em ferramentas de build/dev, formatos de arquivo obscuros).
- Dependabot e scanners criam grandes volumes de alertas, inclusive para dependências de desenvolvimento; equipes lutam para separar risco real de ruído.
- Contraponto: dependências de desenvolvimento e build são vetores de ataque reais (por exemplo, supply chain, exfiltração de sistemas de dev/CI), especialmente em setores regulados.
- Padrões resultantes: alguns fazem auto-merge de todas as atualizações; outros agrupam atualizações ou tentam minimizar grafos de dependências.
LLMs em Segurança: Capacidade e Limitações
- Consenso: LLMs reduzem muito o custo de encontrar muitos bugs superficiais ou baseados em padrões e também geram grandes volumes de relatos falsos ou exagerados.
- Alguns veem LLMs como estando no nível ou perto do nível de pesquisadores medianos de baixo esforço para certas classes de bugs; outros chamam essa afirmação de exagerada e insultuosa.
- Várias organizações agora usam LLMs para triagem de relatos recebidos, classificar severidade ou filtrar spam; outras propõem ferramentas agentic para auditar automaticamente e até corrigir código.
- Céticos enfatizam a inteligência “irregular”: modelos podem deixar passar bugs difíceis, alucinar issues e ainda não conseguem fornecer análise confiável do impacto na última etapa.
Os Relatos de Vulnerabilidade Ainda São Especiais?
- Um lado: vulnerabilidades continuam fundamentalmente diferentes de bugs comuns; confidencialidade e coordenação são ainda mais importantes agora que patches são mais fáceis de transformar em arma.
- Outro lado: a correlação entre “relato de segurança” e “vulnerabilidade real e impactante” colapsou, fazendo os relatos parecerem apenas mais tickets de bugs barulhentos.
- Muitos argumentam que o recurso escasso não é mais encontrar bugs, mas sim fazer triagem confiável e demonstrar impacto no mundo real.
Prática de Segurança, Métodos Formais e Cultura
- Alguns defendem avançar para linguagens seguras em termos de memória, métodos formais e raciocínio mais forte no nível da especificação; outros observam que a indecidibilidade e o alto custo limitam a verificação completa.
- Há tensão entre “segurança perfeita ou falha” e gestão pragmática de risco e defesa em profundidade.
- Vários enfatizam o papel de relações de confiança com pesquisadores conhecidos, melhores incentivos e interação mais profissional, menos adversarial, entre segurança e engenharia.
Perspectiva Futura (Incerta e Contestado)
- Uma visão: a atual “vulnpocalypse” é temporária; LLMs vão devorar bugs fáceis e depois serão integrados antes do lançamento, reduzindo relatos externos.
- Contra-visão: LLMs também vão amplificar a criação de código inseguro, e muitas organizações nunca adotarão varredura robusta antes do lançamento, então o volume e o ruído permanecerão altos.
- Alguns preveem que programas públicos de bounty vão encolher ou fechar por causa de slop, empurrando o trabalho de segurança para redes de confiança e programas internos ou curados.