Приказы ФСТЭК №117, №21, №239 обязывают проводить анализ уязвимостей: в № 21 это мера АНЗ.1, в № 239 — АУД.2, в № 117 — мероприятие по управлению уязвимостями. Значит, нужен сканер уязвимостей, а для ГИС — сертифицированный. Но выбор не очевиден: MaxPatrol VM, RedCheck, XSpider, ScanFactory — у каждого своя ниша, своя архитектура, своя цена. В этой статье: требования регулятора к сканированию, обзор четырёх российских сканеров уязвимостей с сертификатом ФСТЭК, сравнительная таблица по ключевым критериям. И главное: почему сканер уязвимостей без SGRC — это просто список CVE, который не помогает ни приоритизировать риски, ни закрыть проверку ФСТЭК.
Сканер уязвимостей (сканер безопасности, vulnerability scanner) — программа, которая проверяет хосты и сеть по базам известных уязвимостей (БДУ ФСТЭК, CVE) и выдаёт отчёт с найденными записями. Сканирование уязвимостей — сама процедура такой проверки; для ГИС, ИСПДн с УЗ-1 — УЗ-3 и значимых объектов КИИ она обязательна, а непрерывный мониторинг уязвимостей — её регулярное повторение с контролем устранения. Сетевой сканер безопасности проверяет узлы снаружи, по открытым портам и сервисам; агентный — изнутри, по установленному ПО. Ниже — сравнение сканеров безопасности по десяти критериям: MaxPatrol VM, RedCheck, XSpider, ScanFactory и бесплатный ScanOVAL.
Требования ФСТЭК к анализу уязвимостей
Нормативная база: где прописан анализ уязвимостей
Анализ уязвимостей — обязательная мера в трёх основных приказах ФСТЭК.
Приказ ФСТЭК №117 (государственные информационные системы): управление уязвимостями — обязательное мероприятие по защите информации (подп. «в» п. 34). Пункт 38 требует выявлять уязвимости, оценивать их критичность, определять методы и приоритеты устранения и контролировать устранение, пункт 39 — управлять обновлениями.
Приказ ФСТЭК №21 (информационные системы персональных данных): мера АНЗ.1 с аналогичной формулировкой. Входит в базовый набор для ИСПДн с УЗ-1 — УЗ-3. Для УЗ-4 в базовом наборе её нет.
Приказ ФСТЭК №239 (критическая информационная инфраструктура): мера АУД.2 «Анализ уязвимостей и их устранение» обязательна для значимых объектов КИИ всех категорий — первой, второй и третьей. Требует регулярного проведения с документированием. Рядом — ОПО.4 «Установка обновлений программного обеспечения».
По всем трём приказам организация обязана не просто провести сканирование, но и задокументировать результаты и факты устранения уязвимостей. Без этого выполнение меры нечем подтвердить на проверке.
Почему нужен именно сертифицированный сканер
Технически сканировать можно любым инструментом — Nessus, OpenVAS, даже самописными скриптами. Но с точки зрения регулятора важно другое.
Для ГИС приказ № 117 требует сертифицированные средства защиты информации (п. 71). Для значимых объектов КИИ сертификация — одна из трёх форм оценки соответствия, наряду с испытаниями и приёмкой. Обязательна она в случаях, установленных законом, или по решению субъекта КИИ (п. 28 приказа № 239).
Сертификат ФСТЭК (профиль защиты ОУД4 или выше) подтверждает:
- корректность алгоритмов детектирования уязвимостей;
- соответствие методике анализа уязвимостей ФСТЭК;
- поддержку базы данных угроз и уязвимостей (БДУ ФСТЭК).
Для организаций с ГИС К1/К2 и значимых объектов КИИ 1-й категории использование сертифицированного ФСТЭК сканера — жёсткое требование, а не рекомендация.
Дополнительный аргумент: российские сканеры с сертификатом ФСТЭК поддерживают проверку по БДУ ФСТЭК — официальной базе уязвимостей ФСТЭК. Инспектор ожидает именно эти идентификаторы (BDU:XXXX-XXXXX), а не только CVE в американском формате.
💡 Совет: сканер находит уязвимости, но не управляет их устранением. VM-модуль КиберОснова принимает отчёты сканеров, сверяет с БДУ ФСТЭК и раздаёт задачи с контролем сроков по №117 — посмотрите демо.
Что теперь должно храниться после контроля защищённости
С 1 сентября 2026 года приказ ФСТЭК России от 27.02.2026 № 60 (Минюст 24.06.2026, № 87202) изменил Порядок аттестации, утверждённый приказом № 77. Для тех, кто эксплуатирует аттестованные объекты, поменялись три вещи сразу. Чем контроль проводится, что по его итогам оформляется и как часто это уходит регулятору.
Методы названы прямо. Новый пункт 31¹: контроль уровня защищённости информации на аттестованном объекте проводится методами «анализ уязвимостей; тестирование на проникновение». Перечень закрытый: ни «в том числе», ни «может включать» в норме нет. Сканирование, о котором идёт речь в этой статье, стало обязательной частью процедуры.
Отчётность стала строже по срокам, мягче по частоте. Пункт 32 в новой редакции: отчёт представляется во ФСТЭК не реже одного раза в три года и в течение 5 рабочих дней с даты завершения контроля. Раньше было раз в два года и без срока подачи.
Состав отчёта — требование к данным, а не к оформлению
Новый пункт 31² перечисляет, что должно быть в отчёте (протоколе) по результатам контроля:
- наименование объекта информатизации и его назначение, состав программно-технических, программных средств и средств защиты информации;
- класс защищённости информационной системы, категория значимости значимого объекта;
- фамилии, имена, отчества и должности экспертов, проводивших контроль;
- срок проведения контроля;
- дата и номер аттестата соответствия;
- порядок проведения работ по анализу уязвимостей и их результаты;
- порядок проведения работ по тестированию на проникновение и их результаты.
Отчёт подписывают специалисты, проводившие контроль, и утверждает руководитель структурного подразделения органа по аттестации либо работники государственного органа.
Два последних подпункта тяжелее остальных для организации без системы учёта. Итогового вывода «уязвимостей не выявлено» недостаточно. Нужен порядок работ и результаты: что сканировали, каким инструментом, в какой период, что нашли и что с этим сделали. Через три года, к следующему контролю, эти данные нужно будет предъявить. Восстановить их задним числом не выйдет.
Что это означает для учёта
Состав объекта и средств защиты, класс защищённости, реквизиты аттестата, история сканирований, отработка найденного. Всё это обычно живёт в разрозненных таблицах и почте. Требование пункта 31² превращает их в обязательную доказательную базу с трёхлетним горизонтом хранения.
Практический минимум, который стоит завести до первого контроля по новым правилам:
- реестр объектов информатизации с классом защищённости и реквизитами аттестата;
- журнал работ по анализу уязвимостей: инструмент, период, охват, результат;
- журнал работ по тестированию на проникновение с тем же составом полей;
- связь «уязвимость → принятое решение → срок устранения → подтверждение», чтобы результат читался, а не реконструировался;
- календарь: три года от даты завершения предыдущего контроля и пять рабочих дней на подачу отчёта.
Первые два пункта закрываются связкой реестра ИТ-активов и модуля БДУ ФСТЭК. Сканирования привязываются к объектам, найденное к записям банка данных угроз, решения по каждой уязвимости остаются в системе с датами.
Порядок самой аттестации и подготовку к ней разбирает отдельный материал коллег. Тестирование на проникновение теперь входит в обязательные методы контроля и проводится как отдельная услуга. Своими силами закрыть этот метод обычно не выходит.
Обзор российских сканеров уязвимостей
MaxPatrol VM (Positive Technologies)
Полное название: MaxPatrol Vulnerability Management.
Архитектура. Централизованная платформа с агентным и безагентным сбором данных. Архитектура трёхзвенная: сервер управления, сканирующие узлы (могут быть распределены по сегментам сети), консоль управления. Поддерживает изолированные сегменты — сканирующий узел разворачивается внутри, данные передаются на центральный сервер.
Принцип работы. Continuous Vulnerability Management — непрерывный мониторинг. Активы обнаруживаются автоматически, база уязвимостей обновляется регулярно. Новая уязвимость появилась в БДУ или NVD — система автоматически проверяет, затронуты ли активы, без ожидания следующего плановoго сканирования.
Ключевые возможности:
- Приоритизация по ExploitabilityScore с учётом наличия публичных эксплойтов;
- Встроенная поддержка БДУ ФСТЭК;
- Интеграция с MaxPatrol SIEM для корреляции уязвимостей с событиями безопасности;
- Интеграция с PT Network Attack Discovery;
- Покрытие платформ: Windows, Linux, сетевое оборудование, СУБД, веб-приложения;
- API для интеграции с SGRC-платформами.
Сертификация ФСТЭК: да, сертификат ФСТЭК России.
Для кого: крупные организации (от 50 активов), SOC-команды, предприятия с непрерывным мониторингом. Оптимален для субъектов КИИ 1-й категории, где требуется continuous VM с полным документированием.
Позиция на рынке: флагманский продукт Positive Technologies по управлению уязвимостями. Дороже XSpider, но функциональнее по всем параметрам.
RedCheck (АЛТЭКС-СОФТ)
Разработчик: АЛТЭКС-СОФТ — российская компания, специализирующаяся на средствах анализа защищённости.
Архитектура. Клиент-серверная. Сервер RedCheck управляет задачами сканирования, хранит результаты, формирует отчёты. Поддерживает агентный и безагентный режимы: безагентное сканирование по сети, агентное — для изолированных узлов или когда нужно снизить нагрузку на сеть.
Ключевые возможности:
- Нативная поддержка БДУ ФСТЭК как основного источника уязвимостей — важно при взаимодействии с проверяющими;
- Compliance-аудит по OVAL-профилям: проверка настроек ОС, СУБД, сетевого оборудования на соответствие требованиям безопасности;
- Покрытие российского ПО: 1С, Astra Linux, ALT Linux, СУБД PostgreSQL, Apache-решения — существенное преимущество перед западными аналогами;
- Формирование отчётов в формате, привычном для ФСТЭК;
- Интеграция с SIEM через Syslog и API.
Сертификация ФСТЭК: да.
Для кого: госорганы, субъекты КИИ, организации, работающие преимущественно на российском ПО. Оптимален там, где проверяющий ожидает данные именно из БДУ ФСТЭК, а не CVE NVD.
Позиция на рынке: один из самых распространённых сертифицированных сканеров в госсекторе РФ. Баланс функциональности и стоимости.
XSpider (Positive Technologies)
История и позиция. Один из первых российских сканеров уязвимостей, на рынке с начала 2000-х. Предшественник MaxPatrol в линейке Positive Technologies.
Архитектура. Автономный продукт без сложной серверной инфраструктуры. Устанавливается на рабочую станцию или сервер, сканирует сеть по расписанию или по запросу.
Ключевые возможности:
- Обнаружение открытых портов и сервисов;
- Проверка уязвимостей сетевых сервисов, веб-приложений, ОС;
- Периодическое сканирование с отчётами в HTML и XML;
- Поддержка БДУ ФСТЭК;
- Простой интерфейс — минимальный порог входа.
Сертификация ФСТЭК: да.
Для кого: небольшие организации (до 50 активов), которым нужен базовый анализ сетевого периметра и внутренней инфраструктуры. Подходит для анализа уязвимостей по требованиям ФСТЭК при ограниченном бюджете. Continuous VM не поддерживает — только периодическое сканирование.
Ограничение: функциональность ниже MaxPatrol VM, нет агентного сбора, нет встроенной приоритизации по риску. Для средних и крупных организаций возможностей недостаточно.
ScanFactory
Позиция. SaaS-сканер внешнего периметра. Облачная модель доставки — не требует инфраструктуры у клиента.
Архитектура. Облачный сервис с веб-интерфейсом. Сканирование внешнего периметра: домены, IP-адреса, веб-приложения, API. Автоматические уведомления о новых уязвимостях.
Ключевые возможности:
- Быстрый старт: добавил домен — получил отчёт через часы;
- Непрерывный мониторинг внешнего периметра без инфраструктуры;
- API для интеграции с DevSecOps-пайплайнами;
- Автоматические уведомления при обнаружении критических уязвимостей;
- Удобно для организаций с развитым веб-периметром.
Сертификация ФСТЭК: уточнять актуальную информацию на сайте производителя — статус может меняться.
Для кого: DevSecOps-команды, организации с активным веб-периметром, стартапы. Не подходит как основной инструмент для ГИС и КИИ — без подтверждённой сертификации ФСТЭК.
Ограничение: облачный сервис не подходит для изолированных сегментов сети. Внутренняя инфраструктура не сканируется.
Сравнение сканеров уязвимостей ФСТЭК
Ключевая таблица — перед выбором сканера сверьтесь с требованиями своей организации.
| Критерий | MaxPatrol VM | RedCheck | XSpider | ScanFactory | ScanOVAL |
|---|---|---|---|---|---|
| Сертификат ФСТЭК (СЗИ) | ✅ Да | ✅ Да | ✅ Да | Уточнять | ❌ Нет |
| Цена | Платный | Платный | Платный | Платный | Бесплатно |
| Поддержка БДУ ФСТЭК | ✅ Да | ✅ Да (основной источник) | ✅ Да | Частично | ✅ Да (OVAL) |
| Поддержка CVE NVD | ✅ Да | ✅ Да | ✅ Да | ✅ Да | Частично |
| Continuous VM | ✅ Да | ❌ Нет | ❌ Нет | ✅ Да (периметр) | ❌ Нет |
| Агентное сканирование | ✅ Да | ✅ Да | ❌ Нет | ❌ Нет | ❌ Нет |
| Сетевое / удалённое | ✅ Да | ✅ Да | ✅ Да | ✅ Да | ❌ Только локальный хост |
| Покрытие российского ПО | Высокое | Высокое | Среднее | Среднее | Базовое (ОС) |
| CLI / автоматизация | ✅ Да | ✅ Да | ✅ Да | ✅ Да | ❌ Только GUI |
| Закрывает анализ уязвимостей формально | ✅ Да | ✅ Да | ✅ Да | Уточнять | ❌ Нет |
| Целевая аудитория | Enterprise / SOC | Госсектор / КИИ | SMB | DevSecOps | Разовая проверка |
| Модель развёртывания | On-premise | On-premise | On-premise | SaaS | On-premise |
Вывод по таблице. Для субъектов КИИ и ГИС с высоким классом защищённости выбор между MaxPatrol VM и RedCheck. MaxPatrol VM — за непрерывный мониторинг и экосистему Positive Technologies. RedCheck — за нативную работу с БДУ ФСТЭК и широкое покрытие российского ПО. XSpider — разумный выбор для небольших организаций с ограниченным бюджетом. ScanFactory — дополнение для внешнего периметра и DevSecOps. ScanOVAL — бесплатный инструмент для разовых проверок или промежуточного контроля, но не заменяет сертифицированный сканер для формального закрытия меры анализа уязвимостей.
Рейтинг сканеров уязвимостей 2026 по десяти критериям
Если свести таблицу к одному числу, получится рейтинг. Считаем совпадения по десяти критериям выше (сертификат, БДУ, CVE, непрерывный режим, агент, сеть, покрытие российского ПО, CLI, формальное закрытие анализа уязвимостей, модель развёртывания под изолированный контур). Цена в счёт не идёт.
- MaxPatrol VM — 9 из 10. Единственный сканер в списке с непрерывным режимом, агентом и высоким покрытием российского ПО одновременно. Минус один балл за цену и порог входа.
- RedCheck — 8 из 10. Всё то же без непрерывного режима; для госсектора и КИИ часто первый выбор из-за нативной работы с БДУ.
- XSpider — 6 из 10. Сертификат, сеть, CLI есть; агента нет, покрытие российского ПО среднее.
- ScanFactory — 5 из 10. Сильный внешний периметр и непрерывный режим, но SaaS-модель не подходит изолированным сегментам, а сертификат нужно уточнять.
- ScanOVAL — 3 из 10. Бесплатный, с БДУ, но только локальный хост, только GUI и без сертификата СЗИ.
Рейтинг отвечает на вопрос «кто умеет больше», а не «кто нужен вам». Организации с 30 рабочими станциями и без КИИ третье место подойдёт лучше первого. Чек-лист выбора под свою инфраструктуру ниже.
Подробнее о работе с банком данных угроз ФСТЭК →
Сканер без SGRC — почему список CVE не работает
Типичная ситуация после сканирования
Сканер запустили, получили отчёт. Допустим, 847 уязвимостей: 12 критических (CVSS 9.0 и выше), 94 высоких, 341 средняя, 400 низких.
Дальше начинаются вопросы, на которые сканер не отвечает.
Кто отвечает за устранение? В отчёте — IP-адреса и CVE. Нет привязки к конкретному активу, нет владельца актива, нет ответственного за устранение. ИБ-специалист должен вручную выяснить, чья это машина, и найти администратора.
Какой реальный приоритет? Сканер ставит CVSS — Universal Severity Score. CVSS 9.8 на тестовом стенде без выхода в интернет и CVSS 9.8 на продакшн-сервере с публичным IP — одинаковый балл. Но реальный риск принципиально разный. Начинать нужно с продакшн-сервера, а сканер об этом не знает.
Что конкретно делать? В отчёте — описание уязвимости и рекомендация «обновить до версии X.X». Нет задачи, нет дедлайна, нет системы контроля. Если устранение займёт 3 месяца — никто не заметит.
Как закрыть проверку ФСТЭК? Инспектор спрашивает: «Вы проводили анализ уязвимостей? Покажите результаты и что было сделано». Отчёт PDF сканера — это результат. Но документации об устранении нет. Мера анализа уязвимостей выполнена частично.
Итог: 847 CVE остаются висеть в PDF-файле. Никто не устраняет, никто не контролирует.
Проверить любую уязвимость из отчёта сканера вручную можно в реестре БДУ ФСТЭК — карточка показывает CVSS, наличие эксплойта и срок устранения по приказу №117. Сводки по конкретному софту — от Astra Linux до Windows Server — собраны на страницах уязвимостей ПО.
Что меняет SGRC
SGRC берёт результаты сканирования и превращает список CVE в управляемый процесс.
| Этап | Только сканер | Сканер + SGRC |
|---|---|---|
| Получение результатов | Отчёт PDF или CSV | Импорт в реестр уязвимостей |
| Привязка к активу | Нет (только IP) | Автоматически по IP или hostname |
| Бизнес-контекст | Нет | Бизнес-ценность актива из реестра |
| Приоритизация | По CVSS | По риску: CVSS × ценность актива × вектор угрозы |
| Назначение ответственного | Нет | Автоматически по владельцу актива |
| Постановка задачи | Нет | Задача с дедлайном в системе |
| Контроль устранения | Нет | Уведомления, эскалация, статус |
| Документация для ФСТЭК | Отчёт сканера | Полный цикл: сканирование → задача → факт устранения |
| Связь с активами и задачами | Нет | уязвимость → актив → задача на устранение |
Результат: из 847 CVE SGRC выделяет 15 задач с реальным приоритетом на ближайший месяц. Остальные — в очереди с обоснованием почему именно такой порядок.
Есть сканер, но нет управления результатами? В КиберОснове результаты сканирования сводят в реестр уязвимостей рядом с данными БДУ ФСТЭК и CVSS 4.0, а устранение ведут задачами ИБ с ответственным и сроком. Посмотреть как работает →
Подробнее об оценке рисков ИБ →
Как сканер и SGRC работают вместе
Конкретный сценарий: от CVE до отчёта ФСТЭК
Вот как выглядит работа с уязвимостями в SGRC: от записи в реестре уязвимостей из БДУ ФСТЭК до задачи ИБ с ответственным и сроком.
Шаг 1. Сканирование. MaxPatrol VM или RedCheck проводит плановое сканирование по расписанию — еженедельно для критичных сегментов, ежемесячно для остальных.
Шаг 2. Перенос в SGRC. Результаты сканирования переносят в реестр уязвимостей SGRC. Готовых коннекторов к MaxPatrol VM, RedCheck и XSpider в КиберОснове нет: данные заносят вручную или общим импортом таблиц.
Шаг 3. Привязка к активам. Система сопоставляет IP-адреса и hostname с реестром активов. Уязвимость CVE-2024-XXXXX на сервере 192.168.1.10 → автоматически привязывается к «Сервер БД ИСПДн Кадры» из реестра.
Шаг 4. Оценка риска. Специалист ИБ определяет приоритет: CVSS-балл уязвимости, ценность актива и наличие эксплойта в публичном доступе. Сервер с ПДн сотрудников получает приоритет выше, чем тестовая машина с аналогичной CVE.
Шаг 5. Назначение задачи. Ответственный за актив получает задачу: «Устранить CVE-2024-XXXXX на сервере [название] до [дата]». Срок устранения задают по уровню критичности.
Шаг 6. Контроль. Руководитель ИБ следит за статусом задач и плановыми сроками; просроченные разбирает с ответственными.
Шаг 7. Документация. После устранения — факт фиксируется в системе. По итогам периода формируется отчёт: «Выполнена мера АУД.2. Проведено сканирование [дата]. Выявлено уязвимостей: X. Устранено: Y. Остаток с обоснованием: Z».
Этот отчёт — ответ на вопрос инспектора ФСТЭК при проверке.
Связь с моделью угроз и мерами защиты
Уязвимости из сканера — это не просто технические баги, это потенциальные векторы атак из модели угроз организации.
Цепочка выглядит так: уязвимость из сканера → угроза из БДУ ФСТЭК → мера защиты, которая закрывает эту угрозу → статус выполнения меры в плане защиты.
Итог: SGRC видит не отдельные CVE, а целостную картину. Уязвимость привязана к активу, по ней есть задача с исполнителем и сроком, а выполнение меры АУД.2 приказа № 239 отмечается в чек-листе. Регулятор видит связную документацию, а не разрозненные отчёты.
Дополнительно: меры защиты информации по приказам ФСТЭК — полный разбор →
Сканер уязвимостей часто работает в связке с SIEM: SIEM фиксирует события, сканер находит слабые места, SGRC управляет устранением. О разнице между SIEM и SGRC, и зачем нужны оба инструмента: SIEM и SGRC: в чём разница →
Уже есть сканер? КиберОснова добавит управление результатами: реестр активов и уязвимостей, данные БДУ ФСТЭК с CVSS 4.0, задачи ИБ на устранение с ответственным и сроком. Запросить демо →
Итоги: как выбрать сканер уязвимостей
Анализ уязвимостей по ФСТЭК — это не опция, а обязательная мера для ГИС, ИСПДн с УЗ-1 — УЗ-3 и значимых объектов КИИ. Для ГИС нужен сертифицированный ФСТЭК сканер, для КИИ — прошедший оценку соответствия.
Выбор сканера зависит от масштаба инфраструктуры и задач:
- MaxPatrol VM — непрерывный мониторинг, крупные организации, SOC;
- RedCheck — госсектор и КИИ, нативная работа с БДУ ФСТЭК, российское ПО;
- XSpider — небольшие организации, базовый анализ, ограниченный бюджет;
- ScanFactory — внешний периметр, DevSecOps, облачная модель.
Главная ошибка — считать, что сканер = управление уязвимостями. Сканер находит CVE. Управление — это приоритизация, назначение, контроль устранения и документация. Без SGRC список CVE остаётся списком.
КиберОснова — не сканер и не коннектор к нему. В ней ведут реестр активов и уязвимостей с данными БДУ ФСТЭК и CVSS 4.0, а устранение — задачами ИБ с ответственным и сроком.
Посмотрите, как это работает на демо →
Как выбрать сканер: чеклист для ИБ-специалиста
Перед покупкой ответьте на пять вопросов:
-
Нужен ли сертификат ФСТЭК? Для ГИС — да: приказ № 117 требует сертифицированные средства защиты (п. 71). Для значимых объектов КИИ допускаются сертификация, испытания или приёмка (п. 28 приказа № 239). Для ИСПДн — средства, прошедшие оценку соответствия, если без них не нейтрализовать актуальные угрозы (п. 4 приказа № 21).
-
Сколько активов в инфраструктуре? До 50 — хватит XSpider. От 50 до 500 — RedCheck или MaxPatrol VM. Свыше 500 — MaxPatrol VM с распределённой архитектурой.
-
Есть ли изолированные сегменты? Если да — облачный ScanFactory не подходит. Нужен on-premise сканер с агентным режимом: RedCheck или MaxPatrol VM.
-
Какая ОС на серверах? При преобладании Astra Linux, ALT Linux, российского ПО — RedCheck имеет преимущество по покрытию. MaxPatrol VM также поддерживает российские ОС, но RedCheck исторически сильнее в этом направлении.
-
Нужен ли Continuous VM? Если организация хочет узнавать об уязвимостях не раз в месяц, а в день публикации — нужен MaxPatrol VM с непрерывным мониторингом. RedCheck и XSpider работают в режиме периодического сканирования.
После выбора сканера следующий шаг — интеграция с SGRC для управления результатами. Сканер находит уязвимости, SGRC превращает их в управляемые задачи с ответственными и дедлайнами. Подробнее об организации полного VM-процесса по руководству ФСТЭК: Методика управления уязвимостями ФСТЭК. Управление результатами сканирования в единой платформе: модуль управления уязвимостями КиберОснова.
Выбрали сканер, но не знаете, как управлять результатами? Покажем, как вести реестр уязвимостей и задачи на устранение в КиберОснове. Записаться на демо →
