Журнал "Information Security/ Информационная безопасность" #3, 2026

и повышенное внимание клиентов, поэтому тенденция к занижению оценки вполне возможна. Вот лишь один из примеров. CVE- 2026-23534 – вендор заявляет, что влия- ние на конфиденциальность и целост- ность низкое, поэтому ставит оценку 7.6. NVD же считает, что влияние на все три показателя высокое, и подни- мает критичность до 9.8. Все это по версии CVSS 3.1 – данных по новой версии у этих источников нет. Зато он есть в БДУ, которая оценивает уязви- мость где-то посередине: 8.7. Но можно ли ставить это число в один ряд с дру- гими уязвимостями, рассчитанными по версии 3.1, если та же БДУ по этой версии оценивает данную уязвимость лишь на 7.5? Даже на одном примере видно, к каким разбросам может при- водить оценка уязвимости разными экс- пертами. Однако даже неточный CVSS лучше его отсутствия. Более серьезная про- блема в том, что многие вендоры вообще не публикуют оценки CVSS для своих уязвимостей. Для команд по управлению уязвимостями это означает необходи- мость собственной аналитики и незави- симой переоценки критичности. В допол- нение используются такие подходы, как SSVC, VPR или оценка критичности по методике ФСТЭК России (но последняя зависит от CVSS, что сохраняет исход- ную проблему). Проблема своевременности сведений об эксплуатации В качестве дополнительного механиз- ма приоритизации все чаще использу- ется и EPSS, оценивающий вероятность эксплуатации уязвимости. Это сильный инструмент, однако и он не лишен недо- статков: некоторые давно эксплуатируе- мые уязвимости по-прежнему имеют невысокие оценки EPSS. Возможности ИИ помогают не только специалистам по ИБ, но и злоумыш- ленникам. Если раньше после публи- кации технических деталей до появле- ния рабочего эксплойта могло пройти много времени, то теперь этот срок иногда заметно сокращается. В резуль- тате аналитик может приоритизировать уязвимости и не знать, что для части из них уже существует рабочий экс- плойт. Но даже если сведения об эксплойте появились в сети, это не означает, что они быстро дошли до пользователя. Одним из главных ориентиров для сотрудников ИБ остается каталог CISA KEV. Однако CVE попадают туда толь- ко после подтверждения реальных атак. На такую проверку могут уходить часы, дни и значительно более дли- тельные сроки, в то время как между публикацией CVE и первой наблюдае- мой атакой в среднем проходит всего 5 дней – и это только среди подтвер- жденных в CISA атак. Причем всего пять лет назад этот показатель превы- шал 30 дней. Российская специфика На фоне изменений в NVD, растущей роли ИИ в сегменте ИБ и сохраняющихся проблем с мировыми стандартами оцен- ки уязвимостей, интересно посмотреть, как обстоят дела с источниками сведе- ний об уязвимостях в России. Наличие собственной базы данных уязвимостей (БДУ ФСТЭК) является важным фактором устойчивости рос- сийской экосистемы ИБ. В условиях перемен в работе NVD ее роль посте- пенно растет. На российском рынке пока отсут- ствует единый отраслевой стандарт бюллетеней безопасности: сведения о затронутых версиях и условиях экс- плуатации публикуются не всегда полно, а сроки выхода бюллетеней сильно различаются. Дополнительная проблема – отсут- ствие российского аналога CISA KEV. Именно сведения о реальных атаках из этого каталога часто используются как ключевой фактор приоритизации уязви- мостей. В России аналогичного единого перечня фактически нет. В результате компаниям приходится самостоятельно агрегировать данные из множества источников – рассылок НКЦКИ, фору- мов, новостных лент и профессиональ- ных каналов – и строить собственные механизмы оценки угроз. И еще одна особенность – CVE в upstream-продукте не всегда означает наличие уязвимости в конечном продук- те. Российский вендор может использо- вать другую ветку кода или отключить затронутый функционал. Сведения об уязвимостях в таких случаях следует рассматривать внимательно с учетом их применимости к конкретному ПО. Последствия для отрасли ИБ К лету 2026 г. стало очевидно, что прежняя модель работы с уязвимостями перестает быть эффективной. Ранее многие вендоры ИБ-решений могли опи- раться на относительно стабильную цепоч- ку: CVE – NVD – добавление CVSS – сиг- натура. Сегодня эта схема больше не гарантирует полноты и качества дан- ных. Что же делать? Для компаний основ- ные рекомендации такие: l использовать как можно больше неза- висимых источников сведений; l автоматизировать агрегацию данных; l учитывать не только CVSS, но и све- дения об эксплуатации и другие полез- ные характеристики уязвимости; l при приоритизации уязвимостей опи- раться и на их общие параметры, и на критичность конкретных активов в инфраструктуре; l использовать ИИ как полезный инстру- мент для обработки растущего объема данных, но не заменять им полностью человеческую экспертизу, а дополнять профессиональную аналитику. А для российских вендоров и регуля- тора такие: l развивать единые стандарты публи- кации бюллетеней; l расширять охват ПО, для которого публикуются качественные данные об уязвимостях; l вводить собственный реестр уязвимо- стей, активно эксплуатируемых в России. В ближайшие 1–2 года можно ожидать дальнейшего усиления фрагментации источников сведений об уязвимостях и роста роли частных и коммерческих ана- литических платформ. Одновременно ускорится использование ИИ для первич- ной обработки и нормализации данных, однако ключевая роль в принятии реше- ний останется за экспертной аналитикой. Именно эти тренды мы закладываем в основу развития нашей системы конт- роля защищенности RedCheck 1 , где фокус разработки смещен с количества определений на их достоверность и при- менимость. l • 23 УПРАВЛЕНИЕ УЯЗВИМОСТЯМИ www.itsec.ru Рис. 2. Сравнение оценок для CVE-2026-23534 1 https://www.redcheck.ru/ Скачать тестовую версию RedCheck На правах рекламы