در آگوست 2022، گروه استراتژی سازمانی (ESG) "قدم زدن در خط: GitOps و Shift Left Securityیک گزارش تحقیقات امنیتی توسعه دهنده چند مشتری که وضعیت فعلی امنیت برنامه را بررسی می کند. یافته کلیدی این گزارش، شیوع خطرات زنجیره تامین نرم افزار در برنامه های کاربردی ابری است. جیسون اشمیت، مدیر کل گروه یکپارچگی نرم‌افزار Synopsys، این موضوع را تکرار کرد و اظهار داشت: «از آنجایی که سازمان‌ها شاهد سطح تأثیر بالقوه‌ای هستند که آسیب‌پذیری یا نقض امنیت زنجیره تأمین نرم‌افزار می‌تواند از طریق سرفصل‌های پرمخاطب بر کسب‌وکارشان بگذارد، اولویت‌بندی یک استراتژی امنیتی پیشگیرانه اکنون یک الزام اساسی کسب و کار است."
این گزارش نشان می دهد که سازمان ها متوجه شده اند که زنجیره تامین چیزی فراتر از وابستگی است. این ابزارهای توسعه/خطوط، مخازن، APIها، زیرساخت به عنوان کد (IaC)، کانتینرها، پیکربندی‌های ابری و غیره است.
اگرچه نرم افزار منبع باز ممکن است نگرانی اصلی زنجیره تامین باشد، تغییر به سمت توسعه برنامه های کاربردی بومی ابری، سازمان ها را در مورد خطرات ناشی از گره های اضافی زنجیره تامین خود نگران کرده است. در واقع، 73 درصد از سازمان‌ها گزارش دادند که تلاش‌های امنیتی زنجیره تامین نرم‌افزار خود را در پاسخ به حملات اخیر زنجیره تامین به طور قابل توجهی افزایش داده‌اند.
پاسخ دهندگان به این نظرسنجی گزارش، پذیرش نوعی از فناوری احراز هویت چندعاملی قوی (33%)، سرمایه گذاری در کنترل های تست امنیت برنامه (32%) و بهبود یافته کشف دارایی برای به روز رسانی موجودی سطح حمله سازمان خود (30%) را به عنوان امنیت کلیدی ذکر کردند. ابتکاراتی که آنها در پاسخ به حملات زنجیره تامین دنبال می کنند.
چهل و پنج درصد از پاسخ دهندگان به API ها به عنوان مستعدترین منطقه برای حمله در سازمان خود امروز اشاره کردند. مخازن ذخیره‌سازی داده‌ها با 42 درصد بیشتر در معرض خطر در نظر گرفته شدند و تصاویر محفظه برنامه با 34 درصد حساس‌تر بودند.
این گزارش نشان می دهد که فقدان مدیریت منبع باز، تدوین SBOM را تهدید می کند.
این نظرسنجی نشان داد که 99 درصد سازمان‌ها یا از نرم‌افزار متن‌باز استفاده می‌کنند یا قصد دارند تا 12 ماه آینده از آن استفاده کنند. در حالی که پاسخ دهندگان نگرانی های زیادی در مورد نگهداری، امنیت و قابل اعتماد بودن این پروژه های منبع باز دارند، بیشترین نگرانی آنها مربوط به مقیاسی است که منبع باز در توسعه برنامه به کار گرفته می شود. نود و یک درصد از سازمان‌هایی که از منبع باز استفاده می‌کنند معتقدند کد سازمانشان تا 75 درصد از منبع باز تشکیل شده است - یا خواهد بود. پنجاه و چهار درصد از پاسخ دهندگان «داشتن درصد بالایی از کد برنامه که منبع باز است» را به عنوان نگرانی یا چالش با نرم افزار منبع باز ذکر کردند.
مطالعات Synopsys نیز ارتباطی بین مقیاس استفاده از نرم‌افزار منبع باز (OSS) و وجود ریسک مرتبط پیدا کرده‌اند. با افزایش مقیاس استفاده از OSS، طبیعتاً حضور آن در برنامه ها نیز افزایش می یابد. فشار برای بهبود مدیریت ریسک زنجیره تامین نرم‌افزار توجه را به خود جلب کرده است قبض نرم افزار گردآوری مواد (SBOM). اما با افزایش استفاده از OSS و مدیریت ضعیف OSS، کامپایل SBOM به یک کار پیچیده تبدیل می شود - و 39٪ از پاسخ دهندگان به نظرسنجی در مطالعه ESG به عنوان چالش استفاده از OSS مشخص شدند.
مدیریت ریسک OSS یک اولویت است، اما سازمان‌ها فاقد تعریف روشنی از مسئولیت‌ها هستند.
این نظرسنجی به این واقعیت اشاره دارد که در حالی که تمرکز بر وصله‌های منبع باز پس از رویدادهای اخیر (مانند آسیب‌پذیری‌های Log4Shell و Spring4Shell) منجر به افزایش قابل توجهی در فعالیت‌های کاهش خطر OSS شده است (73 درصدی که در بالا ذکر کردیم)، طرف مسئول این تلاش‌های کاهش نامشخص است.
اکثریت واضح از تیم های DevOps مدیریت OSS را به عنوان بخشی از نقش توسعه دهنده می بینید، در حالی که اکثر تیم های IT آن را به عنوان یک مسئولیت تیم امنیتی می دانند. این ممکن است به خوبی توضیح دهد که چرا سازمان ها برای مدت طولانی تلاش کرده اند تا OSS را به درستی وصله کنند. این نظرسنجی نشان داد که تیم های فناوری اطلاعات بیشتر از تیم های امنیتی (48٪ در مقابل 34٪) در مورد منبع کد OSS نگران هستند، که بازتابی از نقش IT در نگهداری صحیح وصله های آسیب پذیری OSS است. پاسخ دهندگان IT و DevOps (در 49٪ و 40٪) که آب را حتی بیشتر گل آلود می کنند، شناسایی آسیب پذیری ها قبل از استقرار را به عنوان مسئولیت تیم امنیتی می دانند.
فعال سازی برنامه نویس در حال رشد است، اما فقدان تخصص امنیتی مشکل ساز است.
"تغییر به چپ" یک محرک کلیدی برای تحمیل مسئولیت های امنیتی به توسعه دهنده بوده است. این تغییر بدون چالش نبوده است. اگرچه 68 درصد از پاسخ‌دهندگان، فعال‌سازی توسعه‌دهنده را به‌عنوان یک اولویت بالا در سازمان خود نام بردند، تنها 34 درصد از پاسخ‌دهندگان امنیتی در واقع احساس اطمینان داشتند که تیم‌های توسعه مسئولیت آزمایش‌های امنیتی را بر عهده می‌گیرند.
به نظر می‌رسد نگرانی‌هایی مانند بارگذاری بیش از حد تیم‌های توسعه با ابزارها و مسئولیت‌های اضافی، ایجاد اختلال در نوآوری و سرعت، و نظارت بر تلاش‌های امنیتی، بزرگترین مانع برای تلاش‌های AppSec به رهبری توسعه‌دهندگان باشد. اکثر پاسخ دهندگان امنیتی و AppDev/DevOps (در 65٪ و 60٪) خط مشی هایی دارند که به توسعه دهندگان اجازه می دهد کد خود را بدون تعامل با تیم های امنیتی آزمایش و اصلاح کنند، و 63٪ از پاسخ دهندگان فناوری اطلاعات گفتند که سازمان آنها سیاست هایی دارد که توسعه دهندگان را ملزم به مشارکت آنها می کند. تیم های امنیتی
درباره نویسنده
Mike McGuire یک مدیر ارشد راه حل در Synopsys است که در آن بر مدیریت ریسک زنجیره تامین نرم افزار و منبع باز متمرکز است. پس از شروع کار خود به عنوان مهندس نرم افزار، مایک به نقش استراتژی محصول و بازار تبدیل شد، زیرا از تعامل با خریداران و کاربران محصولاتی که روی آنها کار می کند لذت می برد. هدف اصلی مایک با بهره‌گیری از چندین سال تجربه در صنعت نرم‌افزار، اتصال مشکلات پیچیده AppSec بازار با راه‌حل‌های Synopsys برای ایجاد نرم‌افزار امن است.
