CORE · مفاهیم استاندارد شناسایی

CVE — شناسه‌ی استاندارد آسیب‌پذیری

Common Vulnerabilities and Exposures

CVE یک شناسه‌ی یکتا برای یک آسیب‌پذیری عمومی‌شده در یک محصول مشخص است — نه امتیاز شدت، نه اثبات اینکه سامانه‌ی شما قابل بهره‌برداری است.

تیم فنی پی‌هانتر

CVE چیست؟

CVE مخفف Common Vulnerabilities and Exposures است و در عمل دو چیز را نشان می‌دهد: یک برنامه‌ی جهانی برای نام‌گذاری آسیب‌پذیری‌ها که MITRE آن را اداره می‌کند، و یک شناسه با قالب CVE-YYYY-NNNNN که به یک آسیب‌پذیری عمومی‌شده در یک محصول مشخص اختصاص می‌یابد.

هدف این برنامه حل یک مشکل ساده اما پرهزینه بود: پیش از CVE، یک آسیب‌پذیری در پایگاه‌داده‌ی هر فروشنده نام دیگری داشت. یک شناسه‌ی مشترک، ارجاع بین ابزار اسکن، بولتن فروشنده، وصله و گزارش تست نفوذ را ممکن می‌کند.

و اینکه CVE چه چیزی نیست، به همان اندازه مهم است:

  • امتیاز نیست. شدت با CVSS بیان می‌شود، نه با شناسه‌ی CVE.
  • نوع ضعف نیست. طبقه‌بندی نوع ضعف کار CWE است.
  • اکسپلویت نیست و وجودش به‌معنای وجود کد بهره‌برداری عمومی نیست.
  • پوشش کامل نیست. آسیب‌پذیری‌های کد سفارشی یک سازمان — که بخش بزرگی از یافته‌های تست نفوذ وب را می‌سازند — هیچ CVE ندارند و هرگز نخواهند داشت.

CNA: چه کسی شناسه صادر می‌کند؟

شناسه‌های CVE به‌صورت توزیع‌شده صادر می‌شوند. CNA (CVE Numbering Authority) سازمانی است که در محدوده‌ی مشخصی می‌تواند شناسه اختصاص دهد: فروشندگان نرم‌افزار برای محصولات خودشان، تیم‌های CERT، و برخی برنامه‌های باگ‌بانتی و پژوهشی.

پیامدهای عملی این معماری برای کسی که گزارش می‌خواند:

  • کیفیت رکوردها یکسان نیست. توصیف، محدوده‌ی نسخه‌های متأثر و مرجع در رکوردهای مختلف عمق متفاوتی دارد.
  • محدوده‌ی نسخه‌ها همیشه دقیق نیست و همین باعث مثبت کاذب در ابزارهای تحلیل ترکیب نرم‌افزار می‌شود.
  • اگر در جریان یک آزمون، آسیب‌پذیری تازه‌ای در محصول یک تأمین‌کننده کشف شود، مسیر درست دریافت شناسه از CNA مربوطه در فرایند افشای مسئولانه است — نه انتشار عمومی.

خط لوله‌ی CVE به NVD و مسئله‌ی تأخیر

رکورد CVE در اصل حاوی شناسه، توصیف، محصولات متأثر و مراجع است. آنچه بیشتر کاربران انتظار دارند — امتیاز شدت، نگاشت به CWE و شناسه‌های نسخه‌ی محصول — در مرحله‌ی غنی‌سازی اضافه می‌شود، و شناخته‌شده‌ترین نهاد این کار NVD (پایگاه‌داده‌ی ملی آسیب‌پذیری NIST) است.

این جداسازی دو پیامد جدی دارد که در تصمیم‌گیری اهمیت دارند:

  • تأخیر. بین انتشار رکورد و کامل شدن غنی‌سازی فاصله وجود دارد. در این فاصله ممکن است آسیب‌پذیری بدون امتیاز یا بدون نگاشت CWE باشد، در حالی که در دنیای واقعی در حال بهره‌برداری است.
  • ناهمگونی داده. در مجموعه‌داده‌ای که OWASP برای نسخه‌ی ۲۰۲۵ فهرست Top 10 تحلیل کرد، از حدود ۲۲۰٬۰۰۰ رکورد CVE، حدود ۱۵۶ هزار رکورد امتیاز CVSS v3 داشتند و تنها حدود ۶ هزار رکورد امتیاز CVSS v4. یعنی نمی‌توان فرض کرد هر CVE امتیاز نسخه‌ی جاری CVSS را دارد.

نکته‌ی سوم درباره‌ی دقت نگاشت CWE: در روش‌شناسی فهرست CWE Top 25 نسخه‌ی ۲۰۲۵، از ۳۹٬۰۸۰ رکورد CVE بررسی‌شده، ۹٬۴۶۸ رکورد (۲۴٪) به‌عنوان نیازمند بازنگاشت علامت خوردند — چون نگاشت CWE آن‌ها بیش از حد کلی بود یا با ابزارهای تطبیق واژگانی هم‌خوانی نداشت. پس نگاشت CWE روی رکوردهای CVE را باید مفید اما ناکامل دانست.

تفاوت CVE، CWE و CVSS

این سه را مرتب با هم اشتباه می‌گیرند، در حالی که سه پرسش متفاوت را پاسخ می‌دهند:

استانداردبه چه پرسشی پاسخ می‌دهدمثال
CVE«کدام آسیب‌پذیری مشخص در کدام محصول؟»CVE-2021-44228 (نمونه‌ی مشهور در یک کتابخانه‌ی لاگ‌گیری جاوا)
CWE«این آسیب‌پذیری از چه نوع ضعفی است؟»مثلاً CWE-79 برای XSS یا CWE-89 برای تزریق SQL
CVSS«شدت فنی آن چقدر است؟»یک امتیاز عددی بین 0.0 و 10.0 با بردار سنجه‌ها

رابطه‌ی درست این است: CVE یک نمونه است، CWE کلاس آن نمونه، و CVSS معیار سنجش آن. در یک گزارش تست نفوذ وب، بیشتر یافته‌ها CWE و CVSS دارند اما CVE ندارند — چون آسیب‌پذیری در کد اختصاصی مشتری است، نه در یک محصول عمومی. یافته‌هایی که CVE دارند معمولاً از دسته‌ی A03:2025 نقص‌های زنجیره‌ی تأمین نرم‌افزار می‌آیند.

KEV: سیگنال «واقعاً در حال بهره‌برداری»

مشکل عملی تیم‌ها این نیست که CVE کم دارند؛ این است که بیش از حد دارند. فهرست KEV (Known Exploited Vulnerabilities) که CISA منتشر می‌کند، این انبوهی را با یک معیار روشن فیلتر می‌کند: آسیب‌پذیری‌هایی که شاهد بهره‌برداری واقعی برای آن‌ها وجود دارد.

این سیگنال کاربرد مستقیم در ابزار هم دارد: مجموعه‌ی قالب‌های Nuclei شامل حدود ۱٬۴۹۶ قالب مخصوص KEV است (بر پایه‌ی داده‌ی CISA و VulnCheck) — عددی که هفتگی تغییر می‌کند و باید همیشه با تاریخ نقل شود.

ترتیب اولویت‌بندی قابل دفاع، ترکیبی است از:

  1. در KEV هست؟ اگر بله، بالاترین اولویت — مستقل از امتیاز CVSS.
  2. در مسیر دسترسی مهاجم قرار دارد؟ کامپوننت آسیب‌پذیر در معرض اینترنت است یا فقط در شبکه‌ی داخلی؟
  3. قابلیت آسیب‌پذیر فعال است؟ بسیاری از CVEها فقط با پیکربندی یا افزونه‌ی خاصی قابل بهره‌برداری‌اند.
  4. کنترل جبرانی چه چیزی را پوشش می‌دهد؟ با توجه به محدودیت‌های WAF، این پوشش را نباید بیش از حد واقعی برآورد کرد.
  5. و در آخر، امتیاز پایه‌ی CVSS به‌عنوان یک ورودی، نه به‌عنوان تصمیم.

چارچوب سازمانی این کار در مدیریت آسیب‌پذیری توضیح داده شده است.

باور غلط: «CVE دارد، پس ما آسیب‌پذیریم»

باور غلط رایج

«اسکنر گفت این کامپوننت CVE دارد، پس سامانه‌ی ما قابل بهره‌برداری است» — و برعکسش: «هیچ CVE نداشتیم، پس امنیم». هر دو نادرست‌اند. وجود CVE به یک محصول و محدوده‌ی نسخه اشاره می‌کند؛ اینکه در محیط شما قابل بهره‌برداری باشد به نسخه‌ی دقیق، پیکربندی، فعال بودن قابلیت آسیب‌پذیر، دسترس‌پذیری مسیر رسیدن به آن و کنترل‌های جبرانی بستگی دارد. از طرف دیگر، آسیب‌پذیری‌های کد اختصاصی — IDOR، نقص کنترل دسترسی، منطق کسب‌وکار — هیچ‌وقت CVE نمی‌گیرند و در هیچ فهرست CVE پیدا نمی‌شوند. نبودن CVE، خبر خوبی نیست؛ فقط بی‌خبری است.

نتیجه‌ی عملی برای مدیر فنی: خروجی یک اسکنر CVE یک فهرست کاندید است، نه فهرست ریسک. تبدیل آن به ریسک نیازمند تأیید قابلیت بهره‌برداری در محیط واقعی است — یعنی همان کاری که یک تست نفوذ وب با PoC قابل تکرار انجام می‌دهد. آسیب‌پذیری‌های بدون CVE و بدون وصله هم دسته‌ی جداگانه‌ای دارند که در روز صفر شرح داده شده است.

پرسش‌های متداول

تفاوت CVE و CWE چیست؟

CVE یک نمونه‌ی مشخص است: یک آسیب‌پذیری در یک محصول و محدوده‌ی نسخه‌ی معین. CWE یک کلاس ضعف است: نوع اشتباهی که آن آسیب‌پذیری را ایجاد کرده، مثل تزریق SQL یا مجوزدهی ناقص. یک CWE می‌تواند به هزاران CVE نگاشت شود.

آیا هر CVE امتیاز CVSS دارد؟

نه لزوماً و نه همیشه با نسخه‌ی جاری. امتیازدهی بخشی از فرایند غنی‌سازی است و تأخیر دارد. در مجموعه‌داده‌ی OWASP برای Top 10:2025، از حدود ۲۲۰٬۰۰۰ رکورد CVE، حدود ۱۵۶ هزار امتیاز CVSS v3 داشتند و تنها حدود ۶ هزار امتیاز CVSS v4.

CVE بالا یعنی سامانه‌ی ما در خطر جدی است؟

نه به‌تنهایی. قابلیت بهره‌برداری در محیط شما به نسخه‌ی دقیق، پیکربندی، فعال بودن قابلیت آسیب‌پذیر و در معرض بودن مسیر دسترسی بستگی دارد. معیار عملی‌تر این است که آسیب‌پذیری در فهرست KEV باشد و کامپوننت در معرض اینترنت قرار داشته باشد.

آسیب‌پذیری‌های سایت اختصاصی ما هم CVE می‌گیرند؟

خیر. CVE برای محصولات و اجزای عمومی صادر می‌شود. یافته‌های کد اختصاصی شما — مثل IDOR یا نقص کنترل دسترسی — CVE نمی‌گیرند و در گزارش با شناسه‌ی CWE، امتیاز CVSS و یک PoC قابل تکرار مستند می‌شوند.

کاربرد عملی

برای استفاده‌ی درست از داده‌ی CVE در سازمان:

  • موجودی نرم‌افزاری (SBOM) داشته باشید. بدون فهرست دقیق اجزا و نسخه‌ها، پایش CVE بی‌معناست.
  • KEV را معیار اول اولویت‌بندی کنید، نه امتیاز پایه‌ی CVSS.
  • هر یافته‌ی اسکنر را با نسخه‌ی واقعی و پیکربندی محیط تأیید کنید؛ محدوده‌ی نسخه در رکوردهای CVE همیشه دقیق نیست.
  • در گزارش، شناسه‌ی CVE را همراه CWE و امتیاز CVSS بنویسید و مشخص کنید امتیاز با کدام نسخه‌ی CVSS محاسبه شده است.
  • برای یافته‌های کد اختصاصی انتظار CVE نداشته باشید؛ آن‌ها با CWE و CVSS مستند می‌شوند.
  • اگر آسیب‌پذیری تازه‌ای در محصول یک تأمین‌کننده یافتید، شناسه را در مسیر افشای مسئولانه از CNA مربوطه بگیرید.

واژه‌های مرتبط

→ بازگشت به دانشنامه
PUT IT TO THE TEST

امنیت سامانه‌ی شما را
به مهاجمان واگذار نکنید

تیم پی‌هانتر با دیدِ یک مهاجم واقعی، این آسیب‌پذیری‌ها و ده‌ها مورد دیگر را روی دارایی‌های شما می‌سنجد.