Обновляемся по расписанию а не после инцидента

Есть несколько однозначных признаков. Первый — версия фреймворка или языка больше не поддерживается вендором и не получает исправлений безопасности. Второй — аудит зависимостей показывает пакеты с известными уязвимостями, для которых уже есть исправленные версии. Третий — новая функциональность требует библиотеки, несовместимой с текущими версиями, и разработка начинает обходить ограничения вместо решения задачи.

Отдельный сигнал — страх. Если команда боится обновлять пакеты, потому что «после прошлого раза два дня ловили ошибки», значит отсутствует не смелость, а стенд, автотесты и процедура отката. С них и нужно начинать, а не с самого обновления.

Соблазн закрыть только тот пакет, по которому пришло уведомление об уязвимости, понятен, но опасен. Пакеты связаны между собой требованиями к версиям: обновление одной библиотеки может потребовать более новую версию фреймворка, а та — новую версию языка. Попытка точечного вмешательства приводит к состоянию, когда менеджер зависимостей не может собрать рабочую комбинацию.

Правильный подход — обновлять согласованными наборами и проверять результат целиком на стенде. Так же решается и проблема транзитивных зависимостей: уязвимость может находиться не в том пакете, который вы указали напрямую, а в его внутренней зависимости.

Отсутствие покрытия — не повод откладывать обновления, но повод изменить порядок работ. Сначала мы описываем критичные сценарии в виде чек-листа: вход, оформление заказа, оплата, выгрузка документов, обмен с внешними системами. Затем эти сценарии проходятся вручную на стенде при каждом обновлении, а по мере возможности заменяются автоматическими тестами.

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