«Bug bounty — это договорённость о вознаграждении за уязвимости без договора. Российское право пока не понимает эту двойственность и пытается подогнать её под устаревшие рамки. Последствия касаются не только энтузиастов, но и компаний, которые хотят запустить программу.»
Что такое bug bounty, а что — нет
Bug bounty program (программа вознаграждения за уязвимости) — это публичное предложение компании выплатить денежное или иное вознаграждение независимым исследователям за обнаружение и ответственное раскрытие уязвимостей в её продуктах или инфраструктуре.
Это не хаотичный поиск дыр «по приколу». Формально это публичная оферта, которую исследователь акцептует своими действиями — находит баг и отправляет отчёт по установленным правилам. Нет трудового договора, гражданско-правового контракта или агентского соглашения. Взаимоотношения строятся на принципах добросовестности и соблюдения правил программы, опубликованных на специализированных платформах (например, HackerOne, Bugcrowd) или на собственном сайте компании.
Именно эта гибридная природа — между коммерческой сделкой и общественным договором — создаёт основную правовую коллизию.
Ключевая правовая проблема: квалификация действий исследователя
Главный вопрос для юристов и регуляторов: как квалифицировать действия человека, который без явного разрешения проводит тесты на проникновение в чужую информационную систему?
С точки зрения Уголовного кодекса РФ, такие действия потенциально подпадают под несколько статей:
- Статья 272 УК РФ «Неправомерный доступ к компьютерной информации». Доступ считается неправомерным, если он совершён без согласия собственника или иного законного владельца информации. Формального письменного согласия в bug bounty часто нет — есть лишь публичная оферта, которую суд может не признать достаточным правовым основанием.
- Статья 273 УК РФ «Создание, использование и распространение вредоносных компьютерных программ». Использование скриптов или инструментов для эксплуатации уязвимостей (например, для доказательства возможности кражи данных) может быть трактовано как использование вредоносных средств.
- Статья 274 УК РФ «Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации». Если действия исследователя приведут к сбоям в работе системы (отказ в обслуживании — DoS), это может быть расценено как нарушение правил эксплуатации.
Проблема усугубляется тем, что оферта компании не является гарантией от уголовного преследования. Прокурор или следователь могут счесть, что исследователь вышел за рамки дозволенного (например, провёл тестирование вне объявленного scope или использовал запрещённые методы), и начать уголовное дело. Доказывать свою невиновность и наличие «разрешения» придётся самому исследователю.
[ИЗОБРАЖЕНИЕ: Схема правовых рисков исследователя: публичная оферта компании, действия исследователя (в scope/вне scope), возможные статьи УК РФ (272, 273, 274) и гражданско-правовые последствия.]
Позиция регуляторов: ФСТЭК и 152-ФЗ
Регуляторная сфера добавляет свой слой сложности. Федеральная служба по техническому и экспортному контролю (ФСТЭК) в своих методических документах и требованиях по защите информации не содержит прямых упоминаний bug bounty. Однако её позиция вытекает из общего подхода к обеспечению безопасности.
Согласно требованиям, все работы по оценке защищённости (тестирование на проникновение) должны проводиться уполномоченными лицами в строго контролируемых условиях. Как правило, это требует:
- Наличия договора с организацией, имеющей лицензию ФСТЭК на деятельность по технической защите конфиденциальной информации.
- Проведения работ по утверждённой программе и методике.
- Оформления результатов актом, подписанным комиссией.
Публичная bug bounty программа, где к тестированию может приступить любой желающий анонимно, формально нарушает эти принципы. Это создаёт риски для компании-организатора: если в её системе, обрабатывающей персональные данные, будет найдена уязвимость через bug bounty, ФСТЭК может расценить это как нарушение требований 152-ФЗ о надлежащем уровне защищённости. Компания не контролирует процесс, не может гарантировать квалификацию тестировщиков и несёт ответственность за возможный ущерб.
Персональные данные как особая зона риска
Если bug bounty программа затрагивает системы, обрабатывающие персональные данные (ПДн), риски многократно возрастают. Действия исследователя, связанные с доступом к ПДн (даже для демонстрации утечки), могут быть квалифицированы как их неправомерное получение. Это уже не только вопрос УК РФ, но и прямое нарушение 152-ФЗ, влекущее административную ответственность для компании по ст. 13.11 КоАП РФ (невыполнение обязанностей по защите ПДн).
Гражданско-правовые и налоговые последствия
Статус выплат
Компания, выплачивающая вознаграждение, сталкивается с вопросом: как оформить эту выплату с точки зрения бухгалтерского и налогового учёта? Вариантов несколько, и у каждого есть недостатки:
- Подарок (безвозмездная передача). Сумма свыше определённого лимита облагается НДФЛ в 35%. Для компании это не является расходом, уменьшающим налогооблагаемую базу.
- Вознаграждение по договору оказания услуг. Требует заключения договора с физическим лицом (что противоречит анонимности многих программ), оформления акта, удержания НДФЛ и страховых взносов. Крайне громоздко для разовых выплат разным людям.
- Приз в рамках конкурса. Организация конкурса требует соблюдения норм Гражданского кодекса о публичном обещании награды, что тоже накладывает формальные обязательства.
На практике многие компании проводят выплаты через иностранные платформы как «фees for services», что создаёт дополнительные валютные и налоговые сложности для российских резидентов-исследователей.
Ответственность исследователя
Если в процессе тестирования исследователь случайно причинит ущерб (например, выведет из строя сервер), компания может потребовать его возмещения в гражданском порядке. Публичная оферта редко содержит пункты, полностью освобождающие исследователя от такой ответственности, особенно в случае неосторожных действий.
Как минимизировать риски: подход для организаторов программ
Полностью устранить правовые риски в текущих реалиях невозможно, но их можно существенно снизить.
- Чёткий Legal Policy. Разработайте и опубликуйте не просто правила программы, а полноценное юридическое соглашение (Legal Terms). В нём должны быть явно прописаны:
- Даётся явное и безотзывное разрешение на тестирование в рамках определённого scope.
- Гарантия не привлекать исследователей, действующих добросовестно и в рамках правил, к юридической ответственности (уголовной, административной, гражданской).
- Чёткое описание запрещённых методов тестирования (DoS, соц-инжиниринг сотрудников, физическое проникновение и т.д.).
- Порядок разрешения споров и применимое право.
- Внедрение «Safe Harbor» (гавани безопасности). Это ключевое положение, закрепляющее иммунитет для добросовестных исследователей. Его текст должен быть одобрен юристами и размещён на видном месте.
- Сегментация и контроль scope. Выделяйте для публичного тестирования только тестовые среды или системы, не содержащие реальных ПДн или коммерческой тайны. Используйте программы типа «инвайт-онли» для более критичных систем.
- Взаимодействие с регулятором. Для критически важных систем может быть целесообразно уведомить ФСТЭК о проведении контролируемой программы bug bounty с привлечением аккредитованных специалистов, формализовав её как часть работ по оценке защищённости.
[ИЗОБРАЖЕНИЕ: Инфографика «Безопасная программа bug bounty»: столпы — Чёткий Legal Policy, Safe Harbor Clause, Контролируемый Scope, Взаимодействие с регулятором.]
Рекомендации для исследователей (хакеров)
- Верифицируйте программу. Участвуйте только в программах с опубликованным и внятным Legal Policy, содержащим пункт о Safe Harbor. Предпочтение — крупным платформам и известным компаниям.
- Строго соблюдайте правила. Не отклоняйтесь от объявленного scope. Если есть сомнения, разрешён ли тот или иной метод, — спросите у организаторов до начала тестов.
- Документируйте всё. Сохраняйте скриншоты, логи, переписку с координаторами программы. Это может стать доказательством ваших добросовестных намерений.
- Избегайте систем с ПДн. Если явно не указано иное, считайте работу с персональными данными красной линией.
- Помните о налогах. Полученное вознаграждение — это ваш доход. Изучите, как платформа или компания оформляет выплату, и будьте готовы декларировать его и уплатить НДФЛ.
Будущее регулирования
Правовой вакуум вокруг bug bounty постепенно начинает заполняться. В некоторых странах принимаются поправки в законы (например, в США — Computer Fraud and Abuse Act), чтобы защитить добросовестных исследователей безопасности. В России подобных инициатив на законодательном уровне пока нет, но дискуссия в профессиональном сообществе ведётся.
Наиболее вероятный сценарий — не появление отдельного закона о bug bounty, а внесение точечных изменений в Уголовный кодекс и законы об информации. Например, может быть добавлена примечание к статье 272 УК РФ, исключающее уголовную ответственность за доступ, осуществлённый в рамках добросовестного исследования безопасности при наличии публичного согласия владельца системы. Однако этот процесс потребует времени и активной позиции как бизнеса, так и ИБ-сообщества.
Пока же bug bounty в России существует в серой зоне, где безопасность обеспечивается не правом, а взаимным доверием, репутацией платформ и точным следованием прописанным правилам игры. Понимание правовых рисков — первый шаг к тому, чтобы это доверие не было нарушено.