اسکن چه چیزی را می‌بیند؟
Trivy می‌تواند تصویر کانتینر و بسته‌های شناسایی‌شده در آن را بررسی کند. محدوده اسکن، نوع یافته‌ها و گزارش خروجی به گزینه‌ها و داده‌های مرجع ابزار وابسته‌اند. خواندن فهرست آسیب‌پذیری با تشخیص وقوع بهره‌برداری در محیط شما یک کار واحد نیست.
نام یک Tag ممکن است در طول زمان به تصویر متفاوت اشاره کند؛ بنابراین ثبت شناسه محتوایی تصویر برای مقایسه نتیجه اهمیت دارد. همچنین سیاست شکست کار CI باید صریح باشد. چاپ گزارش به‌تنهایی تضمین نمی‌کند مرحله انتشار متوقف شود؛ رفتار خروجی فرایند و قواعد خط لوله باید بررسی شوند.
تمرین پیشنهادی تحریریه
دو تصویر آزمایشی با نسخه‌های مشخص بسازید و برای هرکدام زمان اسکن، نسخه ابزار، شناسه تصویر و وضعیت داده مرجع را نگه دارید. سپس یک وابستگی را تغییر دهید و گزارش تازه را با گزارش قبلی مقایسه کنید.
در مرحله بعد، یک سیاست فرضی برای پذیرش تعریف کنید: کدام یافته باید مانع انتشار شود، چه استثنایی مجاز است و استثنا چه زمانی منقضی می‌شود؟ این سیاست را با یک مورد شناخته‌شده آزمایش کنید تا مطمئن شوید خط لوله واقعاً در نقطه موردنظر متوقف می‌شود. اسکن موفق از نظر اجرای ابزار، الزاماً به معنی پذیرش تصویر نیست.
استثنا باید صاحب و پایان داشته باشد
پیشنهاد ما این است که برای هر استثنا، شناسه یافته، دامنه تصویر، مسئول تصمیم و تاریخ بازبینی ثبت شود. یک استثنای کلی و دائمی می‌تواند مسئله را از دید تیم خارج کند. اگر اصلاحی موجود نیست، مسیر کاهش مواجهه را جدا بررسی کنید؛ حذف هشدار، مشکل نرم‌افزار را برطرف نمی‌کند.
برای تصاویر چندمرحله‌ای، مشخص کنید کدام خروجی واقعاً منتشر می‌شود. گزارش روی مرحله ساخت، جای بررسی تصویر نهایی را نمی‌گیرد. همچنین فایل‌های حساس، تنظیمات و مجوزهای زمان اجرا را در فرایند ارزیابی جداگانه ببینید.
گزارش قابل بازتولید
در یک سامانه فرضی انتشار، نتیجه اسکن را به همان نسخه‌ای پیوند دهید که کاربر دریافت می‌کند. تغییر تصویر پس از آزمون، زنجیره شواهد را قطع می‌کند. پیشنهاد تحریریه، نگه‌داشتن گزارش، شناسه تصویر و تصمیم پذیرش در کنار سابقه انتشار است.
در نهایت، گزارش خالی را با نبود تمام انواع ریسک برابر ندانید. اسکن وابستگی یکی از لایه‌های ارزیابی است و جای آزمون برنامه، بررسی کنترل دسترسی، محافظت از اسرار یا پایش محیط عملیاتی را نمی‌گیرد.
چیزی را اسکن کنید که واقعاً منتشر می‌شود
در خط ساخت تصویر، نام tag می‌تواند در زمان‌های مختلف به محتوای متفاوت اشاره کند. بنابراین گزارش باید با digest تصویر پیوند داشته باشد. اگر ابتدا tag را اسکن و بعد تصویر دیگری با همان tag منتشر کنید، گزارش دیگر درباره artifact مستقرشده نیست. ترتیب مناسب این است که تصویر ساخته شود، شناسه محتوای آن مشخص گردد و همان artifact بررسی و منتشر شود. نگه داشتن commit کد، digest، زمان اسکن و نسخه ابزار امکان بازسازی تصمیم را فراهم می‌کند.
در تصویر چندمعماری، خروجی هر معماری ممکن است بسته‌های متفاوت داشته باشد. اسکن یک معماری به تنهایی وضعیت همه variantها را ثابت نمی‌کند. معماری و سیستم‌عامل هدف را در گزارش روشن کنید و variantهای واقعاً استفاده‌شده را پوشش دهید. همچنین تصویر نهایی را با مرحله builder اشتباه نگیرید. ابزارهای ساختی که در مرحله میانی باقی مانده‌اند ممکن است در runtime حضور نداشته باشند، در حالی که یک کتابخانه کپی‌شده به تصویر نهایی باید بررسی شود.
یافته آسیب‌پذیری چه معنایی دارد؟
اسکنر موجودی قابل تشخیص بسته‌ها را با اطلاعات آسیب‌پذیری تطبیق می‌دهد. نتیجه معمولاً می‌گوید یک بسته و نسخه با یک شناسه آسیب‌پذیری مرتبط است؛ این به تنهایی اجرای موفق حمله را ثابت نمی‌کند. از طرف دیگر، نبود یافته تضمین نبود ضعف نیست. بسته ناشناخته، فایل بدون metadata، پایگاه داده قدیمی یا نوع هدف پشتیبانی‌نشده می‌توانند پوشش را محدود کنند. گزارش باید این محدودیت‌ها را کنار نتیجه بیان کند تا عدد صفر به اشتباه گواهی امنیت تلقی نشود.
برای هر یافته، نام بسته، نسخه نصب‌شده، نسخه اصلاح‌شده در صورت وجود، منبع شدت و مسیر حضور را بررسی کنید. توزیع‌های سیستم‌عامل ممکن است اصلاح را به نسخه بسته خود backport کنند؛ مقایسه ساده شماره upstream همیشه نتیجه درست نمی‌دهد. اطلاعات فروشنده توزیع برای بسته‌های همان توزیع اهمیت دارد. وقتی دو منبع شدت متفاوت می‌دهند، علت تفاوت را ثبت کنید و سیاست انتخاب منبع داشته باشید. انتخاب دلخواه عدد کم‌تر برای عبور از دروازه، تصمیم فنی قابل دفاعی نیست.
طراحی دروازه CI
سیاست باید مشخص کند چه یافته‌ای انتشار را متوقف می‌کند. شدت، وجود اصلاح، دسترسی‌پذیری مؤلفه و حساسیت سرویس می‌توانند در تصمیم دخالت داشته باشند. یک قاعده ساده و قابل توضیح بهتر از مجموعه استثناهای نامعلوم است. در شروع می‌توان گزارش‌گیری را از مسدودسازی جدا کرد تا موجودی مشکلات روشن شود، اما این مرحله باید پایان و مسئول داشته باشد. اگر همه اجراها برای همیشه فقط هشدار بدهند، خط ساخت هیچ الزام اصلاحی ایجاد نکرده است.
کد خروج ابزار را با وجود یافته اشتباه نگیرید. تنظیمات اسکن و سیاست تعیین می‌کنند چه نتیجه‌ای باعث شکست مرحله شود. خطای دریافت پایگاه داده یا دسترسی به registry باید از نتیجه «اسکن انجام شد و یافته داشت» جدا گزارش شود. در غیر این صورت، یک خرابی زیرساختی ممکن است به اشتباه تصویر پاک یا تصویر آسیب‌پذیر تفسیر شود. برای هر سه حالت سالم، یافته سیاست‌نقض‌کننده و خطای خود اسکن، آزمون CI داشته باشید.
استثنا باید قابل انقضا باشد
گاهی اصلاح فوری ممکن نیست یا یافته پس از بررسی در سناریوی مشخص اثر ندارد. در این حالت، استثنا باید شناسه، بسته، دلیل فنی، مالک و تاریخ بازبینی داشته باشد. نادیده گرفتن همه یافته‌های یک شدت یا همه نسخه‌های یک بسته دامنه‌ای بسیار بزرگ می‌سازد. اگر نسخه تصویر عوض شد، اعتبار استثنای قبلی را دوباره بررسی کنید. توضیح «فعلاً لازم نیست» به همکار بعدی نمی‌گوید کدام فرض امنیتی پشت تصمیم بوده است.
برای موارد مربوط به قابل بهره‌برداری نبودن، شواهد باید دقیق باشند: مسیر آسیب‌پذیر واقعاً فراخوانی نمی‌شود، قابلیت لازم غیرفعال است یا کنترل مشخصی دسترسی را محدود می‌کند. این ادعاها باید قابل آزمون و بازبینی باشند. وجود یک firewall به تنهایی همه آسیب‌پذیری‌های کتابخانه را بی‌اثر نمی‌کند. همچنین استثنای موقت جایگزین ارتقای برنامه نیست؛ باید زمان و مسئول رفع نهایی معلوم باشد تا بدهی امنیتی در فهرست پنهان نماند.
تازگی داده و اجرای تکرارپذیر
پایگاه داده آسیب‌پذیری با گذر زمان تغییر می‌کند؛ بنابراین همان تصویر ممکن است امروز یافته‌ای داشته باشد که روز ساخت شناخته نشده بود. اسکن هنگام build کافی نیست و تصاویر مستقر یا نگهداری‌شده باید دوباره ارزیابی شوند. در گزارش جدید، تغییر نتیجه را به تغییر تصویر یا تغییر دانش اسکنر نسبت دهید. اگر digest یکسان است ولی یافته تازه آمده، بازسازی بی‌هدف تصویر بدون ارتقای بسته الزاماً مشکل را حل نمی‌کند.
Cache به کاهش زمان و مصرف شبکه کمک می‌کند، اما سیاست تازگی آن باید روشن باشد. محیط جدا از اینترنت نیازمند روش کنترل‌شده انتقال و به‌روزرسانی داده است. صرف فعال کردن حالت آفلاین با داده قدیمی، نتیجه قابل اتکا نمی‌سازد. زمان آخرین به‌روزرسانی و وضعیت دریافت را ثبت کنید. در خط ساخت حساس، باید معلوم باشد هنگام ناتوانی در دریافت داده تازه چه تصمیمی گرفته می‌شود و چه کسی می‌تواند استثنا را تأیید کند.
اسرار و پیکربندی را جدا تحلیل کنید
Trivy قابلیت‌هایی فراتر از بررسی آسیب‌پذیری بسته دارد، ولی فعال بودن هر اسکنر و دامنه آن باید صریح باشد. یافته secret با یافته نسخه آسیب‌پذیر اقدام یکسان ندارد. اگر اعتبارنامه واقعی داخل تصویر پیدا شد، حذف فایل از نسخه بعدی کافی نیست؛ اعتبارنامه باید تعویض یا باطل شود و محل استفاده آن بررسی گردد. لایه‌های قبلی تصویر و نسخه‌های منتشرشده ممکن است هنوز آن را نگه داشته باشند. گزارش خام secret نیز نباید دوباره در artifact عمومی منتشر شود.
بررسی misconfiguration تصویر با بررسی runtime متفاوت است. کاربر پیش‌فرض، تنظیمات تصویر و فایل‌ها بخشی از داستان‌اند، اما مجوزهای کانتینر، mountها و سیاست شبکه در محیط اجرا تعیین می‌شوند. نتیجه اسکن تصویر را گواهی پیکربندی Kubernetes معرفی نکنید. برای تصمیم کامل، یافته‌ها باید با manifest و محیط استقرار مرتبط شوند. تفکیک این دو سطح جلوی این تصور را می‌گیرد که یک ابزار روی یک artifact تمام لایه‌های امنیت را پوشش داده است.
گزارش برای توسعه‌دهنده و ممیز
توسعه‌دهنده به اطلاعات قابل اقدام نیاز دارد: کدام dependency مستقیم یا غیرمستقیم مشکل دارد، ارتقا از چه مسیر انجام می‌شود و چه آزمونی باید بعد از آن تکرار شود. ممیز به سابقه تصمیم نیاز دارد: چه چیزی، چه زمانی و با کدام سیاست پذیرفته شده است. یک خروجی ساختاریافته می‌تواند برای نگهداری و پردازش مناسب باشد، در حالی که خلاصه انسانی باید چند یافته اولویت‌دار را روشن کند. صدها خط تکراری بدون گروه‌بندی، احتمال نادیده گرفتن مسئله مهم را بالا می‌برد.
تمرین یک چرخه اصلاح کامل
یک تصویر آزمایشی با dependency مشخص انتخاب کنید، اسکن را اجرا و گزارش را نگه دارید. سپس نسخه dependency را طبق مسیر پشتیبانی‌شده ارتقا دهید، تصویر تازه بسازید و همان سیاست را اجرا کنید. کاهش یافته باید با تغییر بسته مرتبط باشد، نه با خاموش شدن اسکنر یا افزودن ignore گسترده. آزمون کاربردی برنامه را نیز اجرا کنید؛ اصلاح امنیتی که برنامه را از کار بیندازد نیازمند مدیریت انتشار است. این تمرین نشان می‌دهد اسکن آغاز یک چرخه تصمیم و اصلاح است، نه پایان آن.
دسترسی اسکنر به registry
حساب اسکنر معمولاً فقط به خواندن تصویرهای لازم نیاز دارد. استفاده از اعتبارنامه مدیر registry برای راحتی، دامنه اثر افشای CI را بزرگ می‌کند. توکن را با زمان و سطح دسترسی مناسب صادر کنید و در خروجی خط فرمان یا گزارش چاپ نکنید. اگر اسکنر به socket موتور کانتینر دسترسی دارد، قدرت آن دسترسی را نیز در مدل تهدید runner حساب کنید. runner مشترک با کارهای نامطمئن محیط مناسبی برای اعتبارنامه حساس نیست. خطای احراز هویت registry باید به عنوان خطای اسکن شناخته شود و نباید با تصویر بدون یافته اشتباه گردد. این کنترل‌ها خود گزارش آسیب‌پذیری را تغییر نمی‌دهند، اما از مسیری که گزارش تولید می‌کند حفاظت می‌کنند.
