Automatização da detecção de fim de vida em SBOMs, imagens de contêineres e inventários de software

Objetivo

Situação em 25 de outubro de 2026: este protocolo proposto detecta de forma recorrente a exposição decorrente do ciclo de vida em um parque de sistemas, incluindo ambientes de execução de aplicações, pacotes de distribuições e conteúdos de contêineres. Ele produz uma fila de correções com responsáveis atribuídos e outra fila para evidências incertas. Conferir novamente o esquema da API, as páginas de ciclo de vida dos fornecedores e os direitos locais de suporte sempre que as evidências forem atualizadas. Não se afirma ter obtido uma implantação bem-sucedida nem medições de detecção.

Pré-requisitos

Usar um inventário autorizado de ativos, registros de implantação, identificadores de imagens, listas de materiais de software disponíveis e responsáveis que possam confirmar os acordos de suporte. Definir a idade aceitável do inventário, a frequência de atualização das fontes, a antecedência necessária para migração e um fluxo de escalonamento. Armazenar com as decisões as URLs dos fornecedores, os horários de obtenção e quaisquer datas publicadas de revisão.

O projeto endoflife.date documenta sua própria API; ele agrega os ciclos de vida de outros produtos. Tratar seu feed como evidência de descoberta, deixando ao fornecedor a autoridade sobre as decisões de prazo. Seu esquema separa o fim do suporte ativo, o fim de vida e o fim do suporte estendido. Definição da API.

Passos

1. Coletar as versões observadas nas cargas de trabalho implantadas e associá-las a um responsável e a um identificador de implantação. Incluir templates inativos e etapas de build. Para cada componente, preservar ecossistema, produto, edição, linha de versões, distribuidor e origem do pacote. Exigir revisão manual de nomes ambíguos, em vez de fazer correspondências apenas pela string de versão.
2. Associar cada digest de imagem implantada à sua SBOM e à procedência da imagem base. Onde Docker Scout já estiver disponível, docker scout sbom --format spdx local://IMAGE gera uma SBOM a partir de uma imagem local; substituir IMAGE pela referência da imagem local pretendida. Registrar a plataforma analisada e o digest. Não analisar silenciosamente a imagem que tiver sido construída mais recentemente. Comando de SBOM.
3. Mapear componentes para identificadores revisados de produto e ciclo de versão. Consultar o endpoint documentado /api/v1/products/{product} ou seu endpoint de ciclo de versão. Armazenar respostas em cache, respeitar redirecionamentos e tratar limites de requisições. Preservar isEol, eolFrom, eoasFrom e eoesFrom quando fornecidos. Um eolFrom nulo significa que a data é desconhecida; campos ausentes de suporte estendido podem significar que a fase não se aplica. Nenhuma dessas condições concede suporte por prazo indeterminado.
4. Confirmar os prazos relevantes nas páginas dos fornecedores e registrar qual fase de suporte e qual direito de cobertura se aplicam. Manter separadas as decisões do projeto original e do distribuidor. O ciclo de vida do Ubuntu distingue a manutenção padrão dos pacotes Main da cobertura vinculada a assinatura e de outras categorias de pacotes; não deduzir cobertura idêntica para todos os pacotes apenas pelo nome do sistema operacional. Cobertura da distribuição.
5. Avaliar de forma independente o ciclo de vida e a atualização da imagem. A política do Docker para imagens base desatualizadas compara o digest atual da tag base com aquele usado na construção da imagem e exige dados de procedência. Passar nessa comparação não comprova que a versão subjacente ainda receba suporte. Preservar um estado explicitamente desconhecido quando faltarem evidências de ciclo de vida, mapeamento de pacotes ou procedência. Semântica da política de imagens.
6. Definir os limiares de alerta com base no trabalho necessário: iniciar a migração quando o tempo restante for menor ou igual ao prazo de migração acordado mais a margem para aprovação e recuperação. Escalonar quando restar apenas a janela de troca e recuperação já ensaiada; sinalizar imediatamente a cobertura expirada. Essas são regras propostas de política local, não prazos dos fornecedores. Eliminar alertas duplicados por responsável e componente e fazer as exceções expirarem automaticamente para revisão.
7. Testar o processo de decisão com casos de suporte vigente, expirado, desconhecido, feed desatualizado e suporte estendido documentado. Incluir uma imagem cujo digest esteja atualizado, mas cuja versão não tenha suporte. Atualizar tanto a observação do ativo quanto as evidências de ciclo de vida antes de encerrar uma ocorrência após a correção.

Resultado esperado

Cada ocorrência identifica a carga de trabalho afetada, o componente, a fase de suporte, as evidências do fornecedor, o responsável e a próxima ação. Dados ausentes permanecem visíveis, em vez de serem contabilizados como suporte vigente.

Limites e base de verificação

Uma SBOM, por si só, não comprova cobertura contratual nem captura todas as modificações em tempo de execução. Esta é uma síntese de interfaces documentadas e um protocolo de avaliação proposto; seus testes são critérios de aceitação, não resultados relatados. O monitoramento do ciclo de vida complementa a detecção de vulnerabilidades e de comprometimento, sem comprovar nenhum dos dois resultados.