SYSTEM ONLINE · build / v1.0 · region / RU · CIS · last index sync / 04.06.2026 / 13:11 UTC
· войти →
cyber-index.ru
исследование 3 июня 2026

Управление уязвимостями по требованиям ФСТЭК и БДУ

Управление уязвимостями по требованиям ФСТЭК — это не «поставить сканер», а выстроить непрерывный процесс: выявление уязвимостей, их сопоставление с Банком данных угроз безопасности информации (БДУ ФСТЭК), оценка опасности, приоритизация и устранение в разумные сроки с фиксацией результата. Для значимых объектов критической информационной инфраструктуры (КИИ) и государственных информационных систем (ГИС) такой процесс прямо вытекает из приказов ФСТЭК по защите информации. **Если коротко:** регулятор ждёт от вас не разового аудита, а управляемого цикла. Уязвимости нужно искать регулярно, сверять с БДУ и реестром сертифицированных средств, ранжировать по опасности и контексту, устранять или компенсировать и документировать каждый шаг. Ниже — роль БДУ, увязка с приказами ФСТЭК, таблица «требование → что обеспечить», подход к срокам и приоритизации и чек-лист соответствия. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге систем управления уязвимостями](/rating/vulnerability-management).

9 мин. чтения Блоки данных: 6 Позиции: не продаются Авторы: Антон Смирнов, Ирина Карпова
shortlist

Рейтинги подрядчиков по теме исследования

Если после чтения нужен короткий список исполнителей, начните с профильных рейтингов cyber-index.ru: в них видны компании, кейсы, интервью, категории экспертизы и доверительный индекс.

methodology

Как проверять выводы исследования

Используйте материал как основу для shortlist: сопоставьте выводы с профилями компаний, связанными рейтингами, кейсами, интервью клиентов и источниками. Если в статье есть список источников, начинайте проверку с него; если источников мало, дополнительно запросите у подрядчика методику, baseline и примеры работ.

E-E-A-T

Авторы и проверка материала

У каждого исследования есть персональные авторы, профиль экспертизы, дата публикации, список источников и редакционная проверка выводов.

Experience

Авторы закреплены по теме исследования и опираются на практические разборы страниц, кейсов, источников и рыночных выборок.

Expertise

В профиле автора указаны зона экспертизы, роль в редакции, регалии и темы, за которые он отвечает.

Authoritativeness

Материалы связаны с методологией cyber-index.ru, внутренними рейтингами, карточками компаний и источниками.

Trust

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

Что требует ФСТЭК: управление уязвимостями как процесс

В нормативной логике ФСТЭК анализ уязвимостей и управление обновлениями — это меры защиты информации, встроенные в общий контур обеспечения безопасности значимых объектов КИИ, ГИС и других защищаемых систем. Требования формулируются не как «купите продукт X», а как набор функциональных задач, которые организация обязана решать на протяжении всего жизненного цикла системы.

Ключевая идея — непрерывность и доказуемость. Недостаточно один раз просканировать инфраструктуру: нужно периодически выявлять уязвимости, оценивать их применительно к вашим активам, устранять или обоснованно компенсировать и хранить свидетельства того, что процесс работает. Именно поэтому управление уязвимостями (vulnerability management) естественно ложится на требования регулятора: оно как раз и описывает этот замкнутый цикл.

Роль БДУ ФСТЭК в управлении уязвимостями

Банк данных угроз безопасности информации (БДУ ФСТЭК, [bdu.fstec.ru](https://bdu.fstec.ru/)) — это ведущийся регулятором источник сведений об уязвимостях и угрозах. Для процесса VM он играет несколько ролей:

- **Единая система идентификации.** Уязвимости в БДУ имеют собственные идентификаторы, по которым удобно вести учёт и обмен сведениями внутри страны, в дополнение к международным идентификаторам. - **Источник для приоритизации.** БДУ содержит описания уязвимостей и сведения об их опасности, которые помогают понять, насколько критична уязвимость в вашем контексте. - **Опорная точка для соответствия.** Сопоставление выявленных уязвимостей с записями БДУ показывает регулятору и аудитору, что вы опираетесь на признанный национальный источник, а не только на зарубежные базы.

Практический смысл: сканер или система VM должны уметь сопоставлять найденное с БДУ, а не работать исключительно по внешним фидам. Это одно из ключевых отличий «российского» управления уязвимостями от подхода, ориентированного только на международные базы.

Требование регулятора → что обеспечить в процессе VM

Что ожидает регулятор (обобщённо) Что нужно обеспечить в процессе VM
Регулярное выявление уязвимостей Периодическое сканирование активов, инвентаризация, охват внешнего и внутреннего периметра
Использование признанных источников Сопоставление найденного с БДУ ФСТЭК и реестром сертифицированных СЗИ
Оценка опасности уязвимостей Скоринг с учётом контекста актива: критичность, доступность извне, наличие эксплойта
Своевременное устранение Процесс установки обновлений и патчей, а где невозможно — компенсирующие меры
Приоритизация работ Ранжирование по опасности и значимости актива, а не «по списку подряд»
Документирование и контроль Журналы сканирований, статусы устранения, отчётность, повторная проверка
Доверенные средства защиты Применение средств из реестра сертифицированных СЗИ, где это требуется для объекта

Сроки и приоритизация для КИИ и ГИС

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

- **Критичные и активно эксплуатируемые уязвимости** на доступных извне системах устраняются в первую очередь и в максимально сжатые сроки. - **Высокая опасность на значимых активах** — следующий приоритет; если патч недоступен, вводятся компенсирующие меры (сегментация, ограничение доступа, виртуальный патчинг). - **Средняя и низкая опасность** устраняется планово, в рамках циклов обновления.

Для значимых объектов КИИ и ГИС добавляется требование доказуемости: важно не только устранить, но и зафиксировать, когда уязвимость обнаружена, как оценена её опасность, какое решение принято (устранить/компенсировать) и когда подтверждено закрытие повторной проверкой. Если по конкретному типу объекта установлены нормативные сроки реагирования — их нужно брать из действующих документов ФСТЭК, а не из общих оценок.

Что чаще «проваливает» соответствие в процессах VM

Редакционная оценка частоты типовых пробелов по открытым материалам и практике. Это не официальная статистика ФСТЭК и не заменяет аудит вашей системы.

Нет регулярности: сканируют разово, а не циклом 85 /100
85 /100
Слабая приоритизация: «чиним по списку», без учёта контекста 80 /100
80 /100
Нет сопоставления с БДУ ФСТЭК 70 /100
70 /100
Нет фиксации и доказательной базы устранения 65 /100
65 /100
Не охвачен весь парк активов (теневые узлы) 60 /100
60 /100
Нет компенсирующих мер, когда патч недоступен 55 /100
55 /100

Управление уязвимостями по ФСТЭК: ориентиры

Национальный источник уязвимостей БДУ ФСТЭК

bdu.fstec.ru — сопоставлять найденное обязательно

Характер требования непрерывный процесс

Не разовый аудит, а цикл выявления и устранения

Принцип сроков по риску

Привязка к опасности и значимости актива

Где проверять средства реестры

reestr.fstec.ru и reestr.digital.gov.ru

Как выбрать средства под требования ФСТЭК

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

- **Поддержка БДУ ФСТЭК.** Возможность сопоставлять найденное с национальным банком данных, а не только с зарубежными базами. - **Статус в реестрах.** Для значимых объектов КИИ и ГИС важны наличие в реестре российского ПО и, где требуется, сертификат ФСТЭК нужного класса/типа — проверяйте по первоисточникам, а не по словам поставщика. - **Доказательная отчётность.** Журналы, статусы устранения, выгрузки для аудита и регулятора — то, что превращает «мы сканируем» в «мы соответствуем». - **Охват инфраструктуры.** Серверы, рабочие станции, сетевое оборудование, прикладное и отечественное ПО, по возможности — контейнеры и облако.

Конкретные продукты и их подтверждённые внедрения сравнивайте в [рейтинге систем управления уязвимостями](/rating/vulnerability-management): здесь — требования и критерии, там — поставщики по проверяемым сигналам.

Чек-лист соответствия требованиям ФСТЭК

Инвентаризация активов есть актуальный перечень систем и узлов, включая внешний периметр, без «теневых» активов.
Регулярное сканирование выявление уязвимостей выполняется циклом по графику, а не разово.
Сопоставление с БДУ найденные уязвимости увязываются с записями БДУ ФСТЭК, а не только с зарубежными базами.
Оценка опасности с контекстом скоринг учитывает критичность актива, доступность извне и наличие эксплойта.
Приоритизация по риску сначала критичное на доступных извне системах, далее по убыванию.
Сроки привязаны к опасности для нормативных сроков взяты действующие документы ФСТЭК под вашу категорию объекта.
Устранение и компенсация есть процесс патчинга, а при недоступности патча вводятся компенсирующие меры.
Доказательная база фиксируются обнаружение, решение и подтверждение закрытия повторной проверкой.
Доверенные средства применяемые СЗИ проверены в реестре ФСТЭК и реестре российского ПО, где это требуется.
Сравнение поставщиков выбор средства сверен с [рейтингом систем VM](/rating/vulnerability-management) по подтверждённым внедрениям.

Процесс устранения уязвимости: 6 шагов

  1. 01 Выявление

    Регулярное сканирование активов обнаруживает уязвимость; фиксируется узел, сервис и идентификатор.

  2. 02 Идентификация и сверка

    Уязвимость сопоставляется с БДУ ФСТЭК и зарубежными базами, уточняется описание и опасность.

  3. 03 Оценка в контексте

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

  4. 04 Приоритизация и решение

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

  5. 05 Устранение

    Применяется патч или компенсирующая мера; изменение проводится по процедуре управления обновлениями.

  6. 06 Проверка и фиксация

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

Как мы оцениваем поставщиков

cyber-index.ru не продаёт места в рейтинге. Поставщики сравниваются по проверяемым сигналам: подтверждённые внедрения и кейсы, отзывы и интервью клиентов, внешняя репутация, специализация, прозрачность и свежесть данных. Поэтому статью стоит читать в связке с [рейтингом систем управления уязвимостями](/rating/vulnerability-management): здесь — требования регулятора и критерии, там — сравнение конкретных компаний по подтверждённым фактам.

Следующий шаг

Разобрались с требованиями — переходите к сравнению поставщиков: **[рейтинг систем управления уязвимостями →](/rating/vulnerability-management)**. Полезно прочитать рядом: [что такое управление уязвимостями](/research/chto-takoe-vulnerability-management), [рейтинг российских систем VM 2026](/research/reyting-rossiyskih-vm-2026) и [чем заменить Nessus и Qualys](/research/zamena-nessus-qualys-skanery).

Частые вопросы

Обязательно ли использовать БДУ ФСТЭК в управлении уязвимостями?

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

Какие сроки устранения уязвимостей требует ФСТЭК?

Единого срока «для всех уязвимостей» в законе нет — он зависит от категории объекта и опасности уязвимости. Правильный подход — приоритизация по риску: критичное и доступное извне устраняется в первую очередь. Если для вашего типа объекта установлены нормативные сроки, берите их из действующих документов ФСТЭК, а не из общих оценок.

Чем управление уязвимостями по ФСТЭК отличается от обычного сканирования?

Сканирование — лишь один шаг. Требования регулятора описывают непрерывный цикл: выявление, сверка с БДУ, оценка опасности, приоритизация, устранение или компенсация и документирование с повторной проверкой. Разовый аудит этому не удовлетворяет.

Нужен ли сертификат ФСТЭК на сам сканер уязвимостей?

Зависит от объекта и состава мер. Для значимых объектов КИИ и ГИС применяемые средства защиты часто должны иметь статус в реестрах и, где требуется, сертификат нужного класса/типа. Проверяйте по реестру сертифицированных СЗИ и реестру российского ПО, а не по словам поставщика.

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

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

Где сравнить конкретные системы управления уязвимостями?

В рейтинге систем управления уязвимостями — там поставщики ранжированы по подтверждённым сигналам, а не по рекламе.

verification

Источники и метод проверки

Управление уязвимостями по требованиям ФСТЭК — это не «поставить сканер», а выстроить непрерывный процесс: выявление уязвимостей, их сопоставление с Банком данных угроз безопасности информации (БДУ ФСТЭК), оценка опасности, приоритизация и устранение в разумные сроки с фиксацией результата. Для значимых объектов критической информационной инфраструктуры (КИИ) и государственных информационных систем (ГИС) такой процесс прямо вытекает из приказов ФСТЭК по защите информации. **Если коротко:** регулятор ждёт от вас не разового аудита, а управляемого цикла. Уязвимости нужно искать регулярно, сверять с БДУ и реестром сертифицированных средств, ранжировать по опасности и контексту, устранять или компенсировать и документировать каждый шаг. Ниже — роль БДУ, увязка с приказами ФСТЭК, таблица «требование → что обеспечить», подход к срокам и приоритизации и чек-лист соответствия. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге систем управления уязвимостями](/rating/vulnerability-management).

next step

Сравнить подрядчиков по рейтингу

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

Рейтинг систем управления уязвимостями