🚨 NOVA NOTÍCIA EM DESTAQUE! 🚨
Sua opinião é importante: leia e participe!
Apoie esse projeto de divulgacao de noticias! Clique aqui
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 registram um CVE com um intervalo afetado definido. 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 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 (Crítico, março de 2026, CVSS 9.1)
Esta vulnerabilidade faz com que os 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 compatível, 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 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.
Nesses 350 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
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 registram um CVE com um intervalo afetado definido. 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 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 (Crítico, março de 2026, CVSS 9.1)
Esta vulnerabilidade faz com que os 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 compatível, 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 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.
Nesses 350 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
#samirnews #samir #news #boletimtec #o #ponto #cego #eol #em #seu #feed #cve: #o #que #falta #nas #ferramentas #sca
🔔 Siga-nos para não perder nenhuma atualização!
Postar um comentário