پول بیشتر برای امنیت منبع باز کار نخواهد کرد

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

خبر خوب اینجاست. بر اساس گزارش بنیاد امنیت منبع باز (OpenSSF)، هزینه کمتر از ۱۵۰ میلیون دلار برای نرم افزار منبع باز ایمن خواهد بود. خبر خوب دیگر، غول‌های صنعت آمازون، اینتل، گوگل و مایکروسافت قبلاً ۳۰ میلیون دلار متعهد شده‌اند. فقط ۱۲۰ میلیون دلار برای خرید یک آینده منبع باز امن، درست است؟

خب، نه، زیرا خبر بد این است که هیچ رویکرد عمومی برای امنیت منبع باز کار نخواهد کرد. OpenSSF یک برنامه ۱۰ نقطه‌ای فوق‌العاده دارد تا رویکردی چندوجهی به امنیت ایجاد کند. این رویکرد شانس موفقیت بیشتری نسبت به رویکردهای مقطعی گذشته دارد، برایان بهلندورف، مدیر کل OpenSSF، در یک تماس مطبوعاتی اخیر استدلال کرد، زیرا “یک علت اصلی یا یک رویکرد ریشه ای وجود ندارد که همه آنها را برطرف کند.”

او درست می‌گوید، و دقیقاً به همین دلیل است که من نگران این هستم که ممکن است هنوز به اشتباه به امنیت منبع باز نزدیک شویم.

اما ابتدا، طرح

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

من از طرح ۱۰ نقطه ای OpenSSF خوشحالم:

1. آموزش امنیتی را برای همه افراد شاغل در انجمن ارائه دهید
2. یک داشبورد ارزیابی ریسک برای اجزای منبع باز برتر ایجاد کنید
3. تسریع پذیرش امضای دیجیتال
4. برای از بین بردن علت اصلی بسیاری از اشکالات، زبان های غیر ایمن برای حافظه را جایگزین کنید
5. تیم پاسخگویی به حادثه منبع باز ایجاد کنید
6. برای یافتن سریعتر اشکالات، اسکن کد را توسط نگهبانان و کارشناسان بهبود دهید
7. بررسی کد شخص ثالث تا ۲۰۰ مورد از حیاتی ترین مؤلفه ها را انجام دهید
8. به اشتراک گذاری داده های تحقیقاتی در سراسر صنعت را هماهنگ کنید
9. ابزارها و آموزش های مربوط به صورتحساب مواد (SBOM) نرم افزار را بهبود بخشید تا پذیرش را افزایش دهید
10. ۱۰ سیستم ساخت، مدیران بسته‌ها و سیستم‌های توزیع حیاتی را با ابزارهای امنیتی بهتر و بهترین شیوه‌ها تقویت کنید

این یک رویکرد هوشمندانه و جامع برای امنیت است و دلیل دیگری برای علاقه‌مند شدن توسعه‌دهندگان به منبع باز است. در واقع، زمانی که تیم استراتژی و بازاریابی منبع باز AWS را مدیریت کردم، نظرسنجی را در سال ۲۰۲۰ انجام داد تا بپرسد چرا توسعه دهندگان منبع باز را دوست دارند. بالای لیست امنیت بود:

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

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

فرایند بهتر از برنامه است

بهترین ضامن امنیت منبع باز همیشه فرآیند توسعه منبع باز بوده است. حتی با وجود طرح عالی OpenSSF، این درست است. به عنوان مثال، این طرح وعده داده است که “بررسی کد شخص ثالث تا ۲۰۰ مورد از حیاتی ترین مؤلفه ها را انجام دهد.” عالیه! اما حدس بزنید چه چیزی چیزی را به یک “مولفه مهم” تبدیل می کند؟ درست است – یک رخنه امنیتی که صنعت را ناراحت می کند. همینطور “ایجاد داشبورد ارزیابی ریسک برای اجزای منبع باز برتر.” اگر از قبل در تصمیم‌گیری که کدام مؤلفه‌های منبع باز برتر هستند خوب بودیم، آسیب‌پذیری‌های امنیتی کمتری داشتیم زیرا راه‌هایی برای تأمین مالی آنها پیدا می‌کردیم تا توسعه‌دهندگان درگیر بتوانند بهتر از امنیت خود مراقبت کنند.

البته، اغلب توسعه دهندگانی که مسئول “کامپوننت های منبع باز برتر” هستند، نمی خواهند یک شغل تمام وقت برای تامین امنیت نرم افزار خود داشته باشند. بین پروژه ها بسیار متفاوت است، اما توسعه دهندگان درگیر تمایل دارند انگیزه های بسیار متفاوتی برای مشارکت خود داشته باشند. هیچ رویکرد یکسانی برای تأمین بودجه توسعه منبع باز کار نمی کند (اگرچه من همچنان احساس می کنم که پایدارترین منبع باز مشارکت قابل توجهی در شرکت دارد، چه از یک جامعه (Kubernetes) یا یک شرکت واحد (MySQL/Oracle).< /p>

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

به همین دلیل است که من رویکردهای “متا” را در طرح ۱۰ نقطه‌ای ترجیح می‌دهم، مانند جایگزینی زبان‌های غیرایمن برای حافظه (با چیزهایی مانند Rust) یا استفاده از امضای دیجیتال. اینها به ایجاد امنیت در پروژه کمک می کنند و در عین حال به فرآیند توسعه موکول می شوند تا در صورت کشف اشکالات برطرف شود.

یادمان باشد: با افزایش محبوبیت منبع باز، اشکال‌ها زیاد شده‌اند< /a> همانطور که WhiteSource و سایر شرکت ها به تفصیل توضیح داده اند. به این فکر کنید: جهان کد منبع باز با سرعت چشمگیری در حال گسترش است و آسیب پذیری ها به موازات آن گسترش یافته اند. شناسایی همه آن مولفه های حیاتی از قبل یک کار مهم و شاید غیرممکن است.