Обновления и управление уязвимостями

12 мин чтения·Для руководителя и лидера безопасности

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

История типовая. Большинство успешных взломов — не экзотические атаки нулевого дня, а эксплуатация давно известных уязвимостей с готовыми публичными эксплойтами. Злоумышленники автоматически сканируют интернет в поисках устаревшего ПО — и находят его в считаные часы после публикации CVE.

Задача лидер безопасности — лидер безопасности (сотрудник, который берёт на себя вопросы информационной безопасности в команде как дополнительную зону ответственности) — выстроить процесс, при котором уязвимости обнаруживаются и устраняются до того, как ими воспользуются. Ваша задача как руководителя — поддержать этот процесс ресурсами и полномочиями.

Почему обновления откладываются

Все понимают, что обновлять ПО нужно. Почему же этого не делают?

• «Может сломаться». После одного-двух неудачных обновлений команда начинает избегать обновлений. Накопленный долг растёт месяцами.

• Нет ответственного. Разработчики думают, что этим занимается DevOps. DevOps думает, что разработчики следят за зависимостями. В итоге не следит никто.

• Нет видимости. Никто не знает, какие версии ПО запущены, и не отслеживает CVE, которые затрагивают именно вашу инфраструктуру.

• Это неинтересная работа. Обновления — рутина без очевидного результата. Когда есть срочные задачи, обновления уходят в конец списка.

Лидер безопасности не занимается установкой каждого патча лично — он создаёт процесс и систему ответственности, при которых обновления происходят своевременно.

Два типа обновлений

Операционные системы и инфраструктура

Серверы, виртуальные машины, контейнеры, управляемые сервисы в облаке. Обновления ядра Linux, системных пакетов, базовых образов Docker.

Кто отвечает: DevOps-инженеры, системные администраторы.

Стратегия: максимальная автоматизация, ручные обновления по расписанию в технологические окна.

Риск при игнорировании: удалённое выполнение кода, захват прав администратора, полная компрометация системы.

Зависимости приложений

Библиотеки и пакеты, которые использует ваш код: npm-пакеты, Python-библиотеки, Java-зависимости, Go-модули.

Кто отвечает: разработчики, но часто — никто конкретно.

Стратегия: автоматические проверки в CI/CD, регулярный цикл ревью зависимостей.

Риск при игнорировании: атаки на цепочку поставок, известные уязвимости в используемых библиотеках.

Полностью обновлённая ОС не защитит, если в приложении уязвимая версия библиотеки. Оба направления важны.

Автоматические обновления: что требовать от команды

Главная ошибка — полагаться на ручные обновления. Когда обновление требует чьих-то усилий, оно откладывается. Задача — автоматизировать всё, что не требует ручного решения.

Серверы и инфраструктура

Для серверов под управлением Linux можно включить автоматическую установку обновлений безопасности — без участия человека. Обновления, которые не затрагивают работу сервисов, устанавливаются ночью; те, что требуют перезагрузки, — в согласованное техническое окно.

Что требовать от команды:

• Автоматические обновления безопасности включены на всех серверах.
• Журналы обновлений проверяются еженедельно — чтобы убедиться, что процесс реально работает, а не только настроен.
• Любой сервер, исключённый из автообновлений, задокументирован с обоснованием и компенсирующими мерами.
• Перезагрузки после обновлений ядра выполняются — работа на необновлённом ядре снижает защиту.

Для облачной инфраструктуры (Yandex Cloud, VK Cloud, Selectel, Cloud.ru) управляемые сервисы обновляет провайдер — уточните у команды, включены ли автоматические maintenance windows для баз данных, Kubernetes-кластеров и других управляемых сервисов.

Контейнеры

Образы Docker наследуют уязвимости базового образа. Образ двухлетней давности — это два года непатченных уязвимостей.

Что требовать от команды:

• Еженедельная пересборка контейнеров с обновлёнными базовыми образами, даже если код не изменился.
• Использование минимальных базовых образов (slim, alpine, distroless) — меньше пакетов, меньше уязвимостей.
• Сканирование образов перед деплоем — любой высококритичный или критичный результат сканера блокирует выкладку.

Зависимости приложений

Вместо ручного мониторинга новых версий — инструменты автоматического обнаружения обновлений.

Российские и нейтральные инструменты для SCA (анализ состава ПО):

• CodeScoring — российское решение для анализа зависимостей и лицензионного комплаенса, интегрируется с GitLab CE, Gitea, GitFlic, GitVerse.
• Solar appScreener — российский комплекс SAST/DAST/SCA от ГК «Солар».
• Dependabot / Renovate в self-hosted GitLab CE или Gitea — допустимые open-source инструменты для автоматических PR с обновлениями.
• OWASP Dependency-Check — бесплатный, подходит для Java, .NET, Node.js, Python.

Что это даёт бизнесу: инструмент автоматически создаёт задачи на обновление уязвимых зависимостей. Разработчику не нужно помнить о проверках — система сама уведомляет, когда нужно обновить пакет. Ваша задача — убедиться, что эти задачи не игнорируются неделями.

Сканирование уязвимостей: что использовать

Автоматические обновления — только первый уровень. Второй — систематическое сканирование на уязвимости.

Сканирование инфраструктуры

Для малого и среднего бизнеса подходят:

• MaxPatrol VM / XSpider (Positive Technologies) — российские решения для управления уязвимостями, есть сертификаты ФСТЭК. MaxPatrol VM — для непрерывного мониторинга; XSpider — для периодических проверок.
• RedCheck (Алтэкс-Софт) — сертифицированный российский сканер, подходит для проверки соответствия стандартам ФСТЭК.
• Сканер-ВС (Эшелон) — сертифицированный сканер, востребован в госсекторе и организациях с требованиями регуляторов.
• OpenVAS/Greenbone — бесплатный open-source сканер, подходит для небольших команд без бюджета на коммерческие решения.

Сканирование контейнеров

• Trivy (open-source, Aqua Security) — бесплатный, сканирует образы Docker, файловые системы, Kubernetes-манифесты. Интегрируется в CI/CD.
• Luntry — российское решение для безопасности контейнеров и Kubernetes.
• PT Container Security (Positive Technologies) — для крупных инфраструктур с требованиями к сертификации.

Как выбрать

Для небольшой команды, начинающей с нуля: OpenVAS или Trivy — бесплатно, без сложной инсталляции, дают понимание картины. Когда появляются регуляторные требования (152-ФЗ, КИИ) или нужна централизованная отчётность — переходите на MaxPatrol VM или RedCheck.

Мониторинг CVE: держать руку на пульсе

Сканеры проверяют ваши системы. Но нужно также отслеживать новые уязвимости, которые появляются каждую неделю.

Первичный источник для России — БДУ ФСТЭК

БДУ ФСТЭК (Банк данных угроз безопасности информации) — официальный российский реестр уязвимостей. Ведётся ФСТЭК России (Федеральной службой по техническому и экспортному контролю). Международные идентификаторы CVE и оценки CVSS здесь тоже присутствуют, но реестр дополнен российской аналитикой и привязан к российской нормативной базе.

Лидер безопасности должен регулярно проверять БДУ на уязвимости, затрагивающие используемый стек: языки программирования, фреймворки, СУБД, серверное ПО.

Что ещё отслеживать

• Бюллетени безопасности вендоров — у каждого крупного проекта (Linux-дистрибутив, PostgreSQL, nginx, используемые фреймворки) есть страница с уведомлениями об уязвимостях. Подпишитесь на RSS или email-рассылки для критичных зависимостей.
• Аналитические публикации — Positive Technologies, ГК «Солар» (Solar JSOC), BI.ZONE, F.A.C.C.T. регулярно публикуют отчёты об актуальных угрозах.
• Уведомления вашего сканера — если вы используете MaxPatrol VM или аналог, настройте автоматические оповещения о новых критичных уязвимостях в вашей инфраструктуре.

Еженедельный обзор CVE

Лидер безопасности выделяет 30 минут раз в неделю:

1. Проверяет новые уязвимости в сканере и системе отслеживания зависимостей.
2. Проверяет БДУ ФСТЭК на записи, релевантные вашему стеку.
3. Просматривает уведомления вендоров по критичным компонентам.
4. Расставляет приоритеты: что патчить на этой неделе, что — в течение месяца.

Цель — не прочитать каждый CVE, а не пропустить критичные.

Приоритизация: что патчить и когда

Уязвимости появляются быстрее, чем их можно патчить. Нужна система приоритетов.

Немедленно (24–48 часов)

• Критичная уязвимость с активной эксплуатацией в реальных атаках.
• Уязвимость в интернет-доступных системах с оценкой CVSS 9.0 и выше.
• Уязвимость в интернет-доступных системах, для которой опубликован рабочий эксплойт.

В течение недели

• Высокий уровень CVSS (7.0–8.9), нет данных об активной эксплуатации.
• Затрагивает внутренние системы с чувствительными данными.
• Есть публичный proof-of-concept.

В течение месяца

• Средний уровень (4.0–6.9).
• Требует специфических условий для эксплуатации.
• Не затрагивает системы с критичными данными.

Регулярный цикл

• Низкий уровень (ниже 4.0).
• Теоретические уязвимости без практических эксплойтов.

Как оценить реальный риск CVE

Когда появляется уязвимость, важны не только CVSS-балл, но и несколько вопросов:

Используете ли вы затронутый компонент? Уязвимость в mod_proxy Apache не затрагивает вас, если вы используете nginx.

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

Компонент доступен из интернета? Уязвимость во внутренней БД, недоступной снаружи, менее срочна, чем аналогичная в публичном API.

Есть ли компенсирующие меры? WAF, сегментация сети, отсутствие интернет-доступа снижают реальный риск.

Читайте оригинальный advisory вендора — не только заголовки новостей. Там написано, какие версии затронуты, какие есть временные меры, если обновление пока невозможно.

Управленческая ответственность: кто и за что отвечает

Обновления не происходят без закреплённой ответственности.

Реестр ответственных за обновления

Лидер безопасности ведёт и актуализирует таблицу ответственных:

Система	Ответственный	Частота обновлений	Последнее обновление
Серверы (ОС)	DevOps-инженер	Еженедельно (авто) + ежемесячно вручную	—
Базовые образы Docker	Каждая команда	Еженедельная пересборка	—
npm-зависимости	Фронтенд-команда	По уведомлениям CodeScoring	—
Python-зависимости	Бэкенд-команда	По уведомлениям CodeScoring	—
СУБД PostgreSQL	DevOps-инженер	Квартально или критичные патчи	—
Облачные сервисы	DevOps-инженер	По уведомлениям провайдера	—

Долг по обновлениям

Лидер безопасности ведёт журнал просроченных обновлений:

Компонент	Текущая версия	Актуальная версия	Дней отставания	Причина задержки
Пример: React	17	18	180	Требует тестирования из-за breaking changes

Всё, что висит больше 90 дней без обоснования, — точка разговора с руководством: обновить, зафиксировать принятый риск или заменить зависимость.

Ежемесячная встреча по обновлениям

15 минут раз в месяц. Участники: лидер безопасности, DevOps-лид, представитель разработки.

Повестка:

1. Критичные CVE за прошедший месяц — 2 мин.
2. Журнал долга: что просрочено и почему — 3 мин.
3. Приоритеты на следующий месяц — 5 мин.
4. Разбор сбоев обновлений и откатов — 5 мин.

Регулярная видимость предотвращает накопление критичного долга.

Практические рекомендации для руководителя

Правило «не в пятницу»

Не разрешайте применять обновления в пятницу после обеда. Если что-то сломается — команда либо работает в выходные, либо оставляет проблему до понедельника. Лучшее время — вторник-среда утром: есть несколько дней до выходных, чтобы стабилизировать ситуацию.

Тестирование автоматических обновлений

Настроить автообновления — не то же самое, что убедиться, что они работают. Лидер безопасности должен периодически проверять журналы обновлений: если они пустые или последняя запись — трёхмесячной давности, автоматика не работает.

Канареечные обновления

Для критичных обновлений: сначала обновить один сервер, подождать 15–30 минут, убедиться в стабильности — затем остальные. Это предотвращает одновременный сбой всей инфраструктуры.

Процедура отката

До любого значимого обновления команда должна знать, как откатиться. Это означает:

• Для серверов: снапшот ВМ перед обновлением ОС.
• Для баз данных: резервная копия до обновления версии СУБД — без исключений.
• Для контейнеров: предыдущий образ помечен тегом и доступен для быстрого переката.

Снапшоты в Yandex Cloud, VK Cloud, Selectel создаются за несколько минут. Это дешёвая страховка.

Управление зависимостями в CI/CD

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

Управленческое задание

Это задание для лидера безопасности — с вашей поддержкой в виде выделенного времени и полномочий.

Блок 1 — аудит и автоматизация (3–4 часа):

1. Составить реестр всей инфраструктуры: серверы, сервисы, СУБД, облачные ресурсы.
2. Проверить, включены ли автоматические обновления безопасности на серверах. Задокументировать исключения.
3. Убедиться, что контейнеры пересобираются регулярно.
4. Подключить CodeScoring или аналогичный инструмент к репозиториям.

Блок 2 — мониторинг CVE (2 часа):

1. Задокументировать технологический стек (языки, фреймворки, СУБД, версии).
2. Настроить подписку на уведомления БДУ ФСТЭК для критичных компонентов стека.
3. Поставить еженедельный повтор в календаре: «Обзор CVE» — 30 минут.

Блок 3 — ответственность (1 час):

1. Заполнить реестр ответственных за обновления.
2. Запланировать ежемесячную встречу по обновлениям.

Артефакты на выходе:

• Автоматические обновления включены и подтверждены журналами.
• SCA-инструмент подключён к репозиториям.
• Технологический стек задокументирован.
• Реестр ответственных заполнен.
• Еженедельный CVE-обзор в календаре.

✓Управленческий чек-лист

Контрольные точки для руководителя — «что должно быть готово»:

Автоматические обновления

• Автообновления безопасности включены на всех серверах (или исключения задокументированы).
• Лидер безопасности периодически проверяет журналы — убеждается, что автоматика работает.
• Контейнеры пересобираются по расписанию.

Сканирование зависимостей

• SCA-инструмент (CodeScoring, Solar appScreener или аналог) подключён к репозиториям.
• Критичные уязвимости в зависимостях блокируют деплой или требуют явного решения.
• Команда реагирует на уведомления в разумные сроки.

Мониторинг CVE

• Технологический стек задокументирован.
• Настроен мониторинг БДУ ФСТЭК для критичных компонентов.
• Еженедельный CVE-обзор в расписании лидера безопасности.
• Критичные CVE отрабатываются в течение 24–48 часов.

Ответственность

• Реестр ответственных за обновления ведётся и актуален.
• Долг по обновлениям отслеживается.
• Ежемесячная встреча по обновлениям запланирована.

См. также

• Поверхность атаки — что из этого видно снаружи
• Разведка угроз — как узнавать об уязвимостях раньше
• Безопасность CI/CD — проверка зависимостей в конвейере

Что дальше

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

Следующая глава — безопасность электронной почты: SPF, DKIM, DMARC и защита компании от фишинга и подделки писем от вашего домена.