روابط عمومی شرکت ایدکو (توزیع‌کننده‌ی محصولات کسپرسکی در ایران)؛ اولین بار، این شرکت‌های آی‌تی بودند که منبع باز شدند و بعد از آن کسب و کارهای بزرگ نیز این رویه را پیش گرفتند. از اینها گذشته، توانایی در استفاده مجدد و اصلاح مستقل کد؛ همینطور فیکسِ باگ‌ها باعث نوآوری سریع و کاهش هزینه‌ها می‌شود. اما منبع باز به سبب مسئولیت‌های مبهمش در برابر ساخت و حفظ کد، مشخصه‌های منفی نیز دارد. Endor Labs به کمک بیش از 20 رئیس بخش اطلاعات و تکنولوژیِ شرکت‌های بزرگ آی‌تی، تحلیل نظام‌مندی برای تولید فهرستی از 10 خطر اصلی برای کسب و کارها انجام داده‌ که در ادامه به آن فهرست خواهیم پرداخت.

آسیب‌پذیری‌های شناخته‌شده

مهم‌ترین ریسک شناسایی‌شده حضور آسیب‌پذیری‌هایی هم در خود پروژه‌ی منبع باز و هم ملحقاتش بود؛ منظور اجزای خارجی منبع باز است. آسیب‌پذیری‌های داخل این اجزا می‌توانند برای خیلی از بسته‌های نرم‌افزاری تجاری بزرگ مشکلات بنیادی ایجاد کنند؛ نمونه‌اش مورد آرشیو Apache Log4j (CVE-2021-44228).

راهکار امنیتی: مرتباً اپ‌های خود را برای پیدا کردن آسیب‌پذیری‌های شناخته‌شده اسکن کنید – از جمله آسیب‌پذیری‌هایی هم در ملحقات مستقیم هم غیرمستقیم. سعی کنید این فیکس‌های موجود را به موقع به کار ببرید. به منظور بهینه‌سازیِ منابع شرکت، می‌توان بر اساس شدت آسیب‌پذیری مربوطه و احتمال اکسپلویت شدنشان در نرم‌افزاری که استفاده می‌کنید، پچ‌ها را اولویت‌بندی کرد.

پکیج‌های قانونی دستکاری‌شده

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

راهکار امنیتی: هیچ متود بالغی در حال حاضر وجود ندارد که بتواند جلوی این تهدید را بگیرد پس باید از چندین اقدام امنیتی به طور ترکیبی استفاده کرد: سیستم‌های دستی و خودکار برای تحلیل منبع باز و نظارت بر ذخایر؛ ذخیره لوکال نسخه‌های قابل اعتماد اجزا؛ استفاده از هوش تهدید برای شناسایی چنین حملاتی در مراحل اولیه (پیش از اینکه وقت داشته باشند پکیج‌های استفاده‌شده در اپ‌های منبع باز شرکت‌ها را آلوده کنند).

حمله‌ی «هم‌نام‌ها[1]»

مهاجمین با نام‌هایی مشابه نام‌های پکیج‌های قانونی اقدام به ساخت پکیج‌ها کرده یا نام پکیج‌های قانونی را که به سایر زبان‌ها نوشته شدند یا در سایر پلت‌رم‌ها توزیع شدند کپی می‌کنند. این باعث می‌شود توسعه‌دهندگان منبع باز شما به جای پکیج واقعی اشتباهاً پکیج هم‌نام که از قضا مخرب است یکپارچه‌سازی کنند.

راهکار امنیتی: به توسعه‌دهندگان خود بسپارید که بسیار دقیق عمل کنند. به عنوان بخشی از روند استاندارد (پیش از استفاده) توسعه‌دهندگان باید منبع کد پکیج‌ها را برای موارد خاص مانند اجزای رمزگذاری‌شده در کد، سرقت قابلیت‌ها و غیره بررسی کنند. همچنین توصیه می‌کنیم امضاهای دیجیتال پکیج‌ها را نیز (اگر هستند) بررسی کنید.

کد پشتیبانی‌نشده

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

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

نرم‌افزارهای از رده خارج

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

 راهکار امنیتی: بگذارید توسعه‌دهندگان زمان داشته باشند روی ملحقات کار کنند؛ از جمله اصلاح مجدد کد شما برای به‌روزرسانی جدیدترین نسخه‌ اجزای در حال استفاده.

اجزای ردیابی‌نشده

از آنجایی که تقریباً هر برنامه‌ای از مؤلفه‌های طرف‌سوم استفاده می‌کند – که به نوبه خود از سایر مؤلفه‌های طرف‌سوم استفاده می‌کنند – توسعه‌دهندگان برنامه اصلی اغلب از وجود یک مؤلفه خاص در کد خود آگاه نیستند. 

راهکار امنیتی: با استفاده از ابزارهای اسکنی که می‌توانند حتی وابستگی‌هایی را که بدون مدیر بسته استفاده می‌شوند، شناسایی کنند، یک لایحه مواد نرم‌افزاری دقیق (SBOM) داشته باشید.

ریسک‌های رگولاتوری و لایسنسینگ

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

راهکار امنیتی: ابزارهای SBOM و اسکن کد قبلاً ذکر شده باید برای پیگیری مجوزها و الزامات مجوز قابل اعمال برای برنامه‌ها و مؤلفه‌های منبع باز مورد استفاده در شرکت به کار روند. و منطقی است که با بخش حقوقی کار کنید تا لیستی از مجوزهای استاندارد قابل قبول برای شرکت تهیه نموده و جزئیات سازگاری آنها با هدف نرم افزار مورد استفاده را مشخص کنید. نرم افزارهایی که دارای مجوزهای ناسازگار هستند یا اصلاً مجوز ندارند باید حذف شوند.

نرم‌افزارهای نابالغ

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

 راهکار امنیتی: قبل از استقرار یک برنامه یا مؤلفه، مطمئن شوید که توسعه‌دهندگان از بهترین شیوه‌های فعلی استفاده می‌کنند. شاخص‌های این امر شامل داشتن اسناد کامل و به روز، خطوط لوله CI/CD برای آزمایش رگرسیون، و همچنین اطلاعات دقیق در مورد پوشش تست و حتی تعداد بسته‌هایی است که از پیش از مؤلفه داده‌شده استفاده می‌کرده‌اند.

تغییرات تأییدنشده

اجزای استفاده‌شده توسط اپ می‌تواند طوری تغییر کنند که توسعه‌دهنده آن اصلاً متوجه‌ نشود. این وضعیت می‌تواند درصورتی پیش آید که اجزا بدون کنترل نسخه یا/و روی کانال‌های ارتباطی رمزگذاری‌نشده از سرور دانلود شده باشند و با استفاده از هش‌ها و امضاهای دیجیتال نیز تأیید نشده باشند. در این مورد، اسمبلی اپ می‌تواند به لحاظ تئوریک هر بار نتیجه متفاوتی تولید کند.

 راهکار امنیتی: در به کار بردن تمارین توسعه‌ی امن سختگیر باشید. در طول توسعه از شناساگرهای منبعی که واضحاً نسخه اجزا را نشان می‌دهند استفاده کنید. افزون بر این، با استفاده از امضاهای دیجیتال، اجزای دانلودشده را اعتبارسنجی کنید. همیشه از پروتکل‌های ارتباطی امن استفاده کنید.

ملحقات و اجزایی که یا خیلی بزرگ هستند و یا خیلی کوچک

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

راهکار امنیتی: جلوی مؤلفه‌هایی را که کارایی کمی دارند بگیرید؛ چنین کارایی‌هایی را داخل اپ اصلی توسعه دهید.

[1] Namesakes

منبع: کسپرسکی آنلاین (ایدکو)

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