Забудьте про CVE. ИБ-шники заглянули в теневые реестры Китая и нашли сотни неизвестных Западу уязвимостей

В ИБ давно принято классифицировать уязвимости через CVE: брешь получила номер, дальше подтянулись оценка по CVSS, тип по CWE, список затронутых продуктов, и можно строить приоритеты для патчей. Но 2024 и 2025 годы показали, насколько хрупкой бывает эта цепочка, если один из ключевых узлов начинает сбоить.

Сначала, в феврале 2024 года, просела Национальная база уязвимостей США (NVD), которую ведёт NIST. NVD много лет делала рутинную, но критически важную работу: брала записи из списка CVE и дополняла их тем, что нужно защитникам и сканерам, баллами CVSS, привязками к типам ошибок, списками затронутого софта и другими полями. На фоне замедления NVD признала, что у неё растёт хвост необработанных записей. Приоритет сместили на более свежие уязвимости, в первую очередь после 2018 года, но сам бэклог никуда не делся.

Почти следом случилась другая встряска, уже организационная. После конференции VulnCon 2025, где публично обсуждали будущее программы CVE и качество публикаций от организаций, которым разрешено выпускать CVE (их называют CNA), всплыла история о контракте Министерства внутренней безопасности США, который финансирует работу программы. Контракт вовремя не продлили, началась паника, вплоть до разговоров о разветвлении каталогизации уязвимостей на несколько независимых списков. В итоге кризис погасили, финансирование нашли, программа продолжила работу без остановки. Но сам факт оказался неприятным: отрасль слишком сильно привыкла считать, что MITRE и NIST всегда будут работать как опорные столбы, а выяснилось, что и у них бывают уязвимые места.

И вот недавно исследователь из Bitsight решил посмотреть шире: что происходит в государственных базах уязвимостей за пределами США, и особенно в Китае. Потому что у Китая их сразу две, и они живут по другим правилам.

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

CNNVD ведёт центр оценки информационной безопасности CNITSEC. Кураторство приписывают структуре, связанной с Министерством государственной безопасности. По тому, как CNNVD наполняется и как устроен график публикаций, база выглядит заточенной под «внешний» поток: когда уязвимость раскрывают международные источники, запись быстро появляется и в CNNVD. На практике CNNVD часто работает как зеркало CVE, но в рамках китайских правил публикации.

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

Поверх двух баз лежит отдельный, очень жёсткий регуляторный слой. Китайские правила определяют не только то, что можно писать про уязвимость, но и когда можно писать. Ключевым документом стал регламент управления уязвимостями в сетевых продуктах, известный как RMSV, вступивший в действие в июле 2021 года. RMSV задаёт порядок, который заметно отличается от западной практики согласованного раскрытия.

RMSV требует передавать информацию об уязвимости государственным органам, включая профильное министерство. Срок подачи жёсткий: до 48 часов после обнаружения. До выхода патча нельзя раскрывать технические детали. Публикации не должны содержать proof-of-concept (доказательств концепции) и тем более готовые эксплойты. Отдельным пунктом стоит запрет на искусственное раздувание серьёзности проблемы. Вместо добровольных договорённостей исследователя и вендора получается предписанный порядок, где приоритет отдают управляемости и контролю над темпом раскрытия.

Доступ к данным устроен неудобно для автоматизации. Обе базы требуют регистрации и входа. Выгрузки можно скачать, но автоматизированный доступ почти отсутствует: запросы завязаны на действия в интерфейсе, а файлы формируются на стороне сервера по запросу. Выгрузки приходят в XML, при этом в XML встречаются ошибки, из-за которых стандартные парсеры периодически ломаются и данные приходится вытаскивать более осторожно.

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

CNVD и CNNVD по набору полей местами похожи на западные каталоги, но совпадения неполные. В обеих базах есть шкала серьёзности. По смыслу шкала близка к уровням, которые обычно получают из CVSS, хотя распределение по уровням не повторяет международную статистику один в один. В CNNVD есть отдельное поле для типа уязвимости, по роли оно напоминает CWE, но прямого соответствия нет. CNVD хранит даты поступления и публикации. По этим датам около 90% записей появляются в течение недели после того, как информация попала в базу. Одновременно встречаются странные случаи, когда дата поступления стоит позже даты официального раскрытия, что похоже на ошибки при заполнении и заставляет осторожно относиться к таким таймлайнам.

В CNVD есть ещё один параметр, который легко принять за отметку о связи с инцидентом. На практике почти все карточки помечены как обычные уязвимости программного и аппаратного обеспечения. Выделяется отдельная группа из 74 записей летом 2020 года с пометкой событийные уязвимости. По описаниям такие карточки больше похожи на истории вокруг краж и атак в криптоэкосистеме, чем на признак того, что уязвимость действительно использовали в атаках.

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

Здесь есть важный момент. CVE часто проходит «полупубличную» стадию: номер уже выдали или зарезервировали, патч может уже выйти, обсуждения могут идти, а карточка CVE ещё не считается опубликованной. Поэтому удобнее считать уязвимость публичной с даты, когда запись появилась либо в CVE, либо в NVD. А если китайская база показывает публикацию заметно раньше, стоит ещё проверить дату резервации CVE, чтобы не спутать реальное опережение с задержкой формальной публикации.

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

Если отбросить такие аномалии, получается простая картина. В большинстве случаев CNVD и CNNVD публикуют записи позже CVE или в тот же день. Ранние публикации встречаются редко: около 0,55% для CNNVD и 0,18% для CNVD. В пересчёте на весь период с 2011 года выходит примерно 1 400 записей, где китайская база оказалась первой.

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

Ранние публикации чаще попадаются среди уязвимостей, которым в китайской оценке ставят более низкую серьёзность. В CNNVD среди ранних карточек заметна доля записей без указанной серьёзности. Такое распределение похоже на ситуацию, когда оценку серьёзности берут из западных источников. Пока западной оценки нет, поле остаётся пустым или неопределённым.

Отдельная история, записи CNVD и CNNVD без привязки к CVE. Примерно с 2021 года поведение баз меняется, и по времени это совпадает с введением RMSV. CNVD после регламента стала заметно медленнее публиковать такие карточки. CNNVD начала сокращать публикации примерно за год до регламента, а затем в последний год снова начала публиковать больше записей без CVE. По самим данным можно предположить несколько причин. Базы могли лучше научиться привязывать записи к CVE и реже оставлять карточки без номера. Новые правила могли увести часть уязвимостей из публичного доступа. Плюс часть таких уязвимостей может относиться к локальному софту и устройствам, которые редко встречаются за пределами Китая и поэтому не попадают в международные каталоги. Скорее всего, сработало сразу несколько причин.