Через четыре года после Log4Shell уязвимые экземпляры библиотеки всё ещё остаются в рабочих системах. Эта история хорошо показывает, почему окно между патчами — не формальность из отчёта ИБ, а период, в который атакующий может успеть раньше команды эксплуатации; для российских разработчиков и IT-руководителей это аргумент пересмотреть не только скорость обновлений, но и защиту уже запущенных сервисов.
Как сообщает The New Stack, последствия одной из самых заметных уязвимостей в истории ПО по-прежнему не исчерпаны. Log4Shell стала публичной в декабре 2021 года и затронула Log4j — широко используемую Java-библиотеку журналирования. Проблема была не только в самом исправлении: компонент оказался глубоко спрятан в зависимостях, контейнерных образах, старых продуктах и внутренних сервисах, владельцев которых иногда уже сложно определить.
Обычная схема «вышел патч — ставим в ближайшее окно обслуживания» плохо работает, когда эксплуатация уязвимости начинается почти сразу после публикации деталей. Между появлением исправления, инвентаризацией затронутых систем, тестированием, согласованием изменений и фактическим развёртыванием проходит время. Именно его и описывает термин окно между патчами. Чем больше у компании легаси, стороннего ПО и непрозрачных цепочек поставки, тем шире это окно.
Log4Shell запомнилась рынку не только технической опасностью, но и масштабом организационной работы. Недостаточно было обновить один Maven-артефакт: нужно было понять, где библиотека используется напрямую, где приезжает транзитивной зависимостью, а где упакована внутрь коммерческого продукта. После первых исправлений появлялись дополнительные рекомендации и новые версии, поэтому команды, успевшие закрыть первоначальную задачу, нередко возвращались к ней снова.
Из этого следует неприятный, но полезный вывод: отсутствие известного инцидента не означает отсутствие риска. Уязвимый компонент может жить в редко обновляемом сервисе, резервном окружении, старом образе в реестре контейнеров или продукте подрядчика. Сканер зависимостей поможет найти часть проблемы, но не ответит сам по себе на другой вопрос: доступен ли сервис извне, может ли он обработать опасный ввод и есть ли вокруг него компенсирующие меры.
Для разработки задача начинается с дисциплины зависимостей. Нужны понятный владелец каждого сервиса, регулярная пересборка образов, контроль состава пакетов и приоритизация не по числу CVE, а по реальной экспозиции. Уязвимость в выключенном тестовом стенде и та же уязвимость в интернет-доступном сервисе с чувствительными данными требуют разной реакции. Полезно также заранее проверить, можно ли быстро отключить рискованную функцию конфигурацией, ограничить входящий трафик или изолировать процесс до установки обновления.
Для бизнеса это вопрос не о том, можно ли отменить Patch Tuesday, а о том, что делать в промежутке до планового обновления. Команда ИБ должна иметь право инициировать внеплановое изменение при критическом риске, а эксплуатация — заранее понимать процедуру отката и критерии допуска. Иначе даже идеально подготовленный патч становится заложником календаря, согласований и страха нарушить SLA.
История Log4Shell меняет и подход к метрикам. Важна не только доля закрытых уязвимостей к концу месяца, но и время от обнаружения критичного компонента до его изоляции либо обновления. Атаки не подстраиваются под релизный цикл компании. Чем точнее организация видит свои зависимости и чем быстрее умеет сокращать окно между патчами, тем меньше шанс, что очередная массовая CVE превратится в многонедельную операцию по поиску давно забытого JAR-файла.
