شرکت‌هایی که دارای یک سیاست امنیتی نرم‌افزار منبع باز (OSS) هستند، تمایل دارند در مقیاس‌های خود ارزیابی آمادگی عملکرد بسیار بهتری داشته باشند. بر اساس نظرسنجی منتشر شده در 21 ژوئن، آنها همچنین تمایل دارند که تیم های اختصاصی مسئول امنیت نرم افزار رانندگی داشته باشند.
این نظرسنجی – که توسط شرکت امنیت نرم‌افزاری Snyk و بنیاد لینوکس در روز سه‌شنبه منتشر شد – نشان داد که از هر 10 شرکتی که یک خط‌مشی امنیتی OSS دارند، هفت شرکت توسعه برنامه‌های خود را بسیار یا تا حدودی ایمن می‌دانند. در مقایسه، تنها 45 درصد از شرکت هایی که نتوانستند چنین سیاستی را وضع کنند، حداقل تا حدودی خود را امن می دانند.
مت جارویس، مدیر روابط توسعه‌دهنده Snyk می‌گوید نرم‌افزار متن‌باز مزایای قابل‌توجهی برای توسعه برنامه‌های کاربردی دارد، اما شرکت‌ها باید جنبه‌های منفی را نیز بشناسند و برای آن آماده شوند.
او می‌گوید: «در حالی که منبع باز مکانیزمی اثبات‌شده برای نوآوری و ساخت نرم‌افزار با کیفیت بالا است، اما تا حدودی قربانی موفقیت خود می‌شود، زیرا فراگیر بودن آن آن را به هدفی برای حملات زنجیره تأمین تبدیل کرده است». شرکت‌ها باید درک قوی‌تری از هر دو مکانیسمی که منبع باز کار می‌کند، ایجاد کنند، و این شامل حاکمیت و همچنین کد می‌شود، و رویکرد خود را برای مدیریت زنجیره تامین از طریق اتخاذ ابزارها و روش‌های امنیتی اول توسعه‌دهنده تقویت کنند.
تاخیر شرکت های کوچکتر در سیاست های OSS
به طور کلی، تنها حدود نیمی از شرکت‌ها یک خط‌مشی امنیتی منبع باز دارند تا توسعه‌دهندگان را در استفاده از اجزا و چارچوب‌ها راهنمایی کند، با توجه به اینکه تعداد بیشتری از شرکت‌های کوچک، 60 درصد، یا فاقد خط‌مشی هستند یا نمی‌دانند که آیا آن را دارند یا خیر. به گزارش
در این گزارش آمده است که اقتصاد امنیت تمایل دارد اولویت ایجاد یک سیاست رسمی برای استارت آپ ها و شرکت های کوچکتر را کاهش دهد.
در این گزارش آمده است: «سازمان‌های کوچک دارای کارکنان و بودجه‌های کوچک فناوری اطلاعات هستند و نیازهای عملکردی کسب‌وکار اغلب اولویت دارند تا کسب‌وکار بتواند رقابتی باقی بماند». کمبود منابع و زمان دلایل اصلی عدم توجه سازمان ها به بهترین شیوه های امنیتی OSS بود.
منبع: گزارش «بررسی چالش های امنیت سایبری در نرم افزارهای متن باز».
بر اساس این مطالعه، زبان های برنامه نویسی مختلف نیز ملاحظات امنیتی متفاوتی را به همراه داشتند. برای مثال، برنامه‌هایی که در دات‌نت نوشته شده‌اند، 148 روز طولانی‌ترین میانگین زمان را برای رفع ایرادات دارند و پس از آن جاوا اسکریپت قرار دارد، در همین حال، برنامه‌هایی که در Go نوشته شده‌اند، سریع‌ترین زمان برای اصلاح را داشتند و معمولاً در یک سوم آن زمان رفع می‌شدند. ، یا 49 روز.
وابستگی های جاوا اسکریپت فراوان است
برنامه های جاوا اسکریپت بیشترین وابستگی ها را دارند – به گفته Snyk به طور متوسط 174 در هر پروژه – یا حدود هفت برابر زبان با کمترین وابستگی، Python، که به طور متوسط 25 در هر پروژه است.
جارویس می‌گوید در حالی که درخت‌های وابستگی انتقالی بزرگ می‌توانند منجر به مسیرهای مداری برای رفع آسیب‌پذیری‌ها شوند، اگر سازمانی راه‌هایی برای ردیابی روابط بین پروژه‌ها داشته باشد، داشتن تعداد زیادی وابستگی لزوماً یک نقطه ضعف نیست.
او می‌گوید: «بسته‌های جاوا اسکریپت نسبت به سایر اکوسیستم‌ها دامنه کوچک‌تری دارند، بنابراین اگرچه تعداد آنها بیشتر است، ممکن است کد کمتری برای ممیزی برای نقاط ضعف احتمالی وجود داشته باشد. مهم‌ترین مسئله درک وابستگی‌هایی است که استفاده می‌کنید، به‌ویژه وابستگی‌های انتقالی که به عنوان وابستگی‌های وابستگی وارد می‌شوند، و این به استفاده از ابزار امنیتی مناسب برای اسکن چیزها منتهی می‌شود.»
با این حال، داده‌ها همچنین نشان می‌دهند که زبان‌های مختلف دارای شدت‌های متفاوتی از نقص هستند. به عنوان مثال، متوسط پروژه ای که به زبان جاوا نوشته شده است، دارای بیش از 47 آسیب پذیری با شدت بالا و 28 آسیب پذیری با شدت متوسط است که بسیار بالاتر از جاوا اسکریپت رتبه دوم که به ترتیب دارای میانگین 18 و 21 آسیب پذیری بودند. با این حال، پایتون بیشترین آسیب پذیری های کم شدت را داشت، به طور متوسط 20 آسیب پذیری در هر پروژه.
جارویس می‌گوید: «عوامل زیادی در داده‌ها نقش دارند – پیچیدگی پروژه‌ها، تعداد توسعه‌دهندگان و محبوبیت همگی بر تعداد و انواع آسیب‌پذیری‌ها تأثیر خواهند داشت.» بسیاری از توسعه‌دهندگان به پروژه‌هایی که بسیار محبوب هستند نگاه می‌کنند، احتمالاً باگ‌های بیشتری را نشان می‌دهند.»
اتوماسیون = بلوغ امنیتی
علی‌رغم اهمیت شناسایی آسیب‌پذیری‌ها در وابستگی‌ها، اکثر شرکت‌های بالغ از نظر امنیتی – آنهایی که دارای سیاست‌های امنیتی OSS هستند – به توصیه‌های آسیب‌پذیری صنعت (60%)، نظارت خودکار بسته‌ها برای اشکالات (60%) و اعلان‌های نگهدارنده بسته (49٪) متکی هستند. )، برطبق بررسی ها.
نظارت خودکار نشان‌دهنده مهم‌ترین شکاف بین شرکت‌های بالغ امنیتی و شرکت‌های بدون خط‌مشی است، به طوری که تنها 38 درصد از شرکت‌هایی که خط‌مشی ندارند، از نوعی نظارت خودکار استفاده می‌کنند، در مقایسه با 60 درصد شرکت‌های بالغ.
Snyk’s Jarvis می‌گوید: اگر شرکت‌ها سیاست امنیتی OSS ندارند، باید به عنوان راهی برای تقویت امنیت توسعه خود، یک سیاست امنیتی OSS اضافه کنند. او می گوید حتی یک سیاست سبک وزن شروع خوبی است.
او می‌گوید: «بین داشتن یک سیاست و این احساس که توسعه تا حدودی ایمن است، ارتباط وجود دارد». ما فکر می کنیم که داشتن یک خط مشی نقطه شروع معقولی برای بلوغ امنیتی است، زیرا نشان می دهد که سازمان از مسائل بالقوه آگاه است و این سفر را آغاز کرده است.