Правила Bug Bounty как оферта
Начало серии статей о правовом статусе программ Bug Bounty (вознаграждение за уязвимости). Здесь - анализируем их как оферты.
Программы Bug Bounty — программы вознаграждения за найденные уязвимости — помогают вывести поиск багов из серой зоны деятельности в более легальную, снижая тем самым риски для багхантера. Предлагаю изучить, как для него самого это выглядит с юридической стороны.
Что такое Bug Bounty и как появились такие программы?
Сначала определимся с терминами. Bug Bounty — это программа (а порой и комплекс мероприятий), которую владелец продукта проводит для привлечения сторонних исследователей к поиску уязвимостей. Нужно это для того, чтобы устранить уязвимости и улучшить качество и безопасность продукта.
Если верить «Кобальту», история Bug Bounty началась в 1995 году, когда в октябре фирма Netscape анонсировала программу поиска уязвимостей в Netscape Navigator 2.0 Beta. Сам термин придумал инженер техподдержки Netscape Джарретт Ридлинхафер (Jarrett Ridlinghafer). Такой шаг навстречу сторонним исследователям был оценен сообществом, ведь стало возможно легально зарабатывать, сотрудничая с разработчиками браузера. Но другие производители софта не поддержали эту инициативу, и поэтому программы Bug Bounty как явление еще долго не были широко распространены. В 2007 году стартовал конкурс Pwn2Own, но настоящая популярность ждала Bug Bounty в 2010-е годы.
В чем плюсы Bug Bounty?
Если программы подобного рода получают широкое распространение, значит, они имеют немало достоинств, так? В целом да. Во-первых, экономическая сторона вопроса. Привлекать внешних исследователей может быть дешевле, чем содержать штат своих. За те деньги, что выплачиваются участникам Bug Bounty, можно получить информацию об уязвимостях такого объема, который зачастую нельзя ожидать от штатных специалистов. При этом, конечно, не стоит забывать, что сотрудники, которые проверяют репорты и принимают решения о выплате вознаграждения, должны обладать достойным уровнем знаний и уметь отделять зерна от плевел среди поступающей информации.
В числе внешних исследователей к тому же может оказаться и какой-нибудь высококлассный специалист, который парой своих находок и репортов сэкономит огромное количество денег, нервов, сил и времени, но которого по тем или иным причинам компания не в состоянии нанять в качестве сотрудника.
Важна также скорость и эффективность выявления уязвимостей. Если в штате компании таких специалистов пять-десять, а Bug Bounty подключает к работе над вашим продуктом сразу еще человек пятьдесят-сто, то наверняка работа пойдет быстрее и результативнее.
Понятно, что у таких программ есть и минусы. Информация о выявленных уязвимостях может оказаться в общем доступе до того, как их залатают. Однако не будем на этом останавливаться, так как цель статьи — рассмотреть Bug Bounty с юридической стороны, а не с экономической или организационной.
Какие бывают виды Bug Bounty?
Если говорить простым языком, то Bug Bounty устанавливает правила игры между владельцем программного продукта (объекта исследования) и сторонним исследователем, который будет изучать объект и находить уязвимости. Эти правила могут различаться по объему и содержанию, и даже сам формат может быть разным. Чаще всего встречаются такие варианты:
- оферта (в том числе публичная оферта);
- конкурс;
- публичное обещание награды;
- прямое соглашение (договор) между владельцем и конкретными исследователями.
Каждый из вариантов имеет свои юридические особенности, которые могут повлечь за собой различные юридические последствия. Поэтому об их тонкостях полезно знать любому багхантеру.
Обрати внимание, что мы говорим о российском законодательстве, поэтому некоторые мои комментарии справедливы только для программ Bug Bounty, которые проводятся в России (см. например, правила Яндекса и Газинформсервиса). Нормы законов могут отличаться от страны к стране, но общие принципы в немалом количестве случаев будут похожими. Так что приведенная здесь информация наверняка поможет тебе сориентироваться.Обрати внимание, что мы говорим о российском законодательстве, поэтому некоторые мои комментарии справедливы только для программ Bug Bounty, которые проводятся в России (см. например, правила Яндекса и Газинформсервиса). Нормы законов могут отличаться от страны к стране, но общие принципы в немалом количестве случаев будут похожими. Так что приведенная здесь информация наверняка поможет тебе сориентироваться.
Что представляет собой Bug Bounty как оферта?
Юридическое определение термина оферты приведено в статье 435 Гражданского кодекса РФ:
Статья 435. Оферта
- Офертой признается адресованное одному или нескольким конкретным лицам предложение, которое достаточно определенно и выражает намерение лица, сделавшего предложение, считать себя заключившим договор с адресатом, которым будет принято предложение. Оферта должна содержать существенные условия договора.
- Оферта связывает направившее ее лицо с момента ее получения адресатом.
Если извещение об отзыве оферты поступило ранее или одновременно с самой офертой, оферта считается не полученной.
Проще говоря, оферта — это конкретное предложение от инициатора к одному или нескольким лицам (человеку или компании, без разницы) сделать что-либо определенным образом. В случае с Bug Bounty это предложение владельца ПО к конкретным багхантерам поискать уязвимости в определенные сроки и (возможно) за определенное вознаграждение. При этом условия для всех равны. Допустим, владелец направил свои условия и правила тестирования на почту багхантеру — это значит, он сделал ему оферту. Если тот принял предложение, то это будет считаться акцептом оферты (то есть ее принятием).
Что такое публичная оферта?
Когда предложение организатора поучаствовать в его Bug Bounty адресовано не определенным лицам, а любому, кто пожелает испытать свои силы в поиске (то есть неограниченному кругу лиц), это уже будет считаться не просто офертой, а публичной офертой. И про эту оферту говорит уже пункт 2 статьи 437 ГК РФ:
Статья 437. Приглашение делать оферты. Публичная оферта
2. Содержащее все существенные условия договора предложение, из которого усматривается воля лица, делающего предложение, заключить договор на указанных в предложении условиях с любым, кто отзовется, признается офертой (публичная оферта).
Возьмем для примера программу Bug Bounty фонда Mozilla. В ее тексте нет ограничения относительно того, кто может участвовать в программе по ловле багов. То есть это публичная оферта, так как она адресована неограниченному кругу лиц. Другой пример — лаконичные условия Bug Bounty «Лаборатории Касперского»:
All researchers are welcome to participate.
Это тоже позволяет считать программу «Лаборатории Касперского» публичной офертой. Обрати внимание, что у компаний нередко встречаются ограничения по кругу потенциальных участников (подсмотрено у Uber):
You are not eligible to participate in the Bug Bounty Program if you are: (i) a resident of, or make your Submission from, a country against which the United States has issued export sanctions or other trade restrictions (e.g., Cuba, Iran, North Korea, Sudan and Syria); (ii) employed by Uber Technologies, Inc. or any of its affiliates; (iii) an immediate family member of a person employed by Uber Technologies, Inc. or any of its affiliates; or (iv) less than 18 years of age.
Первое ограничение (по странам) характерно для американских компаний, которым приходится соблюдать строгое экспортное законодательство и введенные экономические санкции, которые затрагивают в том числе и подобную деятельность.
Второй пункт — запрет участвовать в программе сотрудникам Uber. Это требование вытекает из общей логики Bug Bounty. Без него объективность условий программы будет под сомнением, а инсайдеры окажутся в более выгодных условиях, чем сторонние багхантеры. С теми же соображениями связан и третий пункт — запрет на участие членам семей сотрудников.
В общем, тексты Bug Bounty, опубликованные в открытом доступе и не адресованные кому-то из исследователей персонально, можно расценивать как оферты.
Можно ли менять условия оферты?
Интересный момент заключается в том, что оферта — это не железобетонный текст, который нельзя менять после публикации. По ГК прямого запрета на изменение ее условий нет, есть запрет на отзыв ее обратно, но в данном случае это сути не меняет. Поэтому если инициатор программы Bug Bounty выложил правила как оферту, а потом захотел их изменить и изменил, то получается, что он предложил новую оферту взамен первоначальной.
Если багхантер уже начал работать по более ранней версии оферты и ему выгодно завершить свою работу на ее условиях, то ему потребуется приложить определенные усилия для того, чтобы доказать, что он действительно принял именно первоначальную версию правил. В противном случае ему придется вести сотрудничество на условиях новой версии.
Лучше всего, конечно, сделать копию правил перед началом участия, чтобы потом на руках были доказательства того, что текст менялся. Однако просто скопировать текст себе на компьютер будет мало: как потом доказать, что ты этот текст не подправил сам? Надежнее иметь копию на независимой площадке. Для этого могут подойти инструменты создания скриншотов страниц с последующим их сохранением на стороннем сервисе, кеш поисковиков или тот же Archive.org. Конечно, никто не запрещает добраться до нотариуса и надлежащим образом заверить у него текст оферты, но редко кто готов тратить на это время, средства и силы.
Может ли багхантер предложить свои условия?
Если смотреть все в тот же ГК РФ, то там есть статья 443, которая содержит интересную норму:
Статья 443. Акцепт на иных условиях
Ответ о согласии заключить договор на иных условиях, чем предложено в оферте, не является акцептом.
Такой ответ признается отказом от акцепта и в то же время новой офертой.
Получается, что если тебя не устраивают условия Bug Bounty, то ты можешь написать свои и предложить их инициатору. Логика здесь простая: по закону нельзя принять оферту частично или с оговорками (см. статью 438 ГК РФ ниже), ее можно либо принять полностью, либо не принять совсем; но тот же самый закон позволяет другой стороне оферты вместо акцепта предложить свою версию условий.
Возьмем для примера условия Bug Bounty «Рокетбанка».
Обнаружение уязвимостей
В случае обнаружения уязвимостей любого рода мы предлагаем вам сообщить о них по адресу security@rocketbank.ru. Не разглашайте сведения об уязвимостях публично и не передавайте сведения третьим лицам.
Вы можете воспользоваться нашим публичным pgp-ключом, чтобы отправить шифрованное письмо.
За сообщение о серьезной и публично не разглашенной уязвимости мы можем принять решение о вознаграждении за ее обнаружение. Кроме того, ссылка на ваш профиль может быть опубликована на этой странице. Разумеется, если вы того захотите.
Если считать этот лаконичный текст полными условиями Bug Bounty, то закон не запрещает в ответ на них отправить свой вариант оферты. Например, что-то такое:
За сообщение о серьезной уязвимости мы обязуемся выплатить вознаграждение за ее обнаружение не менее 1000 долларов в течение 30 дней с момента получения информации о такой уязвимости.
Но не думай, что если вот так взял и отправил инициатору свою версию правил, то она будет автоматически считаться принятой. Все тот же ГК РФ предусмотрительно имеет на такие случаи следующую норму.
Статья 438. Акцепт
- Акцептом признается ответ лица, которому адресована оферта, о ее принятии. Акцепт должен быть полным и безоговорочным.
- Молчание не является акцептом, если иное не вытекает из закона, соглашения сторон, обычая или из прежних деловых отношений сторон.
То есть если в ответ на предложение своей версии правил другая сторона молчит, то ты потом не сможешь говорить, что молчание — знак согласия. Твоя версия сработает только в том случае, если в ответ от организатора ты получишь однозначное подтверждение.
Когда лучше направлять свою версию правил?
Допустим, ты нашел программу Bug Bounty, прочитал ее условия, успел найти уязвимость и отправить. Потом думаешь, что здорово было бы заслать еще и свою версию правил, и вдогонку пишешь письмо в духе «Я направил вам отчет, но знаете, вы его принимайте, только если примете мои условия, которые в файле во вложении». Так вот, весьма вероятно, что отчет примут именно на первоначальных условиях оферты, а твою версию могут по праву отклонить. И если ты захочешь доказать, что направил ответ на своих условиях, то пункт 3 статьи 438 ГК РФ решит дело не в твою пользу:
Статья 438. Акцепт
3. Совершение лицом, получившим оферту, в срок, установленный для ее акцепта, действий по выполнению указанных в ней условий договора (отгрузка товаров, предоставление услуг, выполнение работ, уплата соответствующей суммы и т. п.) считается акцептом, если иное не предусмотрено законом, иными правовыми актами или не указано в оферте.
Конечно, многое зависит от текста конкретной программы, но в большинстве случаев в целом все сводится к схеме «прочитал правила — нашел уязвимости — отправил на почту, указанную в правилах». То есть отправка багхантером своего отчета будет расцениваться как принятие им условий самой программы.
Если хочешь определить новые правила сотрудничества, то, будь добр вначале согласуй их, а уже потом информируй о своих находках. Истории про доплату уже после предоставления отчетов случаются совсем нечасто (хотя бывает и такое).
Почему мою версию правил могут не принять?
Причины отклонения обычно просты и очевидны. Для большой компании программа Bug Bounty — это прежде всего рабочий процесс, который надо наладить и выстроить: принятие отчетов от багхантеров, их обработка и оценка, вынесение решения о вознаграждении и выплата его через бухгалтерию. Все это требует немалых усилий сотрудников компании, поэтому вряд ли кто-то будет заниматься еще и согласованием новых условий в индивидуальном порядке по своей же собственной оферте — для этого понадобилось бы подключать еще и юриста. Тут, скорее, все работает так: если багхантер не знаменитость, то вряд ли кто с ним будет согласовывать индивидуальные условия; а вот если со своим предложением обратится известный специалист, то вполне могут предложить и персональное соглашение.
Сколько победителей будет в программе, если она идет как оферта?
Термин «победитель» относится скорее к формату конкурса. По оферте победителем считается любой исследователь, результаты деятельности которого были признаны успешными другой стороной (в данном случае инициатором программы Bug Bounty) и который получил за это какое-либо благо (будь то денежное вознаграждение, внесение его имени в «зал славы» или что-то еще).
Должна ли в оферте указываться награда за успешный результат?
В статье 435 ГК РФ, о которой мы уже говорили, есть такая формулировка: «Оферта должна содержать существенные условия договора». О каком договоре речь? Поскольку багхантер оказывает услугу владельцу ПО или сервиса, то под договором следует понимать «возмездное оказание услуг» (глава 39 ГК РФ). Вознаграждение там упомянуто, но не обязательно денежное. Вместо этого может предлагаться что-нибудь хитрое, как, например, в программе General Motors, где в качестве награды в прошлом году пообещали отсутствие судебных исков к багхантерам.
Какие риски у Bug Bounty как оферты?
В первую очередь багхантерам следует помнить, что условия оферты могут быть изменены инициатором программы Bug Bounty в одностороннем порядке, особенно если в самих правилах оговорена такая возможность. Это может касаться, например, размера вознаграждения.
Крайне желательно, чтобы в тексте были указаны сроки: в течение какого времени можно искать и присылать выявленные уязвимости, в течение какого времени надо ждать ответ от сотрудников организатора программы Bug Bounty, в течение какого времени должны прилететь деньги на счет успешного ловца уязвимостей с момента утверждения его результата. Иначе могут возникнуть проблемы с рассмотрением заявки и выплатой вознаграждения.
Для инициаторов Bug Bounty формат оферты может добавить головной боли из-за налоговых вопросов. Выплату вознаграждения багхантерам будет сложно обосновать налоговой как составляющую расходов в целях налогообложения прибыли затрат. Инспекция может и не признать произведенные затраты расходами из-за отсутствия документа, который был бы подписан обеими сторонами.
На этом про оферту пока всё. В следующий раз мы рассмотрим варианты Bug Bounty как конкурса, публичного обещания награды и договора.