Автоматическое выявление окончания поддержки по SBOM, образам контейнеров и реестрам ПО

Цель

По состоянию на 25 октября 2026 года: предлагаемая процедура регулярно выявляет риски, связанные с жизненным циклом, во всей инфраструктуре, включая среды выполнения приложений, пакеты дистрибутивов и содержимое контейнеров. Она формирует очередь задач по устранению рисков с назначенными ответственными и отдельную очередь случаев с неопределёнными свидетельствами. При каждом обновлении сведений заново проверяйте схему API, страницы жизненного цикла поставщиков и права на поддержку в вашей среде. Успешное развёртывание или измерения качества обнаружения не заявляются.

Предварительные условия

Используйте реестр активов, к которому у вас есть разрешённый доступ, записи о развёртываниях, идентификаторы образов, доступные перечни состава программного обеспечения и помощь владельцев, способных подтвердить условия поддержки. Определите допустимый возраст инвентарных данных, частоту обновления источников, время на миграцию и порядок эскалации. Сохраняйте вместе с решениями URL поставщиков, время получения сведений и опубликованные даты редакций, если они есть.

Проект endoflife.date документирует собственный API и агрегирует сведения о жизненных циклах других продуктов. Считайте его данные источником для первичного выявления, а решения о сроках основывайте на сведениях поставщика. Его схема различает окончание активной поддержки, окончание жизненного цикла и окончание расширенной поддержки. Определение API.

Шаги

1. Соберите наблюдаемые версии из развёрнутых рабочих нагрузок и свяжите их с владельцем и идентификатором развёртывания. Включите неактивные шаблоны и этапы сборки. Для каждого компонента сохраняйте экосистему, продукт, редакцию, ветку выпуска, дистрибьютора и происхождение пакета. Требуйте ручной проверки неоднозначных имён вместо сопоставления только по строке версии.
2. Свяжите дайджест каждого развёрнутого образа с его SBOM и сведениями о происхождении базового образа. Там, где Docker Scout уже доступен, docker scout sbom --format spdx local://IMAGE создаёт SBOM по локальному образу; замените IMAGE ссылкой на нужный локальный образ. Запишите проанализированную платформу и дайджест. Не сканируйте молча просто тот образ, который был собран последним. Команда SBOM.
3. Сопоставьте компоненты с проверенными идентификаторами продуктов и циклов выпусков. Запрашивайте документированную конечную точку /api/v1/products/{product} или её конечную точку цикла выпуска. Кэшируйте ответы, следуйте перенаправлениям и обрабатывайте ограничения частоты запросов. Сохраняйте isEol, eolFrom, eoasFrom и eoesFrom, если они предоставлены. Значение null у eolFrom означает неизвестную дату; отсутствие полей расширенной поддержки может означать, что такая фаза неприменима. Ни одно из этих условий не даёт бессрочной поддержки.
4. Подтвердите существенные сроки на страницах поставщиков и запишите, какая фаза поддержки и какие права на неё применимы. Разделяйте решения исходного проекта и дистрибьютора. Жизненный цикл Ubuntu различает стандартное сопровождение пакетов Main, поддержку по подписке и другие категории пакетов; не выводите одинаковый объём поддержки для всех пакетов лишь из названия операционной системы. Поддержка в дистрибутиве.
5. Оценивайте жизненный цикл и актуальность образа независимо. Политика Docker для устаревших базовых образов сравнивает текущий дайджест базового тега с дайджестом, использованным при сборке образа, и требует сведений о происхождении. Успешное сравнение не подтверждает, что лежащий в основе выпуск всё ещё поддерживается. Сохраняйте явное состояние «неизвестно», если отсутствуют свидетельства о жизненном цикле, сопоставление пакетов или сведения о происхождении. Семантика политики образов.
6. Установите пороги оповещения исходя из необходимых работ: начинайте миграцию, когда оставшееся время не превышает согласованного времени на миграцию плюс запас на согласование и восстановление. Эскалируйте, когда остаётся только окно переключения и восстановления, определённое на репетиции; немедленно отмечайте истёкшую поддержку. Это предлагаемые правила локальной политики, а не сроки поставщиков. Устраняйте дубли оповещений по владельцу и компоненту и автоматически завершайте срок действия исключений для их пересмотра.
7. Проверьте процесс принятия решений на случаях действующей и истёкшей поддержки, неизвестного состояния, устаревших данных источника и документированной расширенной поддержки. Включите образ с актуальным дайджестом, но неподдерживаемым выпуском. Перед закрытием выявленной проблемы после устранения обновите и наблюдения об активе, и свидетельства о жизненном цикле.

Ожидаемый результат

Каждая выявленная проблема указывает затронутую рабочую нагрузку, компонент, фазу поддержки, свидетельства поставщика, владельца и следующее действие. Недостающие данные остаются видимыми, а не засчитываются как подтверждённая поддержка.

Ограничения и основание проверки

Сам по себе SBOM не может доказать наличие договорной поддержки или отразить все изменения во время выполнения. Это обобщение документированных интерфейсов и предлагаемая процедура оценки; её тесты — критерии приёмки, а не сообщаемые результаты. Мониторинг жизненного цикла дополняет обнаружение уязвимостей и компрометации, но не устанавливает ни то, ни другое.