Что пользователи VM-систем считают качественным сканированием

Скачать исследование в PDF

Введение

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

Чтобы разобраться, что именно пользователи VM-систем вкладывают в понятие «качество сканирования», R‑Vision провела исследование среди инженеров ИБ, CISO, руководителей SOC и технических специалистов, ответственных за эксплуатацию VM-решений. Опрос стал логичным продолжением одного из наших исследований, где 78% респондентов назвали качество сканирования главным фактором при выборе VM-системы.

Методология исследования

Исследование проводилось в сентябре-октябре 2025 года.

Опрос проходил: 

• Во время вебинара «Внутри базы уязвимостей R-Vision VM: источники, обогащение, верификация»
• На отраслевых ИБ-мероприятиях и митапах R-Vision
• Через email-рассылку и лично на встречах с заказчиками и партнерами компании

В опросе приняли участие 92 специалиста из компаний различных отраслей: финансового сектора, промышленности, госсектора, ИТ, телекоммуникаций, энергетики и ритейла.

Размер компаний

Почти половина опрошенных (48%) работают в организациях с численностью от 1 000 до 10 000 сотрудников, ещё 32% — в крупных корпорациях (свыше 10 000 сотрудников). 20% респондентов представляют компании малого масштаба.

Это подтверждает, что VM-решения становятся стандартом не только для корпораций, но и для средних предприятий.

Количество ИТ-активов

37% участников работают в инфраструктурах с 1 000-10 000 активов, 30% — с 10 000-50 000, а 15% — более 50 000 активов. 

Основные результаты исследования

Что пользователи считают  «качественным сканированием на уязвимости»

Большинство респондентов связывают качество сканирования прежде всего с наличием механизмов оперативного обнаружения уязвимостей и актуальностью базы уязвимостей — оба фактора получили оценки выше 9 баллов. Для специалистов важно, чтобы база регулярно обновлялась, оперативно включала новые CVE и рекомендации производителей, а появление критичных уязвимостей быстро отражалось в результатах сканирования.

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

Прозрачность логики сканирования респонденты также отмечают как значимую, но её средняя оценка находится ниже 8 баллов: это важно для доверия к результатам (понимание, как формируются проверки и по каким признакам подтверждается уязвимость), однако по приоритету уступает актуальности и широте охвата. Относительно более низкие оценки факторов, связанных с ложными и пропущенными срабатываниями, указывают на то, что пользователи готовы мириться с некоторым уровнем FP/FN (False Negative и False Positive), если система остается актуальной и обеспечивает видимость уязвимостей по всей ИТ-инфраструктуре.

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

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

Респонденты поставили на первое место контекст и рекомендации по устранению уязвимостей (9,2 балла) — именно этого они ожидают от результата сканирования в первую очередь. Для большинства пользователей важно не просто получить список найденных уязвимостей, а понять, что именно делать с уязвимостью дальше и как оценить достоверность представляемых сканером результатов. Такой результат показывает, что рынок постепенно уходит от восприятия VM-инструментов как чисто технических сканеров и все чаще ожидает от них аналитическую составляющую — помощь в интерпретации результатов и выборе дальнейших действий.

Высокие оценки получили также параметры, связанные с полнотой и детализацией результатов (8,5 и 8,3 соответственно) — пользователи хотят видеть весь перечень обнаруженных уязвимостей с подробными описаниями, источниками, ссылками на эксплойты и другими важными атрибутами уязвимости. Это говорит о том, что компании ценят глубину анализа и стремятся к максимальной информативности отчета, даже если часть выявленных уязвимостей может оказаться ложными срабатываниями. При этом пропущенные уязвимости (FN) воспринимаются как гораздо более серьезная проблема, чем единичные FP.

Приоритизация критичных уязвимостей (8,2) также вошла в число важных факторов, что подчеркивает потребность в инструментах, способных не просто выявлять, но и определять порядок их устранения. Это особенно актуально для крупных организаций с десятками тысяч активов, где автоматическая оценка критичности помогает оптимизировать нагрузку на команды и не терять фокус на действительно важных задачах.

Относительно более низкую оценку получил параметр “только подтвержденные уязвимости (без FP)" — 8 баллов. Это подтверждает вывод выше, что пользователи готовы мириться с определенным уровнем ложных срабатываний, если система обеспечивает полноту, актуальность и понятную интерпретацию данных.

В целом прослеживается тенденция: пользователи VM-систем все чаще рассматривают результат сканирования как инструмент для принятия решений, а не как технический отчет. Главная ценность — не количество найденных уязвимостей, а понятные, структурированные и приоритизированные данные, которые помогают действовать быстрее и увереннее.

Характеристики базы уязвимостей

Респонденты высоко оценили гибкость базы уязвимостей (9,0 баллов) — именно эта характеристика оказалась на первом месте среди всех параметров. Для пользователей важно, чтобы вендор мог оперативно добавлять новые проверки, корректировать возникающие ошибки и адаптировать логику обнаружения с учетом особенностей в ИТ-инфраструктурах клиентов. Такая гибкость воспринимается как показатель зрелости и экспертизы производителя, а также напрямую влияет на доверие к результатам сканирования.

Ненамного отстали по значимости широта покрытия (8,9) и прозрачность логики проверок (8,8). Это говорит о том, что компании хотят видеть базу уязвимостей максимально прозрачной и всеобъемлющей — чтобы она покрывала все используемые технологии, включая отечественные, и позволяла понимать, как именно выполняются проверки. Пользователи хотят понимать, почему уязвимость была выявлена и на основании каких признаков — прозрачность становится частью доверия к инструменту.

Чуть менее приоритетными, но все же значимыми оказались частота обновлений базы (8,4) и количество источников обогащения (8,2). Это указывает на то, что скорость поступления данных и их разнообразие важны, но воспринимаются скорее как следствие гибкости и прозрачности базы, а не самостоятельная цель. Пользователи ждут от вендора регулярных, но обоснованных обновлений, где приоритет отдан качеству и проверенности данных.

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

Важность понимания источников базы уязвимостей

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

Допустимый уровень ложных срабатываний (False Positive)

Большинство пользователей воспринимают FP как неизбежность, но готовы терпеть небольшой уровень ложных срабатываний, если база остаётся актуальной и охватывает максимум технологий.

Почти половина респондентов (46%) считают приемлемым уровень ложных срабатываний до 5%, ещё 19% готовы допустить до 10%. Для 30% участников наличие FP не является проблемой вовсе — они отмечают, что важнее обеспечить максимально полное покрытие инфраструктуры. Лишь 5% опрошенных указали, что любые ложные срабатывания неприемлемы.

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

Основные проблемы сканеров

Пользователям было предложено выбрать несколько вариантов ответов. 

Самой часто упоминаемой проблемой оказались пропуски уязвимостей (False Negative) — их отметили 45 раз. Это подтверждает, что пользователи особенно чувствительны к неполному охвату и считают надежность детектирования ключевым показателем качества сканера.

На втором и третьем местах — недостаток аналитики и отчётности (34) и ложные срабатывания (32). Такое распределение показывает, что пользователи ожидают от VM-инструментов не только технического выявления уязвимостей, но и качественной аналитики, понятных отчетов и возможности интерпретации результатов.

Отсутствие поддержки нужных ОС и ПО (29), а также задержки обновления базы (27) остаются типичными проблемами эксплуатации, особенно в крупных инфраструктурах, где важна оперативность и актуальность базы уязвимостей.

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

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

Как проверить качество сканера на практике

В одном из наших исследований мы уже анализировали, как компании оценивают качество сканирования на этапе пилотных проектов. Тогда 74% участников делали акцент именно на проверке точности детектирования, рассматривая их как ключевые показатели эффективности VM-решений.

Почти все участники — 92% — изучали документацию вендора и заявленное покрытие, 86% проверяли структуру карточек уязвимостей (наличие CVSS, EPSS, ссылок на патчи и эксплойты), 81% анализировали качество и актуальность базы уязвимостей, а 64% отслеживали скорость появления новых записей. Более половины — 62% — проводили повторное сканирование после устранения уязвимостей, чтобы проверить корректность фиксации изменений.

Чтобы помочь систематизировать процесс оценки качества сканирования, специалисты R‑Vision разработали практическую методику, которая позволяет оценить работу сканера по ключевым параметрам — от покрытия и полноты данных в карточках уязвимостей до качества базы и точности детектирования.

Проверка покрытия сканера

При оценке качества сканера важно учитывать, насколько его функциональность охватывает реальные задачи и потребности сканирования ИТ-инфраструктуры компании. Ключевые параметры, на которые стоит смотреть:

• Состав ИТ-инфраструктуры. Перечень используемых ОС, прикладного ПО, СУБД, сетевого и специализированного оборудования.
• Поддерживаемые режимы сканирования. Анализ доступных режимов (например: Audit, Pentest, Compliance) и их соответствия задачам компании.

Пример карты покрытия сканера уязвимостей R-Vision VM

Карточка описания уязвимости. Ключевые атрибуты

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

Среди них:

• Идентификатор уязвимости — уникальный внутренний ID, который обеспечивает отслеживание уязвимости в системе, связывает ее с тикетами и отчетами. Без него возможны дубли и путаница при работе с результатами.

• Название и описание — короткий и понятный заголовок (например, RCE в модуле X) и развёрнутое пояснение сути проблемы: где она возникает, при каких условиях и с какими последствиями. Помогает быстро оценить контекст и потенциальное влияние.

• Критичность и метрики CVSS — оценка опасности уязвимости на уровне вендора или по системе CVSS (версии 2–4). Эти данные дают технический ориентир по риску и помогают проводить последующую самостоятельную оценку приоритета устранения.

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

• Результаты сканирования — описание оснований, по которым сканер определил уязвимость. В карточке должны быть приведены понятные доказательства логики детектирования - например, какая версия ПО обнаружена на хосте и с какой версией выполнялось сравнение.

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

• Рекомендации и ссылки на патчи — конкретные действия по устранению уязвимости: обновление версии, изменение конфигурации, патчи (не все вендоры уязвимого ПО/ОС включают такую информацию в свои базы).  Наличие прямых ссылок на патчи и инструкции экономит время специалистов и снижает риск ошибок. 

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

• Данные из БДУ ФСТЭК России — дополнительный контекст: от рекомендаций по устранению уязвимостей до сведений о проверке обновлений безопасности на наличие программных закладок.

• EPSS (Exploit Prediction Scoring System) — вероятность эксплуатации уязвимости в ближайшее время. Помогает расставлять приоритеты при устранении уязвимостей.

• Трендовые уязвимости - это те уязвимости, которые активно эксплуатируются злоумышленниками в атаках. Используются также при определении приоритетов устранения. Наличие собственных данных по трендовым уязвимостям показывает, что вендор обладает достаточным ресурсом и экспертизой для формирования качественной базы уязвимостей.

• Перевод на русский язык — важен для удобства работы с зарубежным ПО и ускоряет обработку результатов внутри команды.

Качество базы уязвимостей

Если карточка отражает, насколько полно и понятно представлены данные, то база уязвимостей показывает, насколько точно и своевременно они добавляются в продукт. В R‑Vision мы рассматриваем качество базы через несколько ключевых характеристик:

• Частота обновления
  Чем чаще выходят обновления базы уязвимостей, тем меньше вероятность пропустить критичные уязвимости, о которых стало известно лишь недавно. Рекомендуем ориентир — обновления как минимум один раз в сутки (а лучше быстрее).
• Источники данных
  Важно знать, из каких источников формируется и чем обогащается база уязвимостей. Ключевой момент — поддержка фидов вендоров уязвимого ПО/ОС, чтобы обеспечивать качественное определение уязвимостей.
• Принципы детектирования
  Некоторые сканеры определяют уязвимости только по правилам, описанным в базах агрегаторах уязвимостей (например, NVD), не опираясь на данные и рекомендации производителей ПО. Из-за этого часть проверок может быть некорректной — логика определения уязвимостей у разных вендоров часто отличается. Качественная база формирует детект комплексно: учитывает не только версии ПО или ОС, но и дополнительные параметры. Примеры некоторых из них мы приведем ниже.
• Технологические партнерства
  Некоторые вендоры предоставляют данные по своим уязвимостям через закрытые партнерские каналы и не публикуют их открыто. Если в VM-решении заявлена поддержка обнаружения уязвимостей в конкретном источнике (например, отечественном производителе), желательно убедиться в существовании партнерства между ними или получить иные доказательства наличия доступа вендора VM к этим данным.
• Развитие базы уязвимостей
  Одним из важных параметров является скорость добавления новых источников — как по плану развития (RoadMap) самого вендора, так и по запросам клиентов. Если компании требуется поддержка дополнительных источников, уточните у вендора, предусмотрено ли их добавление и в какие сроки он готов реализовать такую интеграцию. 

Качество детектирования уязвимостей 

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

Обновления пакетов вендором

Некоторые производители ОС (например, RHEL, Ubuntu, Debian) исправляют уязвимость, не меняя основную версию пакета - только номер сборки. Если сканер ориентируется лишь на версию, он может ошибочно посчитать систему уязвимой. Качественный сканер учитывает номер сборки и историю изменений пакета, поэтому не отмечает исправленные версии как уязвимые.

Например, в базе NVD указано, что уязвимости CVE-2023-4736 подвержены все версии vim ниже 9.0.1833:

Однако в Debian 12 (bookworm) эта уязвимость уже исправлена в пакете vim 9.0.1378-2+deb12u2.

Соответственно, если сканер не учитывает наличие подобных обновлений для пакетов и ориентируется только на данные NVD, он посчитает ПО уязвимым, хотя на самом деле проблема уже закрыта.

Учёт окружения

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

Например критическая уязвимость CVE-2021-24078 связана со службой DNS-сервера в Windows и позволяет нарушителю выполнить произвольный код.

Если сканер проверяет данную уязвимость только по отсутствию установленного пакета обновления Microsoft, но не учитывает, что служба DNS может быть отключена, он отметит хост как уязвимый, что автоматически может повлиять на приоритеты устранения уязвимости.

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

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

Кумулятивные обновления Microsoft

В Windows уязвимости часто устраняются через кумулятивные апдейты, которые включают десятки исправлений сразу. Сканеры, не умеющие корректно учитывать такие обновления, могут ошибочно отмечать закрытые уязвимости как актуальные. Надежный сканер определяет наличие установленных KB (Knowledge Base) или номер актуальной сборки Windows и корректно интерпретирует, какие уязвимости уже устранены. 

Вывод

В данном исследовании мы ставили цель разобраться, как специалисты по ИБ и ИТ сегодня воспринимают качество сканирования и какие характеристики делают VM-систему надежным инструментом.

Ответы респондентов и проведенные пилотные проекты показывают, что все больше компаний стали уделять пристальное внимание именно качеству сканирования. Результаты сканирования постепенно перестают восприниматься как данность: их начинают анализировать более тщательно.

Именно поэтому мы дополнили исследование практической методикой оценки качества сканирования — чтобы перевести эти ожидания в конкретные критерии, по которым можно оценить надежность выбираемого VM-решения.