Syft؛ موجودی نرم‌افزار پیش از قضاوت امنیتی
Syft ابزاری برای ساخت صورت مواد نرم‌افزار یا SBOM است. این صورت مواد نشان می‌دهد در یک خروجی نرم‌افزاری چه بسته‌ها و اجزایی شناسایی شده‌اند. اگر فردا آسیب‌پذیری مهمی برای یک کتابخانه اعلام شود، سازمان بدون موجودی باید دوباره در میان مخازن، ایمیج‌ها و سرورها جست‌وجو کند. موجودی مناسب کمک می‌کند دامنه احتمالی اثر سریع‌تر پیدا شود. با این حال خود Syft حکم نمی‌دهد که یک جزء قابل بهره‌برداری است یا محصول امن است؛ کار اصلی آن تولید شواهد ساختاریافته درباره اجزای موجود در ورودی بررسی‌شده است.
مخزن رسمی Syft این پروژه را به عنوان ابزار خط فرمان و کتابخانه گو معرفی می‌کند. ورودی می‌تواند ایمیج کانتینر، فایل‌سیستم، آرشیو و انواع دیگری از خروجی نرم‌افزار باشد. قالب‌های خروجی شامل قالب بومی Syft و استانداردهایی مانند SPDX و CycloneDX هستند. برای تصمیم دقیق درباره پوشش زبان، نوع بسته یا قالب ورودی باید به راهنمای رسمی و قابلیت‌های نسخه انتخاب‌شده مراجعه کرد. نام یک زبان در فهرست پشتیبانی به معنی شناسایی بی‌نقص هر روش بسته‌بندی آن زبان نیست.
تفاوت فهرست وابستگی با محصول نهایی
فایل وابستگی در مخزن قصد سازنده را نشان می‌دهد، اما محصول نهایی ممکن است اجزای بیشتری یا کمتری داشته باشد. در ساخت چندمرحله‌ای، بعضی ابزارهای توسعه وارد ایمیج نهایی نمی‌شوند. از طرف دیگر کتابخانه‌های سیستم‌عامل، فایل‌های کپی‌شده دستی و وابستگی‌های گذرا ممکن است در فهرست اولیه برنامه واضح نباشند. بررسی خروجی نهایی کمک می‌کند این فاصله دیده شود. پیشنهاد عملی آن است که موجودی مرتبط با انتشار از همان بایتی تولید شود که قرار است تحویل مشتری یا محیط تولید شود، نه از پوشه‌ای مشابه روی دستگاه توسعه‌دهنده.
این توصیه مانع بررسی کد منبع نیست. موجودی مرحله توسعه برای کشف زودهنگام تغییر وابستگی‌ها مفید است و موجودی محصول نهایی برای شناخت آنچه واقعاً منتشر شده اهمیت دارد. این دو سند باید برچسب روشن داشته باشند. اگر یک تیم موجودی منبع را به عنوان موجودی ایمیج منتشر کند، ممکن است بسته‌ای که فقط برای آزمون استفاده شده وارد تحلیل ریسک شود یا جزء سیستم‌عامل از قلم بیفتد. کیفیت داده بیش از تعداد ردیف‌ها به درستی نسبت دادن آن به مرحله ساخت، ورودی و هدف استفاده وابسته است.
اتصال موجودی به هویت تغییرناپذیر
برچسب ایمیج مانند latest ممکن است بعداً به محتوای دیگری اشاره کند. برای نگهداری شواهد انتشار، شناسه محتوایی یا digest مناسب‌تر است. در فرایند پیشنهادی، پس از ساخت و پیش از ارتقای خروجی به محیط تولید، شناسه دقیق ثبت شود و Syft همان خروجی را بررسی کند. فایل موجودی همراه نسخه ابزار، زمان اجرا و تنظیمات نگهداری شود. وقتی یک رخداد بعدی بررسی می‌شود، این اطلاعات اجازه می‌دهد بدانیم سند به کدام محصول مربوط بوده و آیا اختلاف نتیجه ناشی از تغییر محصول است یا تغییر روش شناسایی.
این اتصال باید تا سامانه استقرار ادامه یابد. داشتن موجودی برای یک ایمیج کافی نیست اگر معلوم نباشد کدام سرویس و محیط از آن استفاده می‌کند. یک نگاشت میان شناسه خروجی، نام سرویس، محیط و مالک عملیاتی لازم است. چنین نگاشتی وظیفه خود Syft نیست، اما ارزش خروجی آن را چند برابر می‌کند. در تمرین پاسخ، یک بسته فرضی را انتخاب کنید و از تیم بخواهید انتشارهای حاوی آن و محیط‌های فعال را پیدا کند. اگر این کار به جست‌وجوی دستی طولانی نیاز دارد، هنوز زنجیره اطلاعات کامل نشده است.
انتخاب قالب خروجی
قالب بومی ابزار برای حفظ جزئیات شناسایی در جریان کاری همان اکوسیستم مفید است. استانداردهای تبادل برای تحویل به مشتری، اتصال به سامانه دیگر یا نگهداری مستقل از یک محصول ارزش دارند. انتخاب قالب باید بر اساس مصرف‌کننده صورت گیرد. بهتر است پیش از تولید انبوه، یک سند واقعی به سامانه مقصد داده شود و سازگاری فیلدها، نسخه استاندارد و شناسه بسته‌ها آزموده شود. اینکه دو ابزار هر دو نام CycloneDX را ذکر می‌کنند تضمین نمی‌کند تمام جزئیات مورد نیاز شما را به یک شکل تفسیر کنند.
تبدیل قالب نیز باید با ارزیابی همراه باشد. بعضی اطلاعات ممکن است در مقصد معادل مستقیم نداشته باشند یا با ساختار متفاوت نمایش داده شوند. اگر خروجی برای بررسی آسیب‌پذیری استفاده می‌شود، نام، نسخه، نوع بسته، شناسه‌های استاندارد و زمینه سیستم‌عامل اهمیت دارند. اگر برای مدیریت مجوز مصرف می‌شود، کیفیت اطلاعات مجوز باید جداگانه بررسی شود. یک فایل قابل باز شدن لزوماً سند کافی برای هر دو هدف نیست. پیشنهاد می‌شود چند جزء شناخته‌شده از محصول انتخاب و حضور درست اطلاعات مهم آنها در قالب نهایی به صورت دستی کنترل شود.
لایه‌های ایمیج و دامنه بررسی
کانتینر از لایه‌ها تشکیل می‌شود و فایل حذف‌شده از نمای نهایی ممکن است در یک لایه پیشین باقی مانده باشد. بسته به هدف بررسی، دیدن نمای نهایی یا همه لایه‌ها پاسخ متفاوتی می‌دهد. برای موجودی آنچه برنامه هنگام اجرا می‌بیند، نمای نهایی اهمیت دارد. برای تحلیل داده باقی‌مانده در تاریخچه ساخت، لایه‌ها نیز مهم هستند. تنظیم دامنه باید آگاهانه انجام شود و در گزارش نوشته شود. مقایسه دو موجودی با دامنه متفاوت می‌تواند اختلاف بزرگی بسازد که به اشتباه تغییر وابستگی تعبیر شود.
همچنین معماری محصول را ثبت کنید. یک برچسب چندمعماری می‌تواند به خروجی‌های جدا برای پردازنده‌های مختلف اشاره کند و محتوای آنها الزاماً یکسان نیست. اگر فقط یکی از معماری‌ها بررسی شود، نباید نتیجه به همه انتشارها تعمیم داده شود. برای هر خروجی قابل استقرار، موجودی مناسب همان شناسه تولید کنید. این نکته در محصولاتی که کتابخانه بومی یا بسته سیستم‌عامل متفاوت دارند مهم‌تر می‌شود. هدف، تولید سند بیشتر برای بایگانی نیست؛ هدف جلوگیری از پاسخ اشتباه به این سؤال است که «کدام نسخه واقعاً این جزء را دارد؟».
کیفیت شناسایی و نقاط کور
ابزارهای موجودی از شواهدی مانند پایگاه بسته، فایل‌های فراداده و ساختارهای شناخته‌شده استفاده می‌کنند. اگر یک کتابخانه به صورت دستی تغییر نام داده شود، اطلاعات نسخه حذف شود یا کد آن در یک فایل بزرگ ادغام شود، شناسایی ممکن است ناقص شود. خروجی خالی برای یک نوع بسته باید با شناخت فرایند ساخت تطبیق داده شود. تیم توسعه می‌تواند توضیح دهد کدام اجزا ایستا پیوند داده شده‌اند یا از منبع داخلی آمده‌اند. این همکاری برای تشخیص نقاط کور ضروری است؛ هیچ شمارنده بسته‌ای به تنهایی کامل بودن موجودی را ثابت نمی‌کند.
برای سنجش کیفیت، یک مجموعه کوچک از محصولات نماینده بسازید. محصولی با وابستگی زبان، محصولی با بسته‌های سیستم‌عامل و محصولی با کتابخانه بومی انتخاب‌های مفیدی هستند. برای هر کدام چند جزء را از مسیر مستقل بشناسید و با خروجی Syft مقایسه کنید. اختلاف‌ها را طبقه‌بندی کنید: نبود جزء، نام متفاوت، نسخه نامعلوم یا رابطه ناقص. سپس بررسی کنید مشکل از ورودی، تنظیمات یا محدودیت شناسایی است. این روش به تیم امکان می‌دهد پوشش را به زبان قابل دفاع توضیح دهد و از وعده «فهرست کامل همه چیز» فاصله بگیرد.
اجرای امن در خط ساخت
برای نصب از انتشارهای رسمی و روش‌های مستند پروژه استفاده کنید. نسخه ابزار و پیکربندی را در تعریف خط ساخت ثابت نگه دارید تا نتیجه قابل مقایسه باشد. دسترسی اسکنر به رجیستری باید فقط به مخازن لازم محدود شود. قرار دادن سوکت موتور کانتینر در اختیار یک مرحله ساخت می‌تواند سطح دسترسی بالایی ایجاد کند؛ روش دریافت مستقیم یا بررسی آرشیو را نیز متناسب با محیط ارزیابی کنید. انتخاب مسیر ورودی صرفاً مسئله راحتی نیست و بر مرز اعتماد همان مرحله اثر می‌گذارد.
شکست تولید موجودی باید جدا از موجودی بدون بسته دیده شود. اگر دریافت ایمیج ناموفق بوده، فایل خروجی ناقص است یا ابزار با خطا خاتمه یافته، انتشار نباید به طور خودکار سند خالی را به عنوان موفقیت بپذیرد. یک کنترل ساده می‌تواند ساختار سند، شناسه ورودی و حضور اجزای مورد انتظار را بررسی کند. با این حال نباید یک تعداد ثابت بسته برای همه محصولات شرط شود؛ محصول کوچک و محصول بزرگ ماهیت متفاوتی دارند. معیارها باید با نوع محصول و تغییرات مشروع آن سازگار باشند و خطای واقعی را از تغییر طبیعی جدا کنند.
مصرف موجودی برای امنیت و خرید
یکی از مسیرهای رایج، دادن خروجی Syft به اسکنری مانند Grype برای تطبیق با اطلاعات آسیب‌پذیری است. مزیت این جداسازی آن است که می‌توان موجودی یک انتشار ثابت را با داده امنیتی تازه دوباره ارزیابی کرد، بدون دریافت دوباره کل محصول. البته اگر موجودی اولیه ناقص بوده، ارزیابی بعدی هم همان نقص را به ارث می‌برد. زمان تولید موجودی و زمان تحلیل آسیب‌پذیری باید جدا ثبت شوند. این دو تاریخ پاسخ دو سؤال متفاوت هستند و ترکیب آنها می‌تواند باعث سوءبرداشت از تازگی داده شود.
در خرید نرم‌افزار، دریافت SBOM از تأمین‌کننده نقطه شروع گفت‌وگو است. باید پرسید سند به کدام نسخه و معماری مربوط است، چگونه تولید شده و چگونه به خروجی تحویلی متصل می‌شود. وجود قالب استاندارد به تنهایی اصالت یا کامل بودن ادعا را اثبات نمی‌کند. در صورت نیاز، امضا و شواهد فرایند ساخت می‌توانند به این اتصال کمک کنند. همچنین اطلاعات موجودی ممکن است معماری داخلی یا نام اجزای اختصاصی را آشکار کند؛ سیاست اشتراک‌گذاری باید میان نیاز مشتری و اطلاعات حساس محصول تعادل برقرار کند و از انتشار بی‌دلیل جزئیات جلوگیری کند.
نگهداری و استفاده در رخداد
موجودی‌ها را با سیاست نگهداری متناسب با عمر پشتیبانی محصول ذخیره کنید. اگر نسخه‌ای هنوز نزد مشتری فعال است، حذف سند آن صرفاً به دلیل پایان یک دوره کوتاه بایگانی می‌تواند پاسخ آینده را دشوار کند. نام فایل و مسیر ذخیره باید از شناسه انتشار قابل بازیابی باشد. تغییرهای بزرگ در نسخه Syft را ابتدا روی چند نمونه آزمایش کنید و اختلاف موجودی را بخوانید. افزایش یا کاهش ناگهانی شمار بسته‌ها ممکن است حاصل بهبود شناسایی یا تغییر پیکربندی باشد و پیش از ورود به گزارش مدیریتی نیاز به توضیح دارد.
Syft برای ساخت یک پایه اطلاعاتی درباره اجزای نرم‌افزار مناسب است؛ موفقیت آن در سازمان با توان پاسخ سریع و دقیق به سؤال‌های واقعی سنجیده می‌شود. آیا می‌توان نسخه‌های دارای یک کتابخانه را پیدا کرد، مالک آنها را شناخت و سند را به خروجی مستقر وصل کرد؟ آیا نقاط کور شناخته‌شده ثبت شده‌اند؟ اگر پاسخ مثبت باشد، موجودی از یک فایل تشریفاتی به ابزار تصمیم تبدیل شده است. سپس می‌توان تحلیل آسیب‌پذیری، بررسی مجوز و کنترل زنجیره تأمین را بر همین پایه بنا کرد، با آگاهی روشن از دامنه و محدودیت شواهد موجود.
