همانطور که در مطلب پیشین ذکر شد، تاثیر حفاظت از باگهای نرمافزاری در حفظ امنیت اطلاعات کاربران و جلوگیری از سوء‌استفاده هکرها، همچنین کاهش امکان از دست دادن کاربر، بهبود عملکرد در بازار مربوطه و برخورداری از مزیت رقابتی موجب میشود که توسعهدهندگان مایل به راه‌حل‌های حقوقی جلوگیری از افشای باگها باشند. این راه‌حل‌ها ممکن است یا از طریق قانون و تصمیم سیاستگذاران این حوزه ارائه گردد (که تا حدودی در مطلب پیشین مورد بررسی قرار گرفت) و یا در قالب قرارداد جلوه‌گر شود.(موضوع مطلب پیش رو)
حفاظت از باگها در قالب‌های قراردادی
توسعهدهندگان علاوه بر آن که به دنبال عدم انتشار یا افشای اطلاعات مربوط به باگهای نرمافزاری هستند، سعی میکنند تا حد امکان از باگ‌هایی که در نرم‌افزارشان وجود دارد اما از آن بی‌اطلاع هستند، به نحوی محرمانه مطلع شوند؛ یعنی فرد مطلع، فقط توسعه‌دهنده را از وجود باگ آگاه سازد. در زمان‌های نه‌چندان دور توسعهدهندگان نرم‌افزارها، تنها از روش‌هایی همچون آزمایش نفوذ (۱) برای بررسی میزان نفوذپذیری سیستم استفاده می‌کردند. در این آزمایش یک حمله سایبری شبیه سازی شده علیه نرمافزار اعمال میشود تا آسیبپذیری‌های احتمالی بررسی شده و کشف گردند.(۲) در این روش حمله سایبری با مجوز توسعه‌دهنده و توسط تیمی از متخصصین امنیت (۳) صورت می‌پذیرد. هزینه‌های سرسام‌آوری که در نتیجه اعمال این حمله و نتایج ناخواسته که ممکن بود در پی داشته باشد، توسعهدهندگان را به روش‌‌های دیگری برای یافتن باگهای نرمافزار رهنمون کرد. یکی از این روشها پاداش در مقابل گزارش باگ است که در ادامه به آن پرداخته خواهد شد.
چنانچه در مطلب پیش نیز اشاره شد، چنین روشی حتی میتواند نشانه‌ای از تلاش‌های معقول توسعه‌دهنده برای حفاظت از اطلاعات باگهای نرمافزاری باشد.
۱- پاداش در مقابل گزارش باگ(۴)
یکی از شیوه‌های توسعهدهندگان نرم‌افزارهای رایانه‌ای به منظور آگاهی از باگهای موجود در نرمافزار در نظر گرفتن پاداش برای هکرهای کلاه‌سفید(۵) است.
به دلیل دشواری پیاده‌سازی نرم‌افزارها، یک نرمافزار ممکن است دارای رفتاری مغایر با کارکرد یا اهداف خود شود که سازندگان آن از این مشکل بی‌اطلاع باشند و منجر به ناامنی در بستر نرمافزار گردد. پیشگیری از بروز هرگونه رفتار مغایر با هدف نرمافزار و در نتیجه رسیدن به امنیت صد‌در‌صدی، حتی با صرف هزینه‌ی بسیار بالا لزوماً در توان توسعهدهندگان نیست، در نتیجه هر توسعه‌دهنده متناسب با محصول یا خدمتی که ارائه می‌دهد و سطح دانش فنی و توان اقتصادی‌اش اقدام به تشخیص مغایرت‌های کارکردی و تثبیت عملکرد نرمافزار میکند. در کنار آن بی اعتنایی به چنین موضوعی میتواند نتایج جبران‌ناپذیری را برای نرمافزار به همراه داشته باشد.
بسیاری از هکرها ممکن است با استفاده از اطلاعات مربوط به باگهای نرمافزار، امنیت آن و اطلاعات کاربران را به مخاطره انداخته، الگوریتم‌های نرمافزار را به سرقت برده یا آنکه برای از میان بردن شهرت نرمافزار دست به افشاگری در خصوص باگهای نرمافزاری بزنند. توسعهدهندگان با ایجاد بستر اعطای پاداش به هکرهای کلاه‌سفید، نیروی آنها را در جهت اهداف نرمافزار هدایت میکنند.(۶) رسیدن به چنین هدفی منوط به ایجاد فضایی دوستانه و قابل اعتماد میان هکر و توسعه‌دهنده است؛ بستری که در انعقاد مفاد قرارداد پاداش در قبال گزارش باگ(۷) باید مورد توجه قرار گیرد.
با این حال ذکر این نکته ضروری است که در بسیاری از موارد توسعهدهندگان، نرمافزار را بصورت «کد منبع‌باز»(۸) ارائه میدهند؛ بدان معنی که توسعه‌دهنده‌ی نرمافزار، به دریافت‌کنندگانِ نرمافزار، حق توزیع، مداخله و حتی تغییر در کدهای یک نرمافزار را اعطا میکند. در این موارد استفاده از «قرارداد پاداش در قبال گزارش باگ» به دلیل دسترسی کاربران به منابع کد موثرتر است. به طور کلی این قراردادها دو مزیت دارد: اول آنکه تمامی کاربران نرمافزار در سراسر جهان به آزمایش‌کنندگان نرمافزار تبدیل و نواقص آن با سرعت و دقت بالایی رفع میشود و دوم آنکه نرمافزار براساس نیازهای خودِ کاربران تکامل خواهد یافت.(۹)
۲- ماهیت حقوقی
همانگونه که گفته شد موضوع قرارداد پاداش در قبال گزارش باگ، پرداخت پاداش در قبال یافتن باگ مشخص در سیستم مشخص است.
در نظام حقوقی ایران، چنین تعهدی پیوندی ناگسستنی با قرارداد جُعاله دارد. به موجب ماده ۵۶۱ قانون مدنی ایران: «جعاله عبارت است از التزام شخصی به اداء اجرت معلوم در مقابل عملی اعم از اینکه طرف معین باشد یا غیرمعین». همانطور که در این ماده تصریح شده است، تعهد به پاداش دادن و شناسایی این نهاد به عنوان عقد جعاله درصورتی قابل تحقق است که توسعه‌دهنده در متن درخواست افشای باگ، خود را «ملزم» به پرداخت پاداش کرده باشد.
جعاله بر اساس اینکه طرف معامله مشخص باشد یا خیر به ترتیب به دو دسته‌ی جعاله خاص و جعاله عام تقسیم میشود. از آن‌جا که در قرارداد پاداش در قبال گزارش باگ طرف معامله مشخص نیست، این قرارداد یک جعاله عام محسوب میشود و توسعه‌دهنده، جاعل (به معنی شخصی که برای عمل مشخصی پاداشی در نظر می‌گیرد)، هکر، عامل (به معنی شخصی که عمل مورد انتظار جاعل را انجام می‌دهد) و پاداش ارسال گزارش، جُعل (پاداش جعاله) به شمار می‌آیند. در جعاله عام برخلاف جعاله خاص تنها شخصی که برای اولین بار عمل مورد درخواست را انجام داده باشد، مستحق پاداش است.
جعاله یک قرارداد جایز تلقی میشود به این معنی که هر یک از طرفین می‌توانند پیش از انجام عمل یا در اثنای آن، قرارداد را فسخ نمایند؛ با این حال اگر عمل انجام شود دیگر نمی‌توان آن را فسخ نمود.
۳- پیشنهاداتی برای بهبود «قرارداد پاداش در قبال گزارش باگ»
همانطور که گفته شد «قرارداد پاداش در قبال گزارش باگ» را می‌توان مصداقی از عقد جعاله درنظر گرفت. در حقوق ایران و به علت شمول اینگونه قراردادها در ذیل قرارداد جعاله بسیاری از احکام از مفاد مواد مربوط به جعاله، قابل استخراج است؛ با این حال ذکر برخی از موارد همچون اعطای پاداش به نخستین کسی که گزارش یک باگ مشخص را داده باشد، به شفافیت قراردادی و ایجاد اعتماد میان کاربران و توسعهدهندگان کمک میکند. در ادامه به برخی از شروط قراردادی که قراردادهای پاداش در قبال گزارش باگ به آنها نیازمند است پرداخته میشود. در تدوین این شروط قراردادی توجه به ایجاد بستری دوستانه و قابل اعتماد برای گزارش‌کنندگان در ترغیب آنها به دادن گزارش باگ، نقش موثری را ایفا میکند:
الف) احراز تطابق عمل هکرها با آنچه که طرف اول جعاله برای آن پاداش در نظر گرفته است:
یکی از مهم‌ترین مسائل در خصوص اعطای پاداش گزارش باگ، تطابق یا عدم تطابق گزارش با باگ‌هایی است که در قرارداد برای آنها پاداش تعیین شده است. در بسیاری از موارد گزارش‌دهنده گزارش‌های خود را مصداقی از باگهای تعیین شده در قرارداد یا دارای اهمیت فراوان می‌داند.
لیکن، باید توجه نمود که فرآیند و مرجع تعیین تطابق یا عدم تطابق باید مشخص شود. ممکن است توسعه‌دهنده شخصاً و به طور ضمنی یا صریح فرآیند احراز تطابق را برعهده بگیرد. با این حال این روند میتواند به اعتماد گزارش‌کننده لطمه وارد کند و اساساً به دنبال یافتن باگ نباشد. افزون بر آن با ارائه گزارش توسط گزارش‌دهنده قرارداد لازم‌الاجرا خواهد بود و مرجع احراز و تفسیر قرارداد در موارد اختلاف دادگاه است و در هر صورت گزارش‌دهنده میتواند درخواست احراز تطابق را از دادگاه بخواهد.
در این موارد توسعه‌دهنده باید به الزام‌آوربودن قرارداد مذکور توجه داشته باشد. در کنار این واقعیت توسعه‌دهنده میتواند شرایطی را که در ارائه گزارش مطلوب اوست ذکر کند تا یابنده باگ نتواند به طور مطلق از پاداش بهره‌مند شود. بنابراین پیشنهاد میشود که عواملی همچون میزان اهمیت باگ و یا قابلیت تصحیح باگ از لحاظ فنی در اصل دریافت و میزان پاداش اثرگذار باشد. با این حال در تعیین شرایط مذکور حفظ انگیزه یابنده اهمیت داشته و وضوح و شفافیت مصادیق از اولویت برخوردار است.
این شیوه احراز در بسیاری از موارد مشاهده میشود؛ با این حال تعیین هیات کارشناسی تشخیص و احراز تطابق در صورت بروز اختلاف که نمایندگان آن منتخب هر دو هستند، میتواند تا حدودی این فضای ناامن را برای کاشفان باگ از میان ببرد. استفاده از معیارها و الگوهای مشخص برای تعیین باگ و محدوده جستجوی باگ میتواند به ساده‌کردن احراز مصادیق قرارداد کمک کند.(۱۰)
ب) شرط محرمانگی:
همانگونه که گفته شد یکی از اهداف صاحبان نرم‌افزارهای رایانه‌ای برای در نظر گرفتن پاداش، حفظ محرمانگی باگها و عدم افشای آن بخصوص در نزد رقبای خود است. افشای اطلاعات مربوط به باگ میتواند راهی برای دسترسی به الگوریتم نرمافزاری یا اطلاعات کاربران باشد یا آنکه وجهه تجاری نرمافزار را از میان ببرد؛ از طرفی برای هکرهای کلاه‌سفید افشای باگ بسیار اهمیت دارد.
شاید بتوان گفت که بسیاری از هکرها از کشف و ارائه‌‌ی گزارش باگ تنها انگیزه‌ی مالی ندارند و جنبه‌ی کسب اعتبار نیز برای آنها بسیار حائز اهمیت است. اگر در قرارداد سازکارهایی برای انتقال این اعتبار از طریق درج یک رده‌بندی در دسترس، یا موافقت با انتشار گزارش در سطح و چارچوب مورد قبول توسعه‌دهنده وجود داشته‌باشد، هکر به ارسال گزارش بسیار راغب‌تر خواهد بود و توسعه‌دهنده نیز توانسته از خطر افشای غیرقانونی این محتوا جلوگیری کند.
ج) دسته بندی باگها و محدوده‌ی گزارش:
مشخص است که گزارش هر باگ در مورد نرمافزار برای توسعهدهندگان دارای ارزش یکسانی نیست و در صورت عدم تصحیح آن ممکن است هزینه‌های متفاوتی را بر آنها تحمیل کند. افزون بر آن یافتن برخی از باگها نیازمند صرف هزینه، وقت فراوان و داشتن مهارت بسیار بالایی هستند که در صورت عدم تعیین پاداش درخور برای آنها گزارش‌دهندگان انگیزه‌ای برای یافتن یا گزارش آنها ندارند.
بنابراین توسعهدهندگان می‌توانند در قرارداد پاداش در قبال گزارش باگ، که معمولا در دسترس همگان است در کنار مشخص‌کردن انواع باگها، آنها را از باگهای بسیار پیچیده و مهم، تا ساده و دارای اهمیت کم، دسته‌بندی کنند. توسعه‌دهنده در این بند مشخص میکند که چه نوع پاداشی به چه نوع باگ‌هایی تعلق خواهد گرفت.
تعیین دقیق محتوای این بند یا ارجاع به رویه عرفی و فنی در بررسی باگها از بروز اختلافات آتی جلوگیری میکند. افزون بر آن، می‌توان میان گزارش‌‌هایی که صرفا وجود باگ را اعلام میکنند با آن‌هایی که راه‌حلی نیز پیشنهاد میدهند، تفکیک قائل شد. همچنین، محدوده‌ی گزارش باگ باید مشخص باشد. این محدوده اصولا با مشخص کردن دامنه خاص سایت یا محدوده امکان گزارش باگ در نرمافزار مشخص میشود.
د) شکل مخصوص گزارش:
بهتر است ارائه گزارش در قالب یک شکل مخصوص (برای مثال از طریق یک فرم مخصوص که برای ارسال گزارش پیش‌بینی شده است) باشد و این قالب در قرارداد پاداش در قبال گزارش باگ كه در دسترس همگان قرار می‌گیرد، تشریح شود. این روش، ارائه گزارش را منسجم کرده و گزارش‌دهنده را با الزام به تکمیل تمام قسمت‌های فرم گزارش باگ، جزییات کامل اطلاعات مربوط به باگ را از گزارش‌دهنده اخذ کند.
ه) عدم دسترسی غیرقانونی:
در نظر گرفتن پاداش برای گزارش باگ ممکن است گزارش‌دهنده را به نفوذ به نرمافزار خارج از چارچوب قرارداد پاداش در قبال گزارش باگ، ترغیب کرده و خسارات جبران ناپذیری را به سیستم وارد کند. افزون بر آن نفوذ خارج از چارچوب به سیستم میتواند زمینه بهره‌کشی (۱۱) از سیستم را هموار سازد، به این معنی که اطلاعات شخصی مربوط به کاربران را در معرض خطر قرار داده یا کارایی نرمافزار را مختل سازد.
بنابراین قرارداد پاداش در قبال گزارش باگ باید منوط به دستیابی به باگ از طرق معمول طبق شرایط تشریح شده باشد و نه از طریق رخنه خارج از چارچوب به سیستم؛ و توسعه‌دهنده به طور مشخص از هرگونه بهره‌کشی از سیستم چه به صورت مستقیم، توسط هکر، یا غیرمستقیم جلوگیری کند به عنوان مثال هکر این اطلاعات را در اختیار شخص ثالث قرار نداده و یا امکان بهره‌کشی از سیستم توسط شخص ثالث را فراهم نکند.
برای بررسی دقیق‌تر و حل یک باگ ممکن است گزارش‌دهنده نیاز به دریافت اطلاعات یا برخی دسترسی‌ها از توسعه‌دهنده باشد که اهمیت ایجاد تعهد برای گزارش‌دهنده به حفاظت از اطلاعات ارائه شده را در این فرایند تعاملی، دوچندان میکند.
نتیجه‌گیری
به وجود آمدن باگهای نرمافزاری امری غیر‌قابل‌اجتناب در عرصه نرم‌افزارهای رایانه‌ای محسوب شده و هیچ توسعه‌دهنده‌ای نمی‌تواند مدعی عدم وجود باگ در نرمافزار خود باشد. باگها آنقدر پیچیده و دور از دسترس هستند که گاه توسعه‌دهنده نیز از وجود آنها بی‌خبر می‌ماند. اصلاح و یا حذف باگ از جمله فعالیت‌هایی است که نیازمند صرف وقت و هزینه فراوان خواهد بود. در این مدت، افشا یا ارائه اطلاعات باگ به عموم مردم یا رقبای نرمافزار میتواند وضعیت نرمافزار را وخیم سازد. از میان رفتن اعتبار نرمافزار در بازار خود که حجم وسیعی از آن را از طریق تضمین صحت فعالیت فنی خود به دست آورده است، ضربه مهلکی را به توسعهدهندگان وارد می‌سازد. این باگها حتی ممکن است تاثیری نیز در عملکرد اصلی نرمافزار نداشته باشند.
حمایت‌‌های قانونی در این زمینه از اطلاعات مربوط به باگهای نرمافزاری آنچنان موثر واقع نشده است. تنها راه حفاظت از این اطلاعات، حمایت از طریق اسرار تجاری است؛ با این حال احتساب خطا و اشتباه به عنوان اسرار تجاری ممکن است مورد اختلاف نظر باشد. در کنار این واقعیت، توسعهدهندگان می‌توانند تا حدودی با انعقاد قراردادهای محرمانگی با افرادی که بیش از همه با این اطلاعات سروکار دارند؛ مثل کارمندان، از افشا یا ارائه اطلاعات جلوگیری به عمل آورند. توسعهدهندگان همچنین علاقه‌ی فراوانی به آگاهی از باگهای نرمافزاری خود دارند. استفاده از کاربران آن نرمافزار یکی از بهینه‌ترین روشها در جهت آگاهی توسعهدهندگان است. در این راستا، پاداش گزارش باگ، متداول ترین روش کشف و حفاظت از باگ به شمار می آید. در این نوشتار به بررسی حقوقی روش مذکور، اهمیت تعیین حدود و ثغور وظایف و مسئولیت‌های افشاکنندگان باگ های نرمافزاری پرداخته شد. به نظر می‌رسد افزون بر توجه به شفافیت در روند قبول یا رد گزارش باگ و حفظ حقوق توسعه‌دهنده از جمله توجه به حفظ محرمانگی اطلاعات، ایجاد انگیزه برای هکرها برای ارائه گزارش‌های مذکور از مهم‌ترین زوایای این قراردادها محسوب میشود.
[۱] Penetration Test.
[۲] https://www.imperva.com/learn/application-security/penetration-testing/
[۳] White Hat Hackers.
[۴] Bug Bounty Program.
[5] در فرهنگ جامعهٔ امنیت به متخصصینی که با موافقت توسعه‌دهنده در جهت افزایش امنیت سیستم‌های کامپیوتری با توسعه‌دهنده همکاری میکنند هکر کلاه‌سفید گفته میشود.
[۷] Bug-bounty Contracts
[۸] Open source.
[۹] Wang, X., Zhang, L., Xie, T., Anvik, J., & Sun, J. (2008, May). An approach to detecting duplicate bug reports using natural language and execution information. In Proceedings of the 30th international conference on Software engineering (pp. 461-470)
[۱۰] معیارها و استاندارد جهانی مشخصی برای این امر تعیین نشده اما توسعهدهندگان می‌توانند از از نمونه بررسی‌های مراجع شناخته شده نظیر CVE یا Common Vulnerability Scoring System) CVSS) استفاده کنند.
[۱۱] Exploitation
نویسنده: مصطفی عبداللهی
کارشناس ارشد حقوق اقتصادی از دانشگاه شهید بهشتی
کارشناس رگولاتوری تیم حقوقی هزاردستان
