Что такое CVE и чем она отличается от CWE?

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

Что такое CVSS и можно ли по нему определить срочность исправления?

CVSS — стандарт FIRST для оценки технических характеристик уязвимости. Использовать только его для определения срочности нельзя: балл не учитывает внешнюю доступность сервиса, критичность сервера, наличие эксплуатации и действующие защитные меры. Также CVSS v3.1 и v4.0 используют разные метрики, поэтому их баллы нельзя считать полностью эквивалентными.

Что такое exploit и означает ли его наличие атаку на сервер?

Exploit — это код или последовательность действий для использования конкретной уязвимости. Нет, наличие публичного proof of concept или сообщения об exploit не доказывает, что сервер уже атакован. Однако доступный практический exploit или достоверные сведения об эксплуатации повышают приоритет проверки и устранения применимой CVE.

Что такое уязвимость нулевого дня?

Уязвимость нулевого дня — это ранее неизвестная разработчику или защитникам уязвимость, раскрытая либо используемая до подготовки исправления и защитных мер. Отсутствие патча у давно известной CVE само по себе не делает её zero-day. В такой ситуации особенно важны временные ограничения доступа и наблюдение.

Почему сканер показывает уязвимость после установки обновления?

Не закрывайте такую находку только по результату сканера или сравнению с upstream-версией продукта. Для Linux проверьте дистрибутив и его выпуск, имя и релиз установленного пакета, используемый репозиторий, а затем сопоставьте их с бюллетенем или трекером безопасности вендора ОС. Поддерживаемые дистрибутивы могут перенести исправление в пакет со старой upstream-версией. Для Windows сопоставьте выпуск и версию ОС, установленное накопительное обновление или иной пакет, указанный Microsoft, а также роль и условия эксплуатации уязвимого компонента. Проверьте, что обнаруженный баннер действительно относится к нужному серверу, а не к балансировщику или reverse proxy. Если CVE неприменима, сохраните обоснование: ссылку на бюллетень, сведения о версии, состоянии функции и дату проверки.

Что делать, если уязвимость не исправляется?

Сначала определите, почему нельзя применить поддерживаемое исправление: патч отсутствует, несовместим с приложением или требует недоступного окна обслуживания. Компенсирующая мера должна уменьшать именно достижимый путь атаки, а не формально закрывать задачу. Например, можно ограничить источники доступа, отключить уязвимую функцию, применить сегментацию, усиленную аутентификацию, дополнительное обнаружение или виртуальный патч в WAF, IPS либо EDR. Перед принятием меры проверьте её применимость к используемому протоколу и фактическому трафику. Firewall, WAF и IPS могут не видеть зашифрованный трафик, допускать другой вектор атаки или блокировать легитимные запросы. Ограничение доступа также не устраняет риск для уже разрешённых пользователей и соседних систем. Зафиксируйте владельца контроля, доказательства его работы, дату следующего пересмотра и условие, при котором будет установлен основной патч.

Управление уязвимостями сервера: CVE, сканирование и приоритизация

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

Различайте CVE, CWE, CVSS, exploit и zero-day

CVE — идентификатор записи об уязвимости в программе CVE. Он нужен, чтобы сопоставить отчёт сканера, бюллетень поставщика, пакет ОС и задачу на устранение. Идентификаторы назначают уполномоченные организации CNA в рамках CVE Program, после чего записи публикуются в CVE List. Этот список не заменяет базу с техническим анализом или бюллетень безопасности производителя.

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

CVSS — стандарт FIRST для оценки технических характеристик уязвимости. Спецификации FIRST определяют актуальные версии и правила расчёта. CVSS v3.1 и CVSS v4.0 используют разные метрики и шкалы представления контекста, поэтому их баллы нельзя без оговорки складывать, сравнивать как полностью эквивалентные или использовать в одной формуле.

Эксплойт — код либо последовательность действий для использования конкретной уязвимости. Наличие публичного доказательства концепции — proof of concept, или достоверного сообщения об эксплуатации усиливает приоритет, но само по себе не доказывает атаку на ваш сервер. Уязвимость нулевого дня — ранее неизвестная разработчику или защитникам уязвимость, раскрытая либо используемая до того, как они успели подготовить исправление и защитные меры. В этот период особенно важны временные ограничения и наблюдение. Одно лишь отсутствие патча у давно известной CVE не делает её zero-day.

1. Составьте область сканирования и назначьте владельцев

Начните с инвентаризации активов, а не с диапазона IP-адресов. IP-сканирование не увидит выключенную виртуальную машину, хост за NAT, временный облачный экземпляр или сервис, опубликованный через балансировщик. Реестр активов должен позволять ответить: что это за сервер, кто принимает решение об изменении, какие сервисы он предоставляет и кому доступен.

Подготовка области проверки

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

1
Соберите источники активов
Сведите данные CMDB или реестра серверов, виртуализации, облачных учётных записей, DNS, систем развёртывания, мониторинга и списков публичных адресов. Для каждого расхождения создайте запись на проверку, а не удаляйте его как дубликат без сопоставления имени, IP, роли и среды.
2
Зафиксируйте паспорт сервера
Укажите уникальный идентификатор, FQDN, IP-адреса, ОС и выпуск, роль, среду, владельца сервиса, технического владельца, критичность актива, допустимое окно обслуживания и способ отката. Для Windows отдельно полезно указать роль сервера; для Linux — дистрибутив, выпуск и источник репозиториев.
3
Опишите точки внешнего доступа
Для каждого опубликованного имени и адреса отметьте порт, протокол, TLS-терминатор, балансировщик или reverse proxy, а также фактический путь до сервера. Внешний endpoint и внутренний сервер могут иметь разный набор уязвимостей: обновление бэкенда не обязательно меняет конфигурацию внешнего узла.
4
Согласуйте безопасные границы сканирования
Определите разрешённые сети, время, контакт для эскалации, критичные сервисы и запретные проверки, если они способны вызвать нагрузку или изменить состояние. После запуска сверяйте число обнаруженных хостов с реестром: отсутствующий актив — отдельная находка процесса инвентаризации.

Сканирование не заменяет реагирование на инцидент

Если есть признаки уже произошедшей эксплуатации — например, web shell, неизвестная учётная запись, подозрительный процесс или тревога EDR, — не начинайте с обычного сканирования и обновления. Эти действия могут изменить следы. Действуйте по процедуре реагирования на взлом сервера.

2. Выберите неаутентифицированное или аутентифицированное сканирование

Сканер уязвимостей без учётных данных видит сервер как удалённый клиент: открытые порты, баннеры, версии, доступные протоколы и отдельные поведенческие признаки. Такой режим подходит для проверки опубликованных веб-сервисов, контроля внешней поверхности атаки и поиска неожиданно доступных интерфейсов. Результат описывает видимость с конкретной точки сканирования и не показывает надёжно все локальные компоненты, установленные исправления и сервисы за промежуточными узлами.

Аутентифицированное сканирование подключается к ОС и обычно точнее проверяет установленные пакеты, обновления, локальную конфигурацию и состояние служб. Такой режим обычно предпочтителен, когда нужно определить, относится ли CVE к конкретному Linux- или Windows-серверу, включая неэкспортируемые в сеть компоненты. При этом применимость можно дополнительно подтверждать локальной проверкой и по бюллетеню производителя. Аутентифицированное сканирование не устраняет полностью ложноположительные и ложноотрицательные результаты: проверка всё равно зависит от доступности учётной записи, актуальности правил и особенностей конфигурации.

Выбор режима проверки

Сценарий	Предпочтительный режим	Что позволяет проверить	Ограничение
Публичный веб-сервис или VPN-шлюз	Неаутентифицированный, с внешней точки	Наблюдаемые с этой точки сервисы, протоколы и признаки некоторых уязвимостей	Не показывает надёжно все локальные пакеты и патчи
Внутренний Linux- или Windows-сервер	Аутентифицированный плюс сетевой по необходимости	Установленные пакеты, обновления, локальные настройки и состояние компонентов	Нужны защищённые реквизиты и разрешённое подключение
Проверка сегментации и неожиданно открытых портов	Неаутентифицированный из нескольких разрешённых сегментов	Различия доступности в зависимости от источника	Не заменяет анализ правил firewall и маршрутизации
Подтверждение исправления CVE в пакете ОС	Аутентифицированный или проверка по бюллетеню ОС	Версию установленного пакета и её соответствие исправленной версии из бюллетеня	Номер upstream-версии может вводить в заблуждение при backport

Учётные данные сканера — чувствительный секрет

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

Greenbone/OpenVAS и Nessus поддерживают аутентифицированные проверки Linux и Windows в поддерживаемых конфигурациях, но способы подключения, требования к правам, доступные проверки и лицензируемые функции зависят от продукта, редакции, версии, способа развёртывания и версии ленты проверок. Точные имена полей, наборы проверок и методы подключения сверяйте с актуальным официальным руководством выбранного сканера и документацией ОС; не переносите настройку между продуктами по аналогии.

3. Запустите проверку и превратите отчёт в список гипотез

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

Сопоставьте каждый результат с конкретным активом, а не только с IP: адреса и DNS-записи меняются.
Сохраните идентификатор CVE, название проверки, обнаруженный продукт, версию, порт или локальный путь проверки, доказательство сканера и дату feed.
Помечайте ошибки подключения, тайм-ауты и неудачную аутентификацию отдельно от отсутствия уязвимостей.
Не закрывайте находку только потому, что сервис не ответил: результат «не проверено» требует повторной проверки, другого маршрута или ручной валидации.

Почему сканер ошибается

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

4. Проверьте применимость CVE к Linux или Windows Server

Валидация находки

Результат — статус «применима», «неприменима», «требует дополнительной проверки» или «риск принят временно» с доказательствами.

1
Сверьте продукт и точную сборку
Сопоставьте название продукта, редакцию, архитектуру, версию и сборку из сервера со списком затронутых версий в бюллетене производителя. Не полагайтесь только на строку баннера: она может быть изменена, скрыта или отражать версию прокси.
2
Проверьте источник пакета и backport в Linux
Для Linux подтвердите дистрибутив, выпуск, имя пакета, релиз пакета и включённый репозиторий. Поддерживаемые дистрибутивы нередко переносят исправление в более старую upstream-версию пакета, поэтому сравнение только с версией исходного проекта ненадёжно. Решение принимайте по бюллетеню и трекеру безопасности вендора ОС, где указаны затронутые и исправленные пакеты.
3
Проверьте применимость исправления в Windows
Для Windows сопоставьте поддерживаемый выпуск и версию ОС, установленное накопительное обновление или иной указанный Microsoft пакет, редакцию и роль сервера. Затем проверьте условия эксплуатации из Microsoft Security Response Center: уязвимый компонент может требовать включённую роль, службу, конкретную конфигурацию, локальный доступ либо сетевой путь.
4
Установите, включена ли уязвимая функция
Проверьте, установлен ли компонент, запущена ли служба, опубликован ли интерфейс, включена ли необходимая функция и достижима ли она для предполагаемого атакующего. Недоступность из интернета не всегда исключает риск: оцените доступ внутренних пользователей, подрядчиков, других сегментов и возможность бокового перемещения.
5
Запишите решение и доказательства
Для применимой CVE создайте задачу на устранение. Для неприменимой — сохраните ссылку на бюллетень, сведения о версии, состоянии функции и дату проверки. Если данных недостаточно, назначьте владельца дополнительной проверки и срок; статус «ложное срабатывание» без обоснования не является решением.

Установка обновлений, работа с репозиториями и перезагрузками рассматриваются отдельно: обновления безопасности Linux и обновления безопасности Windows Server. Настройку общего hardening не следует подменять закрытием одной CVE: для этого есть материалы о Hardening Linux-сервера и hardening Windows Server.

5. Приоритизируйте уязвимости по риску, а не только по CVSS

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

Каталог KEV CISA содержит CVE, для которых CISA располагает достоверными данными об эксплуатации в реальном мире и считает их приоритетными для устранения. Попадание в KEV — сильный сигнал срочности. Отсутствие записи в KEV не означает, что эксплуатации нет или риск отсутствует: каталог не является полным реестром всех атак.

EPSS FIRST оценивает вероятность эксплуатации CVE в ближайшие 30 дней. Score — модельная вероятность, percentile — положение CVE относительно других записей в распределении модели; оба значения зависят от версии модели и даты публикации. Высокий EPSS усиливает приоритет, но не доказывает эксплуатацию конкретной CVE и тем более конкретного сервера.

Факторы приоритизации CVE без универсальной формулы

Фактор	Что повышает приоритет	Что может снизить срочность, но не отменяет проверку
KEV и признаки эксплуатации	CVE есть в KEV, есть подтверждённые сообщения об эксплуатации или доступный практический exploit	Нет записи KEV и нет публичного exploit; это не доказательство безопасности
CVSS	Высокая техническая серьёзность при применимости к серверу	Низкий балл без достижимого пути атаки; всё равно учитывайте последствия
EPSS	Высокая прогнозная вероятность эксплуатации в опубликованной модели	Низкий score; модель не исключает атаку и меняется со временем
Внешняя доступность	Сервис доступен из интернета или широкого недоверенного сегмента	Доступ только из ограниченного сегмента; оцените доступы внутри сети
Критичность актива	Персональные данные, ключевые бизнес-процессы, привилегированные функции, критичная инфраструктура	Тестовая среда с изолированными данными; проверьте отсутствие связей с production
Боковое перемещение	Сервер имеет доверенные связи, привилегированные учётные данные или доступ к другим системам	Сегментация и минимальные права реально проверены и действуют
Патч и компенсирующие меры	Патч доступен, но ещё не установлен; контроля нет или он слабый	Эффективный временный контроль уменьшает окно риска, но требует срока пересмотра

Универсальной очереди для всех организаций нет. Сильными сигналами срочности служат подтверждённая применимость, наличие CVE в KEV и достоверные сведения об эксплуатации, но их нужно сопоставлять с достижимостью уязвимого компонента, возможными последствиями, критичностью актива и эффективностью действующих ограничений. EPSS используйте как прогнозный дополнительный сигнал, а не как замену сведениям о фактической эксплуатации. Поэтому внешняя активно эксплуатируемая CVE, ещё не попавшая в KEV, может оказаться срочнее записи KEV на изолированном активе. Если обнаружены признаки эксплуатации именно на вашем сервере, переходите к процедуре реагирования на инцидент. Для каждой задачи назначьте владельца, дату устранения, обоснование приоритета и зависимость от окна обслуживания.

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

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

Если патча нет, он несовместим с приложением или его нельзя применить сразу, вводят компенсирующий контроль. Это не формальное исключение, а мера, которая уменьшает конкретный путь атаки: ограничение источников доступа, отключение уязвимой функции, сегментация, усиленная аутентификация, дополнительное обнаружение или виртуальный патч в WAF, IPS либо EDR. Его применимость и эффективность нужно проверять для конкретного протокола и трафика.

Компенсирующий контроль не равен исправлению

Firewall, WAF или IPS могут не видеть зашифрованный трафик, обходиться другим вектором или ошибочно блокировать легитимные запросы. Ограничение доступа также не устраняет риск для уже допущенных пользователей и соседних систем. Укажите владельца контроля, дату повторной оценки и условие, при котором будет установлен основной патч.

7. Подтвердите устранение и оформите временное принятие риска

Закрытие задачи по уязвимости

Задачу можно закрыть только после подтверждения факта исправления либо документированного решения по остаточному риску.

1
Проверьте технический результат изменения
Подтвердите установку требуемого обновления или изменение конфигурации по данным ОС, консоли управления обновлениями и журналам развертывания. Проверьте, что сервис работает по заранее определённым критериям: доступность, ключевой сценарий приложения и отсутствие неожиданных ошибок после перезапуска.
2
Повторите уместную проверку
Запустите повторное сканирование тем же или более подходящим методом после обновления ленты проверок. Если находка была подтверждена локально, повторите аутентифицированную проверку либо валидацию по бюллетеню ОС. Для внешней проблемы убедитесь, что проверка идёт с той же внешней точки и к тому же имени сервиса.
3
Разберите оставшийся результат
Если сканер продолжает показывать CVE, не закрывайте задачу автоматически и не повторяйте обновление вслепую. Сверьте версию, наличие backport, кэш результата, путь подключения и условия применимости. При подтверждённой неприменимости приложите доказательства и отметьте дату следующего пересмотра.
4
Оформите исключение, если исправление отложено
Запишите CVE, актив, владельца риска, причину невозможности исправления, оценку последствий и достижимости, действующие компенсирующие меры, дату истечения исключения, план устранения и лицо, уполномоченное принять остаточный риск. Исключение должно быть ограниченным по сроку и регулярно пересматриваться, а не скрывать находку навсегда.
5
Верните актив в регулярный цикл
Обновите реестр активов, статус задачи и срок следующего сканирования. При изменении роли, внешней доступности, владельца, версии ОС или публикации нового бюллетеня пересмотрите приоритет раньше плановой даты.

Минимальный набор данных для одной находки

Храните CVE, актив и его владельца, обнаруженный продукт и сборку, источник и дату доказательства, статус применимости, CVSS с указанием версии, признаки KEV и EPSS с датой, оценку внешней доступности и критичности, решение, срок, результаты повторной проверки и сведения об исключении. Такой учёт позволяет объяснить, почему две CVE с похожими баллами получили разный приоритет.

Термины в статье

CVE: CVE — система идентификаторов публично раскрытых киберуязвимостей, присваивающая каждой записи уникальный номер для сопоставления бюллетеней, сканеров и исправлений.
CVSS: CVSS — стандартная система оценки серьёзности уязвимостей, вычисляющая балл от 0,0 до 10,0 по техническим характеристикам атаки, её последствиям и контексту среды.
CWE: CWE — классификация типов слабостей программного и аппаратного обеспечения, позволяющая соотносить конкретные уязвимости с их классами, а не каталог самих уязвимостей.
EPSS: EPSS — модель оценки вероятности эксплуатации CVE в ближайшие 30 дней, помогающая приоритизировать устранение уязвимостей наряду с их влиянием на активы.
Аутентифицированное сканирование: Аутентифицированное сканирование — проверка уязвимостей с учётными данными, анализирующая конфигурацию и версии ПО изнутри целевой системы.
Бюллетень безопасности: Бюллетень безопасности — официальное уведомление о риске или уязвимости, содержащее сведения о затронутых версиях, последствиях и мерах защиты.
Виртуальный патч: Виртуальный патч — компенсирующая защита, блокирующая попытки эксплуатации известной уязвимости правилами WAF, IPS, EDR или иного средства без изменения уязвимого кода.
Известно эксплуатируемая уязвимость: Известно эксплуатируемая уязвимость — уязвимость с подтверждёнными данными об использовании в атаках, требующая приоритетной оценки и устранения.
Инвентаризация активов: Инвентаризация активов — процесс выявления и ведения учёта ИТ-активов, их владельцев, характеристик, состояния и значимости для организации.
Каталог KEV: Каталог KEV — поддерживаемый CISA перечень CVE-уязвимостей с подтверждённой эксплуатацией, используемый для приоритизации устранения рисков.
Компенсирующий контроль: Компенсирующий контроль — защитная мера, заменяющая недоступный основной контроль и снижающая тот же риск до приемлемого уровня при документированном обосновании.
Критичность актива: Критичность актива — оценка важности ИТ-актива для бизнеса по последствиям его отказа, компрометации или недоступности, определяющая приоритет защиты и восстановления.
Ложноположительное срабатывание: Ложноположительное срабатывание — результат контроля безопасности, ошибочно отмечающий безопасное событие, файл или конфигурацию как угрозу либо нарушение.
Сканер уязвимостей: Сканер уязвимостей — средство автоматизированной проверки активов на известные уязвимости, ошибки конфигурации и несоответствие политикам безопасности.
Сканирование уязвимостей: Сканирование уязвимостей — автоматизированная проверка активов на известные уязвимости, небезопасные настройки и устаревшие компоненты по правилам сканера.
Управление патчами: Управление патчами — процесс учёта, оценки, тестирования, развёртывания и контроля обновлений ПО и прошивок для снижения риска уязвимостей и сбоев.
Управление уязвимостями: Управление уязвимостями — непрерывный процесс выявления, оценки, приоритизации и устранения слабых мест ИТ-активов с контролем результата и остаточного риска.
Уязвимость: Уязвимость — недостаток программного обеспечения, конфигурации или процесса, который при определённых условиях может быть использован для нарушения безопасности.
Уязвимость нулевого дня: Уязвимость нулевого дня — дефект безопасности, для которого на момент публичного раскрытия или эксплуатации ещё нет доступного исправления от разработчика.
Эксплойт: Эксплойт — код, программа или последовательность действий, использующие конкретную уязвимость для выполнения несанкционированного действия в целевой системе.