Quando as equipes de segurança pensam em software open source fim de vida (EOL), a conversa geralmente começa e termina no mesmo lugar: sem mais patches. Isso é verdade, mas é apenas metade da história, e argumentavelmente a metade menos perigosa. Existem dois problemas agravantes que a maioria das equipes desconhece. ## Problema Um: O Ecossistema CVE Não Investiga o Que Não Suporta Quando uma vulnerabilidade é descoberta em um projeto open source, os mantenedores determinam quais versões são afetadas e registram uma **CVE** com um intervalo afetado definido. Cada scanner de vulnerabilidade, ferramenta SBOM e feed de CVE na indústria consome esse intervalo. Se sua versão estiver fora dele, você não recebe um alerta. Não porque você está seguro, mas porque ninguém verificou. Versões EOL ficam fora desse intervalo quase por padrão. A razão é simples: é um problema de escala. Em apenas cinco anos, o número global de CVEs dobrou enquanto o número de CVEs não pontuadas aumentou 37x, de acordo com o relatório State of the Software Supply Chain 2026 da **Sonatype**. Os mantenedores já estão sobrecarregados investigando e corrigindo as versões que eles ativamente suportam, e com o volume de CVEs e o número total de lançamentos de pacotes continuando a crescer, a largura de banda investigativa necessária para cobrir linhas de lançamento mais antigas simplesmente não existe. Os mantenedores precisam ser realistas sobre até onde em sua própria história de lançamentos eles podem ir razoavelmente. A pesquisa da Sonatype nomeou explicitamente "versões EOL omitidas de avisos" como um impulsionador de falsa confiança de segurança, contribuindo para os 167.286 falsos negativos, componentes exploráveis que passaram totalmente despercebidos, que eles identificaram apenas em 2025. ### Como Isso Se Apresenta na Prática Duas vulnerabilidades críticas recentes no ecossistema Spring tornam isso concreto. **CVE-2026-22732 — Spring Security (Crítica, Março de 2026, CVSS 9.1)** Esta vulnerabilidade faz com que cabeçalhos de resposta de segurança, incluindo `Cache-Control`, `X-Frame-Options`, `Strict-Transport-Security` e `Content-Security-Policy`, sejam silenciosamente descartados em certas configurações de aplicativos servlet. O intervalo afetado oficial cobre Spring Security 5.7.x a 7.0.x. Spring Security 6.2.x não está listado. Ele atingiu o EOL em dezembro de 2025. Spring Boot 3.2 vem com Spring Security 6.2. Qualquer organização executando Boot 3.2, uma versão menor atrás do intervalo listado, não recebe nenhum sinal do scanner. **HeroDevs** confirmou que Spring Security 6.2.x é afetado e fez backport de uma correção para clientes NES. O registro CVE upstream não reflete isso. ### Com Que Frequência Isso Acontece? Os exemplos do Spring acima não são exceções. Eles refletem um padrão que a HeroDevs encontra consistentemente em sua prática de Never-Ending-Support. Quando um novo CVE é divulgado em um pacote suportado, a HeroDevs descobre que precisa corrigir uma versão EOL que o registro CVE oficial não lista como afetada **aproximadamente 80% das vezes**. O raio de explosão de qualquer vulnerabilidade dada é sistematicamente mais amplo do que o registro mostra. Colocando de forma simples: para quatro em cada cinco CVEs divulgados em uma versão suportada, há uma probabilidade razoável de que uma versão EOL que você está executando também seja afetada, e nenhum scanner no mundo lhe dirá isso. ## Problema Dois: A Indústria Está Contando o Software EOL Errado A lacuna de investigação de CVE acima se aplica a software EOL que a comunidade realmente sabe que é EOL. Isso acaba sendo uma fração muito pequena do problema real. A fonte de dados EOL mais citada é [endoflife.date](http://endoflife.date/), que rastreia aproximadamente 350 projetos ativamente mantidos; frameworks e runtimes importantes onde os mantenedores publicaram explicitamente datas de fim de vida. Em todos esses 350 projetos, aproximadamente 7.000 versões de pacotes específicas são identificadas como EOL. Esse é o universo com o qual a maioria dos scanners e equipes de segurança está trabalhando. Aqui está a escala real do problema. No relatório State of the Software Supply Chain 2026 da Sonatype, produzido em parceria com a HeroDevs, os dados contam uma história diferente. Analisando o status do ciclo de vida em 12 milhões de versões de pacotes abrangendo npm, PyPI, Maven, NuGet, RubyGems, Go, Packagist e crates.io, a HeroDevs descobriu que **5,4 milhões dessas versões estão fim de vida**. No entanto, a fonte pública mais completa da indústria (endoflife.date) responde por apenas cerca de 7.000 delas. A divisão por ecossistema é impressionante. Aproximadamente 25% das versões de pacotes npm estão EOL. NuGet está em cerca de 18%, Cargo em 13%, PyPI em 11% e Maven Central em 10%. Estas são versões que aparecem ativamente em SBOMs corporativas hoje, sem cobertura de investigação de CVE e sem caminho de correção. O relatório da Sonatype descobriu que 5-15% dos componentes em grafos de dependência corporativos estão EOL, indicando exposição EOL mesmo quando as equipes acreditam que estão usando apenas bibliotecas de nível superior suportadas. Dependências transitivas, os pacotes dos quais seus pacotes dependem, carregam a maioria dessa exposição oculta. A maioria das organizações está sub-relatando profundamente sua exposição EOL, e não é culpa delas. Suas ferramentas nunca foram construídas para detectar abandono em escala. A HeroDevs confirmou mais de 81.000 versões de pacotes EOL com CVEs conhecidas e sem caminho de correção disponível, o que significa que estas são CVEs que foram ativamente investigadas e confirmadas. Dado que aproximadamente 80% das CVEs em versões suportadas também afetam versões EOL que nunca foram oficialmente investigadas, o número real é provavelmente muito maior. A HeroDevs estima que o número real pode ser mais próximo de **>400.000** em todos os registradores. ## Por Que Isso Está Piorando Essa dinâmica não é nova. O que é novo é a taxa com que ela está se agravando. O ecossistema OSS está escalando mais rápido do que a infraestrutura de segurança construída para monitorá-lo. Apenas o npm registrou mais de 838.000 lançamentos associados a pontuações CVSS 9.0+ críticas em 2025. O volume de downloads do PyPI cresceu mais de 50% ano a ano. Cada nova versão de pacote que entra em um registrador é uma futura versão EOL, e a população EOL cresce continuamente, enquanto a capacidade investigativa para cobri-la não. A força motriz mais significativa, no entanto, pode ser a **IA**. Em abril de 2026, a **Anthropic** anunciou o Project Glasswing ao lado do Claude Mythos Preview, documentando sua capacidade de identificar e explorar vulnerabilidades zero-day em todos os principais sistemas operacionais e navegadores — incluindo vulnerabilidades não detectadas por décadas. A iniciativa é explicitamente defensiva, direcionada a encontrar e corrigir vulnerabilidades críticas antes que os atacantes possam explorá-las. Para software com suporte ativo, esta é uma notícia genuinamente boa. Vulnerabilidades encontradas em escala de IA podem ser encaminhadas para engenheiros que podem resolvê-las. Para software EOL, o cálculo é diferente. Uma IA que encontra vulnerabilidades em toda a paisagem de codebase apresentará descobertas em versões que nenhum mantenedor está observando. Essas descobertas não serão investigadas oficialmente contra os intervalos afetados por EOL. Elas não acionarão alertas de scanner para usuários EOL. Nenhum patch upstream jamais as abordará. A mesma capacidade que acelera a defesa para software suportado amplia a lacuna de exposição para tudo que já foi deixado para trás. Os primeiros sinais dessa mudança já são visíveis. O impacto total ainda não chegou. ## Quanta Parte da Sua Pilha Já Está EOL? Você não sabe. Seu scanner não sabe. Seu feed de CVE não sabe. Os dados da Sonatype dizem que 5-15% dos componentes em uma pilha corporativa típica estão EOL. Apenas para npm, são 25% de todas as versões de pacotes. Spring Boot 3.2 enviou Spring Security 6.2, EOL desde dezembro, sem alerta de scanner. **Qual é o seu número?** O Conjunto de Dados EOL da HeroDevs informa em menos de cinco minutos. Faça upload de um SBOM ou execute o CLI. Nós o verificamos contra mais de 12 milhões de versões de pacotes em npm, PyPI, Maven, NuGet e todos os outros registradores importantes, incluindo as dependências transitivas que seu scanner pulou. Você recebe um relatório listando todos os pacotes EOL em sua pilha. Sem chamada de vendas. Sem cartão de crédito. À medida que a pesquisa de vulnerabilidades assistida por IA escala, o número de vulnerabilidades não divulgadas em pacotes EOL não investigados só aumentará. **[Execute Minha Verificação EOL Gratuita →](http://www.herodevs.com/eol-dataset/eol-data?utm_source=sponsored-article&utm_medium=paid-sponsorship&utm_campaign=2026q2_eolds-ga-phase2_global&utm_content=bleeping-computer_20260505)**