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