Ответы юриста. Что нужно знать хакеру для участия в 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 как оферта?

Юридическое определение термина оферты приведено в статье 435 Гражданского кодекса РФ:

Проще говоря, оферта — это конкретное предложение от инициатора к одному или нескольким лицам (человеку или компании, без разницы) сделать что-либо определенным образом. В случае с Bug Bounty это предложение владельца ПО к конкретным багхантерам поискать уязвимости в определенные сроки и (возможно) за определенное вознаграждение. При этом условия для всех равны. Допустим, владелец направил свои условия и правила тестирования на почту багхантеру — это значит, он сделал ему оферту. Если тот принял предложение, то это будет считаться акцептом оферты (то есть ее принятием).

Что такое публичная оферта?

Когда предложение организатора поучаствовать в его Bug Bounty адресовано не определенным лицам, а любому, кто пожелает испытать свои силы в поиске (то есть неограниченному кругу лиц), это уже будет считаться не просто офертой, а публичной офертой. И про эту оферту говорит уже пункт 2 статьи 437 ГК РФ:

Возьмем для примера программу Bug Bounty фонда Mozilla. В ее тексте нет ограничения относительно того, кто может участвовать в программе по ловле багов. То есть это публичная оферта, так как она адресована неограниченному кругу лиц. Другой пример — лаконичные условия Bug Bounty «Лаборатории Касперского»:

Это тоже позволяет считать программу «Лаборатории Касперского» публичной офертой. Обрати внимание, что у компаний нередко встречаются ограничения по кругу потенциальных участников (подсмотрено у Uber):

Первое ограничение (по странам) характерно для американских компаний, которым приходится соблюдать строгое экспортное законодательство и введенные экономические санкции, которые затрагивают в том числе и подобную деятельность.

Второй пункт — запрет участвовать в программе сотрудникам Uber. Это требование вытекает из общей логики Bug Bounty. Без него объективность условий программы будет под сомнением, а инсайдеры окажутся в более выгодных условиях, чем сторонние багхантеры. С теми же соображениями связан и третий пункт — запрет на участие членам семей сотрудников.

В общем, тексты Bug Bounty, опубликованные в открытом доступе и не адресованные кому-то из исследователей персонально, можно расценивать как оферты.

Можно ли менять условия оферты?

Интересный момент заключается в том, что оферта — это не железобетонный текст, который нельзя менять после публикации. По ГК прямого запрета на изменение ее условий нет, есть запрет на отзыв ее обратно, но в данном случае это сути не меняет. Поэтому если инициатор программы Bug Bounty выложил правила как оферту, а потом захотел их изменить и изменил, то получается, что он предложил новую оферту взамен первоначальной.

Если багхантер уже начал работать по более ранней версии оферты и ему выгодно завершить свою работу на ее условиях, то ему потребуется приложить определенные усилия для того, чтобы доказать, что он действительно принял именно первоначальную версию правил. В противном случае ему придется вести сотрудничество на условиях новой версии.

Лучше всего, конечно, сделать копию правил перед началом участия, чтобы потом на руках были доказательства того, что текст менялся. Однако просто скопировать текст себе на компьютер будет мало: как потом доказать, что ты этот текст не подправил сам? Надежнее иметь копию на независимой площадке. Для этого могут подойти инструменты создания скриншотов страниц с последующим их сохранением на стороннем сервисе, кеш поисковиков или тот же Archive.org. Конечно, никто не запрещает добраться до нотариуса и надлежащим образом заверить у него текст оферты, но редко кто готов тратить на это время, средства и силы.

Может ли багхантер предложить свои условия?

Если смотреть все в тот же ГК РФ, то там есть статья 443, которая содержит интересную норму:

Получается, что если тебя не устраивают условия Bug Bounty, то ты можешь написать свои и предложить их инициатору. Логика здесь простая: по закону нельзя принять оферту частично или с оговорками (см. статью 438 ГК РФ ниже), ее можно либо принять полностью, либо не принять совсем; но тот же самый закон позволяет другой стороне оферты вместо акцепта предложить свою версию условий.

Возьмем для примера условия Bug Bounty «Рокетбанка».

Если считать этот лаконичный текст полными условиями Bug Bounty, то закон не запрещает в ответ на них отправить свой вариант оферты. Например, что-то такое:

Но не думай, что если вот так взял и отправил инициатору свою версию правил, то она будет автоматически считаться принятой. Все тот же ГК РФ предусмотрительно имеет на такие случаи следующую норму.

То есть если в ответ на предложение своей версии правил другая сторона молчит, то ты потом не сможешь говорить, что молчание — знак согласия. Твоя версия сработает только в том случае, если в ответ от организатора ты получишь однозначное подтверждение.

Когда лучше направлять свою версию правил?

Допустим, ты нашел программу Bug Bounty, прочитал ее условия, успел найти уязвимость и отправить. Потом думаешь, что здорово было бы заслать еще и свою версию правил, и вдогонку пишешь письмо в духе «Я направил вам отчет, но знаете, вы его принимайте, только если примете мои условия, которые в файле во вложении». Так вот, весьма вероятно, что отчет примут именно на первоначальных условиях оферты, а твою версию могут по праву отклонить. И если ты захочешь доказать, что направил ответ на своих условиях, то пункт 3 статьи 438 ГК РФ решит дело не в твою пользу:

Конечно, многое зависит от текста конкретной программы, но в большинстве случаев в целом все сводится к схеме «прочитал правила — нашел уязвимости — отправил на почту, указанную в правилах». То есть отправка багхантером своего отчета будет расцениваться как принятие им условий самой программы.

Если хочешь определить новые правила сотрудничества, то, будь добр вначале согласуй их, а уже потом информируй о своих находках. Истории про доплату уже после предоставления отчетов случаются совсем нечасто (хотя бывает и такое).

Почему мою версию правил могут не принять?

Причины отклонения обычно просты и очевидны. Для большой компании программа Bug Bounty — это прежде всего рабочий процесс, который надо наладить и выстроить: принятие отчетов от багхантеров, их обработка и оценка, вынесение решения о вознаграждении и выплата его через бухгалтерию. Все это требует немалых усилий сотрудников компании, поэтому вряд ли кто-то будет заниматься еще и согласованием новых условий в индивидуальном порядке по своей же собственной оферте — для этого понадобилось бы подключать еще и юриста. Тут, скорее, все работает так: если багхантер не знаменитость, то вряд ли кто с ним будет согласовывать индивидуальные условия; а вот если со своим предложением обратится известный специалист, то вполне могут предложить и персональное соглашение.

Сколько победителей будет в программе, если она идет как оферта?

Термин «победитель» относится скорее к формату конкурса. По оферте победителем считается любой исследователь, результаты деятельности которого были признаны успешными другой стороной (в данном случае инициатором программы Bug Bounty) и который получил за это какое-либо благо (будь то денежное вознаграждение, внесение его имени в «зал славы» или что-то еще).

Должна ли в оферте указываться награда за успешный результат?

В статье 435 ГК РФ, о которой мы уже говорили, есть такая формулировка: «Оферта должна содержать существенные условия договора». О каком договоре речь? Поскольку багхантер оказывает услугу владельцу ПО или сервиса, то под договором следует понимать «возмездное оказание услуг» (глава 39 ГК РФ). Вознаграждение там упомянуто, но не обязательно денежное. Вместо этого может предлагаться что-нибудь хитрое, как, например, в программе General Motors, где в качестве награды в прошлом году пообещали отсутствие судебных исков к багхантерам.

Какие риски у Bug Bounty как оферты?

В первую очередь багхантерам следует помнить, что условия оферты могут быть изменены инициатором программы Bug Bounty в одностороннем порядке, особенно если в самих правилах оговорена такая возможность. Это может касаться, например, размера вознаграждения.

Крайне желательно, чтобы в тексте были указаны сроки: в течение какого времени можно искать и присылать выявленные уязвимости, в течение какого времени надо ждать ответ от сотрудников организатора программы Bug Bounty, в течение какого времени должны прилететь деньги на счет успешного ловца уязвимостей с момента утверждения его результата. Иначе могут возникнуть проблемы с рассмотрением заявки и выплатой вознаграждения.

Для инициаторов Bug Bounty формат оферты может добавить головной боли из-за налоговых вопросов. Выплату вознаграждения багхантерам будет сложно обосновать налоговой как составляющую расходов в целях налогообложения прибыли затрат. Инспекция может и не признать произведенные затраты расходами из-за отсутствия документа, который был бы подписан обеими сторонами.

На этом про оферту пока всё. В следующий раз мы рассмотрим варианты Bug Bounty как конкурса и как публичного обещания награды.