فهرست مواد نرم‌افزاری (SBOM) چیست و چگونه امنیت زنجیره تأمین را تضمین می‌کند؟

در ۱۲ مه ۲۰۲۱، پس از حملات گسترده به شبکه‌های سولارویندز و خط لوله کلونیال، فرمان اجرایی ۱۴۰۲۸ در ایالات متحده صادر شد. این فرمان تاریخی، نهادهای فدرال را موظف کرد تا برای تمام نرم‌افزارهای خریداری‌شده، یک «فهرست مواد نرم‌افزاری» (SBOM) دریافت کنند.[1]

این الزام قانونی، مفهوم SBOM را از یک ایده نظری در محافل امنیتی، به یک استاندارد اجباری و عملیاتی برای شرکت‌ها تبدیل کرد. پیش از صدور این فرمان، بسیاری از سازمان‌های بزرگ حتی نمی‌دانستند چه اجزای متن‌بازی در نرم‌افزارهایشان در حال اجراست.[3]

در سال‌های پس از آن، این استانداردهای اولیه به سرعت تکامل یافته‌اند. در ژوئیه ۲۰۲۶، آژانس امنیت سایبری و امنیت زیرساخت آمریکا (CISA) نسخه جدیدی از «حداقل عناصر مورد نیاز» برای یک SBOM را منتشر کرد تا با فناوری‌های روز همگام شود.[2]

این به‌روزرسانی جدید، عناصری حیاتی مانند الگوریتم هش، مجوزهای نرم‌افزاری و نام ابزار تولیدکننده را به الزامات قبلی اضافه کرد. هدف از این تغییرات سخت‌گیرانه، ایجاد یک تصویر شفاف‌تر و قابل‌اتکاتر از زنجیره تأمین نرم‌افزار برای خریداران است.[2]

فهرست مواد نرم‌افزاری دقیقاً چیست؟

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

این فهرست جامع شامل کتابخانه‌های متن‌باز، وابستگی‌های شخص ثالث، نسخه‌های دقیق آن‌ها و روابط ساختاری بین این اجزا است. این داده‌ها باید در یک قالب استاندارد و قابل خواندن توسط ماشین ارائه شوند تا ابزارهای خودکار بتوانند آن‌ها را به سرعت پردازش کنند.[3]

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

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

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

واکنش سریع به آسیب‌پذیری‌ها

ارزش واقعی و کاربردی SBOM دقیقاً در زمان انتشار یک آسیب‌پذیری بحرانی و روز صفر مشخص می‌شود. زمانی که نقص امنیتی معروفی مانند Log4Shell کشف شد، سازمان‌هایی که فاقد این فهرست بودند، هفته‌ها زمان ارزشمند خود را صرف بررسی دستی کدهایشان کردند.[3]

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

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

به همین دلیل، نهادهای نظارتی اکنون بر تولید این فهرست‌ها در زمان ساخت (Build-time) تأکید فراوانی دارند. فهرستی که دقیقاً در حین کامپایل شدن کد ایجاد می‌شود، معتبرترین و دقیق‌ترین تصویر را از آنچه واقعاً در نرم‌افزار نهایی قرار گرفته، ارائه می‌دهد.

تولید فهرست پس از پایان کار و از طریق تحلیل کدهای باینری کامپایل‌شده، اغلب با خطا و کاستی‌های فراوان همراه است. این روش‌های پسینی بیشتر شبیه به حدس زدن مواد تشکیل‌دهنده یک کیک پخته‌شده هستند تا خواندن دستور پخت اصلی و دقیق آن.[3]

نبرد استانداردها: SPDX در برابر CycloneDX

در دنیای پیچیده SBOM، دو استاندارد اصلی برای قالب‌بندی داده‌ها وجود دارد که هر کدام با هدف کاملاً متفاوتی طراحی شده‌اند. اولین مورد استاندارد SPDX است که توسط بنیاد لینوکس توسعه یافته و یک استاندارد بین‌المللی معتبر (ISO/IEC) محسوب می‌شود.

استاندارد SPDX در ابتدا منحصراً برای مدیریت انطباق و بررسی مجوزهای کدهای متن‌باز طراحی و بهینه‌سازی شد. تیم‌های حقوقی از این قالب استفاده می‌کنند تا مطمئن شوند هیچ کد دارای مجوز محدودکننده‌ای به اشتباه وارد محصولات تجاری شرکت نشده است.

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

قالب CycloneDX به طور بومی از داده‌های آسیب‌پذیری پشتیبانی می‌کند و در ابزارهای ردیابی امنیتی نفوذ بسیار بیشتری دارد. در حالی که نسخه ۳.۰ از SPDX نیز قابلیت‌های امنیتی خود را ارتقا داده، اما CycloneDX همچنان انتخاب اول و بی‌چون‌وچرای تیم‌های امنیتی است.

انتخاب نهایی بین این دو استاندارد مستقیماً به نیاز اصلی و ساختار سازمان بستگی دارد. اگر دغدغه اصلی بررسی لایسنس‌ها باشد، SPDX گزینه بهتری است، اما برای ردیابی سریع آسیب‌پذیری‌ها، CycloneDX کارایی و سرعت بالاتری از خود نشان می‌دهد.

آینده شفافیت نرم‌افزاری و VEX

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

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

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

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

در نهایت، شفافیت زنجیره تأمین نرم‌افزار دیگر یک انتخاب فانتزی نیست، بلکه یک الزام تجاری و قانونی غیرقابل انکار است. با ورود قوانین سخت‌گیرانه جدید، ارائه این فهرست‌ها به زودی برای فروش هر نرم‌افزاری در بازارهای جهانی کاملاً اجباری خواهد شد.[3]

چالش‌های پیاده‌سازی و تولید دقیق

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

ابزارهای خودکار تولید SBOM باید مستقیماً در مسیر یکپارچه‌سازی و استقرار مداوم (CI/CD) تیم‌های توسعه ادغام شوند. تنها در این صورت است که هر نسخه جدید از نرم‌افزار، با یک فهرست مواد کاملاً به‌روز، معتبر و قابل استناد همراه خواهد بود.

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

برای رفع این مشکل ساختاری، استفاده از شناسه‌های یکتای جهانی مانند PURL (آدرس بسته نرم‌افزاری) به عنوان یک استاندارد قطعی در حال فراگیری است. این شناسه‌ها ابهام در نام‌گذاری را کاملاً از بین می‌برند و دقت اسکن‌های خودکار امنیتی را به شدت افزایش می‌دهند.[3]

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