Resumo

  • A captura do índice oficial da EEF em 30 de outubro mostra 370 CVEs com data de publicação em 2026 e nove em 2025. São cerca de 41 vezes mais registros, sem que a lista conte correções ou atribua as descobertas à IA.
  • Alistair Woodman projetou mais de 500 CVEs em 2026 e pediu às empresas usuárias que financiem a segurança dos pacotes. Ele disse que duas pessoas faziam a maior parte do trabalho com CVEs na equipe da CNA da EEF.

Alistair Woodman terminou sua apresentação no RIPE 93 com um pedido para as empresas que usam Elixir, Erlang e Gleam: ajudem a pagar o trabalho de segurança do ecossistema. Três dias depois, o índice público da Erlang Ecosystem Foundation (EEF) listava 370 registros de CVE datados de 2026. A pergunta que esse contador deixa pendurada é mais concreta que a próxima meta de descoberta: quando chega a versão corrigida?

Às 08:59 UTC de 30 de outubro, a lista continha 370 registros publicados em 2026 e nove com data de 2025. A proporção é de cerca de 41 para um. O dado conta publicações, não pacotes reparados. O índice não traz, para cada CVE, a versão que corrige a falha nem quanto tempo levou para a correção ser verificada. A coluna que falta muda o sentido do placar.

Woodman havia apresentado outro número em 27 de outubro, no grupo de trabalho de Segurança do RIPE 93. Segundo sua estimativa, a EEF cobre cerca de 20 mil pacotes de Elixir, Erlang e Gleam, usados regularmente por aproximadamente 100 mil pessoas e por pelo menos 5 mil empresas conhecidas pela fundação. Ele esperava mais de 500 CVEs em 2026, contra cerca de dez no ano anterior, e descreveu o salto como superior a cinquenta vezes na carga de trabalho. Essa era a previsão dele. O índice mostra a contagem publicada até três dias depois: as duas cifras medem coisas diferentes.

Woodman disse que as vulnerabilidades já existiam e que a análise assistida por IA tornou mais fácil encontrá-las. Encontrar o problema é só a entrada. Alguém ainda precisa entender o pacote, confirmar o defeito, mudar o código, publicar uma versão e verificar se a correção resolveu o caso.

Foi aí que a fala saiu do contador e chegou às pessoas. Woodman descreveu cinco responsáveis principais no trabalho da CNA da EEF; duas pessoas faziam a maior parte da atividade com CVEs e da pesquisa sobre IA. A fundação está testando agrupar descobertas por projeto, para que mantenedores possam reservar um período e tratar vários problemas de uma vez. O objetivo é reduzir a sucessão de interrupções que transforma cada novo aviso em mais um chamado para quem já sustenta o código.

A política pública da EEF marca prazos para receber e avaliar relatos: confirmação em até dois dias úteis e avaliação nos dois dias úteis seguintes. Para relatos não públicos sobre pacotes Hex cobertos pela CNA, se o mantenedor não responde em 14 dias, a política prevê que a EEF prossiga com a publicação. A divulgação coordenada pode durar até três meses. Há relógios para a entrada e para a publicação; o índice não mostra o tempo até o reparo chegar a uma versão.

Essa diferença importa para empresas que dependem de bibliotecas abertas. Uma CVE ajuda a identificar o problema. Para saber se o risco diminuiu, é preciso seguir o pacote afetado até a primeira versão corrigida e depois conferir qual versão o serviço realmente executa. A base pública da EEF registra identificador, título, detalhes e datas de publicação ou atualização. Não oferece esse percurso até o reparo.

O pedido de Woodman ganha seu peso aqui: milhares de organizações se beneficiam dos pacotes, enquanto um grupo pequeno carrega boa parte da pesquisa e da resposta. Uma CVE publicada põe o alerta na mesa. Uma correção lançada e adotada muda o software que está em produção. A EEF já torna visível a primeira etapa; a próxima contagem útil é a que liga o aviso à versão corrigida.

Fontes: sessão do RIPE 93; transcrição oficial; páginas da EEF sobre a CNA, o escopo, a política de segurança e o índice CVE; conselho da EEF.