CVE یا Common Vulnerabilities and Exposures یکی از بنیادی‌ترین استانداردهای امنیت سایبری است که به هر آسیب‌پذیری یک شناسه‌ی یکتا می‌دهد. بدون CVE، اشاره به یک آسیب‌پذیری خاص در میان تیم‌های امنیتی، ابزارها و سازمان‌ها تقریباً غیرممکن بود. CVE (Common Vulnerabilities and Exposures) به‌عنوان یک زبان مشترک عمل می‌کند که به همه‌ی بازیگران اکوسیستم امنیت اجازه می‌دهد درباره‌ی یک آسیب‌پذیری خاص با اطمینان صحبت کنند. CVE تنها یک شناسه نیست؛ بخشی از یک اکوسیستم گسترده‌تر شامل NVD، CVSS، CWE و CISA KEV است. در این راهنما، ساختار CVE، چرخه‌ی انتشار، ارتباط با سایر استانداردها و نقش آن در مدیریت آسیب‌پذیری سازمانی بررسی می‌شود.

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

CVE چیست و چه مسئله‌ای را حل می‌کند

CVE یا Common Vulnerabilities and Exposures یک استاندارد است که به هر آسیب‌پذیری عمومی‌شده، یک شناسه‌ی یکتا اختصاص می‌دهد. این استاندارد توسط MITRE مدیریت می‌شود و توسط CNA (CVE Numbering Authority) در سراسر جهان پشتیبانی می‌شود.

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

ویژگی‌های کلیدی CVE:

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

CVE یک برچسب نیست؛ یک مرجع جهانی است که به تیم‌های امنیتی، توسعه‌دهندگان و مدیران سیستم اجازه می‌دهد درباره‌ی یک آسیب‌پذیری خاص با دقت صحبت کنند.

ساختار شناسه‌ی CVE

ساختار شناسه‌ی CVE در طول زمان تکامل یافته است. دو فرمت اصلی وجود دارد:

فرمت قدیمی (پیش از ۲۰۱۴)

CVE-YYYY-NNNN
  • CVE: پیشوند ثابت.
  • YYYY: سال اختصاص شناسه.
  • NNNN: شماره‌ی ترتیبی چهاررقمی.

فرمت جدید (پس از ۲۰۱۴)

CVE-YYYY-NNNNNNN
  • CVE: پیشوند ثابت.
  • YYYY: سال اختصاص شناسه.
  • NNNNNNN: شماره‌ی ترتیبی با طول متغیر (حداقل ۴ رقم، بدون سقف).

نمونه‌ها:

CVE-2021-44228     # Log4Shell
CVE-2017-0144      # EternalBlue
CVE-2022-22965     # Spring4Shell
CVE-2014-6271      # Shellshock

چرخه‌ی انتشار CVE

انتشار یک CVE شامل چند مرحله است:

  1. کشف آسیب‌پذیری: محقق امنیتی، فروشنده یا محقق مستقل آسیب‌پذیری را کشف می‌کند.
  2. گزارش به CNA: آسیب‌پذیری به یک CNA (اغلب فروشنده‌ی نرم‌افزار) گزارش می‌شود.
  3. بررسی و تأیید: CNA آسیب‌پذیری را بررسی و تأیید می‌کند.
  4. اختصاص شناسه: یک CVE ID اختصاص داده می‌شود (در حالت Reserved).
  5. انتشار عمومی: جزئیات آسیب‌پذیری منتشر می‌شود.
  6. به‌روزرسانی NVD: NVD اطلاعات را غنی‌سازی می‌کند (CVSS، CWE، منابع).
  7. انتشار وصله: فروشنده وصله را منتشر می‌کند.
  8. پیگیری: پایش برای بهره‌برداری فعال و به‌روزرسانی اطلاعات.

مراحل ۴ و ۵ می‌توانند با تأخیر انجام شوند، به‌ویژه در آسیب‌پذیری‌های حساس. در این حالت، CVE در وضعیت RESERVED باقی می‌ماند تا اطلاعات کامل شود.

NVD: پایگاه داده‌ی ملی آسیب‌پذیری‌ها

NVD یا National Vulnerability Database پایگاه داده‌ای است که توسط NIST مدیریت می‌شود و اطلاعات CVE را غنی‌سازی می‌کند. NVD برای هر CVE، اطلاعات اضافی فراهم می‌کند:

  • CVSS Score: امتیاز شدت آسیب‌پذیری.
  • CWE: نوع ضعف.
  • CPE: محصولات تحت تأثیر.
  • References: منابع خارجی (گزارش‌های فروشنده، مقالات).
  • Configuration: شرایط بهره‌برداری.

NVD یکی از مهم‌ترین منابع برای تیم‌های امنیتی است، چون اطلاعاتی فراتر از CVE اصلی فراهم می‌کند.

CVSS: امتیازدهی شدت

CVSS یا Common Vulnerability Scoring System یک استاندارد برای امتیازدهی شدت آسیب‌پذیری‌ها است. امتیاز CVSS از ۰ تا ۱۰ متغیر است:

امتیاز سطح شدت اقدام پیشنهادی
0.0 None بدون اقدام
0.1–3.9 Low رفع در چرخه‌ی عادی
4.0–6.9 Medium رفع در زمان‌بندی مشخص
7.0–8.9 High رفع در اولویت بالا
9.0–10.0 Critical رفع فوری (۲۴–۴۸ ساعت)

CVSS در سه نسخه اصلی وجود دارد: v2، v3 و v4. نسخه‌ی v3 و v4 دقت بالاتری در ارزیابی دارند. CVSS v4 در سال ۲۰۲۳ معرفی شد و شامل معیارهای جدید مانند Safety و Automatable است.

محدودیت‌های CVSS

  • CVSS شدت را می‌سنجد، نه ریسک واقعی سازمان.
  • ارزیابی بر اساس شرایط عمومی، نه محیط خاص.
  • ممکن است آسیب‌پذیری با CVSS پایین، در یک سازمان خاص بسیار خطرناک باشد.
  • بهره‌برداری فعال، در CVSS لحاظ نمی‌شود.

به همین دلیل، CVSS باید در کنار معیارهای دیگر مانند CISA KEV، EPSS و ریسک سازمانی استفاده شود.

CWE: طبقه‌بندی ضعف‌ها

CWE یا Common Weakness Enumeration یک طبقه‌بندی از انواع ضعف‌های نرم‌افزاری است. برخلاف CVE که به یک آسیب‌پذیری خاص اشاره دارد، CWE به نوع ضعف اشاره می‌کند.

نمونه‌های CWE:

  • CWE-79: Cross-site Scripting (XSS).
  • CWE-89: SQL Injection.
  • CWE-352: Cross-Site Request Forgery (CSRF).
  • CWE-22: Path Traversal.
  • CWE-502: Deserialization of Untrusted Data.

هر CVE اغلب با یک یا چند CWE مرتبط است. این ارتباط، درک نوع ضعف و روش‌های پیشگیری را ساده‌تر می‌کند. برای مطالعه‌ی بیشتر، پست‌های حملات XSS چیست و چگونه جلوگیری کنیم، حملات SQL Injection و راه‌های مقابله و CSRF چیست و چگونه از آن جلوگیری کنیم مفید هستند.

CISA KEV: آسیب‌پذیری‌های بهره‌برداری‌شده

CISA KEV یا Known Exploited Vulnerabilities Catalog فهرستی از آسیب‌پذیری‌هایی است که به‌صورت فعال در دنیای واقعی بهره‌برداری شده‌اند. این فهرست توسط CISA (آژانس امنیت سایبری و زیرساخت آمریکا) مدیریت می‌شود.

KEV یکی از مهم‌ترین منابع برای اولویت‌بندی است، چون:

  • بهره‌برداری فعال را تأیید می‌کند.
  • اولویت را از CVSS بالاتر می‌برد.
  • مهلت رفع مشخص تعیین می‌کند (برای سازمان‌های فدرال آمریکا).

ترکیب KEV با CVSS و EPSS، دقیق‌ترین تصویر از ریسک واقعی را ارائه می‌دهد.

نقش CVE در مدیریت آسیب‌پذیری سازمانی

CVE در فرآیند مدیریت آسیب‌پذیری سازمانی چند نقش کلیدی دارد:

  1. شناسایی: ابزارهای اسکن آسیب‌پذیری، نتایج را بر اساس CVE گزارش می‌کنند.
  2. اولویت‌بندی: بر اساس CVSS، KEV و EPSS.
  3. پیگیری: ردیابی وضعیت رفع برای هر CVE.
  4. ارتباطات: زبان مشترک بین تیم‌ها.
  5. گزارش‌دهی: گزارش‌های مدیریتی بر اساس CVE.
  6. انطباق: اثبات رفع آسیب‌پذیری‌های بحرانی برای نهادهای نظارتی.

فرآیند مدیریت CVE در سازمان

1. Inventory: شناسایی تمام سیستم‌ها و نرم‌افزارها
2. Scanning: اسکن دوره‌ای با ابزارهای تخصصی
3. Mapping: نگاشت یافته‌ها به CVE
4. Prioritization: اولویت‌بندی بر اساس CVSS + KEV + EPSS + ریسک سازمانی
5. Remediation: رفع آسیب‌پذیری‌ها
6. Verification: تأیید رفع
7. Reporting: گزارش‌دهی به مدیریت و نهادهای نظارتی

برای مطالعه‌ی بیشتر درباره‌ی روش‌های اولویت‌بندی، پست چگونه آسیب‌پذیری‌ها را رتبه‌بندی و رفع کنیم مرجع کاملی است.

پرسش‌های پرتکرار

آیا هر آسیب‌پذیری CVE دارد؟

خیر. تنها آسیب‌پذیری‌هایی که عمومی‌شده و تأیید شده‌اند، CVE می‌گیرند. بسیاری از آسیب‌پذیری‌های داخلی یا ناشناخته، CVE ندارند.

آیا CVE و CVSS یکی هستند؟

خیر. CVE یک شناسه است، CVSS یک سیستم امتیازدهی شدت. هر CVE ممکن است چند امتیاز CVSS داشته باشد (Base، Temporal، Environmental).

آیا CVE به‌معنای بهره‌برداری فعال است؟

خیر. بیشتر CVEها بهره‌برداری فعال ندارند. CISA KEV فهرست آسیب‌پذیری‌های بهره‌برداری‌شده را نگه می‌دارد.

چگونه CVE را در پروژه‌های خود ردیابی کنیم؟

با ابزارهای SCA (Software Composition Analysis) مانند Dependabot، Snyk و OWASP Dependency-Check. این ابزارها وابستگی‌ها را بررسی و CVEهای مرتبط را گزارش می‌کنند.

آیا CVE برای آسیب‌پذیری‌های صفر روز هم اختصاص می‌یابد؟

بله، اما اغلب پس از کشف عمومی. در طول پنجره‌ی Zero Day، آسیب‌پذیری ممکن است CVE نداشته باشد یا در وضعیت RESERVED باشد.

آیا CVE به‌تنهایی برای اولویت‌بندی کافی است؟

خیر. CVE باید در کنار CVSS، CISA KEV، EPSS و ریسک سازمانی استفاده شود.

آیا CVE در همه‌ی کشورها استفاده می‌شود؟

بله. CVE یک استاندارد جهانی است و توسط ابزارها و سازمان‌ها در سراسر جهان استفاده می‌شود.

چگونه در فرآیند CVE مشارکت کنیم؟

با گزارش آسیب‌پذیری‌ها به CNA یا MITRE، یا تبدیل شدن به یک CNA.

اشتباهات رایج

نشانه علت ریشه‌ای راه‌حل
تکیه فقط بر CVSS نادیده گرفتن KEV و EPSS ترکیب چند معیار
نادیده گرفتن CVEهای با امتیاز متوسط تمرکز بر Critical ارزیابی ریسک سازمانی
عدم پایش CVEهای جدید فرآیند دستی Feed خودکار CVE
عدم ردیابی CVE در وابستگی‌ها فقدان SCA SCA خودکار در CI/CD
تأخیر در رفع CVEهای بحرانی فرآیند کند SLA مشخص برای رفع
عدم مستندسازی غفلت از انطباق گزارش‌دهی منظم

ملاحظات معماری پیشرفته

در سطح سازمانی، استفاده‌ی مؤثر از CVE نیازمند یک استراتژی جامع است:

1. SBOM (Software Bill of Materials): فهرست کامل وابستگی‌های نرم‌افزاری برای نگاشت CVEها.

2. SCA در CI/CD: بررسی خودکار وابستگی‌ها در هر Build.

3. Threat Intelligence Integration: ترکیب CVE با KEV، EPSS و منابع دیگر.

4. Vulnerability Management Platform: پلتفرم متمرکز برای مدیریت چرخه‌ی آسیب‌پذیری.

5. Automation: رفع خودکار آسیب‌پذیری‌ها در محیط‌های غیرحساس.

6. Continuous Monitoring: پایش مستمر CVEهای جدید مرتبط با دارایی‌های سازمان.

7. Vendor Coordination: ارتباط مستقیم با فروشندگان برای وصله‌های زودهنگام.

8. Metrics and KPIs: اندازه‌گیری زمان رفع (MTTR) و نرخ رفع.

CVE یک شناسه است، نه یک راه‌حل. ارزش واقعی آن در فرآیند تفسیر، اولویت‌بندی و رفع است.

در انتها، باید پذیرفت که CVE یکی از بنیادی‌ترین اجزای اکوسیستم امنیت است. بدون آن، هماهنگی بین تیم‌ها، ابزارها و سازمان‌ها تقریباً غیرممکن بود. اما CVE به‌تنهایی کافی نیست و باید در کنار سایر استانداردها و فرآیندهای سازمانی استفاده شود.

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

💡 نکته‌ی پایانی: CVE یک زبان مشترک است، نه یک راه‌حل. ارزش آن در فرآیندی است که پیرامون آن ساخته می‌شود.