ГЛАДИАТОРЫ
ИНФОРМАЦИОННОЙ
БЕЗОПАСНОСТИ
Напишите намinfo@glabit.ru

Что такое CVE: база данных уязвимостей Common Vulnerabilities and Exposures

В информации об уязвимостях регулярно встречаются обозначения вида CVE-2026-12345. Один и тот же номер можно увидеть в бюллетене производителя программного обеспечения, базе NVD, отчете сканера уязвимостей, системе управления патчами или сообщении исследователей безопасности.

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

Для стандартизации используется CVE — Common Vulnerabilities and Exposures.
CVE присваивает публично раскрытым уязвимостям уникальные идентификаторы и позволяет различным системам информационной безопасности говорить об одной проблеме на общем языке. Однако сам номер CVE еще не показывает, насколько опасна уязвимость для конкретной компании, существует ли для нее готовый эксплойт и нужно ли устанавливать обновление немедленно.

Чтобы принять такое решение, CVE необходимо сопоставить с дополнительными данными: затронутыми версиями ПО, оценкой CVSS, сведениями производителя, наличием реальной эксплуатации, EPSS (Exploit Prediction Scoring System) и, главное, с активами собственной инфраструктуры.

Разберем, как устроена система CVE, кто присваивает идентификаторы уязвимостям, чем CVE отличается от NVD, CVSS и CWE и как эти данные используются при управлении уязвимостями.


Содержание:

Команда редакторов "Гладиаторы ИБ"
Дата публикации: 02.09.2026
Время прочтения 10 минут

Что такое CVE и зачем нужна система Common Vulnerabilities and Exposures

CVE (Common Vulnerabilities and Exposures) — международная система идентификации публично раскрытых уязвимостей информационной безопасности.

Для каждой учитываемой уязвимости назначается уникальный CVE ID, например:

CVE-2026-12345

С этим идентификатором связывается структурированная CVE Record — запись об уязвимости.
Официальный CVE Program определяет CVE List как каталог опубликованных CVE Records, а саму программу — как международную инициативу по идентификации и каталогизации публично раскрытых уязвимостей.

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

Предположим, исследователь обнаружил ошибку в определенной версии корпоративного продукта. Производитель публикует бюллетень безопасности, сканер находит эту же проблему в инфраструктуре, а аналитик SOC получает информацию о ее эксплуатации злоумышленниками.
Если все источники используют одинаковый CVE ID, специалист может быстро понять, что речь идет об одной уязвимости, даже если ее описания различаются.

Получается следующая схема:

уязвимость → CVE ID → единая точка идентификации → данные производителей, NVD, сканеров и других источников.

Сам CVE при этом не является системой обнаружения уязвимостей и ничего не исправляет автоматически. Это идентификатор, который позволяет связать данные из различных источников.
Что такое CVE: база данных уязвимостей Common Vulnerabilities and Exposures

Какие данные хранятся в CVE

CVE может быть присвоен уязвимостям различных продуктов и компонентов, например:
  • операционных систем;
  • серверного программного обеспечения;
  • веб-приложений;
  • библиотек и фреймворков;
  • сетевого оборудования;
  • прошивок;
  • облачных и корпоративных решений;
  • аппаратных и программных компонентов.
При этом не следует считать, что любая проблема информационной безопасности обязательно имеет CVE.
Например, в конкретной компании причиной компрометации может стать небезопасная конфигурация собственного сервера, чрезмерные права пользователя или внутреннее приложение с еще не раскрытой уязвимостью. Отсутствие CVE не означает отсутствия проблемы.
И наоборот: существование CVE не означает, что соответствующая уязвимость присутствует именно в вашей инфраструктуре.
Сначала необходимо определить используемые продукты и их версии.

Как устроен идентификатор CVE

Современный CVE ID имеет вид:
CVE-YYYY-NNNN...
Например, условный:
CVE-2026-12345
состоит из трех элементов.
CVE — постоянный префикс системы.
2026 — годовая часть идентификатора.
12345 — уникальная числовая часть.
Последовательность после года содержит как минимум четыре цифры, но верхнего ограничения в четыре или пять цифр нет: формат был изменен таким образом, чтобы CVE Program мог использовать идентификаторы переменной длины при росте количества регистрируемых уязвимостей.
Важно правильно понимать значение года.
Нельзя автоматически читать CVE-2026-... как «уязвимость обнаружили в 2026 году».
Действующие правила CVE рекомендуют выбирать годовую часть на основании календарного года, в котором произошло одно из соответствующих событий: уязвимость впервые публично раскрыли, CVE Record впервые опубликовали либо CVE ID зарезервировали. Поэтому реальная история обнаружения проблемы может начаться раньше.
Также сам порядковый номер не кодирует:
  • производителя;
  • продукт;
  • тип уязвимости;
  • критичность;
  • наличие эксплойта;
  • вероятность эксплуатации.
То есть из одного CVE-2026-12345 невозможно сделать вывод, опаснее ли эта проблема, например, CVE-2026-54321.
Для этого необходимо читать саму запись и дополнительные данные.

Что означают статусы CVE

До публикации запись может проходить несколько состояний.
RESERVED означает, что CVE ID уже выделен, но полноценная информация об уязвимости еще не опубликована в CVE List.
Так бывает, например, при координированном раскрытии: идентификатор получают заранее, а подробности публикуются одновременно с бюллетенем производителя и исправлением.
После раскрытия информации CVE получает опубликованное описание и ссылки на источники.
NVD (National Vulnerability Database) описывает этот процесс как переход от RESERVED к опубликованной CVE Description и Reference links.
REJECTED используется для идентификаторов, которые больше не должны рассматриваться как действительная отдельная CVE-запись.
Причины могут различаться: например, оказалось, что записи дублируют одну и ту же уязвимость или первоначальная информация не соответствовала критериям.
При этом номер не обязательно просто исчезает. Информация о rejected-записи сохраняется, чтобы старые отчеты и ссылки на этот CVE ID не становились неоднозначными. NVD также сохраняет такие записи со статусом REJECTED.

Как уязвимость получает CVE и кто присваивает номер

CVE Program работает как распределенная система.
Идентификаторы назначает не одна организация вручную для всех найденных в мире уязвимостей.
Для этого существуют CVE Numbering Authorities (CNA) — уполномоченные участники программы, которым разрешено назначать CVE ID и публиковать соответствующие CVE Records в определенной области ответственности. Так CNA определяется и в официальном глоссарии CVE.
CNA могут быть:
  • крупными разработчиками программного обеспечения;
  • производителями оборудования;
  • компаниями в сфере информационной безопасности;
  • CERT/CSIRT;
  • организациями, координирующими раскрытие уязвимостей;
  • open-source проектами и другими участниками экосистемы.
Упрощенно процесс выглядит следующим образом:
обнаружение уязвимости → обращение к соответствующей CNA → проверка соответствия правилам CVE → присвоение или резервирование CVE ID → координация раскрытия → публикация CVE Record.
Конкретный процесс зависит от ситуации.
Например, если исследователь обнаружил проблему в продукте крупного производителя, который сам является CNA для собственных продуктов, взаимодействие может происходить непосредственно с ним.
Если подходящей CNA у производителя нет, запрос может обрабатываться другой организацией в соответствующей иерархии CVE Program.

Что такое CNA

CVE Numbering Authority отвечает не только за выдачу номера.
CNA в своей области ответственности должна:
  • определить, соответствует ли проблема правилам CVE;
  • назначить идентификатор;
  • сформировать данные CVE Record;
  • опубликовать запись;
  • при необходимости обновлять информацию после публикации.
Такая распределенная схема позволяет масштабировать программу: информация об уязвимостях поступает непосредственно от производителей, исследовательских организаций и других участников, которые лучше знают соответствующие продукты.

Что происходит до публичного раскрытия

CVE ID может существовать до того, как описание становится общедоступным.
Например, исследователь сообщает производителю об уязвимости. Производитель подтверждает проблему и готовит исправление. На этом этапе CVE ID уже может быть зарезервирован, но технические сведения еще не публикуются, чтобы не создавать дополнительные возможности для эксплуатации до готовности исправления.
Поэтому обнаружение CVE ID со статусом RESERVED не означает, что где-то существует скрытая общедоступная карточка с полным описанием проблемы.
После публикации данные становятся доступны в CVE List, а затем могут быть дополнительно обработаны другими системами.

Что содержит CVE Record и где искать информацию об уязвимости

Одна из распространенных ошибок — ожидать, что непосредственно CVE Record должна содержать всю информацию, необходимую для оценки и исправления уязвимости.
Основная задача CVE — идентифицировать проблему.
В CVE Record могут присутствовать:
  • CVE ID;
  • описание уязвимости;
  • информация об авторе записи;
  • сведения о затронутых продуктах;
  • ссылки на внешние материалы;
  • дополнительные структурированные данные.
Но для полноценного анализа обычно приходится использовать сразу несколько источников.

CVE.org

CVE List является исходным каталогом опубликованных CVE Records. Официальный глоссарий определяет CVE Record как структурированную информацию об уязвимости, связанную с конкретным CVE ID.
Это хорошая отправная точка, если необходимо проверить сам идентификатор и первичную информацию.
Но специалисту по управлению уязвимостями часто требуется больше данных.

NVD

NVD — National Vulnerability Database — отдельная система Национального института стандартов и технологий США.
Она использует опубликованные CVE, но дополняет их данными для управления уязвимостями.
NVD прямо указывает, что после появления CVE в CVE List выполняется обогащение записи. Оно может включать:
  • CVSS v4.0;
  • CVSS v3.1;
  • CWE;
  • CPE Applicability Statements;
  • классификацию ссылок;
  • другие аналитические данные.
Поэтому утверждение «CVE и NVD — одна и та же база» неправильно.
Условно различие можно представить так:
CVE: «У этой уязвимости есть номер CVE-... и вот ее базовое описание».
NVD: «Вот дополнительные стандартизированные данные, которые помогают анализировать эту CVE».
NVD сама определяет себя как государственный репозиторий стандартизированных данных для управления уязвимостями, автоматизации измерения безопасности и compliance.

Security Advisory производителя

При практическом исправлении уязвимости одним из наиболее важных источников часто становится бюллетень безопасности производителя.
Именно там могут наиболее точно указываться:
  • затронутые версии;
  • исправленные версии;
  • необходимые обновления;
  • способы борьбы с уязвимостью (workaround);
  • особенности конфигурации;
  • дополнительные условия эксплуатации;
  • рекомендации производителя.
Наличие CVE еще не означает, что проблема затрагивает любую версию продукта.
Например, уязвимость могла появиться только начиная с определенного релиза и быть исправлена в нескольких поддерживаемых ветках разными обновлениями.
Поэтому перед патчингом необходимо проверять не только CVE ID, но и vendor advisory.

CISA Known Exploited Vulnerabilities

Еще один важный источник — Known Exploited Vulnerabilities Catalog (KEV) агентства CISA.
В него включаются уязвимости, для которых известна эксплуатация в реальных атаках.
CISA прямо рекомендует использовать KEV как один из входных сигналов при построении системы приоритезации при построении процесса управления уязвимостями.
Это принципиально важный контекст.
У двух уязвимостей может быть похожая техническая критичность, но одна активно эксплуатируется злоумышленниками, а для второй такой активности не наблюдается.
Для команды ИБ это может серьезно менять очередность устранения.

Другие источники

В зависимости от задач могут дополнительно использоваться:
  • БДУ ФСТЭК России;
  • отраслевые CERT;
  • Threat Intelligence;
  • бюллетени разработчиков;
  • GitHub Security Advisories;
  • репозитории эксплойтов;
  • отчеты исследователей безопасности.
При этом информация из сторонних источников требует оценки достоверности. Например, опубликованный пользователем proof-of-concept и официальное подтверждение производителя имеют разный уровень надежности.

Чем CVE отличается от CVSS, CWE, CPE и NVD

CVE часто упоминается рядом с другими стандартами и базами, поэтому термины легко перепутать.

Термин

Основной вопрос

CVE

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

CVSS

Насколько технически серьезна уязвимость с учетом заданного набора метрик?

CWE

Какой тип программной слабости лежит в основе проблемы?

CPE

Как стандартизировано идентифицировать затронутые продукты и платформы?

NVD

Где получить обогащенные данные о CVE для управления уязвимостями?

KEV

Есть ли подтверждение эксплуатации уязвимости в реальных атаках?

EPSS

Какова прогнозируемая вероятность эксплуатации CVE в ближайшие 30 дней?

Рассмотрим основные различия подробнее.

CVE и CVSS

CVE ID идентифицирует уязвимость.
CVSS оценивает ее характеристики и severity.
Это разные задачи.
Например, наличие CVE-... ничего не сообщает о том, имеет ли уязвимость оценку 4, 7 или 10.
Кроме того, у одного CVE на различных ресурсах могут отображаться разные CVSS vector strings или оценки.
NVD объясняет, что ее собственный анализ строится на публично доступной информации, а данные производителя или другого источника могут основываться на несколько ином наборе сведений. Поэтому оценки могут не совпадать.
В реальных карточках NVD можно увидеть такие расхождения. Например, для одной CVE могут одновременно отображаться отдельные оценки NVD и CNA.
Особенно важно не смешивать severity и risk.
В документации CVSS 4.0 FIRST отдельно подчеркивает: CVSS Base Score измеряет тяжесть уязвимости, но не является полной оценкой риска для конкретной организации.
Уязвимость с высоким CVSS может находиться на изолированной тестовой системе, а уязвимость с меньшей базовой оценкой — на интернет-доступном сервере критического бизнес-сервиса и активно использоваться злоумышленниками.
Второй случай может потребовать более срочных действий.

CVE и CWE

CVE описывает конкретную уязвимость.
CWE — категорию слабости, которая может приводить к появлению целого класса уязвимостей.
Условно:
CWE: тип ошибки;
CVE: конкретная реализация такой проблемы в определенном продукте.
Поэтому множество различных CVE могут относиться к одному CWE.
NVD связывает CVE с CWE в рамках своего процесса обогащения данных (enrichment).

CVE и CPE

CPE — Common Platform Enumeration — стандартизированный способ идентификации классов приложений, операционных систем и аппаратных устройств. Такое определение использует NVD.
CPE помогает автоматизированным системам сопоставить сведения об уязвимости с конкретными продуктами и версиями.
Упрощенно:
CVE → какая проблема;
CPE → какой продукт или платформа.
Именно такое сопоставление особенно важно для сканеров уязвимостей и систем автоматизации при исправлении уязвимостей.

CVE и NVD

CVE — источник идентификатора и CVE Record.
NVD получает опубликованную CVE и добавляет дополнительный аналитический слой.
Поэтому отсутствие готовой оценки NVD не делает сам CVE недействительным. Например, в NVD встречаются опубликованные CVE, для которых собственная оценка NIST еще не предоставлена, но присутствует CVSS от CNA.

Как CVE используют в управлении уязвимостями

Знать номер CVE недостаточно.
Для бизнеса значительно важнее ответить на следующие вопросы:
  • есть ли эта уязвимость в нашей инфраструктуре;
  • на каких активах;
  • насколько эти активы критичны;
  • доступна ли уязвимая система злоумышленнику;
  • эксплуатируется ли CVE в реальных атаках;
  • существует ли исправление;
  • насколько быстро его необходимо установить.
Поэтому CVE становится полезной частью более широкого процесса управления уязвимостями.
Типовая последовательность может выглядеть так:
инвентаризация активов → определение продуктов и версий → поиск известных уязвимостей → сопоставление CVE → оценка контекста → приоритизация → исправление → повторная проверка.

Поиск CVE в инфраструктуре

Первый вопрос — какие продукты вообще установлены.
Организации необходимо знать:
  • серверы;
  • рабочие станции;
  • операционные системы;
  • сетевое оборудование;
  • приложения;
  • библиотеки;
  • контейнеры;
  • облачные компоненты;
  • версии используемого программного обеспечения.
Без такой инвентаризации даже очень качественная база CVE мало помогает.
Например, новая критическая CVE появляется в популярном серверном продукте. Чтобы понять реальный риск, компании нужно быстро определить:
используем ли мы этот продукт → какие версии установлены → на каких серверах → доступны ли они извне → выпущено ли исправление.
Для этого могут применяться:
  • vulnerability scanners;
  • authenticated scanning;
  • агенты управления активами;
  • SCA — Software Composition Analysis;
  • container scanning;
  • SBOM;
  • CMDB и другие источники инвентаризации.
“Гладиаторы” по схожей логики проводят инвентаризации активов и управления уязвимостями: процесс начинается с получения актуальной информации об активах и версиях программного обеспечения и продолжается поиском уязвимостей и установкой исправлений.

Как определить, какой CVE исправлять первым

В крупной инфраструктуре сканирование может обнаружить тысячи известных уязвимостей.
Исправлять их исключительно в порядке CVSS — не лучший подход.
Приоритет стоит определять с учетом нескольких факторов.
Наличие уязвимого актива.
CVE не имеет практического значения для компании, если соответствующий продукт не используется.
Критичность актива.
Уязвимость на сервере платежной системы и на изолированном тестовом компьютере имеет разный бизнес-контекст.
Доступность атакующему.
Интернет-доступный сервис обычно требует большего внимания, чем система в изолированном сегменте, хотя это не универсальное правило.
CVSS.
Помогает оценить технические характеристики и критичность.
CISA KEV.
Показывает наличие подтвержденной эксплуатации в реальных атаках. CISA рекомендует использовать каталог в качестве входного сигнала для приоритизации.
EPSS.
Exploit Prediction Scoring System оценивает вероятность того, что CVE будет эксплуатироваться в реальных условиях в течение следующих 30 дней. Модель пересчитывает оценки на основании обновляющихся сигналов.
Наличие публичного эксплойта или PoC.
Доступность патча или другого способа исправления (workaround).
Threat Intelligence.
Например, уязвимость может активно использовать атакующая группа, представляющая особую угрозу именно для вашей отрасли.
Поэтому практическая схема выглядит скорее так:
CVE + CVSS + эксплуатация + вероятность эксплуатации + экспозиция актива + критичность бизнеса + возможность исправления → приоритет.
А не просто:
CVSS 9.8 → исправить первым.

Наличие CVE не означает наличие готового эксплойта

CVE и эксплоит также необходимо разделять.
CVE идентифицирует уязвимость.
Proof of Concept (подтверждение) показывает один из возможных способов продемонстрировать проблему.
Exploit (эксплоит) представляет реализацию, позволяющую воспользоваться уязвимостью в определенных условиях.
Exploitation in the wild означает, что есть данные о применении уязвимости в реальных атаках.
Между этими состояниями нет обязательной автоматической последовательности.
Для CVE может:
  • вообще не существовать общедоступного exploit-кода;
  • существовать только PoC;
  • существовать рабочий публичный exploit;
  • существовать закрытая эксплуатационная техника;
  • быть подтверждена реальная эксплуатация.
Именно поэтому KEV и Threat Intelligence дают контекст, которого нет в самом CVE ID.

Почему установка патча — еще не конец процесса

После исправления желательно подтвердить результат.
Например, организация устанавливает обновление, но:
  • часть серверов осталась без него;
  • установка завершилась ошибкой;
  • приложение использует отдельную уязвимую библиотеку;
  • уязвимый сервис продолжает работать;
  • обновление не применилось после перезагрузки.
Поэтому после исправления проводится повторное сканирование или другая проверка.
Такой подход используется и у наших специалистов из “Гладиаторов ИБ”: после установки исправлений компания рекомендует повторно проверить, что патч установлен успешно и известная уязвимость больше не может быть проэксплуатирована соответствующим способом.
Есть еще один важный сценарий.
Если появилась информация, что CVE уже использовалась в реальной атаке на инфраструктуру, одного патча может быть недостаточно.
Исправление закрывает уязвимость, но не удаляет автоматически последствия уже произошедшей компрометации.
В такой ситуации может понадобиться:
  • анализ журналов;
  • поиск индикаторов компрометации;
  • проверка учетных записей;
  • анализ рабочих станций и серверов;
  • ретроспективный анализ;
  • расследование инцидента.

Вопросы и ответы

Что такое CVE простыми словами?

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

Как расшифровывается CVE?

CVE расшифровывается как Common Vulnerabilities and Exposures.
Название обычно переводят как «общие уязвимости и подверженности» или используют оригинальную англоязычную аббревиатуру.

Что означает номер CVE?

Идентификатор имеет формат:
CVE-YYYY-NNNN...
Первая часть показывает принадлежность к системе CVE.
Годовая часть определяется правилами CVE Program и может соответствовать году резервирования идентификатора, первой публикации записи или первого публичного раскрытия. Она не обязательно совпадает с годом фактического обнаружения уязвимости.
Последняя часть — уникальный числовой идентификатор.

Можно ли определить критичность уязвимости по CVE ID?

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

Чем CVE отличается от CVSS?

CVE отвечает на вопрос:
«О какой уязвимости идет речь?»
CVSS:
«Какими характеристиками обладает уязвимость и насколько велика ее техническая тяжесть?»
При этом CVSS Base Score нельзя автоматически считать полной оценкой бизнес-риска. FIRST прямо отделяет серьезность (уязвимости) от риска.

Чем CVE отличается от NVD?

CVE Program публикует CVE Records и предоставляет единые идентификаторы уязвимостей.
NVD получает опубликованные CVE и добавляет дополнительную информацию для управления уязвимостями, например CVSS, CWE и CPE.
Поэтому NVD и CVE связаны, но это не одна и та же система.

Все ли уязвимости получают CVE?

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

Может ли zero-day иметь CVE?

Да.
Понятия описывают разные свойства.
Zero-day указывает на ситуацию вокруг ранее неизвестной или еще не исправленной уязвимости и возможности ее эксплуатации, а CVE является идентификатором.
CVE ID может быть зарезервирован еще в процессе координированного раскрытия, до публикации полной информации.

Где проверить CVE?

Начать можно с:
  • CVE.org;
  • NVD;
  • security advisory (бюллетени безопасности) производителя.
Для оценки реальной эксплуатации полезно дополнительно проверять CISA KEV и источники Threat Intelligence.
Важно отметить, что в российском контексте нужно не забывать также использовать БДУ ФСТЭК России.

Означает ли наличие CVE, что существует готовый эксплойт?

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

Как узнать, есть ли конкретный CVE в инфраструктуре компании?

Сначала необходимо определить, какие активы, продукты и версии используются.
Затем их можно сопоставлять с данными об известных уязвимостях при помощи:
  • сканеров уязвимостей;
  • систем управления активами;
  • SCA;
  • SBOM;
  • средств управления уязвимостями;
  • ручной проверки рекомендаций производителей.
Для критичных результатов автоматического сканирования полезна дополнительная верификация, поскольку совпадение по версии не всегда означает, что уязвимость действительно эксплуатируемая в конкретной конфигурации.

Заключение

CVE создает единый язык для работы с публично раскрытыми уязвимостями.
Благодаря CVE ID производитель, исследователь, сканер уязвимостей, NVD и специалисты информационной безопасности могут однозначно ссылаться на одну и ту же проблему.
Однако CVE — только начало анализа.
Сам идентификатор не показывает, насколько срочно организация должна исправлять уязвимость, существует ли рабочий эксплойт и затронута ли вообще ее инфраструктура.
Для принятия решения необходимо сопоставить несколько видов информации:
CVE — какая уязвимость;
данные производителя — какие версии затронуты и как исправить проблему;
CVSS — какова техническая тяжесть;
KEV — есть ли подтвержденная эксплуатация в реальных атаках;
EPSS — какова прогнозируемая вероятность эксплуатации;
инвентаризация — присутствует ли уязвимый продукт в компании;
бизнес-контекст — насколько критичен затронутый актив.
После этого можно определить реальный приоритет исправления.
Поэтому эффективное управление уязвимостями начинается не со списка CVE, а с актуальной инвентаризации инфраструктуры, регулярного поиска слабых мест, их приоритизации, установки исправлений и обязательного контроля результата.
БДУ ФСТЭК использует похожий подход и по требованиям регуляторов крайне рекомендуется к использованию для оценки отечественных систем и продуктов.
Если необходимо организовать регулярную инвентаризацию активов, поиск известных уязвимостей и управление их устранением, специалисты «Гладиаторов информационной безопасности» помогут выстроить процесс управления уязвимостями, подобрать необходимые инструменты и интегрировать их в существующую инфраструктуру. Для более глубокой оценки специалисты также могут провести анализ защищенности информационных систем с автоматизированным сканированием, ручной проверкой и формированием приоритетных рекомендаций.
27 августа 2026г.
Что такое обфускация: методы и применение в информационной безопасности
22 августа 2026г.
Из чего состоит ретроспективный анализ в ИБ и как проводится расследование
17 августа 2026г.
Что такое SGRC: основные понятия и применение
13 августа 2026г.
Что такое Single Sign-On (SSO) и как работает единый вход

Есть вопросы или запрос на проект по безопасности?

Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности