На уходящей неделе в отраслевых каналах появилась информация о критических уязвимостях в плагинах Jupiter (CVE-2022-1654) и Tatsu Builder (CVE-2021-25094). Уровень угрозы - максимальный (CVSS 9.9). Для блогов наших проектов на WordPress это означало необходимость немедленной проверки.
Как SEO Team Lead, я отвечаю за стабильность и видимость ряда проектов, включая корпоративные блоги. Любой инцидент, ведущий к простою или компрометации сайта, напрямую влияет на трафик - ключевую метрику. Получив информацию, мы с коллегами из разработки и интернет-безопасности сразу начали аудит.
Определение периметра проверки
Первым делом мы составили полный список всех активов под нашим контролем. Это включало:
- Основные корпоративные блоги и сайты продуктов.
- Вспомогательные проекты и лендинги.
- Сеть тематических сайтов (PBN), используемую для усиления ключевых проектов.
Для PBN проверка была особенно важна, так как там часто используются разнообразные темы и конструкторы для достижения визуальной уникальности, и обновления могут устанавливаться нерегулярно.
Методика аудита
Мы использовали комбинацию методов:
- Автоматизированная проверка. Разработчики быстро собрали скрипт, который по списку доменов проверял наличие определённых файлов и заголовков, характерных для уязвимых версий плагинов.
- Выборочный ручной аудит. Для самых старых и сложных проектов доступ осуществлялся через административную панель для точного определения версий всех компонентов.
- Работа с хостинг-провайдером. По некоторым сегментам сетей мы запросили выгрузки установленного ПО через поддержку хостинга.
Результаты и действия
Аудит показал следующее:
- На основных корпоративных проектах уязвимые плагины обнаружены не были. Это подтвердило правильность выбранного ранее технологического стека, ориентированного на безопасность и простоту поддержки.
- На нескольких вспомогательных лендингах была найдена устаревшая версия Jupiter. Плагин был немедленно отключён, а функциональность перенесена на стандартные средства WordPress.
- В сегменте PBN инцидентов также не обнаружено. Это стало результатом внедрённой ранее политики стандартизации и централизованного управления обновлениями для этой группы сайтов.
Системные выводы
Этот инцидент стал практической проверкой наших процедур управления рисками. Мы закрепили несколько правил:
Единый реестр активов. Все сайты, за которые мы отвечаем, должны быть внесены в общий реестр с указанием ключевых технологических зависимостей (тема, основные плагины).
Канал экстренных оповещений. Назначены ответственные за мониторинг источников информации об уязвимостях (CVE, WPScan) и доведение их до всей команды в структурированном виде.
Приоритет безопасности для всех активов. Политика регулярных обновлений и отказа от неподдерживаемого ПО распространена на все группы проектов без исключений.
Работа с цифровыми активами - это в том числе и работа с рисками
Своевременная реакция на внешние угрозы и наличие чёткого плана аудита позволяют не просто устранить проблему, но и предотвратить её влияние на бизнес-метрики, главная из которых для нас - стабильный органический трафик.
