چرا مدیریت SBOM دیگر اختیاری نیست؟

پس از Log4Shell، تولید صورتحساب‌های نرم‌افزاری مواد و دسترسی سریع به اطلاعات آن‌ها برای پرداختن به واقعیت‌های جدید آسیب‌پذیری‌ها و حملات زنجیره تامین نرم‌افزار حیاتی خواهد بود.

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

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

ایجاد یک SBOM جامع

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

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

در حالی که امروزه اسکن آسیب‌پذیری‌ها قبل از تحویل برنامه رایج است، این به سادگی کافی نیست. اسکن برنامه‌ها برای شناسایی مؤلفه‌ها و آسیب‌پذیری‌های مربوطه باید یک فرآیند مداوم باشد که فقط یک بار اجرا نمی‌شود، بلکه به طور منظم اجرا می‌شود. هر بار که یک برنامه اسکن می شود، نتایج باید ثبت و تجزیه و تحلیل شوند. برای انتقال از یک سیستم موقت به سیستمی مستمر، ابزارسازی و اتوماسیون مهم هستند.

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

قابلیت های حیاتی مورد نیاز برای مدیریت SBOM

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

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

SBOM سرعت پاسخ حادثه

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

واقعیت های جدید SBOM

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

Log4j یک درس بسیار پرهزینه بود تا به ما یادآوری کند که چرا ما نه تنها به SBOM نیاز داریم، بلکه به توانایی مدیریت آنها به عنوان بخشی از استراتژی مدیریت زنجیره تامین نرم افزار کامل نیز نیاز داریم. اکنون زمان آن است که در مورد امنیت زنجیره تامین نرم افزار خود فعال باشید. پیاده‌سازی مدیریت SBOM یک الزام حیاتی است که با فرارسیدن روز صفر بعدی سود سهام را پرداخت می‌کند.

جاش برسرز معاون امنیتی در Anchore است.

—

انجمن فناوری جدید مکانی را برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.