Правила Bug Bounty как договор

🖨️
текст первоначально был опубликован в журнале "Хакер"

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

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

The Complete List of Bug Bounty Programs 2024
Many companies challenge hackers – or anyone else who wants to give it a try – to find security bugs in their systems and break in. Not only that, but they reward anyone who can

Перечень действующих программ Bug Bounty смотрите, например, здесь

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

Какой именно договор заключается для поиска багов?

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

Между кем заключается договор?

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

Может ли багхантер вносить правки в договор заказчика?

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

Гражданский кодекс РФ
статья 421. Свобода договора

  1. Граждане и юридические лица свободны в заключении договора.
  2. <…>
  3. <…>
  4. Условия договора определяются по усмотрению сторон, кроме случаев, когда содержание соответствующего условия предписано законом или иными правовыми актами (статья 422).

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

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

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

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

Стоит ли начинать работать до согласования договора?

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

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

Какие условия должны быть отражены в договоре?

Мы уже обозначили, что подобный договор следует квалифицировать как договор на оказание услуг. В действующем российском законодательстве отношения сторон по такому типу договора регулируются главой 39 Гражданского кодекса РФ «Возмездное оказание услуг». Для нас в особенности интересны положения статьи 779 из этой главы.

Статья 779. Договор возмездного оказания услуг

  1. По договору возмездного оказания услуг исполнитель обязуется по заданию заказчика оказать услуги (совершить определенные действия или осуществить определенную деятельность), а заказчик обязуется оплатить эти услуги.
  2. Правила настоящей главы применяются к договорам оказания услуг связи, медицинских, ветеринарных, аудиторских, консультационных, информационных услуг, услуг по обучению, туристическому обслуживанию и иных, за исключением услуг, оказываемых по договорам, предусмотренным главами 37, 38, 40, 41, 44, 45, 46, 47, 49, 51, 53 настоящего Кодекса.

По своей сути поиск и выявление багов — это деятельность специалиста, включающая в себя:

  1. обнаружение необходимой информации,
  2. фиксацию способа ее обнаружения (составление инструкции),
  3. передачу этой информации заказчику.
  4. Дополнительным действием может быть и предоставление сведений о том, как именно устранить выявленные недочеты наилучшим образом (то есть своего рода консультирование).

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

Законом определено, какие именно условия следует считать существенными применительно к договору на оказание услуг. К ним относятся:

  1. Предмет договора — подробный перечень услуг, которые исполнитель окажет заказчику. Здесь описываются сами услуги (поиск, выявление, сбор необходимой информации, предоставление ее заказчику), а также устанавливаются пределы их оказания, то есть перечисляются те программные продукты и решения, которые будут исследоваться на предмет отсутствия ошибок.
  2. Срок оказания услуг — явным образом определенный период времени, в течение которого исполнитель будет оказывать свои услуги. Как окончание услуг может устанавливаться не только конкретная дата, но и момент наступления определенного действия или события (например, тестирование продукта в версии 1.0 до тех пор, пока не будет выявлено десять уязвимостей). Здесь, правда, судебной практике известны разные подходы. Есть примеры судебных дел, в которых суд делал вывод, что невозможно поставить наличие оказанных услуг в зависимость от достижения конкретного результата (см. постановление ФАС Дальневосточного округа от 24 марта 2014 года по делу № А51-8734/2012). А есть и судебные примеры с прямо противоположными выводами (см. постановление Президиума ВАС РФ от 24 января 2012 года № 11563-11).
    Если заказчик будет выплачивать ловцу багов вознаграждение за проделанную работу, то в этом случае возникает дополнительное условие:
  3. Стоимость услуг — размер вознаграждения исполнителя за оказанные услуги. Из договора должно явно следовать, в какой валюте он определен и в каком размере (если вознаграждение денежное). Сторонам лучше конкретизировать в договоре, полагается ли вознаграждение исполнителю, если за весь срок действия договора он действительно оказывал услуги, но при этом никакого результата в виде найденных ошибок или уязвимостей принести заказчику не смог.

Вопрос о том, является ли стоимость услуг (цена договора) существенным условием, в судебной практике тоже решается по-разному. Есть решения, в которых стоимость услуг признана существенным условием договора — см. постановление ФАС Западно-Сибирского округа от 10 августа 2006 года по делу № Ф04-4313/2006 (24369-А03-36), но есть решения, утверждающие обратное (см. постановление АС Западно-Сибирского округа от 4 июня 2015 года по делу № А67-5688/2014 — PDF).

Если в договоре стороны согласовали не все существенные условия, то договор может быть признан незаключенным, и в этом есть свои риски. Например, если договор не заключен, то, оплатят ли исполнителю услуги, будет зависеть исключительно от воли заказчика (если юридически заказ услуг оформлен не был, то и обязанности оплаты у заказчика не возникает).

Что, если договор был подписан, но не содержит в себе одно из существенных условий?

Если заказчик хотя бы частично принял от исполнителя результаты его услуг, то при возникновении споров этот факт дает исполнителю право все равно требовать признать договор заключенным (см. пункт 3 статьи 432 Гражданского кодекса РФ).

Какой договор заключать для консультирования сотрудников заказчика?

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

Следует иметь в виду, что бухгалтерии заказчика, скорее всего, понадобится отчет исполнителя об объеме оказанных услуг, поэтому лучше заранее уточнить детали у бухгалтера и быть готовым предоставить необходимую информацию.

Можно ли заключить договор в электронном виде?

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

  • Каждая сторона должна подписать договор. Если стороны решили обменяться сканами договора по электронной почте, то каждой стороне следует поставить свою подпись в согласованную версию договора и направить свой скан другой. Как вариант, можно использовать электронную подпись — для этого потребуются соответствующие цифровые сертификаты или же сервис наподобие DocuSign. Этот случай обговорен в статье 434 Гражданского кодекса РФ:

Статья 434. Форма договора

  1. <…>
  2. Договор в письменной форме может быть заключен путем составления одного документа, подписанного сторонами, а также путем обмена письмами, телеграммами, телексами, телефаксами и иными документами, в том числе электронными документами, передаваемыми по каналам связи, позволяющими достоверно установить, что документ исходит от стороны по договору.
    Электронным документом, передаваемым по каналам связи, признается информация, подготовленная, отправленная, полученная или хранимая с помощью электронных, магнитных, оптических либо аналогичных средств, включая обмен информацией в электронной форме и электронную почту.
  • В договоре должен быть описан порядок его заключения. Например, если стороны договорились, что договор вступает в силу после того, как одна сторона отправит другой по электронной почте PDF-версию финальной редакции договора, а другая сторона подтвердит, что согласна с этой версией, то в тексте соглашения должно быть явным образом прописано такое условие, с указанием адресов электронной почты обеих сторон.
    Еще момент: при заключении договора (хоть в бумажном виде, хоть в электронном), если одна из сторон — юридическое лицо, следует попросить такую сторону предоставить документы, подтверждающие правомочия ее представителя подписывать договор (например, доверенность).

Должны ли условия договора быть конфиденциальными?

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

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

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

Может ли багхантер публично раскрыть обнаруженную информацию?

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

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

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

Что надо знать про выплату вознаграждения по договору?

Стоимость услуг по договору будет объектом налогообложения. Так, если заказчик — юридическое лицо, а исполнитель — физическое, то по российскому законодательству заказчик в качестве налогового агента обязуется удержать налоговую часть. Размер налога составляет 13% для физических лиц — налоговых резидентов РФ и 30% для физических лиц — налоговых нерезидентов РФ. Подробно про нерезидентов я писал в одном из предыдущих материалов. Если исполнитель — ИП или компания, с нее может и не удерживаться никакой налог (например, когда такой исполнитель находится на упрощенной системе налогообложения).

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

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

Как определять порядок передачи найденной информации?

Ровно в том виде, о котором договорятся обе стороны, и это должно быть отражено в договоре. Для исполнителя будет нелишним фиксировать эксплуатацию на видео. Это нужно на случай, если недобросовестный заказчик получит от исполнителя все необходимое, устранит выявленную уязвимость, а потом скажет, что такой уязвимости вовсе не было. Тогда запись может послужить хорошим аргументом в составе доказательной базы.

Какие в итоге документы будут у сторон договора?

Если заказ на поиск уязвимостей оформляется в виде договора, а хотя бы одной из сторон договора выступает юридическое лицо, зарегистрированное на территории РФ, или индивидуальный предприниматель, то в итоге у сторон будет следующий комплект документов:

  • сам договор (соглашение), в котором отражаются все существенные условия и вся иная необходимая информация по оказанию услуг. Такая информация может быть вынесена и в приложения или дополнительные соглашения к договору;

  • отчет исполнителя, в котором отражается вся информация о его деятельности, направленной на оказание услуг, а также информация об обнаруженных результатах;

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

Какая у сторон может быть ответственность по договору?

У багхантера может быть ответственность, предусмотренная как законом, так и договором. Об ответственности рекомендую прочитать один из предыдущих моих материалов, там разбирается этот вопрос. Чтобы багхантер не понес ответственность за случайное нанесение ущерба инфраструктуре или программным продуктам заказчика, в договоре следует четко прописать, какие действия он вправе совершать, а какие нет, какие объекты он вправе исследовать, а какие нет, имеет ли он право самостоятельно устранять выявленные уязвимости или нет, имеет ли он право хранить у себя выявленную информацию, и если да, то какую, каким образом и в течение какого времени.

Для заказчика может иметь значение качество оказываемых услуг. Поэтому в договоре могут быть предусмотрены критерии качества и определена ответственность за оказание услуг ненадлежащего качества — например, уменьшение вознаграждения либо отказ в его выплате, досрочное одностороннее прекращение договора.

Также для заказчика крайне важен порядок раскрытия обнаруженной информации либо то, что она не будет раскрываться без согласия самого заказчика. Все это обычно описывается в договоре. Как правило, это сопровождается описанием штрафной неустойки с существенным для исполнителя размером. Это лучше, чем требовать возмещения всех убытков (хотя их можно требовать и наряду с неустойкой, если прописать обе меры ответственности в договоре), и проще доказывать в суде для взыскания.

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

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

Подводя итоги

Для лучшего закрепления повторим вкратце все сказанное.

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

  2. Обе стороны договора вправе вносить предложения, предлагать изменения первоначальной редакции договора и отстаивать свои позиции относительно финальной версии его содержания.

  3. В договоре должны быть определены все существенные условия, чтобы избежать риска, что договор признают незаключенным.

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

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