SBOM چگونه وابستگی‌های نرم‌افزار را آشکار می‌کند؟

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

SBOM خودِ محصول را امن نمی‌کند و اگر ناقص، قدیمی یا به فایل نادرست متصل باشد ارزش کمی دارد. کیفیت به روش ساخت، پوشش اجزای پویا و پیوند فهرست با نسخهٔ دقیق خروجی بستگی دارد. این فهرست بخشی از مدیریت زنجیرهٔ تأمین نرم‌افزار است، نه گواهی سلامت یا جایگزین آزمون امنیتی.

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

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

فهرست می‌تواند کتابخانهٔ مستقیم و بستهٔ تو‌در‌توی آن را نشان دهد، اما دامنهٔ آن باید روشن باشد: کد زمان اجرا، ابزار ساخت، سیستم‌عامل پایه یا افزونهٔ اختیاری کدام‌اند؟ مقالهٔ بررسی چک‌سام فایل هویت یک فایل را می‌سنجد؛ SBOM ترکیب و رابطهٔ اجزا را ثبت می‌کند و به‌تنهایی ثابت نمی‌کند فایل همان چیزی است که ادعا می‌شود.

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

وابستگی مستقیم و گذرا چه تفاوتی دارند؟

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

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

ممکن است بسته‌ای در زمان ساخت فقط برای کامپایل مصرف شود و در محصول نهایی حضور نداشته باشد، درحالی‌که کتابخانه‌ای هنگام اجرا از راه افزونه بارگیری شود. SBOMهای مختلف می‌توانند دامنهٔ build-time و runtime را جدا کنند. این برچسب‌ها به تحلیلگر کمک می‌کنند، اما باید بر اساس فرایند واقعی ساخته شوند. تصویر کانتینر نیز می‌تواند اجزای سیستم‌عامل و برنامه را در لایه‌های مختلف داشته باشد.

در وابستگی‌های اختیاری، باید روشن شود کدام feature آن‌ها را فعال می‌کند. یک package manager ممکن است وابستگی توسعه را از محصول نهایی جدا کند، درحالی‌که ابزار دیگر همه را در یک manifest فهرست کند. پیوند dependency graph باید نوع رابطه را نیز نشان دهد تا تیم هر بستهٔ نصب‌شده را بی‌درنگ در معرض اجرا فرض نکند. این جزئیات برای اولویت‌بندی وصله و ممیزی مجوز مهم‌اند.

SBOM چگونه از ساخت محصول تولید می‌شود؟

ابزار تولید می‌تواند فایل‌های manifest، قفل بسته، خروجی حل وابستگی یا خود فایل‌های ساخته‌شده را بررسی کند. هر روش بخش متفاوتی را می‌بیند: manifest نیت پروژه را نشان می‌دهد، فایل قفل نسخهٔ انتخاب‌شده را، و اسکن محصول نهایی ممکن است کتابخانهٔ بسته‌بندی‌شده را پیدا کند. ترکیب روش‌ها می‌تواند شکاف‌ها را کم کند، اما باید منبع هر داده مشخص باشد.

فهرست بهتر است به build مشخص و artifact نهایی گره بخورد؛ فهرستی که فقط نام پروژه را دارد نمی‌گوید کدام نسخهٔ اجرایی را توصیف می‌کند. فرایند قابل‌بازتولید باید نسخهٔ مولد، ورودی‌ها و زمان تولید را ثبت کند. پس از تغییر وابستگی یا rebuild، فهرست را تازه کنید و نتیجه را همراه محصول نگه دارید تا تیم بعداً همان خروجی را بررسی کند.

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

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

محصول اورجینال INZIP

قالب وردپرس باریستا مخصوص کافه تم نسکافه ای روشن (دو زبانه)

دانلود پوسته وردپرس باریستا؛ قالب کافیشاپ، رُستری قهوه و فروشگاه قهوه دوزبانه با منوی رومیزی، رزرو آنلاین میز با کد پیامکی و ووکامرس. طراحی اختصاصی inzip.ir

تحویل آنی آپدیت رایگان بدون قفل لایسنس پشتیبانی واقعی

۳,۹۹۰,۰۰۰ تومان ۲,۹۶۰,۰۰۰ تومان

بازدید و دانلود آنی

٪۲۶

تخفیف ویژه

سود شما

۱,۰۳۰,۰۰۰ تومان

چطور شناسهٔ یک مؤلفه را درست تطبیق می‌دهند؟

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

شناسهٔ ناقص را می‌توان با اطلاعات اضافی مثل URL منبع، شناسهٔ بسته و وابستگی والد غنی کرد. اما دادهٔ ساختاریافته هم خطا می‌پذیرد؛ تولیدکننده باید بررسی کند نسخهٔ ثبت‌شده با artifact مطابقت دارد. فهرست باید امکان بازبینی انسانی داشته باشد، به‌خصوص برای بسته‌های داخلی، forkها و کدهایی که با نام تجاری یا شناسهٔ سفارشی منتشر شده‌اند.

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

SBOM در پاسخ به آسیب‌پذیری چه کمکی می‌کند؟

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

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

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

مجوزها و منشأ کد چگونه ثبت می‌شوند؟

SBOM می‌تواند اطلاعات مجوز و منشأ مؤلفه‌ها را همراه فهرست ثبت کند تا تیم حقوقی یا نگهدارنده بررسی کند چه تعهدهایی به محصول منتقل می‌شود. شناسهٔ نسخه و منبع دانلود نیز برای ردیابی مفید است. اما دادهٔ مجوز خودکار جای نظر حقوقی نیست؛ متن مجوز، تغییرهای محلی و نحوهٔ توزیع می‌تواند نتیجه را عوض کند.

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

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

قالب‌های SBOM چه نقشی دارند؟

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

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

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

SBOM را چگونه به artifact متصل می‌کنند؟

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

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

پیوست‌کردن فهرست به بسته با یک شناسهٔ ساخت و digest کمک می‌کند زنجیرهٔ انتشار را ردگیری کنید. امضا باید از کلید محافظت‌شده بیاید و مصرف‌کننده امکان بررسی گواهی و وضعیت کلید را داشته باشد. اگر artifact پس از امضا دوباره بسته‌بندی شود، پیوند قبلی دیگر کافی نیست. فرایند باید روشن کند چه سامانه‌ای فهرست را تولید، امضا و در کجا بایگانی می‌کند.

SBOM دامنه و تازگی داده را به‌تنهایی تضمین نمی‌کند

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

فهرست قدیمی می‌شود اگر پروژه تغییر کند ولی فرایند تولید تکرار نشود. تیم باید مالک، زمان تازه‌سازی و محل نگهداری را تعیین کند. نگهداری یک فایل بزرگ به‌تنهایی مدیریت زنجیرهٔ تأمین نیست؛ توان جست‌وجو، پیگیری اصلاح و بازسازی نسخهٔ محصول ارزش عملی آن را می‌سازد.

فهرست ممکن است نسخهٔ کد را نشان دهد، اما پیکربندی اجرا، patchهای محلی یا دسترسی واقعی شبکه را کامل توصیف نکند. محیط‌های مختلف از یک image پایه استفاده می‌کنند و تنظیماتشان فرق دارد. SBOM باید کنار inventory دارایی، پیکربندی و مدیریت وصله دیده شود. با هم ترکیب‌کردن منابع، تصویر ریسک دقیق‌تر می‌شود؛ هیچ سندی به‌تنهایی کل وضعیت را پوشش نمی‌دهد.

چطور SBOM را در سازمان به‌کار بگیریم؟

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

برای نمونه، رکورد قراردادی «۱۱۵» در فهرست آزمایشی فقط شناسهٔ یک جزء است و دربارهٔ شمار آسیب‌پذیری یا کیفیت محصول چیزی نمی‌گوید. قبل از انتشار، فهرست را از نظر اجزای تکراری، نسخه‌های نامشخص و پیوند artifact بررسی کنید. SBOM ابزار شفافیت است؛ ارزشش از دادهٔ درست، اتصال به نسخهٔ دقیق و فرایند پاسخ‌گویی می‌آید.

در تمرین پاسخ به رخداد، شبیه‌سازی کنید که یک شناسهٔ بسته در advisory ظاهر شده است: چه کسی جست‌وجو می‌کند، چطور نسخه‌های تولیدی را جدا می‌کند و به چه ترتیبی وصله می‌دهد؟ سنجش زمان و جاافتادگی محصول از ساخت فهرست آزمایشی مفیدتر است. مسئولیت‌ها و مسیر اعلام به مشتری را از پیش روشن کنید تا هنگام رخداد دادهٔ SBOM به تصمیم عملی تبدیل شود.

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