حمایت حقوقی از باگ‌های نرم‌افزارهای رایانه‌ای (قسمت دوم)

همانطور که در مطلب پیشین ذکر شد، تاثیر حفاظت از باگ‌های نرم‌افزاری در حفظ امنیت اطلاعات کاربران و جلوگیری از سوء‌استفاده هکرها، همچنین کاهش امکان از دست دادن کاربر، بهبود عملکرد در بازار مربوطه و برخورداری از مزیت رقابتی موجب می‌شود که توسعه‌دهندگان مایل به راه‌حل‌های حقوقی جلوگیری از افشای باگ‌ها باشند. این راه‌حل‌ها ممکن است یا از طریق قانون و تصمیم سیاست­گذاران این حوزه ارائه گردد (که تا حدودی در مطلب پیشین مورد بررسی قرار گرفت) و یا در قالب قرارداد جلوه‌گر شود.(موضوع مطلب پیش رو)حفاظت از باگ‌ها در قالب‌های قراردادیتوسعه­‌دهندگان علاوه بر آن که به دنبال عدم انتشار یا افشای اطلاعات مربوط به باگ­‌های نرم‌افزاری هستند، سعی می‌کنند تا حد امکان از باگ‌­هایی که در نرم‌افزارشان وجود دارد اما از آن بی‌­اطلاع هستند، به نحوی محرمانه مطلع شوند؛ یعنی فرد مطلع، فقط توسعه‌دهنده را از وجود باگ آگاه سازد. در زمان‌های نه‌چندان دور توسعه‌دهندگان نرم‌افزارها، تنها از روش‌هایی هم­چون آزمایش نفوذ (۱) برای بررسی میزان نفوذپذیری سیستم استفاده می‌کردند. در این آزمایش یک حمله سایبری شبیه سازی شده علیه نرم‌­افزار اعمال می‌­شود تا آسیب­پذیری‌های احتمالی بررسی شده و کشف گردند.(۲) در این روش حمله سایبری با مجوز توسعه‌­دهنده و توسط تیمی از متخصصین امنیت (۳) صورت می‌پذیرد. هزینه‌های سرسام‌­آوری که در نتیجه اعمال این حمله و نتایج ناخواسته که ممکن بود در پی داشته باشد، توسعه­‌دهندگان را به روش‌‌های دیگری برای یافتن باگ‌­های نرم‌افزار رهنمون کرد. یکی از این روش‌‌ها پاداش در مقابل گزارش باگ است که در ادامه به آن پرداخته خواهد شد.چنانچه در مطلب پیش نیز اشاره شد، چنین روشی حتی می‌تواند نشانه‌ای از تلاش‌های معقول توسعه‌دهنده برای حفاظت از اطلاعات باگ‌های نرم‌افزاری باشد.۱- پاداش در مقابل گزارش باگ(۴)یکی از شیوه­‌های توسعه‌دهندگان نرم‌افزارهای رایانه‌ای به منظور آگاهی از باگ‌­های موجود در نرم‌افزار در نظر گرفتن پاداش برای هکرهای کلاه‌سفید(۵) است. به دلیل دشواری پیاده‌سازی نرم‌افزارها، یک نرم‌‌افزار ممکن است دارای رفتاری مغایر با کارکرد یا اهداف خود شود که سازندگان آن از این مشکل بی‌اطلاع باشند و منجر به ناامنی در بستر نرم‌افزار گردد. پیشگیری از بروز هرگونه رفتار مغایر با هدف نرم‌افزار و در نتیجه رسیدن به امنیت صد‌در‌صدی، حتی با صرف هزینه‌ی بسیار بالا لزوماً در توان توسعه‌دهندگان نیست، در نتیجه هر توسعه‌دهنده متناسب با محصول یا خدمتی که ارائه می‌دهد و سطح دانش فنی و توان اقتصادی‌اش اقدام به تشخیص مغایرت‌های کارکردی و تثبیت عملکرد نرم‌افزار می‌کند. در کنار آن بی اعتنایی به چنین موضوعی می‌تواند نتایج جبران‌ناپذیری را برای نرم‌افزار به همراه داشته باشد. بسیاری از هکرها ممکن است با استفاده از اطلاعات مربوط به باگ‌های نرم‌افزار، امنیت آن و اطلاعات کاربران را به مخاطره انداخته، الگوریتم‌­های نرم‌افزار را به سرقت برده یا آنکه برای از میان بردن شهرت نرم‌‌افزار دست به افشاگری در خصوص باگ‌‌های نرم‌افزاری بزنند. توسعه‌‌دهندگان با ایجاد بستر اعطای پاداش به هکرهای کلاه‌سفید، نیروی آن­ها را در جهت اهداف نرم‌­افزار هدایت می‌‌کنند.(۶) رسیدن به چنین هدفی منوط به ایجاد فضایی دوستانه و قابل اعتماد میان هکر و توسعه‌دهنده است؛ بستری که در انعقاد مفاد قرارداد پاداش در قبال گزارش باگ(۷) باید مورد توجه قرار گیرد. با این حال ذکر این نکته ضروری است که در بسیاری از موارد توسعه‌دهندگان، نرم‌افزار را بصورت «کد منبع‌باز»(۸) ارائه می‌‌دهند؛ بدان معنی که توسعه‌دهنده‌ی نرم‌‌افزار، به دریافت‌کنندگانِ نرم‌‌افزار، حق توزیع، مداخله و حتی تغییر در کدهای یک نرم‌افزار را اعطا می‌کند. در این موارد استفاده از «قرارداد پاداش در قبال گزارش باگ» به دلیل دسترسی کاربران به منابع کد موثرتر است. به طور کلی این قراردادها دو مزیت دارد: اول آن‌که تمامی کاربران نرم‌افزار در سراسر جهان به آزمایش‌کنندگان نرم‌افزار تبدیل و نواقص آن با سرعت و دقت بالایی رفع می‌‌شود و دوم آن­که نرم‌­افزار براساس نیازهای خودِ کاربران تکامل خواهد یافت.(۹)۲- ماهیت حقوقیهمانگونه که گفته شد موضوع قرارداد پاداش در قبال گزارش باگ، پرداخت پاداش در قبال یافتن باگ مشخص در سیستم مشخص است. در نظام حقوقی ایران، چنین تعهدی پیوندی ناگسستنی با قرارداد جُعاله دارد. به ­موجب ماده ۵۶۱ قانون مدنی ایران: «جعاله عبارت است از التزام شخصی به اداء اجرت معلوم در مقابل عملی اعم از اینکه طرف معین باشد یا غیرمعین». همانطور که در این ماده تصریح شده است، تعهد به پاداش دادن و شناسایی این نهاد به عنوان عقد جعاله درصورتی قابل تحقق است که توسعه­‌دهنده در متن درخواست افشای باگ، خود را «ملزم» به پرداخت پاداش کرده باشد. جعاله بر اساس اینکه طرف معامله مشخص باشد یا خیر به ترتیب به دو دسته‌­ی جعاله خاص و جعاله عام تقسیم می‌­شود. از آن‌جا که در قرارداد پاداش در قبال گزارش باگ طرف معامله مشخص نیست، این قرارداد یک جعاله عام محسوب می‌­شود و توسعه‌­دهنده، جاعل (به معنی شخصی که برای عمل مشخصی پاداشی در نظر می‌گیرد)، هکر، عامل (به معنی شخصی که عمل مورد انتظار جاعل را انجام می‌دهد) و پاداش ارسال گزارش، جُعل (پاداش جعاله) به شمار می‌­آیند. در جعاله عام برخلاف جعاله خاص تنها شخصی که برای اولین بار عمل مورد درخواست را انجام داده باشد، مستحق پاداش است.جعاله یک قرارداد جایز تلقی می‌شود به این معنی که هر یک از طرفین می‌­توانند پیش از انجام عمل یا در اثنای آن، قرارداد را فسخ نمایند؛ با این حال اگر عمل انجام شود دیگر نمی‌­توان آن را فسخ نمود.۳- پیشنهاداتی برای بهبود «قرارداد پاداش در قبال گزارش باگ»همانطور که گفته شد «قرارداد پاداش در قبال گزارش باگ» را می‌توان مصداقی از عقد جعاله درنظر گرفت. در حقوق ایران و به علت شمول این­گونه قراردادها در ذیل قرارداد جعاله بسیاری از احکام از مفاد مواد مربوط به جعاله، قابل استخراج است؛ با این حال ذکر برخی از موارد هم­چون اعطای پاداش به نخستین کسی که گزارش یک باگ مشخص را داده باشد، به شفافیت قراردادی و ایجاد اعتماد میان کاربران و توسعه‌­دهندگان کمک می‌کند. در ادامه به برخی از شروط قراردادی که قراردادهای پاداش در قبال گزارش باگ به آن‌­ها نیازمند است پرداخته می‌­شود. در تدوین این شروط قراردادی توجه به ایجاد بستری دوستانه و قابل اعتماد برای گزارش‌­کنندگان در ترغیب آن­ها به دادن گزارش باگ، نقش موثری را ایفا می­‌کند:الف) احراز تطابق عمل هکرها با آنچه که طرف اول جعاله برای آن پاداش در نظر گرفته است:یکی از مهم‌­ترین مسائل در خصوص اعطای پاداش گزارش باگ، تطابق یا عدم تطابق گزارش با باگ­‌هایی است که در قرارداد برای آن­ها پاداش تعیین شده است. در بسیاری از موارد گزارش‌­دهنده گزارش­‌های خود را مصداقی از باگ‌­های تعیین شده در قرارداد یا دارای اهمیت فراوان می‌­داند. لیکن، باید توجه نمود که فرآیند و مرجع تعیین تطابق یا عدم تطابق باید مشخص شود. ممکن است توسعه‌­دهنده شخصاً و به طور ضمنی یا صریح فرآیند احراز تطابق را برعهده بگیرد. با این حال این روند می‌­تواند به اعتماد گزارش‌­کننده لطمه وارد کند و اساساً به دنبال یافتن باگ نباشد. افزون بر آن با ارائه گزارش توسط گزارش­‌دهنده قرارداد لازم‌­الاجرا خواهد بود و مرجع احراز و تفسیر قرارداد در موارد اختلاف دادگاه است و در هر صورت گزارش‌­دهنده می‌­تواند درخواست احراز تطابق را از دادگاه بخواهد. در این موارد توسعه‌­دهنده باید به الزام‌­آوربودن قرارداد مذکور توجه داشته باشد. در کنار این واقعیت توسعه‌­دهنده می‌­تواند شرایطی را که در ارائه گزارش مطلوب اوست ذکر کند تا یابنده باگ نتواند به طور مطلق از پاداش بهره‌­مند شود. بنابراین پیشنهاد می‌­شود که عواملی همچون میزان اهمیت باگ و یا قابلیت تصحیح باگ از لحاظ فنی در اصل دریافت و میزان پاداش اثرگذار باشد. با این حال در تعیین شرایط مذکور حفظ انگیزه یابنده اهمیت داشته و وضوح و شفافیت مصادیق از اولویت برخوردار است.این شیوه احراز در بسیاری از موارد مشاهده می‌­شود؛ با این حال تعیین هیات کارشناسی تشخیص و احراز تطابق در صورت بروز اختلاف که نمایندگان آن منتخب هر دو هستند، می‌­تواند تا حدودی این فضای ناامن را برای کاشفان باگ از میان ببرد. استفاده از معیارها و الگوهای مشخص برای تعیین باگ و محدوده جستجوی باگ می‌­تواند به ساده­‌کردن احراز مصادیق قرارداد کمک کند.(۱۰)ب) شرط محرمانگی:همان‌گونه که گفته شد یکی از اهداف صاحبان نرم‌افزارهای رایانه‌ای برای در نظر گرفتن پاداش، حفظ محرمانگی باگ‌ها و عدم افشای آن بخصوص در نزد رقبای خود است. افشای اطلاعات مربوط به باگ می‌‌تواند راهی برای دسترسی به الگوریتم نرم‌‌افزاری یا اطلاعات کاربران باشد یا آنکه وجهه تجاری نرم‌‌افزار را از میان ببرد؛ از طرفی برای هکرهای کلاه‌سفید افشای باگ بسیار اهمیت دارد. شاید بتوان گفت که بسیاری از هکرها از کشف و ارائه‌‌ی گزارش باگ تنها انگیزه‌ی مالی ندارند و جنبه‌ی کسب اعتبار نیز برای‌ آن‌ها بسیار حائز اهمیت است. اگر در قرارداد سازکارهایی برای انتقال این اعتبار از طریق درج یک رده‌بندی در دسترس، یا موافقت با انتشار گزارش در سطح و چارچوب مورد قبول توسعه‌دهنده وجود داشته‌باشد، هکر به ارسال گزارش بسیار راغب‌تر خواهد بود و توسعه‌دهنده نیز توانسته از خطر افشای غیرقانونی این محتوا جلوگیری کند.ج) دسته بندی باگ‌‌ها و محدوده‌ی گزارش:مشخص است که گزارش هر باگ در مورد نرم‌­افزار برای توسعه‌دهندگان دارای ارزش یکسانی نیست و در صورت عدم تصحیح آن ممکن است هزینه‌های متفاوتی را بر آن‌ها تحمیل کند. افزون بر آن یافتن برخی از باگ‌ها نیازمند صرف هزینه، وقت فراوان و داشتن مهارت بسیار بالایی هستند که در صورت عدم تعیین پاداش درخور برای آن‌ها گزارش‌دهندگان انگیزه‌­ای برای یافتن یا گزارش آن‌ها ندارند.بنابراین توسعه‌‌دهندگان می‌توانند در قرارداد پاداش در قبال گزارش باگ، که معمولا در دسترس همگان است در کنار مشخص‌کردن انواع باگ‌‌ها، آن‌‌ها را از باگ‌های بسیار پیچیده و مهم، تا ساده و دارای اهمیت کم، دسته‌بندی کنند. توسعه‌دهنده در این بند مشخص می‌کند که چه نوع پاداشی به چه نوع باگ‌هایی تعلق خواهد گرفت.تعیین دقیق محتوای این بند یا ارجاع به رویه عرفی و فنی در بررسی باگ‌­ها از بروز اختلافات آتی جلوگیری می‌‌کند. افزون بر آن، می‌توان میان گزارش‌‌هایی که صرفا وجود باگ را اعلام می‌کنند با آن‌هایی که راه‌حلی نیز پیشنهاد می‌دهند، تفکیک قائل شد. همچنین، محدوده‌ی گزارش باگ باید مشخص باشد. این محدوده اصولا با مشخص کردن دامنه خاص سایت یا محدوده امکان گزارش باگ در نرم‌افزار مشخص می‌شود.د) شکل مخصوص گزارش: بهتر است ارائه گزارش در قالب یک شکل مخصوص (برای مثال از طریق یک فرم مخصوص که برای ارسال گزارش پیش‌بینی شده است) باشد و این قالب در قرارداد پاداش در قبال گزارش باگ كه در دسترس همگان قرار می‌گیرد، تشریح شود. این روش، ارائه گزارش را منسجم کرده و گزارش‌دهنده را با الزام به تکمیل تمام قسمت‌های فرم گزارش باگ، جزییات کامل اطلاعات مربوط به باگ را از گزارش‌دهنده اخذ کند.ه) عدم دسترسی غیرقانونی: در نظر گرفتن پاداش برای گزارش باگ ممکن است گزارش‌دهنده را به نفوذ به نرم‌افزار خارج از چارچوب قرارداد پاداش در قبال گزارش باگ، ترغیب کرده و خسارات جبران ناپذیری را به سیستم وارد کند. افزون بر آن نفوذ خارج از چارچوب به سیستم می‌­تواند زمینه بهره‌کشی (۱۱) از سیستم را هموار سازد، به این معنی که اطلاعات شخصی مربوط به کاربران را در معرض خطر قرار داده یا کارایی نرم‌افزار را مختل سازد. بنابراین قرارداد پاداش در قبال گزارش باگ باید منوط به دستیابی به باگ از طرق معمول طبق شرایط تشریح شده ‌باشد و نه از طریق رخنه خارج از چارچوب به سیستم؛ و توسعه‌دهنده به طور مشخص از هرگونه بهره‌کشی از سیستم چه به صورت مستقیم، توسط هکر، یا غیرمستقیم جلوگیری کند به عنوان مثال هکر این اطلاعات را در اختیار شخص ثالث قرار نداده و یا امکان بهره‌کشی از سیستم توسط شخص ثالث را فراهم نکند.برای بررسی دقیق‌تر و حل یک باگ ممکن است گزارش‌دهنده نیاز به دریافت اطلاعات یا برخی دسترسی‌ها از توسعه‌دهنده باشد که اهمیت ایجاد تعهد برای گزارش‌دهنده به حفاظت از اطلاعات ارائه شده را در این فرایند تعاملی، دوچندان می‌کند.نتیجه‌گیریبه وجود آمدن باگ‌های نرم‌افزاری امری غیر‌قابل‌اجتناب در عرصه نرم‌افزارهای رایانه‌ای محسوب شده و هیچ توسعه‌دهنده‌ای نمی‌­تواند مدعی عدم وجود باگ در نرم‌افزار خود باشد. باگ­‌ها آنقدر پیچیده و دور از دسترس هستند که گاه توسعه‌دهنده نیز از وجود آن­­ها بی‌خبر می‌ماند. اصلاح و یا حذف باگ از جمله فعالیت‌­هایی است که نیازمند صرف وقت و هزینه فراوان خواهد بود. در این مدت، افشا یا ارائه اطلاعات باگ به عموم مردم یا رقبای نرم­‌افزار می­‌تواند وضعیت نرم‌افزار را وخیم سازد. از میان رفتن اعتبار نرم‌افزار در بازار خود که حجم وسیعی از آن را از طریق تضمین صحت فعالیت فنی خود به دست آورده است، ضربه مهلکی را به توسعه­‌دهندگان وارد می‌­سازد. این باگ‌­ها حتی ممکن است تاثیری نیز در عملکرد اصلی نرم‌­افزار نداشته باشند.حمایت‌‌­های قانونی در این زمینه از اطلاعات مربوط به باگ‌­های نرم‌افزاری آن­چنان موثر واقع نشده­‌ است. تنها راه حفاظت از این اطلاعات، حمایت از طریق اسرار تجاری است؛ با این حال احتساب خطا و اشتباه به عنوان اسرار تجاری ممکن است مورد اختلاف نظر باشد. در کنار این واقعیت، توسعه‌دهندگان می‌توانند تا حدودی با انعقاد قراردادهای محرمانگی با افرادی که بیش از همه با این اطلاعات سروکار دارند؛ مثل کارمندان، از افشا یا ارائه اطلاعات جلوگیری به عمل آورند. توسعه‌دهندگان هم‌چنین علاقه‌­ی فراوانی به آگاهی از باگ‌­های نرم‌افزاری خود دارند. استفاده از کاربران آن نرم­‌افزار یکی از بهینه‌ترین روش‌­ها در جهت آگاهی توسعه‌دهندگان است. در این راستا، پاداش گزارش باگ، متداول ترین روش کشف و حفاظت از باگ به شمار می آید. در این نوشتار به بررسی حقوقی روش مذکور، اهمیت تعیین حدود و ثغور وظایف و مسئولیت‌های افشاکنندگان باگ های نرم‌افزاری پرداخته شد. به نظر می‌رسد افزون بر توجه به شفافیت در روند قبول یا رد گزارش باگ و حفظ حقوق توسعه‌دهنده از جمله توجه به حفظ محرمانگی اطلاعات، ایجاد انگیزه‌ برای هکرها برای ارائه گزارش‌های مذکور از مهم‌ترین زوایای این قراردادها محسوب می‌شود.[۱] Penetration Test.[۲] https://www.imperva.com/learn/application-security/penetration-testing/[۳] White Hat Hackers.[۴] Bug Bounty Program.[5] در فرهنگ جامعهٔ امنیت به متخصصینی که با موافقت توسعه‌دهنده در جهت افزایش امنیت سیستم‌های کامپیوتری با توسعه‌دهنده همکاری می‌کنند هکر کلاه‌سفید گفته می‌شود.[۶] https://portswigger.net/daily-swig/researchers-earn-2-5k-bug-bounty-after-exposing-credentials-in-iranian-app-cafe-bazaar[۷] ‌‌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نویسنده: مصطفی عبداللهی کارشناس ارشد حقوق اقتصادی از دانشگاه شهید بهشتی کارشناس رگولاتوری تیم حقوقی هزاردستان