یک هشدار درباره کدام فایل است؟
تصور کنید سامانه سفارش‌گیری یک شرکت در گزارشی که شب گذشته تولید شده، برای کتابخانه‌ای جاوا هشدار دریافت کرده است. مخزن برنامه در این مدت تغییر نکرده و تیم توسعه می‌خواهد بداند آیا باید انتشار صبح را متوقف کند. برای تصمیم، سه پرسش باید پاسخ داشته باشند. آیا فایل گزارش‌شده واقعاً در محصول عرضه‌شده وجود دارد؟ آیا هویت کتابخانه درست تشخیص داده شده است؟ آیا نسخه موجود در محدوده آسیب‌پذیر قرار می‌گیرد؟ OWASP Dependency-Check شواهد لازم برای شروع این بررسی را گرد می‌آورد و پیوند میان وابستگی‌ها و آسیب‌پذیری‌های عمومی را در گزارش نشان می‌دهد.
یک اسکن نمونه را از بسته نهایی برنامه آغاز کنید. اگر فایل قابل عرضه یک آرشیو است، همان نسخه آرشیو را همراه با شناسه ساخت در محیط آزمایش نگه دارید. سپس نتیجه را با فهرست وابستگی‌هایی که مدیر بسته هنگام ساخت انتخاب کرده مقایسه کنید. این دو نما به پرسش‌های متفاوتی پاسخ می‌دهند. ممکن است کتابخانه‌ای در گراف ساخت برای اجرای آزمون لازم باشد و در بسته عرضه‌شده حضور نداشته باشد. در مقابل، یک بسته بازتوزیع‌شده ممکن است کتابخانه‌ای را همراه داشته باشد که نامش در فایل وابستگی مستقیم برنامه دیده نمی‌شود.
از شواهد کتابخانه تا شناسه محصول
راهنمای رسمی، اطلاعات جمع‌آوری‌شده را در سه گروه فروشنده، محصول و نسخه توضیح می‌دهد. برای نمونه، تحلیلگر فایل جاوا از اطلاعات مانیفست، پرونده مشخصات Maven و نام بسته‌های داخل آرشیو سرنخ می‌گیرد. این شواهد کمک می‌کنند ابزار حدس بزند کدام محصول استاندارد با فایل روبه‌رو مطابقت دارد. اگر فایل فقط با نامی کوتاه و عمومی توزیع شده باشد، اتکا به نام فایل ممکن است گمراه‌کننده باشد. اطلاعات مستقل داخل آرشیو می‌تواند این ابهام را کاهش دهد. هنگام تحلیل هشدار به محل و منشأ هر شاهد نگاه کنید.
ابزار می‌کوشد مجموعه شواهد را به یک شناسه CPE وصل کند. داده آسیب‌پذیری برای این شناسه‌ها محدوده‌های آسیب‌پذیر معرفی می‌کند و گزارش، رکوردهای مرتبط را نمایش می‌دهد. درجه اعتماد شناسایی، کیفیت شواهد استفاده‌شده برای انتخاب محصول را بیان می‌کند. طبق توضیح پروژه، ضعیف‌ترین شاهدی که در شناسایی استفاده شده می‌تواند درجه اعتماد نهایی را محدود کند. این درجه با شدت پیامد امنیتی فرق دارد. ممکن است یک آسیب‌پذیری پیامد بسیار شدید داشته باشد ولی اطمینان به اینکه فایل شما همان محصول است پایین باشد. در چنین وضعی اول هویت فایل را روشن کنید.
برای نمونه، پس از نصب بسته رسمی خط فرمان در محیط لینوکس، پرونده‌های جاوای آزمایشی را در پوشه آزمایش قرار دهید و پوشه گزارش را از آن جدا نگه دارید. این فرمان مطابق الگوی مخزن رسمی، فایل‌های پوشه اول را بررسی می‌کند و گزارش را در پوشه دوم می‌نویسد. مسیرها را با محل بسته نصب‌شده و نمونه خود تطبیق دهید.
mkdir -p ./lab/reports
./bin/dependency-check.sh --scan ./lab/jars --out ./lab/reports
در گزارش، مسیر یک فایل را با محتوای واقعی پوشه مقایسه کنید. اگر تحلیلگر به دلیل نبود داده از کار افتاده، نتیجه را به عنوان اجرای کامل وارد پرونده نکنید. ثبت نسخه فایل و زمان اجرای این نمونه امکان مقایسه با تغییر بعدی پیکربندی را فراهم می‌کند.
آزمایش نتیجه مثبت و منفی
برای پذیرش اولیه، یک محصول نمونه با نسخه معلوم بسازید و نام سازنده، نسخه و محل فایل‌های آن را ثبت کنید. بهتر است از نمونه‌ای استفاده شود که اطلاعات رسمی کافی درباره وابستگی آن در دسترس باشد. نتیجه را با همان محصول واقعی مقایسه کنید. اگر ابزار کتابخانه را شناسایی کرد ولی نام سازنده نامرتبط بود، فرض نخست باید خطای شناسایی باشد. بررسی نسخه آسیب‌پذیر پیش از حل اشتباه هویت، زمان تیم را تلف می‌کند. ممکن است دو محصول مستقل نام کوتاه یکسان داشته باشند یا یک فایل داخلی از نام پروژه دیگری استفاده کرده باشد.
آزمایش منفی را نیز طراحی کنید. برای مثال، محصول سالمی که نام فایلش به کتابخانه آزمایشی شباهت دارد باید جداگانه بررسی شود. همین نمونه می‌تواند بعداً برای سنجش اصلاح قاعده یا تغییر نسخه ابزار به کار رود. اگر گزارش نمونه آسیب‌پذیر خالی است، ببینید فایل در دامنه اسکن قرار گرفته، تحلیلگر لازم فعال بوده و اطلاعات وابستگی از بسته حذف نشده است. نبود نتیجه، فقط با دانستن این شرایط معنا دارد. ذخیره چند ورودی کوچک با پاسخ مورد انتظار از دیدن تغییرات مهم در گزارش‌های بزرگ آسان‌تر است.
آماده‌سازی ایستگاه ساخت
پروژه فایل اجرایی خط فرمان و راه‌های اتصال به فرایندهای ساخت از جمله Maven و Gradle را معرفی کرده است. انتخاب مسیر به جایی بستگی دارد که محصول کامل و قابل شناسایی می‌شود. اگر چند پروژه زبان‌ها و ابزارهای ساخت متفاوت دارند، اجرای خط فرمان در مرحله تحویل بسته می‌تواند یک قرارداد مشترک ایجاد کند. اگر تحلیل باید اطلاعات وابستگی فرایند ساخت را نیز در اختیار داشته باشد، افزونه متناسب با همان فرایند ارزش بررسی دارد. برای هر انتخاب نسخه ابزار، محیط جاوا و ابزارهای کمکی لازم را ثبت کنید.
تحلیل برخی اکوسیستم‌ها به ابزارهای دیگری در میزبان نیاز دارد. مستندات پروژه برای نمونه به ابزارهای مدیریت بسته جاوااسکریپت، محیط اجرای دات‌نت و ابزار Go اشاره می‌کند. بنابراین موفقیت نصب فایل اصلی به تنهایی پوشش تمام زبان‌های سازمان را ثابت نمی‌کند. با تیم هر محصول یک نمونه نماینده بسازید و مطمئن شوید تحلیلگر مرتبط واقعاً اجرا می‌شود. اگر یک تحلیلگر به دلیل نبود وابستگی یا مجوز بیرونی غیرفعال شود، این محدودیت را در گزارش پوشش ثبت کنید. در محیط ساخت مشترک، محل نصب و نسخه ابزارهای کمکی نیز باید قابل بازتولید باشد.
به‌روزکردن داده بدون ازدحام درخواست
Dependency-Check برای دریافت بخش مهمی از داده آسیب‌پذیری به رابط NVD متکی است. پروژه به محدودیت نرخ و اهمیت راهبرد کش در خط ساخت اشاره می‌کند. تصور کنید همه شاخه‌های یک سازمان پس از شروع ساعت کاری هم‌زمان نخستین اسکن خود را اجرا کنند. اگر هر اجرای کوتاه‌عمر تمام اطلاعات را از ابتدا دریافت کند، هم زمان ساخت افزایش می‌یابد و هم درخواست‌های هم‌زمان می‌توانند به محدودیت سرویس برسند. یک مسئول مشخص برای تازه‌سازی داده و توزیع نسخه قابل استفاده تعیین کنید و تازگی این نسخه را برای مصرف‌کنندگان قابل مشاهده نگه دارید.
کلید دسترسی رابط داده را از مسیر مدیریت اسرار به فرایند مورد نیاز برسانید. مقدار آن نباید داخل پرونده تنظیمات عمومی یا خروجی فرمان ثبت شود. کلید مشترک میان چند کار هم‌زمان محدودیت نرخ را حذف نمی‌کند. اگر پاسخ ممنوع یا محدودیت دریافت ظاهر شد، دوره اجرا و تعداد مصرف‌کنندگان را بررسی کنید. پاک کردن همه داده‌های کش به عنوان نخستین اقدام ممکن است بار دریافت را بیشتر کند. ابتدا وضعیت نسخه ابزار، سازگاری قالب پایگاه و سلامت نسخه موجود را مشخص کنید و فقط در صورت نیاز بازسازی را انجام دهید.
بررسی گزارش با یک پرونده فرضی
فرض کنید گزارش به کتابخانه‌ای در پوشه توزیع برنامه اشاره می‌کند و نسخه اصلاح‌شده نیز در دسترس است. ابتدا شناسه ساخت و مسیر فایل را با محصولی که در تولید اجرا می‌شود تطبیق دهید. سپس پرونده مدیریت وابستگی و محتویات آرشیو را ببینید تا منشأ ورود کتابخانه مشخص شود. اگر وابستگی غیرمستقیم باشد، افزودن نسخه جدید به فهرست اصلی همیشه کافی نیست. مدیر بسته ممکن است در حل نهایی همچنان نسخه قدیمی را انتخاب کند. نتیجه تغییر را باید در بسته ساخته‌شده دوباره سنجید و تنها به متن تغییر در مخزن اکتفا نکرد.
در مرحله ارزیابی، اطلاعیه سازنده همان مؤلفه را بخوانید و شرایط اثر را مشخص کنید. ممکن است قابلیت آسیب‌پذیر فقط در پیکربندی مشخصی استفاده شود یا توزیع‌کننده اصلاحی را بدون تغییر کامل شماره نسخه بالادستی منتقل کرده باشد. اگر تیم تصمیم به تأخیر اصلاح می‌گیرد، علت و کنترل جبرانی را همراه با موعد بازبینی ثبت کند. اگر علت گزارش اشتباه در شناسایی محصول است، نمونه شواهد اشتباه را ثبت کنید. این دو پرونده به اقدام متفاوت نیاز دارند و نباید هر دو زیر یک برچسب عمومی «قابل چشم‌پوشی» پنهان شوند.
استثنا با دامنه روشن
پروژه سازوکاری برای کنار گذاشتن یافته‌های مشخص دارد. دلیل عملی استفاده از آن، جلوگیری از تکرار بررسی‌ای است که نتیجه‌اش با شواهد روشن ثبت شده است. دامنه استثنا را تا حد ممکن به وابستگی، شناسه و پرونده مشخص محدود کنید. فرض کنید یک فایل داخلی با نام کتابخانه مشهوری اشتباه گرفته شده است. حذف همه هشدارهای آن کتابخانه از تمام محصولات سازمان، هشدار واقعی یک سرویس دیگر را هم ناپدید می‌کند. استثنا باید پاسخ به همان اشتباه شناخته‌شده باشد و بتوان اثر آن را روی یک نمونه مثبت مستقل امتحان کرد.
پس از ساخت استثنا، گزارش پیش و پس از تغییر را مقایسه کنید. یافته مورد نظر باید حذف شده باشد و یافته‌های معتبر نمونه همچنان دیده شوند. مالک استثنا و دلیل آن را در روند بازبینی تیم نگه دارید. تغییر نام فایل، ارتقای ابزار یا بهتر شدن اطلاعات منتشرشده می‌تواند دلیل قبلی را از اعتبار بیندازد. در پروژه‌های بلندمدت، مرور دوره‌ای استثناها هزینه کمی در مقایسه با خطر پنهان ماندن یک وابستگی حساس دارد. نتیجه این مرور می‌تواند حذف استثنا یا محدودتر کردن آن باشد.
معنی شکست در خط انتشار
خط ساخت ممکن است به علت یافته امنیتی، خطای دریافت داده یا شکست پردازش فایل متوقف شود. پیام کاربر باید این سه حالت را از هم جدا کند. در حالت اول توسعه‌دهنده به نام وابستگی و راه اصلاح نیاز دارد. در حالت دوم مسئول زیرساخت دریافت داده باید وارد شود. در حالت سوم باید ورودی و پشتیبانی تحلیلگر بررسی شود. اگر همه شکست‌ها با یک پیام مبهم نمایش داده شوند، معمولاً افراد به دنبال خاموش کردن کنترل می‌روند. گزارش کوتاه و قابل پیگیری از یک خروجی طولانی بدون محل اقدام مفیدتر است.
پیش از اجباری کردن آستانه انتشار، چند اجرای واقعی را ارزیابی کنید. تعداد یافته‌ها، کیفیت شناسایی، زمان تازه‌سازی داده و زمان بررسی انسانی را اندازه بگیرید. برای سیستم قدیمی می‌توان بدهی موجود را با مالک و موعد ثبت کرد و ورود موارد تازه را زیر کنترل روشن‌تری گذاشت. آستانه باید با شرایط محصول هماهنگ باشد. یک کتابخانه در مسیر عمومی پرداخت با همان کتابخانه در برنامه آفلاین آموزشی زمینه متفاوتی دارد، هرچند داده آسیب‌پذیری هر دو یکسان باشد. این زمینه در تصمیم تیم ثبت می‌شود و از خود عدد شدت به دست نمی‌آید.
تأیید اصلاح تا محیط اجرا
پس از تغییر وابستگی، فرایند ساخت را از ابتدا اجرا کنید و آرشیو تازه را دوباره بسنجید. نتیجه باید نشان دهد فایل قبلی حذف شده یا نسخه اصلاح‌شده واقعاً انتخاب شده است. سپس هویت همان آرشیو را با نسخه مستقر مقایسه کنید. اگر استقرار عقب مانده باشد، گزارش پاک ساخت تازه هنوز وضعیت سرویس در حال اجرا را بیان نمی‌کند. در پرونده اصلاح، پیوند گزارش، شناسه ساخت و زمان تحویل را کنار یکدیگر نگه دارید تا تیم عملیات بتواند تغییر را مستقل از تیم توسعه تأیید کند.
یک شاخص مناسب، مدت میان انتشار اطلاعیه و یافتن محصولات دارای وابستگی مرتبط است. شاخص دیگر، سهم یافته‌هایی است که هویت بسته، مالک و نتیجه بررسی مشخص دارند. این اعداد به تیم کمک می‌کنند بفهمد مشکل اصلی دریافت داده، کیفیت شناسایی، انتخاب وابستگی یا تحویل نسخه اصلاح‌شده است. با این روش، گزارش Dependency-Check در هر انتشار به شواهد قابل پیگیری تبدیل می‌شود و مهندس مسئول می‌تواند توضیح دهد کدام فایل را بررسی کرده، چرا به نتیجه اعتماد دارد و اصلاح چگونه به محصول واقعی رسیده است.
