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

در یکی از پروژه‌ها، تیمی پس از دریافت هشدار CVE، نسخه‌ای از یک کتابخانه را ارتقا داد، اما بعداً مشخص شد که آسیب‌پذیری روی نسخه‌ی دیگری از آن کتابخانه بوده است. دلیل این اشتباه، عدم توجه به بخش CPE در گزارش CVE بود. تجربه نشان داد که خواندن دقیق گزارش، پیش از اقدام، بخش اصلی کار است.

آناتومی یک گزارش CVE

یک گزارش CVE در NVD شامل بخش‌های متعددی است. شناخت این بخش‌ها، پیش‌نیاز خواندن مؤثر است:

  • CVE ID: شناسه‌ی یکتای آسیب‌پذیری.
  • Description: توضیح مختصر آسیب‌پذیری.
  • Published Date: تاریخ انتشار عمومی.
  • Last Modified: تاریخ آخرین به‌روزرسانی.
  • Source: مرجع گزارش‌دهنده (اغلب CNA).
  • CVSS Scores: امتیازهای CVSS (v2، v3، v4).
  • CWE: نوع ضعف.
  • References: لینک‌های خارجی.
  • CPE: محصولات تحت تأثیر.
  • Configurations: شرایط بهره‌برداری.
  • Known Exploited: آیا در CISA KEV است؟

بخش Description

توضیح (Description) اولین بخشی است که باید خوانده شود. اما این بخش اغلب کوتاه و فنی است و به‌تنهایی برای تصمیم‌گیری کافی نیست. نکات کلیدی در خواندن Description:

  • نوع آسیب‌پذیری: XSS، SQL Injection، RCE، DoS، و غیره.
  • سطح دسترسی مورد نیاز: بدون احراز هویت، با احراز هویت، دسترسی محلی.
  • شرایط بهره‌برداری: آیا نیاز به تنظیمات خاص است؟
  • محصول تحت تأثیر: نام محصول و نسخه.

نمونه‌ی Description برای Log4Shell:

Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.

نکات کلیدی از این Description:

  • محصول: Apache Log4j2.
  • نسخه‌های تحت تأثیر: 2.0-beta9 تا 2.15.0 (به‌جز نسخه‌های امن).
  • نوع: RCE (Remote Code Execution).
  • شرایط: دسترسی به Log Message یا Parameter.
  • نیاز به فعال بودن: Message Lookup Substitution.

CPE: محصولات تحت تأثیر

CPE یا Common Platform Enumeration یک استاندارد برای شناسایی محصولات و نسخه‌ها است. در گزارش CVE، بخش CPE تعیین می‌کند که کدام محصولات و نسخه‌ها تحت تأثیر هستند.

ساختار CPE:

cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other

نمونه:

cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*
  • a: Application.
  • apache: Vendor.
  • log4j: Product.
  • 2.14.1: Version.

نکته‌ی مهم: CPE می‌تواند شامل نسخه‌های بازه‌ای یا چندگانه باشد. در گزارش‌های NVD، این بخش اغلب به‌صورت Configurations نمایش داده می‌شود. برای توسعه‌دهندگان، تطبیق CPE با وابستگی‌های پروژه، گام حیاتی است.

تطبیق CPE با SBOM

اگر پروژه SBOM (Software Bill of Materials) داشته باشد، تطبیق CPE با آن، فرآیند را خودکار می‌کند. ابزارهای SCA مانند Dependabot، Snyk و OWASP Dependency-Check این کار را انجام می‌دهند.

CVSS: تفسیر امتیاز

CVSS امتیاز شدت آسیب‌پذیری را از ۰ تا ۱۰ ارائه می‌دهد. اما امتیاز پایه (Base Score) تنها بخشی از تصویر است. CVSS از سه گروه معیار تشکیل شده:

Base Metrics

  • Attack Vector (AV): Network، Adjacent، Local، Physical.
  • Attack Complexity (AC): Low، High.
  • Privileges Required (PR): None، Low، High.
  • User Interaction (UI): None، Required.
  • Scope (S): Unchanged، Changed.
  • Confidentiality (C): None، Low، High.
  • Integrity (I): None، Low، High.
  • Availability (A): None، Low، High.

Temporal Metrics

  • Exploit Code Maturity: Unproven، Proof-of-Concept، Functional، High.
  • Remediation Level: Official Fix، Temporary Fix، Workaround، Unavailable.
  • Report Confidence: Unknown، Reasonable، Confirmed.

Environmental Metrics

  • تنظیمات مخصوص سازمان.
  • تأثیر بر Confidentiality، Integrity، Availability در محیط خاص.

نکته‌ی مهم برای توسعه‌دهندگان: Base Score بالاتر، همیشه به‌معنای خطر بالاتر برای پروژه‌ی شما نیست. یک آسیب‌پذیری با CVSS ۹.۸ در یک کتابخانه‌ی غیرقابل دسترس از اینترنت، ممکن است برای پروژه‌ی شما ریسک کمتری از یک آسیب‌پذیری با CVSS ۷.۵ در یک کتابخانه‌ی مستقیم مواجه با کاربر داشته باشد.

References و منابع خارجی

بخش References شامل لینک به منابع خارجی است:

  • گزارش فروشنده: جزئیات رسمی از توسعه‌دهنده.
  • گزارش محقق: جزئیات فنی از کاشف آسیب‌پذیری.
  • گزارش وصله: Commit یا نسخه‌ی اصلاح.
  • گزارش تحلیلی: مقالات تحلیلی از شرکت‌های امنیتی.
  • PoC: Proof of Concept (در صورت انتشار).

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

Configurations و شرایط بهره‌برداری

بخش Configurations تعیین می‌کند که تحت چه شرایطی آسیب‌پذیری قابل بهره‌برداری است. این بخش می‌تواند شامل:

  • Operating System: سیستم‌عامل‌های تحت تأثیر.
  • Application: نرم‌افزارهای تحت تأثیر.
  • Hardware: سخت‌افزارهای تحت تأثیر.
  • Environment: شرایط محیطی.
  • AND/OR Nodes: ترکیب شرایط.

برای مثال، یک آسیب‌پذیری ممکن است تنها روی Apache نسخه‌ی خاص، روی Ubuntu، با PHP ۷.۴ قابل بهره‌برداری باشد. این جزئیات، تصمیم‌گیری را دقیق‌تر می‌کند.

گردش کار خواندن یک CVE

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

  1. Description: نوع و سطح خطر آسیب‌پذیری.
  2. CPE/Configurations: آیا محصولات و نسخه‌های پروژه‌ی شما تحت تأثیر هستند؟
  3. CVSS: امتیاز شدت، همراه با معیارهای Base.
  4. CWE: نوع ضعف (برای درک روش پیشگیری).
  5. References: جزئیات عمیق‌تر از فروشنده و محقق.
  6. KEV Check: آیا در فهرست CISA KEV است؟
  7. EPSS: احتمال بهره‌برداری در ۳۰ روز آینده.
  8. ارزیابی سازمانی: آیا آسیب‌پذیری بر دارایی‌های حیاتی اثر دارد؟
  9. تصمیم: رفع فوری، رفع زمان‌بندی‌شده، یا پذیرش ریسک.
  10. مستندسازی: ثبت تصمیم و اقدامات انجام‌شده.

ابزارهای کمکی برای توسعه‌دهندگان

ابزارهای متعددی برای خواندن و پیگیری CVE وجود دارد:

ابزار کاربرد مناسب برای
NVD پایگاه داده‌ی اصلی CVE جستجوی دستی
MITRE CVE مرجع اصلی CVE جستجوی دقیق
Snyk SCA و هشدار CVE پروژه‌های نرم‌افزاری
Dependabot هشدار وابستگی‌های آسیب‌پذیر GitHub
OWASP Dependency-Check SCA متن‌باز CI/CD
Trivy اسکن کانتینر و وابستگی Kubernetes
Grype اسکن تصاویر کانتینر CI/CD
Vulners جستجوی CVE و آسیب‌پذیری تحقیق امنیتی 
# نمونه استفاده از Trivy برای اسکن یک تصویر کانتینر
trivy image myapp:latest

# نمونه استفاده از OWASP Dependency-Check
dependency-check --project myapp --scan ./

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

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

آیا همه‌ی CVEها به بهره‌برداری منجر می‌شوند؟

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

آیا CVSS بالا به‌معنای رفع فوری است؟

نه همیشه. باید شرایط محیطی، دسترسی، و اثر بر دارایی‌های حیاتی را نیز در نظر بگیرید.

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

با تطبیق CPE با SBOM یا وابستگی‌های پروژه. ابزارهای SCA این کار را خودکار انجام می‌دهند.

آیا باید همه‌ی CVEها را رفع کنم؟

خیر. باید بر اساس اولویت‌بندی (CVSS + KEV + EPSS + ریسک سازمانی) تصمیم بگیرید. برخی CVEها ممکن است قابل پذیرش باشند.

چند وقت یک‌بار باید CVEها را بررسی کرد؟

حداقل هفتگی برای دارایی‌های حیاتی. روزانه برای آسیب‌پذیری‌های بحرانی.

آیا NVD تنها منبع CVE است؟

خیر. منابع دیگری مانند GitHub Advisory، Snyk Vulnerability DB و Vulners نیز اطلاعات مشابهی ارائه می‌دهند. اما NVD جامع‌ترین است.

آیا CVE در کتابخانه‌های متن‌باز اهمیت بیشتری دارد؟

بله. چون کتابخانه‌های متن‌باز در پروژه‌های متعدد استفاده می‌شوند و آسیب‌پذیری در آن‌ها می‌تواند دامنه‌ی گسترده‌ای داشته باشد.

چگونه یک CVE را به درستی تفسیر کنیم بدون دانش عمیق امنیتی؟

با تمرکز بر Description، CPE، CVSS و References. برای تصمیم‌گیری نهایی، مشورت با تیم امنیت توصیه می‌شود.

اشتباهات رایج در خواندن CVE

نشانه علت ریشه‌ای راه‌حل
تکیه فقط بر CVSS نادیده گرفتن CPE و شرایط بررسی کامل گزارش
نادیده گرفتن CPE عدم تطبیق با پروژه تطبیق دقیق با SBOM
رفع CVEهای نامرتبط عدم بررسی نسخه تأیید تطبیق پیش از رفع
نادیده گرفتن References تمرکز فقط بر Description بررسی منابع عمیق‌تر
عدم بررسی KEV نادیده گرفتن بهره‌برداری فعال پایش CISA KEV
عدم مستندسازی غفلت از انطباق ثبت تصمیم و اقدامات
تأخیر در رفع CVEهای بحرانی فرآیند کند SLA مشخص برای رفع

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

در سطح معماری، خواندن CVE بخشی از یک فرآیند مستمر است:

1. SBOM: تولید و نگهداری SBOM برای تطبیق دقیق CVEها با وابستگی‌ها.

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

3. Threat Intelligence Feed: دریافت خودکار CVEهای مرتبط.

4. Vulnerability Management Platform: پلتفرم متمرکز برای ردیابی و اولویت‌بندی.

5. Risk-Based Prioritization: ترکیب CVSS، KEV، EPSS و ریسک سازمانی.

6. Automated Remediation: رفع خودکار در محیط‌های غیرحساس.

7. Metrics: اندازه‌گیری MTTR (Mean Time To Remediate) و نرخ رفع.

8. Continuous Learning: به‌روزرسانی مداوم دانش تیم درباره‌ی CVEهای جدید.

خواندن CVE یک مهارت است، نه یک وظیفه. هرچه این مهارت در تیم عمیق‌تر باشد، تصمیم‌گیری سریع‌تر و دقیق‌تر می‌شود.

در انتها، باید پذیرفت که CVE یک ابزار است و ارزش آن در تفسیر دقیق و اقدام مؤثر است. توسعه‌دهندگانی که CVE را با دقت می‌خوانند، سطح امنیت پروژه‌های خود را به‌طور معناداری افزایش می‌دهند.

اگر تجربه‌ای در خواندن CVE در پروژه‌های خود داشته‌اید، برای ما جالب است بدانیم کدام بخش بیشترین کمک را کرد: CPE، CVSS یا References. تجربه‌ی خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل متفاوتی برای تفسیر سریع CVE پیدا کرده‌اید که می‌تواند برای خواننده‌ی بعدی مفید باشد.

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