Automatización de la detección del fin de vida útil en SBOM, imágenes de contenedor e inventarios de software

Objetivo

Estado al 25 de octubre de 2026: este protocolo propuesto detecta de forma recurrente los riesgos derivados del ciclo de vida en un conjunto de sistemas, incluidos los entornos de ejecución de aplicaciones, los paquetes de las distribuciones y el contenido de los contenedores. Genera una cola de tareas de corrección con responsables asignados y otra independiente para las pruebas inciertas. Volver a consultar el esquema de la API, las páginas de ciclo de vida de los proveedores y los derechos de soporte locales cada vez que se actualicen las pruebas. No se afirma haber realizado un despliegue satisfactorio ni mediciones de detección.

Requisitos previos

Utilizar un inventario de activos autorizado, registros de despliegue, identificadores de imágenes, las listas de materiales de software disponibles y responsables que puedan confirmar los acuerdos de soporte. Definir la antigüedad aceptable del inventario, la frecuencia de actualización de las fuentes, la antelación necesaria para migrar y una vía de escalamiento. Conservar con las decisiones las URL de los proveedores, las horas de consulta y las fechas de revisión publicadas, si las hay.

El proyecto endoflife.date documenta su propia API y recopila los ciclos de vida de otros productos. Tratar sus datos como pruebas para la detección, dejando que el proveedor determine las decisiones sobre plazos. Su esquema separa el fin del soporte activo, el fin de la vida útil y el fin del soporte extendido. Definición de la API.

Pasos

1. Recopilar las versiones observadas en las cargas de trabajo desplegadas y vincularlas a un responsable y un identificador de despliegue. Incluir las plantillas inactivas y las etapas de construcción. Para cada componente, conservar el ecosistema, el producto, la edición, la rama de versiones, el distribuidor y el origen del paquete. Exigir una revisión manual de los nombres ambiguos en lugar de establecer correspondencias únicamente por la cadena de versión.
2. Asociar el digest de cada imagen desplegada con su SBOM y la procedencia de su imagen base. Donde Docker Scout ya esté disponible, docker scout sbom --format spdx local://IMAGE genera una SBOM a partir de una imagen local; sustituir IMAGE por la referencia a la imagen local prevista. Registrar la plataforma analizada y el digest. No analizar sin advertencia la imagen que se haya construido más recientemente. Comando de SBOM.
3. Asociar los componentes con identificadores revisados de producto y ciclo de versiones. Consultar el endpoint documentado /api/v1/products/{product} o su endpoint de ciclo de versiones. Guardar las respuestas en caché, respetar las redirecciones y gestionar los límites de solicitudes. Conservar isEol, eolFrom, eoasFrom y eoesFrom cuando se proporcionen. Un eolFrom nulo significa que la fecha se desconoce; la ausencia de campos de soporte extendido puede significar que esa fase no se aplica. Ninguna de esas condiciones concede soporte indefinido.
4. Confirmar los plazos relevantes en las páginas de los proveedores y registrar qué fase y derechos de soporte se aplican. Mantener separadas las decisiones del proyecto original y las del distribuidor. El ciclo de vida de Ubuntu distingue el mantenimiento estándar de los paquetes Main de la cobertura mediante suscripción y de otras categorías de paquetes; no deducir que todos los paquetes tienen la misma cobertura solo a partir del nombre del sistema operativo. Cobertura de la distribución.
5. Evaluar por separado el ciclo de vida y la actualización de las imágenes. La política de Docker para imágenes base desactualizadas compara el digest actual de la etiqueta base con el utilizado para construir la imagen y exige información de procedencia. Superar esa comparación no demuestra que la versión subyacente siga teniendo soporte. Conservar un estado explícito de desconocido cuando falten pruebas del ciclo de vida, la correspondencia de paquetes o la procedencia. Semántica de la política de imágenes.
6. Fijar los umbrales de alerta según el trabajo necesario: iniciar la migración cuando el tiempo restante no sea mayor que la antelación acordada para migrar más el margen de aprobación y recuperación. Escalar cuando solo quede el tiempo necesario para el cambio y la recuperación ensayados; señalar de inmediato la cobertura vencida. Estas son reglas propuestas de política local, no plazos de los proveedores. Eliminar alertas duplicadas por responsable y componente, y hacer que las excepciones caduquen automáticamente para su revisión.
7. Probar el proceso de decisión con casos de soporte vigente, soporte vencido, estado desconocido, datos de la fuente desactualizados y soporte extendido documentado. Incluir una imagen cuyo digest esté actualizado pero cuya versión carezca de soporte. Actualizar tanto la observación del activo como las pruebas del ciclo de vida antes de cerrar un hallazgo tras su corrección.

Resultado esperado

Cada hallazgo identifica la carga de trabajo afectada, el componente, la fase de soporte, las pruebas del proveedor, el responsable y la siguiente acción. La falta de datos permanece visible en lugar de contabilizarse como soporte vigente.

Límites y base de verificación

Una SBOM no puede demostrar por sí sola la cobertura contractual ni recoger todas las modificaciones realizadas durante la ejecución. Esto es una síntesis de interfaces documentadas y un protocolo de evaluación propuesto; sus pruebas son criterios de aceptación, no resultados comunicados. La supervisión del ciclo de vida complementa la detección de vulnerabilidades y de sistemas comprometidos, sin acreditar por sí misma ninguna de las dos.