فهرست مطالب
در دنیای پیچیده و به‌هم‌پیوسته نرم‌افزار امروز، درک اجزای تشکیل‌دهنده یک محصول نرم‌افزاری بیش از هر زمان دیگری اهمیت یافته است. حملات به زنجیره تأمین نرم‌افزار رو به افزایش است و سازمان‌ها نیازمند شفافیت بیشتری در مورد کتابخانه‌ها، ماژول‌ها و سایر قطعاتی هستند که در برنامه‌های کاربردی خود استفاده می‌کنند. اینجاست که مفهوم “صورتحساب مواد نرم‌افزار” یا SBOM (Software Bill of Materials) به عنوان یک ابزار حیاتی مطرح می‌شود، به‌ویژه برای متخصصان امنیت و تسترهای نفوذ که در خط مقدم دفاع سایبری قرار دارند. این مقاله به بررسی جامع SBOM، اهمیت آن در اکوسیستم امنیت نرم‌افزار و چگونگی بهره‌برداری تسترهای امنیتی از آن برای تقویت وضعیت امنیتی سازمان‌ها می‌پردازد.
صورتحساب مواد نرم‌افزار (SBOM) چیست؟
صورتحساب مواد نرم‌افزار (SBOM) یک لیست رسمی و ساختاریافته از اجزای تشکیل‌دهنده یک نرم‌افزار است. این لیست مشابه فهرست مواد اولیه در تولید صنعتی (Bill of Materials) است که تمامی قطعات، مواد خام و مونتاژهای فرعی لازم برای ساخت یک محصول فیزیکی را مشخص می‌کند. در دنیای نرم‌افزار، SBOM شامل جزئیاتی در مورد کتابخانه‌های متن‌باز و تجاری، ماژول‌ها، فریم‌ورک‌ها و سایر وابستگی‌هایی است که یک برنامه کاربردی را تشکیل می‌دهند. NCSC.GOV.UK اشاره می‌کند که SBOM به فروشندگان و توسعه‌دهندگان کمک می‌کند تا درک بهتری از اجزای متن‌باز و شخص ثالث موجود در نرم‌افزار خود داشته باشند.
یک SBOM معمولاً اطلاعات زیر را برای هر جزء شامل می‌شود:
- نام جزء: نام دقیق کتابخانه یا ماژول.
- نسخه جزء: نسخه خاص استفاده شده.
- تأمین‌کننده/نویسنده: سازنده یا نگهدارنده جزء.
- اطلاعات مجوز (License): نوع مجوزی که تحت آن جزء توزیع شده است. این امر برای اطمینان از انطباق قانونی ضروری است.
- شناسه‌های منحصر به فرد: مانند Package URL (PURL) یا Common Platform Enumeration (CPE) برای شناسایی دقیق و ارتباط با پایگاه‌داده‌های آسیب‌پذیری.
- روابط وابستگی: چگونگی ارتباط این جزء با سایر اجزا در نرم‌افزار.
استانداردهای مختلفی برای فرمت SBOM وجود دارد که دو مورد از رایج‌ترین آن‌ها عبارتند از:
- SPDX (Software Package Data Exchange): یک استاندارد باز که توسط بنیاد لینوکس نگهداری می‌شود و به عنوان استاندارد بین‌المللی (ISO/IEC 5962:2021) نیز منتشر شده است. SPDX در ابتدا بر ردیابی مجوز متمرکز بود اما اکنون جزئیات فراوانی از متادیتای نرم‌افزار را پوشش می‌دهد. (Legit Security، Sonatype)
- CycloneDX: یک استاندارد سبک‌وزن SBOM که توسط جامعه OWASP توسعه یافته و با تمرکز بر اتوماسیون و امنیت، برای استفاده در خطوط لوله مدرن DevSecOps طراحی شده است. (Legit Security، Sonatype)
- SWID (Software Identification Tags): فرمت قدیمی‌تری که ابتدا برای مدیریت موجودی نرم‌افزار طراحی شده و تحت استاندارد ISO/IEC 19770-2 تعریف شده است. (Legit Security)
چرا SBOM برای امنیت نرم‌افزار حیاتی است؟
اهمیت SBOM در امنیت نرم‌افزار از چندین جنبه قابل بررسی است:
- شفافیت و دیده‌بانی: SBOMها شفافیت بی‌سابقه‌ای را در مورد اجزای داخلی یک نرم‌افزار فراهم می‌کنند. این شفافیت به سازمان‌ها امکان می‌دهد تا بفهمند دقیقاً از چه چیزی استفاده می‌کنند و ریسک‌های مرتبط با هر جزء را ارزیابی کنند. Balbix تأکید می‌کند که SBOM دید واضحی از تمام اجزای نرم‌افزار ارائه می‌دهد و به سازمان‌ها بینشی برای شناسایی و رسیدگی زودهنگام به خطرات بالقوه می‌دهد.
- مدیریت آسیب‌پذیری: با داشتن لیست دقیقی از اجزا و نسخه‌های آن‌ها، سازمان‌ها می‌توانند به سرعت بررسی کنند که آیا آسیب‌پذیری‌های تازه کشف‌شده (مانند Log4Shell) بر سیستم‌هایشان تأثیر می‌گذارد یا خیر. OWASP اشاره می‌کند که SBOM تضمین می‌کند توسعه‌دهندگان از وابستگی‌های آسیب‌پذیر شناخته‌شده استفاده نمی‌کنند و دید کاملی نسبت به اجزای نرم‌افزار خود دارند. (OWASP Foundation)
- انطباق با مجوزها: نرم‌افزارهای مدرن به شدت به اجزای متن‌باز متکی هستند که هر یک دارای مجوزهای خاص خود هستند. SBOM به ردیابی این مجوزها و اطمینان از انطباق با آن‌ها کمک می‌کند و از مشکلات قانونی بالقوه جلوگیری می‌نماید. Black Duck Blog بیان می‌کند که عدم رعایت مجوزهای متن‌باز می‌تواند کسب‌وکارها را در معرض خطر قابل توجه دعوی قضایی و به خطر افتادن مالکیت معنوی قرار دهد.
- امنیت زنجیره تأمین نرم‌افزار: با افزایش حملات به زنجیره تأمین، SBOM به عنوان ابزاری برای تأیید اصالت و یکپارچگی اجزای نرم‌افزار عمل می‌کند. سازمان‌ها می‌توانند SBOMهای دریافتی از تأمین‌کنندگان را بررسی کرده و از عدم وجود اجزای مخرب یا دستکاری‌شده اطمینان حاصل کنند.
- پاسخگویی به حوادث: در صورت وقوع یک حادثه امنیتی، SBOM می‌تواند به تیم‌های پاسخگویی کمک کند تا به سرعت گستره تأثیر حادثه را مشخص کرده و اجزای آسیب‌دیده را شناسایی و اصلاح نمایند. LeanIX عنوان می‌کند که SBOM با ارائه دید واضحی از اجزای تحت تأثیر، به شناسایی و رسیدگی سریع به آسیب‌پذیری‌ها کمک می‌کند.
طبق گزارش‌ها، استفاده از اجزای متن‌باز بسیار رایج است؛ به عنوان مثال، گزارش OSSRA نشان داد که ۹۶٪ از پایگاه‌های کد اسکن‌شده حاوی اجزای متن‌باز بوده‌اند و ۸۴٪ از این پایگاه‌های کد حداقل یک آسیب‌پذیری متن‌باز شناخته‌شده داشته‌اند. (Black Duck Blog، Architecture Technology Corporation). این آمار اهمیت روزافزون SBOM را بیش از پیش نمایان می‌سازد.
نقش SBOM برای تسترهای امنیت
تسترهای امنیت، شامل متخصصان تست نفوذ و تحلیلگران آسیب‌پذیری، می‌توانند از SBOM به شیوه‌های مختلفی برای بهبود اثربخشی فعالیت‌های خود بهره‌مند شوند:
۱. شناسایی دقیق‌تر و سریع‌تر آسیب‌پذیری‌ها
با دسترسی به SBOM یک برنامه، تستر امنیت دیگر نیازی به صرف زمان زیاد برای شناسایی دستی کتابخانه‌ها و وابستگی‌های مورد استفاده ندارد. آن‌ها می‌توانند به سرعت لیست اجزا را با پایگاه‌داده‌های آسیب‌پذیری عمومی و خصوصی (مانند NVD، Vulners، یا پایگاه‌داده‌های داخلی سازمان) مقایسه کرده و آسیب‌پذیری‌های شناخته‌شده مرتبط با نسخه‌های خاص اجزا را کشف کنند. این امر به‌ویژه برای شناسایی آسیب‌پذیری‌های N-day (آسیب‌پذیری‌هایی که اصلاحیه برای آن‌ها منتشر شده اما هنوز اعمال نشده) بسیار کارآمد است. OWASP توصیه می‌کند که SBOM تولید شده باید در یک مخزن امن منتشر شده و به طور خودکار توسط ابزارهایی مانند OWASP Dependency-Track برای نظارت مداوم بر آسیب‌پذیری‌ها و شناسایی آسیب‌پذیری‌های N-day استفاده شود. (OWASP Foundation)
۲. اولویت‌بندی تلاش‌های تست
SBOM به تسترهای امنیت کمک می‌کند تا تلاش‌های خود را بر روی اجزایی متمرکز کنند که بیشترین ریسک را به همراه دارند. برای مثال، کتابخانه‌های قدیمی‌تر، اجزایی با سابقه آسیب‌پذیری‌های متعدد، یا اجزایی که توابع حساس و حیاتی را پیاده‌سازی می‌کنند، می‌توانند اهداف اولویت‌دار برای بررسی دقیق‌تر باشند. با استفاده از سیستم امتیازدهی مشترک آسیب‌پذیری (CVSS)، می‌توان شدت آسیب‌پذیری‌ها را رتبه‌بندی و اولویت‌بندی کرد. (OWASP Foundation)
۳. تحلیل ریسک زنجیره تأمین
تسترهای امنیت می‌توانند از SBOM برای ارزیابی ریسک‌های مرتبط با زنجیره تأمین نرم‌افزار استفاده کنند. با بررسی منابع اجزا، سابقه امنیتی تأمین‌کنندگان، و نحوه مدیریت وابستگی‌ها، می‌توان نقاط ضعف بالقوه در زنجیره تأمین را شناسایی کرد. این اطلاعات برای ارائه توصیه‌های امنیتی جامع‌تر به سازمان بسیار ارزشمند است.
۴. کمک به تست انطباق مجوزها
اگرچه تمرکز اصلی تسترهای امنیت بر آسیب‌پذیری‌هاست، اما انطباق با مجوزهای نرم‌افزاری نیز بخش مهمی از مدیریت ریسک است. SBOM اطلاعات لازم برای بررسی انطباق با مجوزهای اجزای متن‌باز را فراهم می‌کند و به جلوگیری از مشکلات قانونی و نقض مالکیت معنوی کمک می‌کند. Black Duck Blog گزارش می‌دهد که بیش از ۵۳٪ از پایگاه‌های کد بررسی‌شده در گزارش OSSRA حاوی تضادهای مجوز نرم‌افزار متن‌باز بوده‌اند.
۵. بهبود فرآیند تست نفوذ برنامه‌های کاربردی وب (WAST) و موبایل
در تست نفوذ برنامه‌های کاربردی، شناسایی فریم‌ورک‌ها، کتابخانه‌های سمت کلاینت (JavaScript) و سرور (مانند Spring، Django، Express.js) و نسخه‌های آن‌ها برای یافتن اکسپلویت‌های شناخته‌شده یا بردارهای حمله خاص بسیار مهم است. SBOM این اطلاعات را به صورت آماده در اختیار تستر قرار می‌دهد و فرآیند شناسایی اولیه (Reconnaissance) را تسریع می‌بخشد.
۶. ارزیابی امنیت نرم‌افزارهای شخص ثالث و خریداری‌شده
هنگامی که یک سازمان نرم‌افزاری را از یک فروشنده شخص ثالث تهیه می‌کند یا قصد خرید شرکتی دیگر را دارد (M&A)، درخواست و بررسی SBOM محصول یا دارایی‌های نرم‌افزاری آن شرکت می‌تواند به ارزیابی دقیق وضعیت امنیتی و ریسک‌های پنهان کمک شایانی کند. LeanIX اشاره می‌کند که در هنگام ادغام و اکتساب، داشتن SBOM جامع می‌تواند به ارزیابی وضعیت امنیتی نرم‌افزار، شناسایی خطرات بالقوه و ارزیابی سازگاری با سیستم‌های موجود کمک کند.
چالش‌ها و محدودیت‌های SBOM برای تسترهای امنیت
با وجود مزایای فراوان، استفاده از SBOM بدون چالش نیست:
- دقت و کامل بودن SBOM: کیفیت یک SBOM به ابزارها و فرآیندهای تولید آن بستگی دارد. SBOMهای ناقص یا نادرست می‌توانند منجر به ایجاد حس امنیت کاذب یا نادیده گرفتن آسیب‌پذیری‌های واقعی شوند. Cossack Labs هشدار می‌دهد که ابزارهای فعلی عمدتاً از منابع ثانویه مانند مدیران بسته و فایل‌های مانیفست برای تولید SBOM استفاده می‌کنند که ممکن است حاوی اطلاعاتی باشند که در کد واقعی وجود ندارند.
- پویایی نرم‌افزار: نرم‌افزارها به طور مداوم در حال تغییر هستند. SBOM باید به طور منظم به‌روزرسانی شود تا منعکس‌کننده آخرین وضعیت اجزا باشد. SBOMهای قدیمی ارزش محدودی دارند. Mender اشاره می‌کند که نرم‌افزار به سرعت تکامل می‌یابد و نیاز به حسابرسی و مستندسازی مداوم برای به‌روز نگه داشتن SBOM دارد.
- تحلیل اجزای تودرتو (Transitive Dependencies): شناسایی و تحلیل تمامی وابستگی‌های تودرتو (وابستگی‌هایِ وابستگی‌ها) می‌تواند پیچیده باشد. برخی ابزارهای تولید SBOM ممکن است در این زمینه ضعف داشته باشند.
- عدم پوشش آسیب‌پذیری‌های Zero-day: SBOM عمدتاً به شناسایی آسیب‌پذیری‌های شناخته‌شده کمک می‌کند. آسیب‌پذیری‌های جدید یا Zero-day که هنوز در پایگاه‌داده‌ها ثبت نشده‌اند، از طریق تحلیل SBOM قابل کشف نیستند و همچنان نیازمند تکنیک‌های پیشرفته تست نفوذ و تحلیل کد هستند.
- پیکربندی و زمینه استقرار: یک جزء نرم‌افزاری ممکن است در یک پیکربندی خاص آسیب‌پذیر باشد اما در پیکربندی دیگر خیر. SBOM به تنهایی اطلاعات کاملی در مورد نحوه پیکربندی یا استقرار اجزا ارائه نمی‌دهد. Cossack Labs بیان می‌کند که SBOMها معمولاً اطلاعاتی در مورد پیکربندی وابستگی‌ها، محیط، خطوط لوله توسعه یا داده‌هایی که استفاده می‌کنند، شامل نمی‌شوند.
- مقاومت در برابر اشتراک‌گذاری SBOM: برخی تولیدکنندگان نرم‌افزار ممکن است به دلایل مربوط به مالکیت معنوی یا نگرانی‌های امنیتی، تمایلی به اشتراک‌گذاری SBOM محصولات خود نداشته باشند.
ادغام SBOM در جریان کاری تسترهای امنیت
برای بهره‌برداری مؤثر از SBOM، تسترهای امنیت می‌توانند اقدامات زیر را انجام دهند:
- درخواست SBOM: به عنوان بخشی از فرآیند تعامل اولیه (Engagement Kick-off) برای پروژه‌های تست نفوذ، از کارفرما درخواست ارائه SBOM برای برنامه‌های تحت ارزیابی را داشته باشند.
- استفاده از ابزارهای تحلیل SBOM: از ابزارهای تخصصی برای تحلیل SBOM، مقایسه آن با پایگاه‌داده‌های آسیب‌پذیری، و شناسایی ریسک‌های مرتبط با مجوزها استفاده کنند. ابزارهایی مانند OWASP Dependency-Track، Syft (Oligo Security)، و سایر ابزارهای تجاری و متن‌باز در این زمینه مفید هستند.
- ترکیب با سایر ابزارهای تست: اطلاعات به‌دست‌آمده از SBOM را با نتایج سایر ابزارهای تست امنیت مانند ابزارهای تحلیل ایستای کد (SAST)، تحلیل پویای کد (DAST) و تحلیل ترکیب نرم‌افزار (SCA) ترکیب کنند. Balbix به ارتباط نزدیک SCA و SBOM اشاره می‌کند.
- آموزش و آگاهی‌بخشی: دانش خود را در مورد استانداردهای SBOM، ابزارهای مرتبط، و بهترین شیوه‌ها به‌روز نگه دارند و در صورت لزوم، کارفرمایان و تیم‌های توسعه را در مورد اهمیت و نحوه تولید SBOMهای باکیفیت راهنمایی کنند.
- گنجاندن یافته‌های SBOM در گزارش‌ها: یافته‌های مرتبط با آسیب‌پذیری‌ها یا ریسک‌های شناسایی‌شده از طریق تحلیل SBOM را به طور واضح در گزارش‌های تست نفوذ خود مستند کرده و توصیه‌های عملی برای رفع آن‌ها ارائه دهند.
آینده SBOM در امنیت سایبری
انتظار می‌رود استفاده از SBOM در آینده به طور قابل توجهی افزایش یابد. ابتکارات دولتی، مانند دستور اجرایی ایالات متحده در مورد بهبود امنیت سایبری کشور، بر لزوم استفاده از SBOM تأکید دارند. Architecture Technology Corporation اشاره می‌کند که دولت بایدن در یک دستور اجرایی در می ۲۰۲۱ بر SBOM به عنوان یک هشدار برای سازمان‌ها برای تقویت امنیت سایبری خود تأکید کرد. همچنین، پیش‌بینی می‌شود که بازار جهانی SBOM از ۴۲۷.۳ میلیون دلار در سال ۲۰۲۲ به ۴.۲۴ میلیارد دلار در سال ۲۰۲۹ با نرخ رشد مرکب سالانه ۳۱.۴٪ افزایش یابد. (Architecture Technology Corporation) گارتنر نیز پیش‌بینی کرده است که تا سال ۲۰۲۵، ۶۰٪ از سازمان‌هایی که نرم‌افزار زیرساخت حیاتی را می‌سازند یا تهیه می‌کنند، SBOM را در رویه مهندسی نرم‌افزار خود الزامی و استاندارد خواهند کرد. (Scribe Security)
ابزارهای تولید و تحلیل SBOM هوشمندتر شده و با استفاده از هوش مصنوعی و یادگیری ماشین، قابلیت‌های پیشرفته‌تری مانند پیش‌بینی آسیب‌پذیری یا شناسایی الگوهای مشکوک در اجزای نرم‌افزار را ارائه خواهند داد. ادغام عمیق‌تر SBOM در چرخه حیات توسعه نرم‌افزار (SDLC) و فرآیندهای DevSecOps، به امری عادی تبدیل خواهد شد. Sonar تأکید می‌کند که یک استراتژی قوی SBOM با اصول DevSecOps همسو است و امنیت را در هر مرحله از توسعه نرم‌افزار جای می‌دهد.
نتیجه‌گیری
صورتحساب مواد نرم‌افزار (SBOM) دیگر یک مفهوم لوکس یا اختیاری نیست، بلکه یک ضرورت اساسی برای تضمین امنیت و شفافیت در اکوسیستم پیچیده نرم‌افزار امروزی است. برای تسترهای امنیت، SBOM ابزاری قدرتمند برای شناسایی سریع‌تر و دقیق‌تر آسیب‌پذیری‌ها، اولویت‌بندی تلاش‌های تست، و ارائه تحلیل‌های جامع‌تر از وضعیت امنیتی یک برنامه یا سازمان است. با درک عمیق از چیستی SBOM، مزایا، محدودیت‌ها و نحوه استفاده مؤثر از آن، متخصصان امنیت می‌توانند نقش کلیدی‌تری در حفاظت از دارایی‌های دیجیتال و تقویت دفاع سایبری ایفا کنند. پذیرش و ترویج فرهنگ استفاده از SBOM، گامی مهم در جهت ساخت آینده‌ای امن‌تر برای دنیای نرم‌افزار خواهد بود.
سوالات متداول
یک SBOM معمولاً شامل نام جزء، نسخه دقیق آن، نام تأمین‌کننده یا نویسنده، اطلاعات مربوط به مجوز استفاده (مانند MIT، Apache 2.0، GPL)، شناسه‌های منحصر به فردی مانند PURL یا CPE برای ردیابی آسیب‌پذیری‌ها، و گاهی اوقات هش‌های رمزنگاری شده فایل‌ها برای تأیید یکپارچگی است. همچنین روابط وابستگی بین اجزا نیز ممکن است ذکر شود. (Sonar)
خیر. SBOM در درجه اول به شناسایی آسیب‌پذیری‌های شناخته‌شده در اجزای لیست شده کمک می‌کند. آسیب‌پذیری‌های جدید (Zero-day) یا آسیب‌پذیری‌های ناشی از کدنویسی سفارشی و نادرست که مختص خود برنامه هستند، معمولاً از طریق تحلیل SBOM قابل کشف نیستند و نیازمند روش‌های دیگری مانند تست نفوذ دستی، SAST و DAST هستند.
SPDX (Software Package Data Exchange) یک استاندارد جامع‌تر و بالغ‌تر است که توسط بنیاد لینوکس پشتیبانی می‌شود و در ابتدا با تمرکز قوی بر انطباق مجوزها توسعه یافت. این استاندارد بسیار دقیق است و جزئیات زیادی را پوشش می‌دهد. CycloneDX یک استاندارد سبک‌تر و جدیدتر است که توسط OWASP توسعه داده شده و با تمرکز بر امنیت و سهولت استفاده در محیط‌های DevSecOps طراحی شده است. CycloneDX برای اتوماسیون و یکپارچه‌سازی سریع مناسب‌تر است. (Legit Security، Sonatype)
با تحلیل SBOM، تستر می‌تواند اجزایی را شناسایی کند که احتمالاً ریسک بالاتری دارند. این‌ها می‌توانند شامل کتابخانه‌های قدیمی و به‌روزنشده، اجزایی با تاریخچه طولانی از آسیب‌پذیری‌ها، اجزایی که توسط تأمین‌کنندگان کمتر شناخته‌شده ارائه شده‌اند، یا اجزایی باشند که عملکردهای حیاتی و حساس (مانند احراز هویت، رمزنگاری، پردازش پرداخت) را انجام می‌دهند. تمرکز تست بر این اجزا می‌تواند کارایی فرآیند تست را افزایش دهد.
تولید دستی SBOM برای نرم‌افزارهای پیچیده امروزی تقریباً غیرممکن و مستعد خطا است. ابزارهای متعددی برای تولید خودکار SBOM وجود دارند. این ابزارها کد منبع، فایل‌های باینری، یا تصاویر کانتینر را اسکن کرده و لیستی از اجزا و وابستگی‌ها را در فرمت‌های استاندارد SBOM (مانند SPDX یا CycloneDX) تولید می‌کنند. ابزارهایی مانند Syft، Microsoft’s SBOM tool، و CycloneDX Generators از جمله این ابزارها هستند. (Oligo Security، Cossack Labs بر عدم توصیه تولید دستی SBOM تاکید دارد)
بیشتر بخوانید:
