Одна уязвимость, дюжина названий, 321 запись и стенд, за которым конкуренты договорились “дружить”. История создания самого известного идентификатора в кибербезопасности по первоисточникам 1999 года.
Всем привет! Меня зовут Юля Волкова, и уже почти три года я отвечаю за направление данных в CodeScoring, а точнее — руковожу отделом сбора и аналитики данных.
Моя команда готовит продуктовые данные об уязвимостях, лицензиях, open source пакетах и всём, что с ними связано. Мы собираем информацию из множества источников, и у каждого из них свои особенности: разная полнота, качество, структура и глубина описаний. Иногда источники дополняют друг друга, иногда расходятся в деталях, а порой прямо противоречат друг другу.
Возможно, об этой стороне нашей работы я тоже еще расскажу, но начать цикл статей хочется не с сегодняшних нюансов в данных, а с истории: как вообще появилась инфраструктура, на которую сейчас опирается работа с уязвимостями. Что такое программа CVE, откуда и зачем появилась база NVD, зачем нужно было запускать GitHub Advisory Database и формат OSV, какую роль играет FIRST.org, как все эти инициативы связаны между собой и что нас ждет дальше?
В цикле статей разберемся в том, как устроены эти проекты, но и в том, почему они возникли, какие задачи должны были решить, как они развивались и где проходят границы их ответственности.
Многие привычные сегодня стандарты и форматы появились не по заранее продуманному плану, а как ответ на ситуационные, вполне конкретные проблемы — технические, организационные и даже политические. И начать логично с главного кита мира уязвимостей — программы CVE.
Итак… Начнём с хаоса, из которого вырос CVE.
Ситуация: одна уязвимость, три имени
Представьте: конец девяностых. Вы отвечаете за безопасность в крупной организации. У вас три сканера уязвимостей от трёх вендоров, IDS (Intrusion Detection System) от четвёртого и папка распечатанных advisory от CERT (Computer Emergency Response Team). Сканер №1 докладывает о проблеме под одним именем, сканер №2 — под другим, а в бюллетене CERT та же самая дыра названа третьим способом. И ваша задача — понять, описывают ли они разные проблемы или говорят об одном и том же.
Это не гипотетика. В сентябрьской статье о развитии CVE (1999) приводится пример, от которого у любого практика дернется глаз. Одна и та же уязвимость NFS фигурировала:
в базе сканера CyberCop как «NFS file guessing check»;
в базе X-Force (ISS) как «nfs-guess»;
в advisory CERT как «SunOS NFS Jumbo and fsirand patches».
Хотя во всех трех названиях можно заметить NFS, этого недостаточно, чтобы понять, что записи описывают одну и ту же проблему и находятся на одинаковом уровне абстракции. Более того, источники по-разному представляли один и тот же набор проблем NFS. CERT описывал их в шести бюллетенях, CyberCop сообщал о них через 13 отдельных тестов безопасности, а X-Force разбивал информацию на 20 карточек с описаниями уязвимостей.
Попробуй догадайся, что всё это многообразие говорило об одном и том же.
А уязвимость PHF CGI (классическая дыра в веб-сервере того времени) была известна примерно под дюжиной разных названий одновременно у дюжины разных вендоров. Каждый вёл собственную базу и крестил уязвимости, как хотел. Где-то она называлась по программе phf, где-то по функции escape_shell_cmd, где-то по номеру внутренней проверки.
Математика была убийственной. Если напрямую сопоставлять N независимых баз, для каждой пары придётся поддерживать отдельный набор соответствий — всего до N(N−1)/2 интеграций, то есть порядка N2. А внутри каждой такой интеграции нужно вручную связывать записи, которые могут описывать одну и ту же уязвимость под разными именами.
Сами авторы будущего CVE называли этот процесс «labor intensive and error prone» — трудоёмким и ошибкоопасным. Ситуация напоминала Вавилонскую башню: все говорят об одном и том же, но на разных языках. И в этой башне приходилось жить. Идея CVE меняла архитектуру задачи: каждый источник можно было бы сопоставить с одним общим перечнем.
Внутренняя боль MITRE
Интересно, что CVE родился не как великий проект по стандартизации всей отрасли. Всё было гораздо скромнее и прагматичнее.
В некоммерческой организации MITRE был внутренний Information Security Committee (комитет по информационной безопасности). Комитет использовал сканеры и IDS от разных поставщиков и строил централизованную защиту собственной корпоративной сети. У них были конкретные задачи:
понимать, сообщают ли разные инструменты об одной и той же уязвимости;
связывать сигнал IDS с результатом последнего сканирования того же хоста;
собирать всё известное по найденной проблеме;
сравнивать покрытие разных средств между собой и с бюллетенями CERT.
Каждый продукт имел свою базу и своё имя для одной и той же проблемы. Корреляция превращалась в ручной детективный труд.
И вот, пытаясь найти решение наболевшей проблемы, 8 января 1999 года два инженера MITRE — Дэвид Манн (David E. Mann) и Стивен Кристи (Steven M. Christey, известный как Coley) — выпустили документ «Towards a Common Enumeration of Vulnerabilities», в котором и описали предлагаемую программу.
В работе авторы также отдельно благодарили коллегу Уильяма Хилла (William H. Hill), от которого, по их словам, исходила значительная часть концептуального вдохновения. Обратите внимание и на исходное название: Common Vulnerability Enumeration (дословно: Общий перечень уязвимостей). В первой работе речь шла именно об общем перечне уязвимостей. К моменту публичного запуска название расширилось до знакомого нам Common Vulnerabilities and Exposures (дословно можно было бы перевести как «Общий перечень уязвимостей и экспозиции», но ближе и понятнее по смыслу будет перевод «Общий перечень уязвимостей и проблем безопасности»), но аббревиатура CVE сохранилась.
«Перечень», а не «таксономия»
Ключевым решением при создании CVE было не то, какие поля включить в новую базу, а то, от каких полей сознательно отказаться.
Манн и Кристи могли попытаться построить универсальную классификацию уязвимостей: определить категории, отношения, уровни абстракции и точную модель затронутых продуктов. Такие попытки, в индустрии уже были: авторы прямо упоминают работы над «универсальными примитивами» и «формальными таксономиями», к примеру, таксономию Unix-дефектов Таймура Аслама (Taimur Aslam). Но авторы CVE сознательно не пошли в эту сторону, поскольку даже относительно простой вопрос (например, как описывать операционную систему) быстро приводил к новым поводам для спора внутри профессионального сообщества.
Поэтому Манн и Кристи предложили минимальную модель: уникальное имя и текстовое описание, достаточное для различения записей. Одномерный список. Перечень. Никакой онтологии, никаких «правильных» категорий: только договориться, что вот эта проблема и вот та проблема — одна и та же. Остальные базы могли сохранять собственные классификации, оценки и представления, используя CVE как логический мост.
Обоснование они подкрепили двумя аналогиями. Первой стала химия: до Менделеева элементы почти век просто перечисляли — от Лавуазье до периодической таблицы 1869 года прошло более 80 лет. Простой одномерный список, о котором все договорились, оказался именно тем инструментом, который позволил науке разговаривать на одном языке.
Вторая — зоология: калифорнийский золотой медведь, бурый медведь, кадьяк и гризли когда-то считались разными видами, а сегодня это один вид Ursus arctos.
Номенклатура — итеративный процесс, и начинается он не с идеальной классификации, а с договорённости, что считать «тем самым» объектом.
Это был не только методологический, но и политический выбор. Чтобы пользоваться CVE, компаниям не требовалось соглашаться с чужой оценкой уязвимости, моделью риска или классификацией ошибки. Нужно было принять лишь одно: эта запись и та запись описывают одну проблему.
Даже формат имени выбрали нарочито скучным. Цитата из статьи о развитии CVE:
«The decision regarding naming was to keep the name a simple number with a "CVE" prefix. More detailed naming conventions would not add to the usefulness or effectiveness of CVE».
Более сложная схема лишь породила бы споры о вещах, нерелевантных простому списку. Именно этот минимализм объясняет успех CVE на старте. Идентификатор можно повесить поверх любой модели. CVE не оценивает риск, не предлагает исправление, не классифицирует. Он просто говорит: «CVE-1999-0067 — это та самая уязвимость», где 1999 — это год, а 0067 — порядковый номер записи в нём. И да, это номер того самого PHF из первого раздела, посмотрите его запись в CVE.
Открытость
Второе принципиальное решение — открытость. На рынке уже существовали коммерческие базы уязвимостей, но все они были закрыты авторским правом, неполны или отражали интересы конкретного продукта. Если бы общий идентификатор принадлежал одному вендору, он никогда не стал бы нейтральным мостом между конкурентами.
MITRE сформулировала модель достаточно жестко: CVE должен быть публичным, свободно распространяемым, с открытым архивом обсуждений и голосований. Это сразу решало несколько задач:
снижало барьер доступности до нуля;
не конкурировало с коммерческими базами по глубине аналитики (CVE — не аналитика, а ключ к ней);
создавало «community ownership», ощущение общей собственности сообщества;
превращало MITRE в модератора, а не владельца истины об уязвимостях.
Последний пункт важен. MITRE не претендовала на роль оракула. Она предлагала инфраструктуру и правила игры, а решения оставляла за сообществом.
Девять месяцев от документа до запуска
21–22 января идея была представлена на семинаре 2nd Workshop on Research with Security Vulnerability Databases в Университете Пердью (Purdue University). Работа делалась для внутреннего комитета безопасности. Но именно этот текст стал концептуальным фундаментом для программы CVE.
Пердью не был выбран случайной площадкой: на тот момент, в 1999 году, университет уже играл роль крупного академического центра исследований в области информационной безопасности на территории США. В частности, именно на базе этого университета в начале 1990-х Юджин «Джин» Спаффорд (Eugene “Gene” Spafford) и Сэмюэл Уэгстафф создали лабораторию COAST, которая занималась аудитом Unix-систем, обнаружением вторжений, анализом уязвимостей и компьютерной криминалистикой. К 1 января 1999 года COAST вошла в состав междисциплинарного центра CERIAS, организовавшего семинар, на котором была представлена CVE программа.
Приглашение на семинар Джин Спаффорд опубликовал в Bugtraq 4 января 1999 года. Организаторы хотели собрать исследователей из академической среды, государства и индустрии. Причём это была именно рабочая встреча: количество мест ограничивалось, а участникам предлагалось активно включаться в обсуждения и рабочие группы.
На семинар приехали около 100 человек примерно из 50 организаций. Среди них были представители NIST (того самого National Institute of Standards and Technology, который позже запустит и будет поддерживать базу уязвимостей NVD), NSA, IBM, Cisco, Secure Computing и университетов. Именно NIST и NSA так же впоследствии возьмут на себя непосредственное финансирование CVE программы.
Из присланных на семинар материалов программный комитет отобрал восемь работ, которые вошли в опубликованные материалы встречи. Доклад Манна и Кристи был шестым и, согласно отчёту, вызвал заметный интерес аудитории. На следующий день участники распределились по пяти рабочим группам, обсуждавшим открытые, централизованные и федеративные модели баз уязвимостей. Из этой среды выросла рабочая группа, позднее ставшая первым CVE Editorial Board, которая взяла на себя роль управления программой CVE).
Далее MITRE начала собирать черновой перечень уязвимостей. Данные поступали от ISS, L-3 Security, SANS и Netect, а также извлекались из Bugtraq, NTBugtraq, бюллетеней CERT и баз сканеров CyberCop, NetSonar и NetRecon. Это было важно не только для наполнения: каждый новый источник показывал, где именно расходятся границы и названия записей.
9 мая 1999 года на конференции SANS-99 в Балтиморе прошла первая встреча CVE Task Force, будущего Editorial Board. В сохранившихся заметках цели сформулированы очень приземленно: получить поддержку ключевых игроков рынка, провести валидацию чернового списка и согласовать выпуск.
Май–сентябрь 1999. MITRE составляет черновой список, Board дискутирует об уровне абстракции (сколько отдельных багов считать «одной уязвимостью»), правилах включения, терминах vulnerability/exposure и голосует по кандидатам. Основная работа Editorial Board шла по электронной рассылке. Кристи выполнял роль модератора и центральной точки процесса. Архив переписки сохранился, при желании можно посмотреть не только итог, но и сам процесс обсуждений и принятия решений. На старте в работе участвуют представители 12 коммерческих и исследовательских организаций.
29 сентября 1999 состоялись пресс-телеконференция и публичный запуск CVE. В списке — 321 запись. Рядом с ним — Editorial Board из 19 организаций.
Примечание: В современных источниках часто пишут о 19 участниках первого состава Board, тогда как в статье сентября 1999 года упомянуты 23 человека.
Девятнадцать организаций, один стенд и будущий зал славы
Ставка MITRE на открытость программы сыграла. В состав запуска успешно вошли организации, многие из которых были прямыми конкурентами: сканеры, IDS, базы уязвимостей — компании, которые зарабатывали тем, что их продукт лучше соседского.
CERT Coordination Center, IBM Research, Cisco, Internet Security Systems (ISS), AXENT, BindView, Bugtraq, CERIAS/Purdue, Network Associates, NFR, NTBugtraq, SANS Institute, SecurityFocus.com, Silicon Defense, UC Davis и другие. И Ballistic Missile Defense Organization — да, организация противоракетной обороны. Среди участников программы — известные на территории США эксперты индустрии: Джин Спаффорд, Мэтт Бишоп (Matt Bishop), Адам Шостак (Adam Shostack), Элиас Леви (Elias Levy) и другие.
Символом взаимовыгодного сотрудничества стал стенд CVE на конференции SANS Network Security. Этот стенд был хорошей репрезентацией идеи проекта: его демонстративно комплектовали представителями конкурирующих компаний. За кулисами этой коалиции стояли не только Манн и Кристи. Руководителем проекта и главным организатором принятия CVE индустрией была Марджи Зук (Margie Zuk), позднее возглавившая CVE, а внутренним спонсором и защитником инициативы в MITRE — Пит Таскер (Pete Tasker), руководитель направления Security and Information Operations. При этом сам Кристи совмещал три роли в одном лице: дизайнер формата, редактор списка и модератор Editorial Board, то есть держал в своих руках архитектурную, содержательную и процедурную власть одновременно.
В 2000 году Зук, Кристи, Манн и Таскер получили SANS Security Technology Leadership Award. Индустрия признала значимость случившегося почти сразу.
От списка к «планетарной» инфраструктуре
Публичный запуск CVE был только началом. За следующую четверть века простой перечень идентификаторов стал основой целой экосистемы данных об уязвимостях.
В сентябре 2002 года NIST выпустил специальную публикацию SP 800-51, в которой рекомендовал федеральным ведомствам США использовать CVE в деятельности, связанной с уязвимостями. С этого момента CVE закрепился не только как добровольная отраслевая договоренность, но и как элемент официальных федеральных рекомендаций.
10 августа 2005 года NIST запустил National Vulnerability Database — NVD. Новая база была построена поверх CVE: при запуске она содержала почти 12 тысяч записей и позволяла искать уязвимости по типу, серьёзности, последствиям, производителю, продукту и версии. Со временем NVD стала отдельным слоем обогащения данных: NIST связывает опубликованные CVE Records с оценками CVSS, типами ошибок CWE, конфигурациями применимости на основе CPE и другими метаданными.
К 2013 году программа столкнулась с неожиданно прозаическим ограничением: они осознали, что в старом формате рано или поздно начнет заканчиваться место. Изначальная схема CVE-YYYY-NNNN позволяла выдать не более 9 999 идентификаторов за один год. Когда поток сообщений начал стремительно расти, CVE Board пришлось выбирать новый формат.
Начавшись с 321 записей в 1999 году, к концу 2012 года программа содержала уже 54392 уязвимостей. Только за один 2012 год было добавлено 5351 записей.
Новая схема с произвольным количеством цифр после года вступила в силу 1 января 2014 года, а 13 января 2015 года были опубликованы первые идентификаторы, вышедшие за четырехзначный предел: пятизначный CVE-2014-10001 и шестизначный CVE-2014-100001. Изменение казалось косметическим, но затронуло всю экосистему: базы данных, регулярные выражения, парсеры, форматы отчетов и интерфейсы, которые много лет исходили из того, что CVE ID всегда имеет фиксированную длину. CVE официально готовился учитывать десятки тысяч уязвимостей в год.
В 2016 году программа CVE, в которой на тот момент участвовали только 23 CNA (CVE Numbering Authority), приняла стратегию масштабирования федеративной модели: всё больше производителей, исследовательских команд, CERT, open source-проектов и других организаций стали самостоятельно присваивать CVE ID и публиковать CVE Records в пределах своих согласованных зон ответственности. При этом сам механизм CNA не был изобретён в 2016-м: Candidate Naming Authorities описывались ещё в документах 1999 года. Новым стал именно масштаб распределенной публикации.
А теперь стоит поговорить о деньгах.
При всей своей открытости CVE никогда не была инфраструктурой, существовавшей только на энтузиазме сообщества. С момента формирования программы её ядро финансировалось правительством США: первыми источниками средств были NSA и NIST, как уже было сказано выше, а позднее к поддержке подключились и другие федеральные ведомства. В 2001–2005 годах отдельный CVE Senior Advisory Council должен был обеспечивать инициативе не только стратегическое руководство, но и долгосрочное финансирование. К 2004 году основным спонсором стало Министерство внутренней безопасности США — DHS, а в современной модели финансирование обеспечивает входящая в него CISA. MITRE при этом остаётся оператором программы, выполняя эту работу по федеральному контракту через HSSEDI — управляемый MITRE исследовательский центр класса FFRDC. Такая схема дала CVE ресурсы для постоянной редакционной, организационной и технической работы, но одновременно поставила глобальную инфраструктуру в зависимость от одного государственного заказчика.
15 апреля 2025 года в публичное поле попала информация из письма MITRE к CVE Board: контракт, поддерживавший работу организации над программой, должен был закончиться на следующий день, а продолжение на тот момент не было подтверждено. Однако 16 апреля CISA сообщила, что ещё 15 апреля активировала предусмотренный контрактом опционный период, поэтому перерыва в работе CVE не произошло. Позднее агентство отдельно уточнило, что речь шла не об отсутствии финансирования, а о проблеме администрирования контракта, разрешенной до истечения его срока.
Но этого было достаточно, чтобы в тот же день группа участников CVE Board объявила о создании CVE Foundation. По заявлению самой организации, подготовка к этому шагу шла около года. Задачами фонда назывались долгосрочная устойчивость и снижение зависимости глобальной программы от одного государственного спонсора и одного контрактного механизма. При этом объявление о создании фонда не означало немедленной передачи ему управления CVE: речь шла о предложении новой модели на будущее.
На 5 сентября 2026 года CVE List содержал уже 380 563 опубликованных уязвимостей. Сегодня масштаб инфраструктуры вокруг CVE программы уже трудно сравнивать с первым списком из 321 записи. На момент написания статьи в CVE программе участвует 537 организаций в ролях CNA и CNA of Last Resort из 43 стран, а также одна организация без указанной страновой принадлежности.
Неслучайный успех
Если не знать всех деталей, можно предположить, что в старые-добрые 90-е, на заре расцвета отрасли, любой более или менее инициативный инженер мог оставить свой след в истории, просто предложив хорошее решение насущной проблемы. Но это не совсем так. Давайте вспомним, что такое MITRE.
Успех CVE нельзя объяснить только удачной идеей Манна и Кристи. Не менее важно, где именно эта идея появилась.
MITRE выросла из работ над SAGE — одной из крупнейших информационных систем времен холодной войны. Организацию создавали не для производства одного радара или компьютера, а для системной инженерии: ей предстояло связывать в единое целое государственные структуры, исследовательские организации, промышленных подрядчиков и множество технических компонентов.
К концу 1990-х такой способ работы уже был частью организационной культуры MITRE. Она умела заниматься задачами, в которых ни один участник не контролирует всю систему, но всем нужны общие правила взаимодействия.
Кроме того, MITRE находилась в подходящем институциональном положении. Она работала в общественных интересах, управляла федерально финансируемыми исследовательскими центрами и при этом не продавала собственный коммерческий сканер или закрытую базу уязвимостей. Для конкурирующих вендоров она выглядела значительно более приемлемым координатором, чем один из участников рынка.
У MITRE были и практическая проблема, на которой можно было проверить идею, и доступ к государству, индустрии и академическому сообществу, и ресурсы для поддержания не только перечня, но и всего процесса вокруг него: встреч, рассылки, голосований, сайта и постоянной редакторской работы.
Это не гарантировало CVE успех. Но создало условия, без которых работа Манна и Кристи вполне могла просто остаться удачным докладом с конференции 1999 года.
CVE ID, ранняя CVE Entry и современный CVE Record
В финале истории про CVE важно уточнить упомянутую формулу: «CVE ничего не оценивает и не классифицирует».
Для первоначальной философии и самого идентификатора это верно, он так и задумывался. CVE ID не содержит severity, тип ошибки, производителя или способ исправления. В работе 1999 года основная запись состояла из уникального имени и короткого описания. Дополнительные сведения — даты, категории, ссылки, тезаурус и ключевые слова — хранились в отдельном CVE Maintenance Extension, или CMEX. Причём категории CMEX прямо не считались формальной таксономией.
Но время шло, потребности индустрии уточнялись, участники программы и Editorial Board вносили свои коррективы в изначальную идею CVE. На сегодняшний день CVE Record, который стал эволюцией первоначального CVE Entry, содержит объемное описание уязвимости и строго диктует его формат, включая severity, затронутые продукты, векторы и многое другое.
Остается ли CVE на сегодня главным «мостиком», связывающим уязвимости?
Главным — да, единственным — нет.
Несмотря на появление CVE-идентификатора, уязвимости не перестали иметь много имен. Например, если вы пишете на Python, то могли сталкиваться с PYSEC- идентификаторами, если на Rust, то RUSTSEC-, и другими “SEC”-ами, если вы используете опенсорс пакеты, вы точно знаете GHSA от Github Advisory. А в России существует БДУ ФСТЭК, которая предоставляет не только описания известных уязвимостей, найденных в других источниках, но и локально-специфичные данные. И, кажется, список можно продолжать и продолжать, но большинство из всех этих описаний уязвимостей как раз ссылаются на определенные CVE. Большинство, но не все.
CVE не устранила проблему дублирования информации в разных источниках. Она не избавила вендоров, опенсорс-комьюнити и регуляторов от желания вести собственные базы уязвимостей. Более того, это никогда и не было целью программы.
Благодаря CVE в отрасли четко зафиксировалась идея необходимости “связанности” уязвимостей. Поэтому если мы и видим сейчас записи, которые не ссылаются на CVE, но при этом являются описаниями уже где-либо известной проблемы, они в большинстве своем содержат другие ее идентификаторы, будь то BDU или GHSA.
Одна из особенностей платформы CodeScoring в части работы с уязвимостями как раз в том, что мы определяем, какие записи из разных источников данных описывают одну и ту же проблему, и объединяем их в единую запись – UNCS (Unified CodeScoring Vulnerability).
Собственно, это возможно исключительно благодаря наличию таких “связей-мостиков”, как общие идентификаторы или, как их еще называют в данных, “алиасы” (aliases), и не важно, это CVE, GHSA, BDU или любые другие.
Вместо вывода
Значимость появления CVE-программы невозможно переоценить. История CVE началась с операционной боли внутри отдельной организации и двух инженеров, осмелившихся предложить свое решение проблемы целой отрасли.
И вот двадцать шесть лет спустя вряд ли найдется специалист по безопасности, который за день не произнесет хотя бы один номер CVE, не так ли?
А как много CVE за день приходится упоминать вам?
