چگونه از کابوس امنیتی پروژه های منبع باز خلاص شویم؟

امروزه شاهد ظهور بسیاری از مسائل امنیتی مهم در نرم افزارهای متن باز هستیم[۱] یا منبع باز هستیم. به عنوان مثال، توسعه دهنده نرم افزار Marak Squires اخیراً نسخه های جعلی بسته های faker.js و color.js را به منظور انتقام گرفتن و ایجاد مشکلات فنی در پروژه هایی که از این بسته ها استفاده می کنند، منتشر کرده است. این اقدام خصمانه منجر به قطع و حتی شکست هزاران پروژه شد. پس آیا استفاده از نرم افزار متن باز در چنین شرایطی منطقی است؟ کاخ سفید همچنین از سازمان‌های فناوری کلیدی خواست تا در مورد امنیت نرم‌افزار پس از مشکل Log4j که خطرات قابل‌توجهی برای امنیت سرورهای راه دور ایجاد می‌کند، نظر دهند.

کارشناسان امنیتی توصیه می کنند قبل از انتخاب و استفاده از نرم افزار منبع باز نکات زیر را در نظر بگیرید:

• آیا کدهای نوشته شده توسط داوطلبانی که امنیت نسبتاً کمتری نسبت به توسعه دهندگان حرفه ای دارند؟
• آیا در صورت بروز مشکل در محصول، باید از شخص خاصی شکایت کنید؟
• آیا محصول به دست آمده ارزش قیمت دارد؟

نرم افزار متن باز (یا متن باز) چیست؟

هیچ نظریه قطعی مبنی بر اینکه همه نرم افزارها و پروژه های بسته شده بدون خطا هستند وجود ندارد. همچنین نمی توان با اطمینان کامل گفت که همه نرم افزارهای منبع باز دارای مشکلات امنیتی هستند. فروشندگان نرم افزار متن باز نیز معمولا تمرکز ویژه ای روی «امنیت» دارند و حتی برخی برای ایجاد امنیت در محصولات خود اهمیت ویژه ای قائل هستند.

به طور کلی نرم افزارهای متن باز بر اساس ساختار خود به پنج گروه تقسیم می شوند که عبارتند از:

• نرم افزار انفرادی: این محصول توسط یک نفر یا حداکثر چند نفر با دید یکسان ارائه می شود.
• نرم افزار رویال: این یک نرم افزار منبع باز فردی است که از حمایت جامعه بزرگی از شرکت کنندگان برخوردار است و خالق اصلی آن به عنوان یک دیکتاتور خیرخواه عمل می کند. لینوکس یکی از نرم افزارهای سلطنتی است.
• نرم افزارهای اجتماعینرم افزار بازی متنی که توسط یک گروه برای اهداف مشابه و با مدیریت مشترک ارائه شده است. PostgreSQL یک نرم افزار اجتماعی است.
• نرمافزار سازمانی: این محصول معمولاً به عنوان شعبه یک پروژه تجاری ارائه می شود. به عنوان مثال، شرکت فناوری آمریکایی Sun، OpenOffice[۲] به عنوان یک شاخه منبع باز از [۳]ارسال شده توسط StarOffice. جهت چنین پروژه ای توسط ناشر تعیین می شود.
• نرم افزار پایه: این نرم افزار منبع باز ساختار تجاری مستقلی دارد و از همه نرم افزارهای متن باز رسمی تر است. گروهی از اعضای هیئت مدیره مسئولیت تصمیم گیری در مورد این نرم افزار را بر عهده دارند. آپاچی بهترین نمونه نرم افزار پایه است.

به طور کلی، پروژه های فردی معمولا در معرض خطرات امنیتی هستند. همانطور که یک نویسنده می تواند وب سایت خود را با هر محتوایی به روز کند و محتوای مورد علاقه خود را در آن قرار دهد، توسعه دهنده نیز توانایی به روز رسانی و تغییر کد خود را به هر شکلی دارد. اگرچه امکان ایجاد واحدهای مجزا در پروژه های اجتماعی وجود ندارد و این پروژه ها یک پروژه استاندارد پایه محسوب می شوند. به عنوان مثال، Squires می توانند به راحتی کد خود را با چاپ مقادیر بنر و درج کد در حلقه های بی پایان تغییر دهند.

امنیت پروژه های متن باز و متن بسته به تمرکز و هدف اصلی رمزگذارهای آنها بستگی دارد نه به ساختار پروژه. به عنوان مثال، دغدغه اصلی لینوس توروالدز[۴] و [۵]تئو د راد (معروف به “دیکتاتور خیرخواه”) امنیت است. Theo de Raat همیشه در ایمن سازی و حفظ OpenBSD مهم بوده است[۶] او چنین فکر می کند. در حالی که پروژه تجاری StarOffice و در نتیجه OpenOffice دارای آسیب پذیری های امنیتی بسیاری است. این حفره‌های امنیتی امکان اجرای کد دلخواه را در فایل‌های XML (مخفف Extensible Markup Language) می‌دهد.

تمرکز شرکت کنندگان در پروژه

یکی از باورهای غلط در مورد پروژه های متن باز این است که هر چه کد کاربر و افراد بیشتری کد پروژه را بررسی کنند، امنیت پروژه بیشتر می شود. اگرچه طرفداران امنیت سال‌ها استدلال می‌کردند که پروژه‌های منبع باز به دلیل توانایی جامعه توسعه‌دهندگان در بازبینی کد، امن‌تر هستند، برخلاف تصور عمومی، توسعه‌دهندگان زمان زیادی را صرف بررسی، اصلاح و به‌روزرسانی کد نمی‌کنند. به عنوان مثال، چنین احساس نادرستی از امنیت در باگ نرم افزاری در کتابخانه رمزنگاری منبع باز [۷]OpenSSL وجود دارد. آسیب پذیری Heartbleed به مهاجمان اجازه می دهد تا حافظه رایانه ای را که این برنامه را اجرا می کند، بخوانند. وجود بسیاری از کدها و عدم بازنگری گسترده و مؤثر آنها، نیاز به فرآیندها و سیستم های خودکار را برای بهبود امنیت پروژه های منبع باز ایجاد کرد.

البته این تصور که از آنجایی که امکان تماشای نرم افزارهای متن بسته برای همه وجود ندارد، این نرم افزارها از امنیت بیشتری برخوردار هستند نیز کاملا اشتباه است. به عنوان مثال، جامعه توسعه دهندگان پس از مطالعه عمیق آسیب پذیری های Heartbleed و شناسایی حفره ها در OpenSSL، متوجه شدند که راه حل اصلی برای رفع این آسیب پذیری ها، باز کردن یک پروژه است. LibreSSL شاخه ای از OpenSSL با تمرکز ویژه بر امنیت است.

امنیت پروژه های منبع باز به مسئولیت مشترک بستگی دارد

اگرچه نرم افزار متن باز رایگان است و برای خرید آن نیازی به پرداخت هزینه نیست، اما باز هم بسته به کسب و کار و به خصوص اعتماد مشتریان، مسئولیت تمامی نرم افزارهای متن بازی که در اختیار دارید، بر عهده شماست. در اینجا مواردی وجود دارد که هنگام استفاده از نرم افزار منبع باز باید در نظر داشته باشید.

توجه داشته باشید که از چه محصولاتی استفاده می کنید

سهولت استفاده از یک پروژه متن باز در یک پروژه متنی دیگر برای یک بازی اکوسیستمی از جمله خطرات امنیتی مهم است و عواقب منفی زیادی در پی خواهد داشت. امروزه بسیاری از پروژه ها از پروژه های دیگری استفاده می کنند. وجود سیستم هایی مانند کتابخانه منبع باز رایگان NPM (Node Package Manager) که امکان افزودن بسته های مختلف به پروژه را فراهم می کند، باعث می شود تا کدهای مختلف بدون درک کامل از عملکرد آنها در پروژه درج شوند. ابزارهایی برای ایجاد لیستی از اجزای نرم افزار در کد وجود دارد که می توانید از آنها برای بررسی کد و تعیین اینکه آیا به کد دیگری بستگی دارد که از آن اطلاعی ندارید استفاده کنید.

از استفاده از پروژه های انفرادی و رها شده خودداری کنید:

یک توسعه‌دهنده مخرب می‌تواند کدهای مخرب زیادی را به یک پروژه تزریق کند (مخصوصاً زمانی که به‌روزرسانی خودکار را فعال کرده باشید). عدم توجه، رسیدگی و اصلاح آسیب پذیری های جدید در پروژه های متروکه از جمله خطرات ناشی از آن است. حتما وضعیت پروژه هایی را که با هر نسخه استفاده می کنید بررسی کنید.

آزمایش را از قبل انجام دهیدتکد توپ

بیشتر ریسک پروژه های منبع باز ناشی از به روز رسانی پروژه بدون آزمایش است. اگر کد شما حاوی یک کتابخانه منبع باز آسیب پذیر باشد، کاربران شما مسئول خواهند بود. همیشه اطلاعات نسخه های مختلف پروژه را بررسی و به روز نگه دارید. بهتر است قبل از ارسال این نسخه ها آزمایش و خطا را اجرا کنید. به عنوان مثال، می توانید شاخه ای از کتابخانه های منبع باز که استفاده می کنید ایجاد کنید و منابعی را برای بررسی کد اختصاص دهید.

برنامه‌جزئیات را به روز کنید

آسیب‌پذیری Log4j امکان اجرای کد دلخواه را بر روی پلتفرم‌هایی که نرم‌افزار را در ROM جاسازی می‌کنند، می‌دهد. در حالی که برخی از سیستم های اینترنت اشیا به هیچ راه حلی برای ارتقای کتابخانه Log4j و حل مشکلات امنیتی ناشی از آن مجهز نیستند. در چنین مواقعی آسیب پذیری های دائمی ایجاد می شود که قابل رفع نیست. کارشناسان امنیتی توصیه می کنند که برای جلوگیری از چنین حوادثی، بهتر است قبل از بروز مشکلات امنیتی، مسیر ارتقای هر کامپوننت در نظر گرفته شود. برای افزایش امنیت کد می توانید برنامه خاصی را برای انجام به روز رسانی های منظم در نظر بگیرید.

مشارکت در پروژه های متن باز

بسیاری از پروژه های منبع باز کد مفیدی را ارائه می دهند، اگرچه منابع زیادی ندارند. می‌توانید با اهدا، مشارکت در توسعه محصول یا پاسخ دادن به سؤالات مربوط به پروژه‌های منبع باز از آنها حمایت کنید. این پروژه های متن باز نیز نیاز به پشتیبانی مستمر دارند، بنابراین در برنامه های بلندمدت و بودجه سالانه خود برنامه ای برای این موضوع لحاظ کنید و پشتیبانی خود را به یک یا یک روز محدود نکنید. این کمک می کند تا آخرین نسخه بسیار امن تر از نسخه اول باشد.

سرمایه‌در جعبه قرار دهید DevSecOps

در کدهای نوشته شده توسط تیم شما و همچنین کدهایی که به عنوان پروژه های متن باز تهیه شده است، احتمال نقض امنیتی وجود دارد. بنابراین، پیاده سازی و نصب مداوم به روز رسانی ها باید یک هنجار و یک مشکل همیشگی باشد، نه استثنا. معمولاً برای همگام شدن با تغییرات به نسخه های جدید نیاز است. استفاده از روش های یکپارچه سازی پیوسته (یا CI) و تحویل مداوم (یا CD) در چرخه DevSecOps برای ردیابی سریع و ایمن تغییرات کد یکی از راه حل های عملی در این زمینه است. افزودن بحث امنیتی به این رویکرد و پرداختن به آن از ابتدایی ترین مراحل طراحی منجر به راه حل پیچیده تری می شود.

بیداری از کابوس عدم قطعیت پروژه های منبع باز

بسیار محتمل است که حداقل یکی از محصولاتی که استفاده می کنید دارای اجزا و نرم افزار منبع باز باشد. شما حتی می توانید همین مطلب را در یک مرورگر مبتنی بر فناوری منبع باز یا قابل دسترسی از یک سرور هسته منبع باز بخوانید. بنابراین تحت هیچ شرایطی از امنیت محصولات و نرم افزارهای متن باز غافل نشوید. اگرچه کابوس ها واقعی نیستند، اما ممکن است ناشی از ترس کاملاً منطقی باشند. برای جلوگیری از مشکلات جدی، هنگام استفاده از نرم افزار منبع باز مراقب باشید و اقدامات احتیاطی امنیتی را رعایت کنید.

[۱] امکان تغییر کد پایه این نرم افزارها و اصلاح خطاهای آنها توسط کاربران و مشتریان وجود دارد.

[۲] مجموعه آفیس منبع باز

[۳] شامل مجموعه ای از نرم افزارهای آفیس می باشد

[۴] مهندس نرم افزار مسئول هماهنگ کننده پروژه (کرنل لینوکس) – ویکی پدیا، دانشنامه آزاد

[۵] مهندس نرم افزار که بنیانگذار و مدیر عامل OpenBSD و OpenSSH است.

[۶] نرم افزار متن باز رایگان با تمرکز ویژه بر امنیت.

[۷] یک کتابخانه منبع باز که کد SSL و TLS را پیاده سازی می کند.

منبع: Forrester