واژه‌ی «آسیبپذیری» در محتوای فارسی امنیت، تقریباً همیشه با سه واژه‌ی دیگر — ضعف، تهدید و ریسک — جابه‌جا استفاده میشود، و همین جابه‌جایی باعث میشود گزارش‌های امنیتی غیرقابل مقایسه و اولویت‌بندی‌ها بی‌معنی شوند. این مقاله ابتدا این واژه‌ها را دقیق تفکیک میکند، سپس انواع آسیبپذیری را در سه شیوه‌ی دسته‌بندیِ کاربردی مرور میکند، بعد مثلث CWE (کلاس ضعف)، CVE (نمونه‌ی مشخص) و CVSS (امتیاز شدت) را روشن میکند، و در پایان نشان می‌دهد چرخه‌ی عمر یک آسیبپذیری چه مراحلی دارد و چرا آسیب‌پذیری‌های وصله‌دارِ نصب‌نشده — یعنی N-day — عامل رخنههای واقعی بیشتری از روز صفر هستند.
در یک نگاه
- آسیبپذیری یک ضعف قابل بهرهبرداری در یک سامانهی مشخص است؛ تهدید عاملی است که ممکن است از آن استفاده کند و ریسک ترکیب احتمال و اثر است.
- CWE کلاس ضعف است (مثل CWE-89)، CVE یک نمونه‌ی مشخص در یک محصول مشخص، و CVSS فقط یک امتیاز شدت — نه امتیاز ریسک.
- امتیاز پایه‌ی CVSS چیزی از دارایی شما و از فعالیت مهاجمان نمیداند؛ به همین دلیل CVSS v4.0 گروه‌های Threat و Environmental و نامگذاری CVSS-B/BT/BE/BTE را معرفی کرد.
- چرخه‌ی عمر: ایجاد ← کشف ← افشا ← وصله ← نصب وصله؛ فاصله‌ی بین انتشار وصله و نصب آن، همان پنجره‌ای است که بیشترین رخنه در آن رخ می‌دهد.
- «روز صفر» یعنی وصله وجود ندارد. اگر وصله منتشر شده و شما نصب نکرده‌اید، آن آسیبپذیری N-day است — نه روز صفر.
آسیبپذیری چیست؟ تعریف دقیق
آسیبپذیری (Vulnerability) یک ضعف در طراحی، پیاده‌سازی یا پیکربندی یک سامانهی مشخص است که میتواند برای نقض یکی از اهداف امنیتی آن سامانه — محرمانگی، یکپارچگی یا دسترس‌پذیری — مورد بهرهبرداری قرار گیرد.
دو کلمه‌ی این تعریف بار سنگینی دارند:
- «مشخص»: آسیبپذیری همیشه به یک سامانه، نسخه و پیکربندی معین تعلق دارد. «تزریق SQL» به‌خودی‌خود آسیبپذیری نیست؛ یک کلاس ضعف است. «تزریق SQL در پارامتر
orderIdاندپوینت گزارش‌گیری نسخهی ۲٫۴ برنامه‌ی ما» یک آسیبپذیری است. - «میتواند مورد بهرهبرداری قرار گیرد»: قابلیت بهرهبرداری بخشی از تعریف است. کدی که ضعف دارد اما هیچ مسیر رسیدنی از ورودی کاربر به آن وجود ندارد، در عمل یک ضعف غیرقابل دسترس است. این تفکیک در اولویت‌بندی حیاتی است و بخش اعظم «CVEهایی که برای شما مهم نیستند» از همین‌جا می‌آید.
در همه‌ی موارد، آسیبپذیری چیزی است که مرز امنیتی را می‌شکند: کاربر بدون مجوز به داده‌ای می‌رسد، داده‌ای به کد تبدیل میشود، یا سامانه در وضعیت ناامن می‌افتد. اگر رفتاری غلط است ولی هیچ مرز اعتمادی را رد نمیکند، آن یک باگ عملکردی است، نه آسیبپذیری امنیتی.
ضعف، تهدید، ریسک، اکسپلویت، بردار حمله: تفکیک دقیق
این پنج واژه در محتوای فارسی معمولاً به‌جای هم به‌کار می‌روند. تفکیک درست آنها پیش‌شرط هر گفت‌وگوی جدی درباره‌ی امنیت است:
| واژه | معنای دقیق | مثال |
|---|---|---|
| ضعف (Weakness) | الگوی خطای عمومی در نرم‌افزار — یک کلاس، مستقل از محصول | «اعتبارسنجی نادرست مجوز» (CWE-285) |
| آسیبپذیری (Vulnerability) | وقوع آن ضعف در یک سامانه و نسخهی مشخص، به‌شکل قابل بهرهبرداری | کاربر عادی میتواند فاکتور کاربر دیگری را در اندپوینت /api/invoice/{id} بخواند |
| تهدید (Threat) | عامل یا رخدادی که میتواند از آسیبپذیری استفاده کند | گروه مهاجم انگیزه‌دار، کارمند ناراضی، ربات اسکن انبوه |
| ریسک (Risk) | ترکیب احتمال وقوع و شدت اثر بر کسبوکار | «افشای دادهی ۲۰۰ هزار مشتری با احتمال بالا» — نه یک عدد فنی |
| اکسپلویت (Exploit) | کد یا روال مشخصی که آسیبپذیری را عملاً به‌کار می‌گیرد | درخواست HTTP ساخته‌شده‌ای که مجوز را دور می‌زند |
| بردار حمله (Attack Vector) | مسیری که مهاجم از آن به آسیبپذیری می‌رسد | API عمومی، فرم آپلود، ایمیل، وابستگی نرم‌افزاری |
| سطح حمله (Attack Surface) | مجموعه‌ی همه‌ی نقاط ورودی قابل دسترس مهاجم | هر دامنه، زیردامنه، اندپوینت و پورت باز |
نتیجه‌ی عملی: جمله‌ی «ریسک این آسیبپذیری ۹٫۸ است» بی‌معنی است. ۹٫۸ یک امتیاز شدت است. ریسک بدون دانستن ارزش دارایی و فعالیت واقعی مهاجمان محاسبه نمی‌شود — همان چیزی که در بخش بعد و در مدل‌سازی تهدید دنبال میشود.
وجود آسیبپذیری به معنای وجود اکسپلویت عمومی نیست، و نبودِ اکسپلویت عمومی هم به معنای امن بودن نیست. این تفکیک در CVSS v4.0 با متریک Exploit Maturity رسمیت پیدا کرده و در بخش شدت به آن برمی‌گردیم.
مثلث CWE، CVE و CVSS — پرتکرارترین اشتباه محتوای فارسی
این سه، سه چیز کاملاً متفاوت‌اند و هر سه لازم‌اند:
| CWE | CVE | CVSS | |
|---|---|---|---|
| چیست | فهرست شماره‌دار کلاس‌های ضعف | شناسه‌ی یکتا برای یک آسیبپذیری مشخص در یک محصول مشخص | چارچوب امتیازدهی شدت |
| پاسخ به چه سؤالی | «چه نوع اشتباهی رخ داده؟» | «کجا و در چه محصولی؟» | «چقدر جدی است؟» |
| نمونه | CWE-79 (XSS)، CWE-89 (تزریق SQL) | CVE-2021-44228 (Log4Shell) | امتیاز ۹٫۰ تا ۱۰٫۰ = بحرانی |
| متولی | MITRE، با حمایت CISA | برنامه‌ی CVE و شبکه‌ی CNAها | FIRST.Org |
| در گزارش تست نفوذ | برچسب نوع یافته | فقط برای اجزای شناختهشده | عدد شدت هر یافته |
نکته‌ی مهم عملی: اکثر یافته‌های یک تست نفوذ وب هیچ CVE ندارند. CVE برای آسیب‌پذیری‌های محصولات و کتابخانه‌های عمومی صادر میشود، نه برای باگ کد اختصاصی شما. اگر پیمانکاری برای هر یافته‌ی برنامه‌ی سفارشی شما یک CVE ذکر میکند، آن گزارش را با دقت بیشتری بخوانید. برچسب درست یافته‌ی کد اختصاصی، شناسه‌ی CWE است — و جزئیات این تفکیک در دانشنامه‌ی CWE و دانشنامه‌ی CVE آمده است.
برای مقیاس: نسخهی جاری فهرست CWE نسخهی 4.20 است (اعلامشده در آوریل ۲۰۲۶) و آخرین فهرست «۲۵ ضعف خطرناک» آن، نسخهی ۲۰۲۵ است که در ۱۵ دسامبر ۲۰۲۵ منتشر شد و بر پایه‌ی ۳۹٬۰۸۰ رکورد CVE در بازه‌ی یک‌ساله ساخته شده. در آن فهرست، رتبه‌ی یک CWE-79 (XSS) و رتبه‌ی دو CWE-89 (تزریق SQL) است — دو ضعف کلاسیک وب.
انواع آسیبپذیری: سه شیوه‌ی دستهبندی که به‌کار می‌آیند
«انواع آسیبپذیری» بسته به اینکه با چه هدفی دستهبندی می‌کنید، سه پاسخ متفاوت دارد:
۱) بر پایه‌ی کلاس ضعف — کاربرد در گزارش‌دهی
رایج‌ترین شیوه، دستهبندی بر اساس OWASP Top 10:2025 است. نسخهی جاری ده دسته دارد که مهم‌ترین‌شان برای برنامه‌های وب: A01 کنترل دسترسی شکسته، A02 پیکربندی نادرست، A03 نقصهای زنجیرهی تأمین نرم‌افزار، A05 تزریق و A07 خطاهای احراز هویت. فهرست کامل با تغییرات نسبت به ۲۰۲۱ در راهنمای OWASP Top 10 آمده و کاتالوگ عملی هر کلاس در باگ‌های امنیتی سایت.
۲) بر پایه‌ی محل بروز — کاربرد در تعیین دامنه‌ی تست
- در کد اختصاصی شما: منطق کسبوکار، کنترل دسترسی، اعتبارسنجی ورودی. هیچ اسکنری این‌ها را کامل پیدا نمیکند.
- در وابستگیها و اجزای ثالث: کتابخانه‌ها، فریم‌ورک، افزونه‌ها. اینجا سرزمین CVE است و OWASP آن را در ۲۰۲۵ به رتبه‌ی سه (A03) بالا آورد.
- در پیکربندی: هدرهای غایب، سرویس‌های باز، اعتبارنامه‌ی پیش‌فرض، دسترسی عمومی فضای ذخیره‌سازی ابری.
- در زیرساخت و پلتفرم: سیستم‌عامل، وب‌سرور، پایگاه‌داده، کانتینر.
- در فرایند و انسان: نبود بازبینی کد، دسترسی‌های پاک‌نشده‌ی کارمند سابق، نداشتن فرایند وصله.
۳) بر پایه‌ی پیش‌شرط بهرهبرداری — کاربرد در اولویت‌بندی
این دستهبندی کمتر گفته میشود اما در تصمیم‌گیری کاربردی‌ترین است: آیا بهرهبرداری از راه شبکه و بدون احراز هویت ممکن است، یا نیاز به حساب معتبر دارد؟ آیا تعامل کاربر لازم است؟ آیا شرط محیطی خاصی باید برقرار باشد؟ همین سه پرسش، ستون‌های متریک‌های پایه‌ی CVSS هستند.
شدت در برابر ریسک: CVSS چه می‌گوید و چه نمی‌گوید
CVSS نسخهی 4.0 استاندارد جاری است و در ۱ نوامبر ۲۰۲۳ توسط FIRST.Org منتشر شد. بازه‌های کیفی آن نسبت به نسخهی ۳ تغییری نکرده:
| رتبه‌ی کیفی | بازه‌ی امتیاز |
|---|---|
| None | ۰٫۰ |
| Low (کم) | ۰٫۱ – ۳٫۹ |
| Medium (متوسط) | ۴٫۰ – ۶٫۹ |
| High (بالا) | ۷٫۰ – ۸٫۹ |
| Critical (بحرانی) | ۹٫۰ – ۱۰٫۰ |
«امتیاز CVSS یعنی ریسک ما.» خیر. CVSS یک معیار شدت فنی است. امتیاز پایه (Base) عامدانه هیچ چیزی از محیط شما نمیداند: نمیداند آن سامانه در اینترنت است یا در شبکه‌ی داخلی، نمیداند داده‌اش حساس است یا آزمایشی، و نمیداند آیا مهاجمان همین حالا در حال بهرهبرداری از آن هستند. یک آسیبپذیری با امتیاز پایه‌ی ۹٫۸ روی سروری که خاموش است، ریسک صفر دارد؛ و یک آسیبپذیری با امتیاز ۶٫۵ روی درگاه پرداخت شما میتواند بحرانی‌ترین کار امروزتان باشد.
خودِ استاندارد این مشکل را می‌شناسد و برای حلش دو گروه متریک دیگر دارد:
- گروه Threat — در نسخهی ۴٫۰ تنها یک متریک دارد: Exploit Maturity، بر پایه‌ی وجود کد اثبات مفهوم یا شواهد بهرهبرداری فعال.
- گروه Environmental — سازمان شما با آن امتیاز را بومی‌سازی میکند: الزامات امنیتی دارایی (CR/IR/AR) و متریک‌های پایه‌ی اصلاح‌شده که کنترل‌های جبرانی موجود شما را منعکس می‌کنند.
و برای اینکه کسی نتواند امتیاز پایه را به‌جای ارزیابی کامل جا بزند، نسخهی ۴٫۰ نامگذاری صریحی معرفی کرد: CVSS-B (فقط پایه)، CVSS-BT (پایه + تهدید)، CVSS-BE (پایه + محیطی) و CVSS-BTE (هر سه). در یک گزارش حرفه‌ای باید مشخص باشد کدام‌یک ذکر شده است.
یک واقعیت عملی هم بگوییم: پذیرش نسخهی ۴٫۰ در دادهی واقعی هنوز جزئی است. در همان مجموعه‌داده‌ای که OWASP برای Top 10:2025 استفاده کرد، از حدود ۲۲۰٬۰۰۰ رکورد CVE، ۱۵۶ هزار امتیاز CVSS v3 داشتند و فقط ۶ هزار امتیاز v4. استفاده از v3.1 در ۲۰۲۶ قابل دفاع است — به شرط آنکه در گزارش صریحاً نوشته شود از کدام نسخه استفاده شده.
چرخه‌ی عمر یک آسیبپذیری
هر آسیبپذیری یک خط زمانی دارد و فهم این خط زمانی، تفاوت دفاع مؤثر و دفاع تشریفاتی است:
- ایجاد (Introduction). در لحظه‌ی نوشتن کد، تصمیم معماری، یا افزودن یک وابستگی. نکته‌ی تلخ این است که فاصله‌ی ایجاد تا کشف میتواند سال‌ها باشد.
- کشف (Discovery). توسط تیم خودتان، یک پژوهشگر مستقل، یک پیمانکار تست نفوذ، یا مهاجم. اینکه کدام‌یک اول کشف کند، تعیین‌کننده‌ی همه‌ی مراحل بعدی است.
- افشا (Disclosure). در مسیر سالم، افشای هماهنگ: گزارش به تولیدکننده، مهلت معقول برای رفع، و بعد انتشار عمومی. چارچوب این کار در افشای مسئولانه توضیح داده شده.
- وصله (Patch). تولیدکننده اصلاح را منتشر میکند و — در محصولات عمومی — معمولاً یک CVE هم تخصیص می‌یابد.
- نصب وصله (Remediation). و اینجا همان جایی است که در عمل خراب میشود.
فاصله‌ی بین گام چهارم و پنجم، پنجره‌ی بهرهبرداری شما است. با انتشار وصله، جزئیات فنی آسیبپذیری هم عملاً عمومی میشود؛ مهاجمان با مقایسه‌ی نسخهی وصله‌شده و نسخهی قبلی، اکسپلویت می‌سازند. یعنی انتشار وصله ریسک را در کوتاه‌مدت بالا می‌برد، نه پایین — تا لحظه‌ای که شما نصب کنید.
مدیریت سیستماتیک همین خط زمانی، همان چیزی است که به آن مدیریت آسیبپذیری می‌گویند: موجودی دارایی، کشف پیوسته، اولویت‌بندی، SLA رفع و راستی‌آزمایی.
روز صفر در برابر N-day — و کدام‌یک واقعاً به شما آسیب می‌زند
تعریف‌ها را دقیق نگه داریم:
- آسیبپذیری روز صفر (Zero-day): آسیب‌پذیری‌ای که تولیدکننده وصلهای برایش منتشر نکرده است — چون یا نمیداند، یا در حال کار روی آن است.
- N-day: آسیب‌پذیری‌ای که وصلهاش موجود است اما روی سامانهی هدف نصب نشده. حرف N به تعداد روزهای گذشته از انتشار وصله اشاره دارد.
«هر آسیبپذیری وصلهنشده روی سرور ما یک روز صفر است.» نه. اگر وصله منتشر شده و شما نصب نکرده‌اید، این یک N-day است — و مسئولیتش هم متفاوت است. این تفکیک صرفاً لفظی نیست: در برابر روز صفر، بهترین کار دفاع در عمق و تشخیص است؛ در برابر N-day، کار مشخصی وجود دارد که انجام نشده است.
و نکته‌ی صادقانه‌ای که کمتر گفته میشود: N-dayها عامل رخنههای واقعی بسیار بیشتری از روز صفر هستند. مهاجم انگیزه‌دار برای ورود به یک برنامه‌ی وب معمولاً به آسیبپذیری ناشناخته نیازی ندارد؛ اسکن انبوه اینترنت برای نسخههای وصله‌نشده‌ی شناختهشده به‌مراتب ارزان‌تر است. دو نمونه‌ی مشهوری که OWASP هم در دسته‌ی A03:2025 به آنها اشاره میکند، سال‌ها پس از انتشار وصله همچنان قربانی می‌گرفتند: Log4Shell با شناسه‌ی CVE-2021-44228 و RCE در Struts 2 با شناسه‌ی CVE-2017-5638.
پیامد مدیریتی روشن است: بودجه‌ای که برای «دفاع در برابر روز صفر» صرف میشود، اگر فرایند وصله‌ی شما ضعیف است، در جای اشتباهی خرج شده. تفکیک کامل‌تر این مفاهیم در مقاله‌ی آسیبپذیری روز صفر و در دانشنامه‌ی zero-day آمده است.
آسیبپذیری، باگ و پیکربندی نادرست: کدام کدام است؟
سه تعبیر که مرتب با هم اشتباه می‌شوند:
- باگ رفتاری است که با مشخصات مورد انتظار نمی‌خواند. هر آسیبپذیری امنیتی یک باگ است، اما هر باگ آسیبپذیری نیست؛ معیار تفکیک این است که آیا آن رفتار غلط، یک مرز اعتماد یا امنیتی را رد میکند یا نه. توضیح کامل در باگ چیست.
- پیکربندی نادرست آسیب‌پذیری‌ای است که در کد نیست: هدر امنیتی غایب، دسترسی عمومی به فهرست دایرکتوری، پیام خطای پرجزئیات، اعتبارنامه‌ی پیش‌فرض. این دسته در OWASP Top 10:2025 با صعود از رتبه‌ی ۵ به رتبه‌ی ۲ بزرگ‌ترین جابه‌جایی نسخه را داشت — و معمولاً ارزانترین دسته برای رفع است، چون تغییر کد لازم ندارد.
- نقص طراحی در معماری است، نه در سطر کد. جمله‌ی خودِ OWASP بهترین توضیح است: یک طراحی امن میتواند نقص پیاده‌سازی داشته باشد، اما یک طراحی ناامن را هیچ پیاده‌سازی بی‌نقصی اصلاح نمیکند.
این تفکیک روی چه کسی باید مشکل را حل کند اثر مستقیم دارد: باگ کد به توسعه‌دهنده می‌رود، پیکربندی نادرست به تیم زیرساخت، و نقص طراحی به جلسه‌ی معماری و مدل‌سازی تهدید.
با آسیب‌پذیری‌ها در عمل چه باید کرد؟
یک مسیر عملی و قابل اجرا، مستقل از اندازه‌ی سازمان:
- موجودی دارایی بسازید. چیزی را که نمی‌دانید وجود دارد، نمی‌توانید ایمن کنید. فهرست دامنه‌ها، زیردامنه‌ها، APIها و سرویس‌های عمومی، نقطه‌ی صفر است.
- کشف را پیوسته کنید. اسکن وابستگیها در خط لوله، اسکن پیکربندی، و رصد هشدارهای آسیبپذیری اجزایی که استفاده می‌کنید.
- اولویت را با سه ورودی تعیین کنید: شدت (CVSS)، بهرهبرداری واقعی (فهرست CISA KEV و شواهد میدانی)، و اهمیت دارایی در کسبوکار شما.
- SLA رفع تعریف کنید و آن را بر اساس باند شدت بنویسید، نه احساس. جدول نمونه در مدیریت آسیبپذیری آمده است.
- راستی‌آزمایی کنید. «بسته شد» بدون آزمون مجدد، یک ادعا است؛ آزمون مجدد بخش استانداردی از یک تعامل حرفه‌ای است.
- آسیبپذیریهایی را که اسکنر پیدا نمیکند جدی بگیرید. کنترل دسترسی، منطق کسبوکار و زنجیره‌های چندمرحله‌ای فقط با آزمون دستی کشف می‌شوند؛ این تفاوت بنیادی اسکن با تست نفوذ است.
اگر نقطه‌ی شروع ندارید، ترتیب پیشنهادی ساده است: ابتدا چک‌لیست امنیتی برای موارد ارزان و پرتکرار، سپس تست نفوذ وب برای یافته‌های عمیق‌تر با اثبات اثر.
پرسش‌های متداول
آسیبپذیری چیست به زبان ساده؟
ضعفی در یک سامانهی مشخص که کسی میتواند از آن برای انجام کاری که مجاز نیست استفاده کند — خواندن دادهی دیگران، تغییر اطلاعات، یا از کار انداختن سرویس. تأکید روی «مشخص» و «قابل استفاده» است: یک الگوی خطای عمومی، ضعف (CWE) است و وقتی در نسخه و پیکربندی معینی قابل بهرهبرداری شد، آسیبپذیری میشود.
تفاوت CVE و CWE چیست؟
CWE کلاس ضعف است — مثل CWE-89 برای تزریق SQL — و مستقل از محصول. CVE شناسه‌ی یک آسیبپذیری مشخص در یک محصول مشخص است، مثل CVE-2021-44228 برای Log4Shell. یک CWE میتواند هزاران CVE داشته باشد. یافته‌های تست نفوذ روی کد اختصاصی شما معمولاً CWE دارند و CVE ندارند.
امتیاز CVSS چیست و آیا همان ریسک است؟
CVSS چارچوب امتیازدهی شدت فنی است؛ ریسک نیست. امتیاز پایه چیزی از ارزش دارایی شما و از فعالیت مهاجمان نمیداند. نسخهی ۴٫۰ برای همین دو گروه Threat و Environmental دارد و با نامگذاری CVSS-B/BT/BE/BTE مشخص میکند امتیاز اعلامشده بر چه پایهای محاسبه شده است.
انواع آسیبپذیری سایت کداماند؟
در سطح کلاس، دستهبندی مرجع OWASP Top 10:2025 است: کنترل دسترسی شکسته، پیکربندی نادرست، نقصهای زنجیرهی تأمین، خطاهای رمزنگاری، تزریق، طراحی ناامن، خطاهای احراز هویت، نقص یکپارچگی، نقص ثبت رخداد و هشدار، و مدیریت نادرست شرایط استثنایی. در سطح محل بروز هم میتوان آنها را به کد اختصاصی، وابستگیها، پیکربندی، زیرساخت و فرایند تقسیم کرد.
تفاوت آسیبپذیری روز صفر و N-day چیست؟
روز صفر یعنی وصلهای وجود ندارد. N-day یعنی وصله منتشر شده اما نصب نشده است. اگر روی سرور شما نسخهای قدیمی از یک کتابخانه نصب است که وصلهاش شش ماه پیش آمده، آن روز صفر نیست؛ N-day است. در عمل هم N-dayها عامل رخنههای بیشتری هستند، چون اسکن انبوه برای نسخههای وصلهنشده برای مهاجم ارزانترین راه است.
چطور بفهمم سایت من چه آسیبپذیریهایی دارد؟
سه لایه لازم است: اسکن خودکار برای اجزای شناختهشده و پیکربندی، بازبینی کد برای الگوهای خطرناک، و آزمون دستی برای کنترل دسترسی و منطق کسبوکار که هیچ ابزاری آنها را کامل پیدا نمیکند. برای شروع بررسی امنیت سایت و برای ارزیابی کامل تست نفوذ وب.
منابع
علیرضا کیا
متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیره‌سازی ناامن، تخصص اوست.