خواندن گزارش امنیتی · رکوردهای عمومی
وضعیت رکورد CVE چه می‌گوید و چه چیزی هنوز باید بررسی شود؟
در گزارشی نوشته‌اند «سامانه این شرکت آسیب‌پذیر است» و کنارش یک شناسه CVE گذاشته‌اند. با دیدن شناسه هنوز نمی‌توان این نتیجه را پذیرفت. باید معلوم شود رکورد اکنون چه وضعیتی دارد، درباره کدام محصول و نسخه حرف می‌زند و چه مدرکی آن نسخه را به سامانه مورد بحث وصل می‌کند.
برای خواندن دقیق گزارش، سه نتیجه را جدا بنویسید: محتوای رکورد، انطباق آن با محصول، و آنچه درباره نصب واقعی می‌دانیم. ممکن است هشدار امنیتی کاملاً معتبر باشد، اما ارتباطش با سامانه‌ای که نام برده شده هنوز ثابت نشده باشد.
برچسب‌های رکورد را چطور بخوانیم؟
شناسه را در وب‌سایت برنامه CVE باز کنید. نشانی رکورد، زمان مشاهده، وضعیت فعلی و ارجاع‌های مرتبط را نگه دارید؛ تصویر بریده‌شده یا خلاصه موتور جست‌وجو ممکن است اطلاعات تازه را نشان ندهد.
- Reserved: شناسه اختصاص یافته، اما جزئیات عمومی رکورد هنوز منتشر نشده است. شاید اطلاعیه‌ای از قبل به آن اشاره کند؛ همان اطلاعیه را بخوانید و برای بخش خالی رکورد توضیح نسازید.
- Published: اطلاعات رکورد منتشر شده است. اکنون باید محدوده محصول، نسخه‌ها و شرط‌های ذکرشده را بخوانید.
- Rejected: علت رد را بررسی کنید و از آن رکورد به‌عنوان ارجاع فعال آسیب‌پذیری استفاده نکنید. اگر جایگزینی معرفی شده، به همان رکورد بروید.
طبق قواعد رسمی نهادهای صادرکننده CVE، رد شدن می‌تواند علت‌هایی مانند تخصیص تکراری یا شناسه نادرست داشته باشد. پس نمی‌توان از روی Rejected به‌تنهایی گفت مشکل فنی وجود نداشته است؛ شاید فقط پرونده تکراری کنار گذاشته شده باشد.
برچسب Disputed را هم همراه توضیحش ثبت کنید. سیاست رسمی رسیدگی به اختلاف درباره اختلاف بر سر اعتبار یا نحوه رسیدگی به رکورد توضیح می‌دهد. این برچسب به‌خودی‌خود نه «قطعاً نادرست» است و نه «قطعاً قابل بهره‌برداری». وضعیت انتشار و اختلاف بر سر محتوا را در دو جای جدا بنویسید.
صف بررسی NVD، نتیجه آزمایش نرم‌افزار نیست
پایگاه NVD اطلاعات تکمیلی به رکوردهای CVE اضافه می‌کند. در راهنمای وضعیت‌های NVD، عبارت‌هایی مثل Awaiting Enrichment و Not Scheduled به فرایند تکمیل اطلاعات مربوط‌اند. در خروجی API ممکن است نام‌های Awaiting Analysis یا Deferred دیده شود. انتشار رکورد الزاماً به معنی پایان این بررسی نیست.
هنگام خواندن هر برچسب، نام سامانه‌ای را که آن را نمایش داده نیز یادداشت کنید. نبود امتیاز یا تکمیل‌نشدن بررسی پایگاه داده، تأیید امن‌بودن نرم‌افزار نیست. از طرف دیگر، تکمیل اطلاعات NVD هم به این معنا نیست که نصب واقعی شرکت مورد نظر آزمایش شده است.
تمرین: ارجاع را اصلاح کرده‌ایم؛ آیا نتیجه هم درست شد؟
مثال کاملاً ساختگی: یادداشت بررسی یک تأمین‌کننده، نرم‌افزار فرضی «دفتر نارنج» را آسیب‌پذیر معرفی کرده و به پرونده آموزشی «الف» ارجاع داده است. الف اکنون به دلیل تکراری‌بودن رد شده و به «ب» اشاره می‌کند. ب نسخه‌های قبل از ۳٫۲ را، با یک شرط مشخص در پیکربندی، تحت تأثیر معرفی کرده است. در برگه تحویل نسخه ۳٫۲ آمده است. این نام‌ها و شماره‌ها واقعی نیستند و هیچ سامانه‌ای آزمایش نشده است.
ارجاع الف را به ب اصلاح کنید، اما همان‌جا متوقف نشوید. «قبل از ۳٫۲» با «۳٫۲ و نسخه‌های قدیمی‌تر» فرق دارد. متن دقیق محدوده و استثناهای اطلاعیه سازنده را بخوانید. سپس ببینید سند تحویل درباره نصب فعلی چه چیزی را واقعاً ثابت می‌کند.
اگر فهرست معتبر و به‌روز نرم‌افزارهای نصب‌شده، نسخه ۳٫۲ را تأیید کند و این نسخه خارج از محدوده ب باشد، استدلال نسخه‌ای یادداشت پشتیبانی نمی‌شود. این نتیجه فقط درباره همین مورد است؛ به معنی بی‌نقص‌بودن محصول نیست.
اگر سند تحویل قدیمی باشد و نسخه نصب‌شده را ندانیم، نتیجه «نامشخص» است. باید از مسئول مجاز سامانه، مدرک فعلی نسخه و پیکربندی را گرفت. اگر مدرک تازه یک نسخه مشمول هشدار را نشان دهد، شرط پیکربندی را نیز بررسی کنید و یافته را به تیم امنیت مسئول بسپارید. تطبیق نسخه به‌تنهایی خبر از نفوذ موفق نمی‌دهد.
در هر سه حالت، عامل تعیین‌کننده مدرک مربوط به نصب واقعی بود. جست‌وجوی شناسه نمی‌تواند جای اطلاعاتی را بگیرد که اصلاً درباره آن نصب در دست نداریم.
یادداشتی بنویسید که با شواهد تازه قابل اصلاح باشد
برای هر مورد این اطلاعات را کنار هم بگذارید:
- شناسه و نشانی رکورد فعلی؛ وضعیت انتشار و علت رد یا اختلاف.
- اطلاعیه سازنده، محدوده نسخه و شرط‌های مؤثر.
- مدرک مربوط به محصول، نسخه و پیکربندی نصب واقعی.
- تاریخ مدرک، زمان مشاهده شما و نتیجه محدود به همین شواهد.
- بررسی‌های انجام‌نشده و مدرکی که برای ادامه لازم است.
اگر تنها مدرک شما نام نرم‌افزار در یک بنر سرویس است، ابتدا راهنمای خواندن نتیجه Shodan را ببینید. اگر مسئله اتصال یک بسته به کد منبع است، بررسی منشأ بسته مسیر دیگری دارد.
این یادداشت را به‌عنوان یک یافته در گزارش قابل پیگیری اوسینت قرار دهید. خواننده باید بتواند با رسیدن یک اطلاعیه یا مدرک نسخه جدید، همان نتیجه را اصلاح کند. این روش، خواندن اسناد عمومی است؛ اسکن شبکه، آزمایش بهره‌برداری یا تأیید رخداد امنیتی محسوب نمی‌شود.
انتشار: ۲۴ اکتبر ۲۰۲۶ · تحریریه اوسینت جت
ادامه مسیر اوسینت
سرنخ‌های خام را به یک تحقیق ساختارمند در اوسینت جت تبدیل کنید
برای نتیجه بهتر، فقط به یک سرنخ اکتفا نکنید. شماره تلفن، ایمیل، یوزرنیم، دامنه، نام شرکت، تصویر، شهر، لینک شبکه اجتماعی و توضیح زمینه پرونده را کنار هم قرار دهید تا موتور اطلاعاتی اوسینت جت تحلیل دقیق‌تری بسازد.