مدیریت آسیبپذیری (Vulnerability Management) یک ابزار نیست، یک فرایند پیوسته است: می‌دانید چه دارایی‌هایی دارید، پیوسته آن‌ها را می‌سنجید، یافته‌ها را با معیار روشن اولویت‌بندی می‌کنید، برای رفع هر باند شدت زمان‌بندی تعریف‌شده دارید، و رفع را با آزمون مجدد راستی‌آزمایی می‌کنید. تفاوت سازمان‌هایی که این فرایند را دارند با آن‌هایی که ندارند، در تعداد آسیب‌پذیری‌ها نیست — در مدت زمانی است که هر آسیبپذیری باز می‌ماند. این مقاله هر شش گام را با جزئیات عملی، جدول SLA و متریک‌های قابل اندازه‌گیری توضیح میدهد.
در یک نگاه
- چیزی را که نمی‌دانید وجود دارد نمی‌توانید ایمن کنید؛ موجودی دارایی گام صفر است، نه گام آخر.
- «دارای CVE» با «قابل بهرهبرداری در محیط ما» یکی نیست — این تفکیک، تفاوت یک برنامهی کارآمد با یک صف بی‌پایان تیکت است.
- اولویت‌بندی به سه ورودی نیاز دارد: CVSS (شدت)، CISA KEV و شواهد بهرهبرداری، و اهمیت دارایی در کسبوکار شما.
- CVSS v4.0 با نام‌گذاری CVSS-B/BT/BE/BTE مشخص میکند امتیاز اعلام‌شده فقط پایه است یا تهدید و محیط را هم شامل میشود.
- مدیریت آسیبپذیری جایگزین تست نفوذ نیست: اسکن پیوسته، موارد شناختهشده را مییابد و تست نفوذ، منطق کسبوکار و کنترل دسترسی را.
مدیریت آسیبپذیری چیست و با تست نفوذ چه تفاوتی دارد؟
این دو مرتب با هم اشتباه می‌شوند و نتیجه‌اش خرید اشتباه است: سازمانی که به فرایند پیوسته نیاز دارد یک تست نفوذ سالانه می‌خرد، یا سازمانی که به آزمون عمیق دستی نیاز دارد به خروجی یک اسکنر بسنده میکند.
| مدیریت آسیبپذیری | تست نفوذ | |
|---|---|---|
| ماهیت | فرایند پیوسته و چرخه‌ای | پروژه‌ی زماندار با دامنه‌ی مشخص |
| پرسش اصلی | آیا هیچ آسیبپذیری شناخته‌شده‌ای بیش از SLA باز مانده؟ | آیا مهاجم می‌تواند به هدفی برسد که نباید؟ |
| پوشش | وسیع: همه‌ی دارایی‌ها | عمیق: دارایی‌های در دامنه |
| روش | عمدتاً خودکار، با تریاژ انسانی | عمدتاً دستی، با کمک ابزار |
| یافته‌های شاخص | اجزای وصلهنشده، پیکربندی نادرست، سرویس‌های افشاشده | کنترل دسترسی، منطق کسبوکار، زنجیره‌های چندمرحله‌ای |
| خروجی | داشبورد، صف کار، متریک روند | گزارش با اثبات اثر و راهکار |
| آنچه پیدا نمی‌کند | هر چیزی که «قاعده»ی شناختهشده ندارد | آسیب‌پذیری‌هایی که فردا در وابستگیها منتشر می‌شوند |
رابطه‌ی درست، مکمل بودن است: مدیریت آسیبپذیری کف را بالا می‌برد و تست نفوذ سقف را می‌سنجد. سازمانی که فرایند پیوسته دارد، در تست نفوذ یافته‌های سطح پایین کمتری می‌گیرد و بودجه‌ی آزمون دستی صرف چیزهایی میشود که واقعاً به مهارت انسانی نیاز دارند. تفکیک کامل انواع ارزیابی در ارزیابی امنیتی آمده است.
گام ۱ — موجودی دارایی: چیزی را که نمی‌دانید نمی‌توانید ایمن کنید
بیشتر برنامه‌های مدیریت آسیبپذیری در همین گام شکست می‌خورند، چون از فهرستی شروع می‌کنند که یک نفر سه سال پیش در یک فایل صفحه‌گسترده نوشته. برای یک سازمان با حضور وب، موجودی باید حداقل این‌ها را شامل شود:
- دامنه‌ها و زیردامنه‌ها — همه، نه فقط آن‌هایی که به یاد می‌آورید. زیردامنه‌ی فراموش‌شده‌ی یک کمپین تبلیغاتی سه سال پیش، هنوز یک وردپرس وصلهنشده را سرو میکند.
- برنامه‌ها و APIها با مالک مشخص، نسخه، و طبقه‌بندی داده‌ای که پردازش می‌کنند.
- سرویس‌های در معرض اینترنت: پورت‌های باز، پنل‌های مدیریتی، سرویس‌های ابری، فضای ذخیره‌سازی آبجکت.
- وابستگی‌های نرم‌افزاری — همان SBOM که در بخش جداگانه‌ای به آن می‌رسیم.
- دارایی‌های سایه (Shadow IT): سروری که تیم محصول بدون اطلاع IT بالا آورده، اکانت ابری شخصی، محیط دموی مشتری.
موجودی باید پیوسته ساخته شود، نه یکبار. سازوکار عملی، ترکیب سه منبع است: کشف بیرونی از راه شمارش زیردامنه و اسکن سطح حمله (روش‌هایش در شناسایی و Subfinder توضیح داده شده — همان کاری که مهاجم هم انجام میدهد)، خروجی API ارائه‌دهنده‌ی ابری، و رکوردهای DNS خودتان.
یک آزمون ساده: به تیم امنیت بگویید فهرست دارایی‌های اینترنتی را بدهد، و به‌طور مستقل یک شمارش زیردامنه انجام دهید. اختلاف این دو فهرست، اندازه‌ی نقطه‌ی کور شماست. در بیشتر سازمان‌ها این اختلاف صفر نیست.
گام ۲ — کشف پیوسته و آهنگ اسکن
«هر چند وقت یکبار اسکن کنیم؟» پاسخ واحدی ندارد، چون انواع بررسی نرخ تغییر متفاوتی دارند. یک آهنگ قابل دفاع:
| نوع بررسی | آهنگ پیشنهادی | محرک اضافی |
|---|---|---|
| اسکن وابستگیها (SCA) | در هر Commit و Build | انتشار هر توصیه‌نامه‌ی امنیتی مرتبط |
| تحلیل استاتیک کد (SAST) | در خط لوله‌ی CI، روی هر Pull Request | تغییر در ماژول‌های حساس |
| اسکن پیکربندی و مقاوم‌سازی | هفتگی یا در هر استقرار | هر تغییر زیرساخت |
| اسکن پویا (DAST) روی محیط تست | هفتگی تا ماهانه | انتشار قابلیت جدید |
| کشف سطح حملهی بیرونی | ماهانه | راه‌اندازی دامنه یا سرویس جدید |
| تست نفوذ وب | حداقل سالانه | پس از هر تغییر معماری یا افزودن قابلیت حساس (پرداخت، احراز هویت، آپلود) |
دو مرجع بیرونی که این آهنگ را پشتیبانی می‌کنند: PCI DSS v4.0.1 در الزام ۱۱٫۴٫۲ و ۱۱٫۴٫۳ تست نفوذ داخلی و بیرونی را حداقل هر ۱۲ ماه و پس از هر تغییر مهم زیرساخت یا برنامه می‌خواهد (و برای ارائه‌دهندگان خدمات، آزمون کنترل‌های تفکیک را هر شش ماه). و ISO/IEC 27001:2022 در کنترل‌های A.8.8 و A.8.29 یک فرایند مدیریت آسیبپذیری و آزمون امنیتی مبتنی بر ریسک می‌خواهد — اما توجه کنید که ISO فرکانس مشخصی تعیین نمی‌کند؛ ادعای «ISO 27001 تست نفوذ سالانه را الزامی کرده» نادرست است.
نکته‌ی مهم پوشش: اسکن پویا روی برنامه‌های احرازهویت‌شده و APIها بدون پیکربندی درست (نشست معتبر، مشخصات OpenAPI) عملاً چیزی نمی‌بیند. «ما اسکن ماهانه داریم» بدون بررسی اینکه اسکنر تا چه عمقی از برنامه رفته، یک ادعای بی‌پشتوانه است.
گام ۳ — تریاژ و اولویت‌بندی: از خروجی خام تا صف کار
خروجی خام اسکنر یک برنامهی امنیتی نیست؛ ماده‌ی خام آن است. تریاژ چهار کار انجام میدهد:
- حذف مثبت کاذب. هر یافته باید تأیید شود. تیمی که یافته‌های تأییدنشده را به توسعه‌دهنده می‌فرستد، در چند هفته اعتبار خود را از دست میدهد.
- یکپارچه‌سازی و حذف تکرار. یک آسیبپذیری در یک کتابخانه‌ی مشترک، در ۴۰ سرویس گزارش میشود؛ این یک کار است، نه چهل کار.
- سنجش قابلیت بهرهبرداری در محیط شما. این مهم‌ترین گام است و بیشتر از همه نادیده گرفته میشود.
- امتیازدهی و ترتیب‌گذاری.
«این جزء CVE دارد، پس ما آسیب‌پذیریم.» نه لزوماً. سه پرسش را باید پاسخ داد: آیا کدِ آسیبپذیر واقعاً در مسیر اجرای برنامهی ما فراخوانی میشود؟ آیا پیششرطهای بهرهبرداری (پیکربندی خاص، دسترسی احرازهویت‌شده، ویژگی فعال) در محیط ما برقرار است؟ آیا کنترل جبرانی مؤثری در مسیر هست؟ برنامهای که این تفکیک را انجام نمیدهد، صف بیپایانی از تیکت میسازد و در نتیجه هیچکدام رفع نمیشوند.
برای امتیازدهی، سه ورودی لازم است و هیچکدام به‌تنهایی کافی نیست:
- شدت فنی با CVSS. نسخه‌ی جاری ۴٫۰ است (منتشرشده در نوامبر ۲۰۲۳). دقت کنید که امتیاز پایه عامدانه از محیط شما بی‌خبر است. نسخه‌ی ۴٫۰ برای همین گروه Threat (متریک Exploit Maturity) و گروه Environmental (الزامات امنیتی دارایی و متریک‌های پایه‌ی اصلاح‌شده) را دارد، و با نام‌گذاری CVSS-B، CVSS-BT، CVSS-BE و CVSS-BTE صریح میکند که امتیاز اعلام‌شده بر چه پایه‌ای است. در سیاست خود بنویسید کدام را مبنا می‌گیرید.
- شواهد بهرهبرداری فعال. فهرست CISA KEV سیگنال روشنی میدهد: موردی که در KEV است، معمولاً فوری‌تر از موردی با امتیاز پایه‌ی بالاتر و بدون اکسپلویت میدانی است.
- اهمیت دارایی. همان اندپوینت با همان آسیبپذیری، روی درگاه پرداخت و روی سایت رویدادِ سال گذشته دو اولویت متفاوت دارد.
و یک هشدار عملی: پذیرش نسخه‌ی ۴٫۰ در داده‌ی واقعی هنوز جزئی است — در مجموعه‌داده‌ی OWASP برای Top 10:2025، از حدود ۲۲۰٬۰۰۰ رکورد CVE، ۱۵۶ هزار امتیاز v3 داشتند و فقط ۶ هزار امتیاز v4. پس ابزارهای شما احتمالاً امتیاز v3.1 می‌دهند؛ این اشکالی ندارد، به شرط آنکه در گزارش‌ها ثابت و صریح باشد.
گام ۴ — تعریف SLA بر اساس باند شدت
بدون زمان‌بندی مکتوب، «رفع می‌کنیم» یعنی «هیچ‌وقت». باندهای شدت CVSS استاندارد و ثابت‌اند؛ مهلت‌های رفع سیاست سازمان شما هستند، نه بخشی از استاندارد. جدول زیر یک طرح قابل دفاع برای یک سازمان با حضور وب است که می‌توانید مبنا بگیرید و با ریسک‌پذیری خود تنظیم کنید:
| باند شدت | بازه‌ی CVSS | مهلت رفع (نمونه) | مهلت در صورت حضور در CISA KEV |
|---|---|---|---|
| بحرانی (Critical) | ۹٫۰ – ۱۰٫۰ | ۷ روز | ۲۴ تا ۴۸ ساعت |
| بالا (High) | ۷٫۰ – ۸٫۹ | ۳۰ روز | ۷ روز |
| متوسط (Medium) | ۴٫۰ – ۶٫۹ | ۹۰ روز | ۳۰ روز |
| کم (Low) | ۰٫۱ – ۳٫۹ | در چرخه‌ی نگهداشت بعدی | ۹۰ روز |
چهار قاعده که این جدول را از یک سند تشریفاتی به یک ابزار کاری تبدیل میکند:
- ساعت از لحظه‌ی تأیید یافته شروع میشود، نه از لحظه‌ی گزارش خام اسکنر.
- هر یافته مالک مشخص دارد — یک نام، نه یک تیم. تیکت در همان سیستمی ثبت میشود که تیم توسعه واقعاً از آن استفاده میکند، نه در یک پرتال امنیتی جدا.
- پذیرش ریسک باید مکتوب، زماندار و امضاشده باشد. «فعلاً نمی‌توانیم رفع کنیم» یک تصمیم مدیریتی معتبر است — به شرط اینکه ثبت شود، مهلت بازبینی داشته باشد و کنترل جبرانی موقت برایش تعریف شود.
- SLA برای دارایی‌های حساس سخت‌گیرانه‌تر است. یک طرح دو‌سطحی (دارایی بحرانی / عادی) در عمل بهتر از یک جدول واحد کار میکند.
گام ۵ — رفع، پیگیری و راستی‌آزمایی
سه اشتباه رایج در این گام:
اشتباه اول: بستن تیکت بدون آزمون مجدد. «بسته شد» یک ادعا است تا وقتی کسی آزمون نکند. آزمون مجدد بخش الزامی یک تعامل حرفه‌ای است و در PCI DSS هم صریح آمده: در الزام ۱۱٫۴٫۴، آسیب‌پذیری‌های قابل بهرهبرداری باید اصلاح شوند و تست نفوذ برای راستی‌آزمایی اصلاح تکرار شود. در گزارش‌های ما هم آزمون مجدد پس از رفع، بخش استاندارد گزارش تست نفوذ است.
اشتباه دوم: رفع نمونه به‌جای رفع الگو. اگر تزریق SQL در یک اندپوینت پیدا شد، احتمال اینکه همان الگوی کدنویسی در ده جای دیگر تکرار شده باشد بالاست. رفع درست، جست‌وجوی الگو در کل مخزن و افزودن یک قاعده‌ی تحلیل استاتیک است تا الگو دوباره وارد نشود.
اشتباه سوم: ثبت کنترل جبرانی به‌عنوان رفع. قاعده‌ی WAF، وصله‌ی مجازی است و هیچ‌گاه رفع نیست: زمان می‌خرد، و در برابر کنترل دسترسی، منطق کسبوکار، شرایط مسابقه و SSRF ساختاراً بی‌اثر است؛ ضمن اینکه با پیدا شدن IP اصلی سرور دور زده میشود (دانشنامه‌ی WAF). در سیستم پیگیری، وضعیت چنین موردی «کاهش‌یافته» است، نه «بسته‌شده».
یک جریان کاری که در عمل جواب میدهد: یافته‌ی تأییدشده ← تیکت با مالک، شدت و مهلت ← اصلاح ← آزمون مجدد توسط کسی که یافته را ثبت کرده ← بستن با ثبت شاهد آزمون ← اگر کلاس یافته تکرارشدنی است، افزودن قاعده‌ی تحلیل استاتیک یا مورد آزمون خودکار.
گام ۶ — متریک‌هایی که واقعاً چیزی می‌گویند
متریک بد، رفتار بد میسازد. «تعداد کل آسیب‌پذیری‌ها» بدترین متریک است، چون هم با بهبود پوشش اسکن بالا می‌رود و هم تیم را به کاهش پوشش تشویق میکند. متریک‌های قابل دفاع:
| متریک | چه چیزی را می‌سنجد | چرا مهم است |
|---|---|---|
| میانگین زمان رفع (MTTR)، تفکیک‌شده بر اساس باند شدت | سرعت واقعی سازمان | تنها متریکی که با ریسک واقعی رابطه‌ی مستقیم دارد |
| انطباق با SLA (درصد یافته‌های رفع‌شده در مهلت) | پایداری فرایند | MTTR خوب با چند مورد بسیار دیرکرد، وضعیت را پنهان میکند |
| پوشش (درصد دارایی‌های زیر پایش فعال) | اندازه‌ی نقطه‌ی کور | یافته‌ی صفر روی دارایی اسکن‌نشده، خبر خوبی نیست |
| نرخ بازگشت (Recurrence) | درصد یافته‌هایی که پس از رفع برگشته‌اند | نشانه‌ی رفع نمونه‌ای به‌جای رفع الگو |
| سن یافته‌های باز (Aging) | توزیع سنی صف کار | دم بلندِ موارد قدیمی، ریسک انباشته است |
| سهم یافته‌های حاضر در KEV | مواجهه با تهدید فعال | باید همیشه نزدیک صفر باشد |
یک متریک مکمل که ارزش گزارش‌دهی به مدیریت را دارد: زمان از انتشار وصله تا استقرار آن. این عدد، پنجره‌ی بهرهبرداری شما را مستقیماً اندازه می‌گیرد و — همان‌طور که در آسیبپذیری روز صفر توضیح داده‌ایم — بیشتر رخنه‌های واقعی در همین پنجره رخ می‌دهند، نه از راه آسیب‌پذیری‌های ناشناخته.
SBOM و زنجیره‌ی تأمین نرم‌افزار
در OWASP Top 10:2025، دسته‌ی A03 نقص‌های زنجیره‌ی تأمین نرم‌افزار از رتبه‌ی شش به رتبه‌ی سه رسید و دامنه‌اش گسترش یافت تا «همه‌ی نقص‌های زنجیره‌ی تأمین را پوشش دهد، نه فقط مواردی که به آسیبپذیری شناختهشده مربوط‌اند». اولین توصیه‌ی رفع OWASP در این دسته، مدیریت متمرکز SBOM و موجودی‌برداری پیوسته است.
SBOM (فهرست دارایی نرم‌افزاری) پاسخ یک سؤال عملیاتی است: در ساعت اول انتشار یک آسیبپذیری بحرانی در یک کتابخانه‌ی پرکاربرد، آیا می‌توانید در چند دقیقه بگویید کجا از آن استفاده می‌کنید و در چه نسخه‌ای؟ تیمی که نمی‌تواند، روزها را صرف جست‌وجوی دستی میکند — و آن روزها همان پنجره‌ی بهرهبرداری است.
حداقل‌های عملی این بخش از برنامه:
- تولید SBOM در خط لوله‌ی ساخت برای هر سرویس، و نگهداری متمرکز و نسخه‌دار آن.
- دریافت اجزا فقط از منابع رسمی، همراه با راستی‌آزمایی امضا؛ یا از یک آینه‌ی داخلی بررسی‌شده.
- رصد توصیه‌نامه‌های امنیتی اجزایی که استفاده می‌کنید، و اشتراک در هشدارهای آسیبپذیری.
- تفکیک وظایف و MFA روی مخازن و خط لوله‌ی CI/CD — چون در حوادثی مثل کرم npm سال ۲۰۲۵، مسیر گسترش، توکن‌های سرقتی توسعه‌دهندگان بود.
- انتشار مرحله‌ای به‌جای استقرار هم‌زمان روی کل ناوگان.
در سایت‌های وردپرسی، این بخش عملاً همان مدیریت افزونه‌ها است: حذف افزونه‌های بلااستفاده (نه فقط غیرفعال‌کردن)، به‌روزرسانی منظم و پرهیز از افزونه‌های بدون نگهداری. تفصیلش در امنیت وردپرس آمده است.
شش اشتباهی که برنامه‌های مدیریت آسیبپذیری را از کار می‌اندازد
- شروع از ابزار به‌جای شروع از موجودی دارایی. اسکنری که ۳۰٪ دارایی‌ها را نمی‌بیند، داشبورد سبز تولید میکند.
- نداشتن مالک برای یافته‌ها. تیکتی که به «تیم توسعه» تخصیص یافته، تیکت بی‌صاحب است.
- یکسان گرفتن CVSS با ریسک. امتیاز پایه از دارایی و تهدید بی‌خبر است؛ ریسک نیازمند زمینه است. تفکیک کامل در آسیبپذیری چیست.
- ارسال خروجی تأییدنشده‌ی اسکنر به توسعه‌دهنده. سریع‌ترین راه از بین بردن اعتماد بین امنیت و توسعه.
- ثبت WAF یا کنترل جبرانی به‌عنوان رفع. وضعیت درست «کاهش‌یافته» است.
- نداشتن آزمون مجدد. بدون راستی‌آزمایی، متریک‌های شما داستان می‌گویند، نه واقعیت.
و یک نکته‌ی ساختاری: مدیریت آسیبپذیری بدون توان انتشار سریع کار نمی‌کند. اگر استقرار یک نسخه‌ی اصلاحی در سازمان شما دو هفته طول می‌کشد، هیچ SLA هفت‌روزه‌ای قابل تحقق نیست. سرمایه‌گذاری روی خط لوله‌ی استقرار، در عمل یک سرمایه‌گذاری امنیتی است.
برای راه‌اندازی این فرایند، ترتیب پیشنهادی: چک‌لیست امنیتی برای بستن سریع موارد ارزان، کاتالوگ باگ‌های امنیتی برای شناخت کلاس‌هایی که باید دنبالشان بگردید، تست نفوذ وب برای تعیین خط پایه، و مشاوره‌ی امنیتی برای طراحی سیاست SLA و متریک‌ها متناسب با سازمان خودتان.
پرسش‌های متداول
مدیریت آسیبپذیری چیست؟
یک فرایند پیوسته با شش گام: موجودی دارایی، کشف پیوسته، تریاژ و اولویت‌بندی، تعریف SLA رفع بر اساس شدت، رفع و راستی‌آزمایی با آزمون مجدد، و سنجش با متریک. تفاوت سازمان‌های بالغ با بقیه در تعداد آسیب‌پذیری‌ها نیست، در مدت زمانی است که هر آسیبپذیری باز می‌ماند.
تفاوت مدیریت آسیبپذیری و تست نفوذ چیست؟
مدیریت آسیبپذیری فرایندی پیوسته و عمدتاً خودکار است که پوشش وسیع میدهد و موارد شناختهشده (اجزای وصلهنشده، پیکربندی نادرست) را مییابد. تست نفوذ پروژهای زماندار و عمدتاً دستی است که عمق میدهد و مواردی مثل نقص کنترل دسترسی و سوءاستفاده از منطق کسبوکار را کشف میکند. جای هم را نمیگیرند.
SLA رفع آسیبپذیری چقدر باید باشد؟
باندهای شدت CVSS استاندارد است (بحرانی ۹٫۰ تا ۱۰٫۰، بالا ۷٫۰ تا ۸٫۹، متوسط ۴٫۰ تا ۶٫۹، کم ۰٫۱ تا ۳٫۹) اما مهلت‌ها سیاست سازمان شماست. یک طرح قابل دفاع: بحرانی ۷ روز، بالا ۳۰ روز، متوسط ۹۰ روز و کم در چرخه‌ی نگهداشت بعدی — با مهلت‌های سخت‌گیرانه‌تر برای مواردی که در فهرست CISA KEV هستند.
هر چند وقت یکبار باید اسکن آسیبپذیری انجام دهیم؟
بسته به نوع بررسی: اسکن وابستگیها در هر Build، تحلیل استاتیک روی هر Pull Request، اسکن پیکربندی هفتگی یا در هر استقرار، اسکن پویا هفتگی تا ماهانه، کشف سطح حملهی بیرونی ماهانه، و تست نفوذ حداقل سالانه و پس از هر تغییر معماری یا افزودن قابلیت حساس.
آیا داشتن CVE به معنی آسیبپذیر بودن ماست؟
نه لزوماً. سه پرسش را باید پاسخ داد: آیا کد آسیبپذیر در مسیر اجرای برنامهی ما فراخوانی میشود؟ آیا پیششرطهای بهرهبرداری در محیط ما برقرار است؟ آیا کنترل جبرانی مؤثری در مسیر هست؟ برنامهای که این تفکیک را انجام نمیدهد، صف بیپایانی از تیکت میسازد که در نتیجه هیچکدام رفع نمیشوند.
چه متریک‌هایی برای گزارش به مدیریت مناسب است؟
میانگین زمان رفع به تفکیک باند شدت، درصد انطباق با SLA، درصد پوشش دارایی‌های تحت پایش، نرخ بازگشت یافته‌ها پس از رفع، توزیع سنی یافته‌های باز، و سهم یافته‌های حاضر در فهرست بهرهبرداری فعال. «تعداد کل آسیب‌پذیری‌ها» متریک بدی است، چون با بهبود پوشش اسکن بالا می‌رود.
منابع
امیر پیامنی
شکارچی ضعف‌های زیرساخت؛ از نقشه‌برداری سطح حمله تا بهرهبرداری از سرویس‌های شبکه و حرکت جانبی داخل دامنه.