ارزش یک تست نفوذ به اندازهی گزارش آن است. خودِ تست چند روز طول میکشد؛ اما گزارش همان چیزی است که تیم فنی ماهها با آن کار میکند، ممیز آن را میخواند و مدیریت بر اساس آن تصمیم میگیرد که هزینه درست خرج شده یا نه. با این حال بیشتر گزارشهایی که برای بازبینی به ما میرسند یکی از دو مشکل را دارند: یا خروجی خام اسکنر با یک صفحهی جلد هستند، یا روایتی آنقدر محافظهکارانه که هیچکس نمیفهمد اول باید چه چیزی را درست کند.
این ساختاری است که گزارشهای خودمان را با آن میسنجیم و پیشنهاد میکنیم آن را در درخواست پیشنهاد (RFP) بعدیتان بنویسید.
۱. محدودهی واقعاً آزمونشده، نه محدودهی برنامهریزیشده
صفحهی اول باید دقیقاً بگوید چه چیزی در محدوده بوده و چه چیزی واقعاً آزمون شده است: نام دامنهها، بازههای IP، نسخهی برنامهها، نقشهای کاربری، محیطها (عملیاتی، آزمایشی، نسخهی کپی) و تاریخها. اگر سامانهای در محدوده بوده ولی امکان آزمون آن فراهم نشده — سرویس از دسترس خارج بوده، اطلاعات ورود نرسیده، یا WAF آزمونگر را مسدود کرده و تنظیم نشده — گزارش باید صریحاً بنویسد. در غیر این صورت «نتیجهی پاک» برای آن سامانه یک اطمینان کاذب است.
آنچه باید بخواهید: فهرست داراییهای آزمونشده با تاریخ آزمون هر یک، و فهرست استثناها با دلیل.
۲. روششناسی و استاندارد
روششناسی را نام ببرید و به آن پایبند بمانید. برای برنامههای وب معمولاً راهنمای OWASP WSTG و برای عمق بیشتر استاندارد ASVS؛ برای APIها فهرست OWASP API Security Top 10 و همان فصلهای ASVS؛ برای زیرساخت، PTES یا مراحل NIST 800-115. ارزش این کار در خودِ نام اختصاری نیست؛ در این است که یک چکلیست نامدار به خواننده اجازه میدهد ببیند چه چیزی پیدا نشده، نه فقط چه چیزی پیدا شده.
یک جدول کوتاه که بخشهای استاندارد را به «آزمونشده / بیربط / خارج از محدوده» نگاشت کند، تنها صفحهای است که بیشتر گزارشها کم دارند و بیشترین فایده را دارد.
۳. خلاصهی مدیریتی که یک مدیر بتواند بر اساس آن اقدام کند
یک صفحه. چه چیزی آزمون شد، ریسک کلی در یک جمله، تعداد یافتهها به تفکیک شدت، و دو یا سه کاری که باید همین فصل انجام شود. بدون اسکرینشات، بدون payload. اگر خواننده همینجا متوقف شود، باید بداند نگران باشد یا نه و به چه کسی زنگ بزند.
۴. یافتهها، هر کدام در یک صفحه و با قالب ثابت
هر یافته باید همان فیلدها را با همان ترتیب داشته باشد تا صد یافته را بتوان در یک بعدازظهر اولویتبندی کرد:
| فیلد | باید شامل چه باشد |
|---|---|
| عنوان | خودِ ضعف، نه هشدار ابزار («جستوجوی سفارش، سفارشهای مشتریان دیگر را نشان میدهد»، نه «IDOR پیدا شد») |
| شدت | یک درجه و دلیل آن، با یک طرح منتشرشده (امتیاز پایهی CVSS v4 همراه با رشتهی بردار، یا رتبهبندی ریسک OWASP) |
| داراییهای متأثر | نشانیها، پارامترها، میزبانها و نسخههای دقیق؛ آنقدر که بدون پرسیدن بتوان بازتولید کرد |
| بازتولید | گام به گام، همراه با درخواست و پاسخ، و پنهانسازی فقط در جای لازم |
| اثر | مهاجم واقعاً چه به دست میآورد: کدام داده، کدام حساب، کدام سامانه — با ادبیات کسبوکار مشتری |
| علت ریشهای | کنترل غایب، نه نشانه («مجوزدهی فقط سمت کلاینت بررسی میشود») |
| رفع | یک اصلاح مشخص و در صورت لزوم یک اقدام موقت؛ پیوند به استاندارد، نه پاراگرافی که از آن کپی شده |
| شواهد | اسکرینشات یا ثبت ترافیکی که یافته را روی همان سامانهی آزمونشده اثبات کند |
دو چیز گزارش قابل اقدام را از گزارش غیرقابل اقدام جدا میکند. نخست، شدت باید استدلال شود، نه اعلام: «بالا» بدون بردار هیچ معنایی ندارد. دوم، علت ریشهای باید نام برده شود: پنج یافته با یک علت مشترک، یک اصلاح هستند و گزارش باید این را بگوید.
۵. زنجیرهها و اثر بر کسبوکار
یافتههای منفرد وقتی با هم ترکیب میشوند ریسک را کمتر از واقع نشان میدهند. یک افشای اطلاعات با شدت پایین بهعلاوهی یک نقص کنترل دسترسی با شدت متوسط میتواند برابر با تصاحب کامل حساب باشد. گزارش خوب دستکم یک زنجیرهی حمله را به شکل داستان روایت میکند: آزمونگر از کجا شروع کرد، هر گام چه به دست داد و به کجا رسید. همین روایت است که عدد داخل خلاصه را برای هیئتمدیره قابل فهم میکند.
۶. آنچه امتحان شد و جواب نداد
آزمونگری که یک روز روی جریان احراز هویت وقت گذاشته و چیزی پیدا نکرده، شاهد تولید کرده است. این باید در قالب بخشی کوتاه از نتایج منفی در گزارش بیاید: کدام دسته از حملات روی کدام اجزا امتحان شد. بدون آن، مشتری نمیتواند «امن» را از «بررسینشده» تشخیص دهد.
۷. شرایط آزمون مجدد
مشخص کنید آزمون مجدد شامل قرارداد هست یا نه، بازهی زمانی آن چیست و چه چیزی را پوشش میدهد. گزارشی که مسیر آزمون مجدد ندارد، یافتهها را بلاتکلیف رها میکند. گزارش آزمون مجدد باید به شناسهی یافتههای اصلی ارجاع دهد و برای هر یک وضعیت بنویسد: رفعشده، تا حدی رفعشده، رفعنشده، یا ریسک پذیرفتهشده با مالک مشخص.
۸. پیوستهایی که در وقت صرفهجویی میکنند
خروجی اسکنرها، لاگ کامل درخواستها، ابزارها و نسخههای استفادهشده، و یک خروجی ماشینخوان از یافتهها (CSV یا JSON) تا تیم فنی بتواند آنها را به سامانهی پیگیری خود وارد کند، نه اینکه دوباره تایپ کند. نسخهی ماشینخوان لطف نیست؛ همان چیزی است که باعث میشود گزارش واقعاً پیگیری شود.
پرسشهایی که پیش از امضا باید بپرسید
۱. آیا گزارش مینویسد چه چیزی قابل آزمون نبود و چرا؟ ۲. پوشش آزمون به کدام استاندارد نگاشت میشود و آیا آن نگاشت را میبینم؟ ۳. آیا هر یافته شدتِ امتیازدهیشده با بردار، علت ریشهای و مراحل بازتولید دارد؟ ۴. آیا آزمون مجدد وجود دارد و وضعیتها چگونه گزارش میشوند؟ ۵. آیا یافتهها را در قالبی دریافت میکنم که سامانهی پیگیری من بتواند وارد کند؟
پیمانکاری که به هر پنج پرسش بیدرنگ پاسخ میدهد، دارد گزارشی را توصیف میکند که میتوانید بر اساس آن اقدام کنید. اگر پاسخ هر کدام «میتوانیم اضافه کنیم» بود، اول یک نمونهی محرمانهزداییشده بخواهید.