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