Программы баг-баунти для поиска уязвимостей в платформах ЦФА

Баг-баунти (bug bounty) — программа, при которой организация выплачивает вознаграждение исследователям безопасности за обнаружение уязвимостей в её программном обеспечении. На международном рынке такие программы — стандарт: HackerOne, Bugcrowd, Intigriti обслуживают тысячи компаний. В России программы баг-баунти ведут Яндекс, Тинькофф, VK и ряд других.

На рынке ЦФА ситуация особая. Платформы оперируют финансовыми активами и финансовыми данными пользователей, что делает безопасность критичной. При этом масштаб аудитории — пока сотни тысяч, а не миллионы — ограничивает бюджет на программы.

Текущее состояние программ у российских платформ

На середину 2025 года ни одна из пяти платформ не запустила публичную программу баг-баунти в полном смысле. Вместо этого используются гибридные модели:

Сбер. Безопасность ЦФА-платформы покрывается внутренней программой Bug Bounty Сбера, действующей с 2020 года. Платформа Сбер — часть единой экосистемы, и уязвимости в её компонентах могут быть обнаружены через общую программу. Вознаграждения — от 10 000 до 1 000 000 рублей в зависимости от критичности.

Атомайз. Проводил аудит смарт-контрактов через независимые лаборатории (Positive Technologies, BI.ZONE). Публичной программы баг-баунти нет, но компания проводит закрытые pentest-сессии с приглашёнными исследователями.

Токеон (Московская биржа). Безопасность — через внутреннюю команду Security Response Centre Московской биржи, которая взаимодействует с исследователями по запросу.

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

Классификация уязвимостей

Почему публичные программы пока редки

• Риск репутации. Публичное раскрытие уязвимости, даже через корректный канал, может подорвать доверие инвесторов.
• Санкции 115-ФЗ. Исследователь, обнаруживший уязвимость и попытавшийся её эксплуатировать (даже без корыстных целей), может быть привлечён к уголовной ответственности.
• Масштаб. При количестве пользователей платформы в десятки тысяч публичная программа привлекает мало исследователей — экономически нецелесообразно.

Ещё один сдерживающий фактор — неопределённость правового статуса исследователя. Граница между «нашёл и сообщил» и «получил несанкционированный доступ» проходит по действиям: как только проверка заходит дальше публичного интерфейса, её формально можно квалифицировать как неправомерный доступ к компьютерной информации. Без письменных правил программы, где оператор заранее разрешает тестирование в заданном периметре и снимает претензии, исследователь остаётся один на один с этим риском. Именно поэтому закрытые pentest-сессии с договором и техзаданием оказались удобнее открытых баунти: они дают оператору тот же результат, но с контролируемым кругом участников.

Что оператор обязан делать с уязвимостями без публичной программы

Отсутствие баг-баунти не означает отсутствия обязательств. Закон о ЦФА требует от оператора информационной системы обеспечивать защиту информации, а требования Банка России к операторам задают минимальный набор мер: оценку угроз, средства защиты, контроль доступа и реагирование на инциденты. На практике это выливается в:

1. Регулярное внутреннее и внешнее тестирование инфраструктуры — аудиты, pentest, сканирование.
2. Канал приёма сообщений об уязвимостях от внешних исследователей и пользователей.
3. Процедуру разбора инцидента: локализация, устранение, оценка последствий для записей реестра.
4. Взаимодействие с регулятором и отраслевыми центрами реагирования по значимым событиям.

Для инвестора отсюда практический вывод: при выборе платформы имеет смысл смотреть не на громкие обещания безопасности, а на измеримые признаки — упоминание аудитов, наличие политики ответственного раскрытия, регламент реагирования на сбои. Проверить платформу ЦФА по реестрам Банка России и сопутствующим признакам поможет отдельный гайд по проверке легальности платформы ЦФА.

Как устроена зрелая программа баг-баунти

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

1. Периметр (scope). Точно перечислены домены, приложения и интерфейсы, которые можно тестировать, — всё остальное исключено.
2. Правила игры. Формат ответственного раскрытия: куда и как сообщать, сколько времени даётся на исправление, что запрещено (социальная инженерия, атаки на пользователей, деградация сервиса).
3. Юридическая защита. Обязательство оператора не инициировать претензии к исследователю, действовавшему в рамках программы (safe harbor) — без этого пункта публичная программа не имеет смысла.
4. Шкала вознаграждений. Заранее опубликованная сетка по уровням критичности, привязанная к таблице выше.
5. Triage и прозрачность. Сроки первичного ответа, статус обработки отчёта, публичная благодарность или анонимность по выбору исследователя.

Баг-баунти, pentest и аудит: три разных слоя проверки

Эти инструменты часто смешивают, хотя они дополняют друг друга и отвечают за разные сценарии:

• Аудит смарт-контрактов — разовая проверка кода выпуска независимой лабораторией перед размещением. Отвечает на вопрос «корректно ли исполняются условия выпуска».
• Pentest — периодическая имитация атаки на платформу приглашённой командой по техническому заданию. Отвечает на вопрос «можно ли войти в систему снаружи».
• Баг-баунти — непрерывный поток находок от распределённого сообщества исследователей, работающих на своей инициативе. Отвечает на вопрос «что мы пропустили».

Слой непрерывного внешнего контроля — самый дешёвый по инфраструктуре и самый редкий на рынке ЦФА: он требует выстроенных процессов обработки отчётов и готовности публично признавать ошибки. Комбинация всех трёх слоёв — признак зрелой ИТ-команды оператора.

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

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

• при выборе платформы учитывать зрелость процессов безопасности наравне со ставками и комиссиями;
• следить за уведомлениями оператора: добросовестные платформы сообщают об инцидентах и их устранении, а не молчат;
• иметь план действий на случай сбоя или недоступности сервиса — порядок зафиксирован в инструкции о сбоях платформ ЦФА;
• не рассчитывать на страховку: компенсации за технические ошибки платформы стандартный полис не покрывает.

Рекомендации для исследователей

Если вы обнаружили уязвимость на платформе ЦФА:

1. Не пытайтесь эксплуатировать её.
2. Свяжитесь с security-командой оператора через официальные каналы.
3. Задокументируйте шаги воспроизведения.
4. Не раскрывайте информацию публично до устранения уязвимости (Responsible Disclosure).
5. Сохраняйте переписку с оператором и фиксируйте даты сообщений — они понадобятся при эскалации.
6. Если оператор не отвечает или уклоняется от устранения проблемы, направьте отчёт в CERT РУС (ГосСОПКА) — этот канал работает и без публичной программы.

Источники

• Федеральный закон № 259-ФЗ — ст. 7 (требования к безопасности оператора)
• Закон № 115-ФЗ — ответственность за легализацию
• CERT РУС (ГосСОПКА) — канал сообщений об уязвимостях
• HackerOne — международный опыт

Что ещё почитать

• Безопасность ЦФА: информационная защита — требования к защите информационных систем операторов.
• Аудит исходного кода смарт-контракта независимой лабораторией — обязательная проверка перед выпуском.
• Аппаратные криптографические модули (HSM) при хранении ключей — защита ключевой инфраструктуры.
• Ответственность оператора платформы за сбои и утрату данных о ЦФА — что происходит, если уязвимость сработала.
• Мошенничество: риски и защита инвесторов — как не стать жертвой на рынке цифровых прав.

Материал носит справочный характер и не является индивидуальной инвестиционной рекомендацией.