«Классическая картина — независимый исследователь находит баг, вендор выпускает патч, всем спасибо. Но это картинка. В реальности всё чаще не ясно, кто нашёл и зачем. Внутренние отчёты вендоров, приватные баг-баунти программы, договорённости с ‘дружественными’ кибератаками, скрытые коммерческие предложения исследователям — всё это сильно искажает публичную статистику CVE. Уязвимость становится не просто ошибкой кода, а экономическим активом в сложных отношениях между вендорами, исследователями и регуляторами.»
Почему источник уязвимости — не просто любопытный факт
Когда речь заходит об уязвимости, публике показывают две вещи: идентификатор CVE и краткое описание проблемы. Редко кто задаётся вопросом, откуда вообще появилась эта запись в каталоге. Кто её туда добавил — сам производитель программного обеспечения или внешний специалист по безопасности? Ответ на этот вопрос влияет далеко не только на статистику.
Понимание источника уязвимости меняет восприятие как самого вендора, так и всей экосистемы безопасности продукта. Если большинство проблем находит сам разработчик, это говорит о зрелости внутренних процессов тестирования (Security Development Lifecycle, SDL) и, возможно, о меньшем количестве скрытых «сюрпризов» от сторонних исследователей. Обратная ситуация — когда поток CVE идёт преимущественно извне — указывает на пробелы во внутреннем аудите и зависимость от сообщества.
Однако эти выводы слишком поверхностны. Реальная картина скрывается за аббревиатурой CNA (CVE Numbering Authority) — организацией, уполномоченной присваивать идентификаторы. Список CNA включает не только гигантов вроде Microsoft или Google, но и компании, занимающиеся исключительно безопасностью, и даже национальные CERT-центры. Процедура публикации и учёта разнится от CNA к CNA, создавая серьёзные искажения в глобальной статистике.
Статистика: что показывают публичные данные
Прямых и полностью открытых отчётов, где бы агрегировались данные по источнику каждой CVE, не существует. Информацию приходится собирать по крупицам, анализируя описания в базах данных, отчёты отдельных вендоров и исследования аналитиков.
Например, крупные IT-компании, которые одновременно являются и разработчиками, и CNA, часто публикуют собственные отчёты по безопасности. В них можно встретить распределение обнаруженных уязвимости по категориям: «найдено внутренними командами», «сообщено через программу Bug Bounty», «обнаружено независимыми исследователями вне программ». Процент внутренних находок у таких компаний может быть весьма высок — до 70-80% для некоторых продуктовых линеек. Это говорит о мощных инвестициях в собственные «красные команды» и автоматизированный фаззинг.
Для другого сегмента рынка — корпоративного ПО, систем управления предприятиями и промышленных систем — картина иная. Многие вендоры в этих областях традиционно не имели сильных внутренних отделов безопасности. Основной поток уязвимостей к ним приходил и приходит извне: от специализированных фирм, академических исследователей или участников программ Bug Bounty. Лишь в последние годы, под давлением регуляторов и крупных заказчиков, ситуация начала меняться.
Стоит отметить и феномен «профессиональных охотников за багами». Это исследователи или небольшие компании, чья бизнес-модель построена на поиске уязвимостей в популярном ПО с последующим их ответственным раскрытием через программы вознаграждений. Они генерируют значительный объём CVE, особенно для веб-приложений и облачных сервисов, создавая видимость высокой активности внешнего сообщества.
Экономика и политика за кулисами CVE
Присвоение CVE — не только техническая, но и экономическая процедура. Для вендора публикация уязвимости, найденной внутренней командой, часто дешевле. Не нужно выплачивать вознаграждение внешнему исследователю, проще контролировать сроки разработки и выпуска патча, можно лучше подготовить коммуникацию для клиентов. Иногда внутреннее обнаружение позволяет «тихо» исправить проблему в рамках регулярного обновления, даже не присваивая ей отдельный идентификатор CVE с высоким приоритетом.
Внешний исследователь, в свою очередь, заинтересован в официальном признании своей находки. CVE, это валюта в его портфолио, необходимая для карьерного роста, приглашений на конференции и повышения статуса в программах Bug Bounty. Поэтому он будет настаивать на публикации записи, даже если вендор пытается минимизировать шумиху. Возникает переговорный процесс, где стороны могут договориться о сроках раскрытия, формулировке описания (которая может приуменьшить или, наоборот, выделить серьёзность) и, конечно, размере вознаграждения.
Отдельный пласт — так называемые «нулевые дни» (zero-day), уязвимости, неизвестные вендору. Их обнаружение почти всегда является результатом работы внешних сил: разведслужб, коммерческих продавцов эксплойтов или хакерских группировок. Эти CVE изначально не попадают в публичное поле, а живут в теневой экономике, и лишь спустя месяцы или годы, будучи обнаруженными в ходе расследования инцидента, обретают публичный идентификатор. В статистике они, как правило, проходят как «обнаруженные третьей стороной», но реальная история их происхождения остаётся скрытой.
Как источник влияет на качество и критичность уязвимости
Существует устойчивое мнение, что уязвимости, найденные самими вендорами, менее критичны. Отчасти это логично: внутренние тестировщики и аудиторы в первую очередь смотрят на самые очевидные и опасные векторы атак, которые и исправляют в приоритетном порядке. Сложные, требующие цепочки действий или нестандартных условий эксплуатации баги могут остаться за бортом внутренних проверок.
Внешние исследователи, особенно в рамках Bug Bounty, часто действуют иначе. Их цель — найти хоть что-то, что подпадает под критерии программы и принесёт выплату. Это приводит к большому количеству CVE с низкими и средними показателями CVSS (Common Vulnerability Scoring System). Часто это проблемы в дополнительных компонентах, устаревших библиотеках или сценариях с низкой вероятностью эксплуатации. Таким образом, высокая доля внешних CVE не обязательно означает, что продукт дыряв; это может указывать на тщательность его изучения сообществом.
С другой стороны, независимые эксперты или конкурирующие компании по безопасности, проводящие глубокий аудит, могут выявить фундаментальные архитектурные изъяны, которые команда разработки, находясь внутри проекта, просто не замечает в силу «профессиональной слепоты». Такие находки, хоть и редкие, обычно получают максимальные баллы критичности и становятся поводом для серьёзных доработок.
Влияние регуляторов и стандартов
Требования регуляторов, например, в рамках отечественного 152-ФЗ или отраслевых стандартов ФСТЭК, постепенно смещают баланс в сторону внутреннего обнаружения. Заказчики, особенно государственные и критически важные объекты, требуют от вендоров предоставления доказательств проведения регулярного аудита безопасности кода (SAST, DAST) и проведения пентестов. Это вынуждает разработчиков создавать и усиливать внутренние компетенции.
Более того, процедура аттестации и сертификации продуктов предполагает анализ не только функционала, но и документов, включая политики реагирования на инциденты безопасности. Вендор, способный продемонстрировать отлаженный процесс внутреннего поиска и устранения уязвимостей до их попадания к заказчику, получает конкурентное преимущество. В этом контексте высокая доля CVE от внешних исследователей может быть воспринята аудитором как признак слабости процессов обеспечения безопасности жизненного цикла разработки (SDLC).
Стандарты вроде ГОСТ Р 56939 или PCI DSS также косвенно стимулируют проактивную работу. Хотя они не диктуют прямо «найди X уязвимостей сам», требования по контролю изменений, управлению исправлениями и мониторингу угроз делают внутренний поиск дефектов экономически более выгодным, чем реактивное устранение проблем, обнаруженных извне уже на работающих системах клиентов.
К чему стремиться: баланс или преобладание?
Идеальная модель не заключается в стремлении к 100% внутреннего обнаружения. Это нереалистично и экономически неоправданно. «Слепота» разработчика — объективный фактор, и взгляд со стороны всегда будет ценен.
Цель зрелого вендора — построить сбалансированную экосистему, где:
- Внутренние команды (красные команды, пентестеры, инструменты статического/динамического анализа) перекрывают основные, наиболее очевидные и опасные векторы атак на ранних стадиях разработки.
- Программы Bug Bounty с чёткими правилами и адекватными вознаграждениями привлекают широкое сообщество для поиска специфических или сложно находимых уязвимостей в уже готовых продуктах.
- Налажены профессиональные каналы взаимодействия с уважаемыми исследовательскими компаниями и отдельными экспертами для глубокого аудита критических компонентов.
В такой модели статистика по источникам CVE перестаёт быть индикатором проблем, а становится метрикой эффективности этой экосистемы. Резкий всплеск внешних CVE может сигнализировать о выходе новой версии продукта, которую активно изучает сообщество, или, наоборот, о сбое во внутренних процессах тестирования. Постепенное увеличение доли внутренних находок при сохранении общего числа CVE будет говорить о росте зрелости собственных команд безопасности.
вопрос «сколько CVE обнаруживается вендорами vs исследователями» не имеет и не должен иметь однозначного цифрового ответа. Это динамический показатель, который нужно анализировать в контексте конкретного продукта, бизнес-модели вендора, зрелости рынка и регуляторного давления. Гораздо важнее не само соотношение, а процессы, которые стоят за этими цифрами, и способность организации извлекать из них уроки для повышения реальной, а не статистической, безопасности своих решений.