2026-05-05 00:00
← VoltarEscrito por Isaac Wuest, gerente principal de produto da HeroDevs. Quando as equipes de segurança pensam em software de código aberto em 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, sem dúvida, a metade menos perigosa. Existem dois problemas complicados 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 de código aberto, os mantenedores determinam quais versões são afetadas e arquivam um CVE com um intervalo definido de afetados. Cada scanner de vulnerabilidade, ferramenta SBOM e feed CVE do setor consome essa faixa. Se a sua versão estiver fora dela, você não receberá nenhum alerta. Não porque você esteja seguro, mas porque ninguém verificou.
As versões EOL ficam fora dessa faixa quase por padrão. A razão é simples: é um problema de escala. Em apenas cinco anos, a contagem global de CVE dobrou, enquanto o número de CVEs não pontuados aumentou 37x, de acordo com o relatório State of the Software Supply Chain de 2026 da Sonatype. Os mantenedores já estão sobrecarregados investigando e corrigindo as versões que eles suportam ativamente e, à medida que o volume de CVE e o número total de lançamentos de pacotes continuam a crescer, a largura de banda investigativa necessária para cobrir linhas de lançamento mais antigas simplesmente não existe. Os mantenedores devem ser realistas...
Escrito por Isaac Wuest, gerente principal de produto da HeroDevs. Quando as equipes de segurança pensam em software de código aberto em 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, sem dúvida, a metade menos perigosa. Existem dois problemas complicados 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 de código aberto, os mantenedores determinam quais versões são afetadas e arquivam um CVE com um intervalo definido de afetados. Cada scanner de vulnerabilidade, ferramenta SBOM e feed CVE do setor consome essa faixa. Se a sua versão estiver fora dela, você não receberá nenhum alerta. Não porque você esteja seguro, mas porque ninguém verificou.
As versões EOL ficam fora dessa faixa quase por padrão. A razão é simples: é um problema de escala. Em apenas cinco anos, a contagem global de CVE dobrou, enquanto o número de CVEs não pontuados aumentou 37x, de acordo com o relatório State of the Software Supply Chain de 2026 da Sonatype. Os mantenedores já estão sobrecarregados investigando e corrigindo as versões que eles suportam ativamente e, à medida que o volume de CVE e o número total de lançamentos de pacotes continuam a crescer, a largura de banda investigativa necessária para cobrir linhas de lançamento mais antigas simplesmente não existe. Os mantenedores devem ser realistas sobre até onde podem retroceder razoavelmente em seu próprio histórico de lançamentos. A pesquisa da Sonatype nomeou explicitamente “versões EOL omitidas dos avisos” como um impulsionador da falsa confiança na segurança, contribuindo para os 167.286 falsos negativos, componentes exploráveis que não foram sinalizados, identificados apenas em 2025. As versões do pacote EOL de 5,4 milhões que sua ferramenta SCA não está verificando. Digitalize gratuitamente.
O EOL DS da HeroDevs rastreia o status de fim de vida útil em mais de 12 milhões de versões de pacotes em npm, PyPI, Maven, NuGet e todos os outros registros importantes. Carregue um SBOM ou execute a CLI para encontrar todas as dependências de EOL em sua pilha, incluindo aquelas transitivas que seus scanners não conseguem sinalizar. Obtenha seu relatório de risco de EOL gratuito Como isso se parece na prática Duas vulnerabilidades críticas recentes no ecossistema Spring tornam isso concreto. CVE-2026-22732 — Spring Security (Critical, 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 descartados silenciosamente em determinadas configurações de aplicativos servlet. A faixa oficial afetada cobre Spring Security 5.7.x a 7.0.x. Spring Security 6.2.x não está listado. Atingiu o EOL em dezembro de 2025. Spring Boot 3.2 vem com Spring Security 6.2.
Qualquer organização que execute o Boot 3.2, uma versão secundária atrás do intervalo listado, não recebe sinal de scanner. HeroDevs confirmou que o Spring Security 6.2.x foi 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 discrepantes. Eles refletem um padrão que o HeroDevs encontra consistentemente em sua prática de suporte sem fim. Quando um novo CVE é divulgado em um pacote compatível, a HeroDevs descobre que precisa corrigir uma versão EOL que o registro oficial do CVE não lista como afetado em aproximadamente 80% das vezes. O raio de explosão de qualquer vulnerabilidade é sistematicamente mais amplo do que o mostrado nos registros.
Simplificando: 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 do CVE acima se aplica ao 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, que rastreia cerca de 350 projetos mantidos ativamente; principais estruturas e tempos de execução onde os mantenedores publicaram explicitamente as datas de fim de vida. Entre esses 350 profissionais projetos, aproximadamente 7.000 versões de pacotes específicos são identificadas como EOL. Esse é o universo a partir do qual a maioria dos scanners e equipes de segurança trabalham. Aqui está a escala real do problema. No relatório State of the Software Supply Chain de 2026 da Sonatype, produzido em parceria com 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 em fim de vida. No entanto, a fonte pública mais completa do setor (endoflife.date) representa apenas cerca de 7.000 deles. A divisão por ecossistema é impressionante. Aproximadamente 25% das versões do pacote npm são EOL. NuGet fica em torno de 18%, Cargo em 13%, PyPI em 11% e Maven Central em 10%. Essas são versões que aparecem ativamente nos SBOMs corporativos hoje, sem cobertura de investigação de CVE e sem caminho de correção. O relatório Sonatype descobriu que 5–15% dos componentes nos gráficos de dependência empresarial sã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 maior parte dessa exposição oculta.
A maioria das organizações subnotifica profundamente a sua exposição ao EOL, e isso não é culpa delas. Suas ferramentas nunca foram construídas para detectar abandono em grande escala. HeroDevs confirmou mais de 81.000 versões de pacotes EOL com CVEs conhecidos e nenhum caminho de correção disponível, o que significa que esses são CVEs que foram ativamente investigados e confirmados. Dado que cerca de 80% dos CVEs em versões suportadas também afetam versões EOL que nunca foram investigadas oficialmente, o número real é provavelmente muito maior. HeroDevs estima que o número real pode estar próximo de >400.000 em todos os registros. Porque é que isto está a piorar Esta dinâmica não é nova. A novidade é a taxa de capitalização. O ecossistema OSS está a crescer mais rapidamente do que a infraestrutura de segurança construída para monitorizá-lo.
Somente o npm registrou mais de 838.000 lançamentos associados a pontuações críticas de CVSS 9.0+ em 2025. O volume de downloads do PyPI cresceu mais de 50% ano após ano. Cada nova versão de pacote que entra em um registro é uma versão futura de EOL, e a população de EOL cresce continuamente, enquanto a capacidade investigativa para cobri-la não cresce. A função de forçamento mais significativa, entretanto, pode ser a IA. Em abril de 2026, a Anthropic anunciou o Projeto Glasswing junto com Claude Mythos Preview, documentando sua capacidade de identificar e explorar vulnerabilidades de dia zero em todos os principais sistemas operacionais e navegadores – incluindo vulnerabilidades não detectadas por décadas. A iniciativa é explicitamente defensiva, direcionada para encontrar e corrigir vulnerabilidades críticas antes que os invasores 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 possam resolvê-las.
Para software EOL, o cálculo é diferente. Uma IA que encontra vulnerabilidades em todo o cenário da base de código revelará descobertas em versões que nenhum mantenedor está observando. Essas descobertas não serão investigadas oficialmente em relação às faixas afetadas pelo EOL. Eles não acionarão alertas de scanner para usuários EOL. Nenhum patch upstream irá resolvê-los. A mesma capacidade que acelera a defesa do software suportado amplia a lacuna de exposição para tudo o que já foi deixado para trás. Os primeiros sinais desta mudança já são visíveis. O impacto total ainda não chegou.
Quanto da sua pilha já está EOL? Você não sabe. Seu scanner não sabe. Seu feed CVE não sabe. Os dados da Sonatype dizem que 5–15% dos componentes em uma pilha corporativa típica são EOL. Somente para o npm, são 25% de todas as versões do pacote. Spring Boot 3.2 lançado Spring Security 6.2, EOL desde dezembro, sem alerta de scanner. Qual é o seu número?
O conjunto de dados HeroDevs EOL informa você em menos de cinco minutos. Carregue um SBOM ou execute a CLI. Verificamos isso em mais de 12 milhões de versões de pacotes em npm, PyPI, Maven, NuGet e todos os outros registros principais tente, incluindo as dependências transitivas que seu scanner ignorou. Você recebe um relatório listando cada pacote EOL em sua pilha. Nenhuma chamada de vendas. Sem cartão de crédito. À medida que a investigação de vulnerabilidades assistida por IA aumenta, o número de vulnerabilidades não divulgadas em pacotes EOL não investigados só aumentará. [Run My Free EOL Scan →] Patrocinado e escrito por HeroDevs.