Os runtimes de linguagens de programação (os interpretadores, máquinas virtuais e ambientes de execução que rodam o código das aplicações) são a camada fundamental da cadeia de suprimentos de software, abaixo tanto do código da aplicação quanto de suas dependências de código aberto. Um runtime que chegou ao fim da vida útil, ou que contém vulnerabilidades não corrigidas, cria risco para toda aplicação construída sobre ele, por melhor que seja o código da própria aplicação ou por mais atualizadas que estejam suas dependências. A segurança do runtime é a camada que a maioria das varreduras de SCA e dos programas de SBOM não aborda diretamente: as ferramentas de SCA verificam as dependências da aplicação, não o runtime de linguagem que executa essas dependências.
O problema do fim da vida útil dos runtimes de linguagem segue o mesmo padrão das dependências em fim de vida: a versão de runtime que era atual no desenvolvimento inicial torna-se cada vez mais vulnerável à medida que a equipe de segurança do projeto da linguagem publica vulnerabilidades para as versões atualmente suportadas e não leva as correções para as versões em EOL. Uma plataforma em Python 3.9 acumula vulnerabilidades do Python indefinidamente após a data de EOL de outubro de 2025, não porque novas vulnerabilidades sejam introduzidas especificamente no Python 3.9, mas porque vulnerabilidades descobertas e corrigidas no Python 3.11 e 3.12 podem ter estado presentes no Python 3.9 e continuarão sem correção.
A barreira da complexidade de migração é a razão operacional pela qual o EOL de runtimes se acumula como dívida técnica. Migrar de uma versão principal do Python para outra, ou de uma versão LTS do Java para outra, exige testar toda a aplicação no novo runtime. Em bases de código grandes e maduras, esse esforço de teste é significativo. Fornecedores sob pressão para entregar funcionalidades adiam rotineiramente as migrações de runtime em favor do desenvolvimento da aplicação, acumulando uma dívida de EOL de runtime que acaba se tornando um passivo de segurança impossível de resolver.
Por que isso importa
A segurança de runtime é importante para TPRM porque um fornecedor que entrega código de aplicação bem corrigido rodando em um runtime em EOL está entregando software cujo ambiente de execução fundamental tem vulnerabilidades permanentes não corrigidas. Uma avaliação de segurança da camada de aplicação que não inclui a atualização da versão do runtime deixa de lado a camada mais fundamental da cadeia de suprimentos de software.
- Atualização da versão de runtime não avaliada na SCA nem na revisão de segurança da cadeia de suprimentos
- Status de EOL dos runtimes não acompanhado na avaliação da saúde das dependências
- Vulnerabilidades de runtime fora do escopo da varredura de SCA: apenas dependências da aplicação
- Cronograma de migração para runtimes em EOL não avaliado
- Segurança do runtime separada da segurança da aplicação na avaliação do fornecedor
Como é uma boa prática
Programas maduros de segurança de runtime avaliam a atualização da versão do runtime de linguagem junto com a saúde das dependências da aplicação, usam a base de dados do endoflife.date para acompanhar o status de EOL dos runtimes no software implantado e exigem que os fornecedores divulguem suas versões de runtime e apresentem cronogramas de migração para runtimes em EOL.
- Avaliação da versão de runtime junto com a varredura de SCA
- Acompanhamento de EOL pelo endoflife.date para os runtimes de linguagem do software implantado
- Exigência de cronograma de migração para runtimes em EOL
- Vulnerabilidades de runtime no monitoramento de vulnerabilidades, junto com as CVEs das dependências
- Atualização do runtime como métrica de saúde da cadeia de suprimentos na avaliação de fornecedores
Ferramentas
Acompanhamento de EOL: endoflife.date para datas de EOL de runtimes de linguagem, frameworks e OS; o Trivy inclui a verificação de versões de runtime
O projeto endoflife.date mantém dados de EOL legíveis por máquina para linguagens, runtimes, frameworks e sistemas operacionais, oferecendo a referência autorizada de status de EOL que permite a detecção automatizada de EOL nas avaliações da cadeia de suprimentos. A varredura de contêineres do Trivy inclui a detecção da versão do runtime de linguagem junto com a varredura de vulnerabilidades das dependências. Para profissionais de TPRM, comparar as versões de runtime do software dos fornecedores com o endoflife.date permite uma avaliação específica da atualização do runtime.
Desafios de governança
O desafio de governança da segurança de runtime é o problema da priorização das migrações. As migrações de runtime competem com o desenvolvimento de funcionalidades e com as atualizações de dependências da aplicação pela capacidade de engenharia. A solução de governança é incluir o EOL de runtime como constatação de risco da cadeia de suprimentos, com SLAs de correção definidos, tratando uma plataforma que roda em um runtime em EOL como uma constatação com urgência equivalente à de vulnerabilidades críticas nas dependências da aplicação.
- Avaliar a atualização da versão de runtime de todo o software crítico dos fornecedores
- Acompanhar o status de EOL dos runtimes do software implantado usando o endoflife.date
- Exigir cronograma de migração para runtimes em EOL como constatação de cadeia de suprimentos
- Incluir o monitoramento de vulnerabilidades do runtime junto com o monitoramento das dependências da aplicação
- Ponderar o EOL de runtimes na pontuação de risco da cadeia de suprimentos
Se você faz parte de uma equipe pequena
Para os seus três fornecedores de software mais críticos, pergunte em qual versão de runtime de linguagem a plataforma é construída e verifique essa versão em endoflife.date. A verificação leva cinco minutos por fornecedor. Se algum runtime estiver em EOL ou a menos de seis meses do EOL, você tem uma constatação de cadeia de suprimentos que o programa de SBOM e SCA não teria revelado. Inclua essa constatação nos resultados da avaliação do fornecedor, junto com as vulnerabilidades das dependências da aplicação.
- Pedir aos fornecedores a versão do runtime de linguagem
- Verificar a versão do runtime no endoflife.date
- Sinalizar runtimes em EOL ou próximos do EOL como constatações de cadeia de suprimentos
- Exigir cronograma de migração para runtimes em EOL
O que exigir
Pergunte diretamente:
“Em qual versão de runtime de linguagem sua plataforma é construída? E, se esse runtime estiver se aproximando do fim da vida útil, qual é o seu cronograma de migração e como vocês pretendem tratar as vulnerabilidades no nível do runtime que não serão corrigidas após a data de EOL?”
O que esperar como evidência
- Versão atual do runtime de linguagem
- Confirmação do status de EOL
- Cronograma de migração para runtimes em EOL ou próximos do EOL
- Abordagem de monitoramento de vulnerabilidades do runtime
Um fornecedor que confirma que as dependências da aplicação estão atualizadas deve ser questionado sobre a atualização do runtime. A SCA da aplicação cobre as dependências. A avaliação do runtime cobre a camada sobre a qual as dependências são executadas. Ambas são necessárias para uma avaliação completa da saúde da cadeia de suprimentos.
Como comprovar
- Registros de avaliação das versões de runtime
- Acompanhamento do status de EOL
- Cronograma de migração para runtimes em EOL
- Inclusão do runtime na pontuação de risco da cadeia de suprimentos
Principal conclusão
Código da aplicação: bem corrigido. Runtime: Python 3.9, EOL em outubro de 2025. CVEs críticas no runtime: 3. Correções futuras: nenhuma. A camada da aplicação era mantida. O ambiente de execução em que ela rodava acumulava vulnerabilidades permanentes não corrigidas. A segurança do runtime é a camada fundamental da cadeia de suprimentos, abaixo da aplicação e de suas dependências. Runtimes em EOL não recebem correções futuras para vulnerabilidades descobertas após a data de EOL. O endoflife.date identifica o status de EOL em minutos. Os cronogramas de migração são a constatação de cadeia de suprimentos que a avaliação de runtimes em EOL gera.