CVSS 10 پہلے patch ہو؟ KEV اور asset exposure فیصلہ بدل سکتے ہیں

مختصر جواب: نہیں، ہر CVSS 10 vulnerability کو لازماً پہلے patch نہیں کرنا چاہیے۔ پہلے تصدیق کریں کہ متاثرہ product اور version واقعی آپ کے ماحول میں موجود اور قابلِ رسائی ہیں؛ پھر KEV status، internet exposure اور asset کی کاروباری اہمیت دیکھیں۔ CVSS Base Score تکنیکی شدت بتاتا ہے، مگر آپ کے مقامی exposure، controls اور کاروباری نقصان کی مکمل تصویر نہیں دیتا۔

عملی queue میں معلوم استحصال اور attacker کی رسائی فیصلہ بدل سکتے ہیں: internet-facing KEV asset کو emergency lane مل سکتی ہے، جبکہ tested segmentation کے پیچھے موجود internal CVSS 10 asset طے شدہ test window تک رک سکتا ہے۔ EPSS کو non-KEV findings چھانٹنے، SSVC کو کارروائی کا outcome منظم کرنے اور CVSS کو severity اور آخری tie-breaker کے طور پر استعمال کریں۔

چار signals مختلف سوالوں کے جواب دیتے ہیں

CVSS vulnerability کی اندرونی severity، exploitability اور ممکنہ technical impact بیان کرتا ہے۔ Base Score deployed asset کی کاروباری اہمیت یا مقامی mitigations کے مطابق خود نہیں بدلتا، اس لیے صرف 10.0 سے patch order اخذ کرنا risk decision کو ادھورا چھوڑ دیتا ہے۔

KEV پیش گوئی نہیں بلکہ observed exploitation کا signal ہے۔ CISA کا KEV Catalog ان vulnerabilities کا authoritative record ہے جن کے عملی استحصال کا ثبوت ملا ہے، اور اداروں کو اسے prioritization framework کا input بنانے کی ہدایت دیتا ہے۔ کسی CVE کا catalog میں نہ ہونا اس کے محفوظ یا ناقابلِ استحصال ہونے کا ثبوت نہیں۔

EPSS اس احتمال کا تخمینہ دیتا ہے کہ کسی CVE کا قریب کی مدت میں عملی استحصال دیکھا جائے گا؛ یہ asset-specific business risk score نہیں۔ NIST کی exploitation-probability تحقیق کے مطابق EPSS کو enterprise remediation priority کے لیے اکیلا استعمال نہیں کرنا چاہیے، اور معلوم exploitation کا ثبوت EPSS پر فوقیت رکھتا ہے۔ تحقیق یہ بھی کہتی ہے کہ زیادہ احتمال والے candidates کو KEV items کے ساتھ، ممکنہ طور پر ان سے کم priority پر، remediation میں شامل کیا جا سکتا ہے۔

SSVC ایک اور severity score بنانے کے بجائے exploitation، technical impact اور mission context سے decision outcome نکالتا ہے۔ 17 جون 2026 کو NVD کی deployment update نے CVE feeds اور APIs میں CISA-ADP کا computed SSVC data اور affected-product information شامل ہونے کی تصدیق کی؛ NVD نے KEV entries کو enrichment کے لیے بھی ترجیح دی۔ یہ data مفید ہے، مگر مقامی reachability، asset owner اور controls پھر بھی ادارے کو خود شامل کرنا ہوتے ہیں۔

Score سے پہلے تین دروازے

1. کیا asset واقعی affected ہے؟ Installed version، package build، enabled feature اور vendor advisory ملائیں۔ غیر متاثر version کو کم score دینے کے بجائے remediation queue سے نکالیں اور disposition محفوظ کریں؛ نامعلوم حالت کے لیے owner اور discovery deadline مقرر کریں۔
2. کیا exploitation معلوم ہے؟ KEV match یا معتبر active-exploitation evidence ملے تو finding کو exploitation lane میں بھیجیں۔ ثبوت نہ ہو تو EPSS اور public exploit availability کو forecast سمجھیں، ثابت شدہ حملہ نہیں۔
3. کیا attacker پہنچ سکتا ہے، اور کامیابی کا نتیجہ کتنا اہم ہوگا؟ Direct internet path، authentication boundary، حاصل ہونے والے privileges، sensitive data، lateral movement اور service criticality درج کریں۔ یہی context برابر CVSS scores کی ترتیب بدل سکتا ہے۔

اس tree میں “not KEV” کا مطلب “not exploitable” نہیں، اور internet-facing ہونا بذاتِ خود vulnerability ثابت نہیں کرتا۔ Exposure صرف اس finding کی urgency بڑھاتا ہے جس کا affected status پہلے verify ہو چکا ہو۔

قابلِ نقل 100-point worksheet

یہ model کوئی NIST، CISA یا SSVC معیار نہیں بلکہ مقامی backlog کے لیے قابلِ ترمیم ادارتی worksheet ہے۔ ہر عدد کے ساتھ evidence field رکھیں: inventory record، scanner output، firewall path، vendor advisory یا control owner کے بغیر score کو حتمی نہ سمجھیں۔

• Exploitation، زیادہ سے زیادہ 35: KEV یا تصدیق شدہ active exploitation پر 35۔ Non-KEV کے لیے ادارہ اپنی EPSS bands بنا سکتا ہے: بلند band پر 20، درمیانی پر 10، کم پر صفر۔ KEV اور EPSS points جمع نہ کریں۔
• Internet exposure، زیادہ سے زیادہ 20: براہِ راست public reachability پر 20، محدود partner یا VPN path پر 10، verified internal-only path پر صفر۔ CMDB کا label اکیلا ثبوت نہیں؛ firewall یا external attack-surface evidence جوڑیں۔
• Privilege اور blast radius، زیادہ سے زیادہ 15: root، domain یا administrative control اور وسیع lateral movement پر 15؛ محدود user context پر 8؛ isolated معمولی اثر پر صفر۔
• Business criticality، زیادہ سے زیادہ 15: payment، identity، customer data یا لازمی operational service پر 15؛ معاون service پر 8؛ کم اثر والے asset پر صفر۔ مقامی تعریف business owner سے منظور ہونی چاہیے۔
• Compensating controls، زیادہ سے زیادہ 10: مؤثر control نہ ہو تو 10، جزوی segmentation یا قابلِ تصدیق monitoring ہو تو 5، tested control exploit path روکتا ہو تو صفر۔ Control urgency کم کر سکتا ہے، مستقل remediation obligation ختم نہیں کرتا۔
• CVSS tie-breaker، زیادہ سے زیادہ 5: critical band پر 5، high پر 3، اس سے کم پر صفر۔ اس محدود وزن سے severity شامل رہتی ہے مگر پوری queue پر حاوی نہیں ہوتی۔

کل score کے بعد patch test window الگ column میں لکھیں: emergency، تیز رفتار یا معمول کی change window؛ test owner؛ rollback plan؛ اور آخری قابلِ قبول deployment وقت۔ اگر patch فوری ممکن نہ ہو تو isolation، access restriction یا service disablement کو عارضی action اور واضح expiry کے ساتھ درج کریں۔

فرضی backlog میں ترتیب کیسے بدلتی ہے

درج ذیل مثالیں فرضی ہیں اور صرف اوپر والے worksheet کا حساب دکھاتی ہیں۔ Thresholds ہر ٹیم اپنی change capacity، regulatory obligations اور risk appetite کے مطابق مقرر کرے۔

• Edge VPN؛ KEV، direct internet، administrative impact، critical remote access، tested control موجود نہیں: 35 + 20 + 15 + 15 + 10 = 95۔ یہ فوری validation، mitigation یا patch کا پہلا امیدوار ہے، خواہ کسی دوسرے CVE کا CVSS زیادہ ہو۔
• Public CMS؛ non-KEV، بلند EPSS band، محدود user privilege، درمیانی business impact، control موجود نہیں: 20 + 20 + 8 + 8 + 10 = 66، پھر CVSS tie-breaker شامل ہوگا۔ یہ KEV lane سے نیچے مگر تیز test cycle میں جا سکتا ہے۔
• Internal database component؛ CVSS 10، non-KEV، کم EPSS band، admin impact، critical data، tested segmentation: 0 + 0 + 15 + 15 + 0 + 5 = 35۔ اسے نظرانداز نہیں کیا جائے گا، مگر verified isolation برقرار ہو تو 95-score edge asset پہلے آئے گا۔ اس فرق کے لیے affected version کی تصدیق بنیادی شرط ہے۔
• Scanner finding، مگر installed version متاثر نہیں: scoring روکیں، evidence کے ساتھ finding بند کریں اور audit trail محفوظ رکھیں۔ غیر متاثر asset remediation backlog کا حصہ نہیں ہونا چاہیے۔

Priority کو patch window میں تبدیل کریں

Queue تب قابلِ عمل بنتی ہے جب ہر اوپری row کے ساتھ affected status، asset owner، control evidence، test owner، rollback readiness اور deployment deadline موجود ہوں۔ KEV یا exploitation status بدلنے پر row دوبارہ کھولیں؛ EPSS band refresh کریں، مگر کسی معلوم exploitation کو کم EPSS کی وجہ سے نیچے نہ بھیجیں۔

بند item کے record میں asset اور affected version، patch یا mitigation کا وقت، validation result اور residual-risk owner درج ہوں۔ Exception کی expiry اور review date لازمی رکھیں، کیونکہ بے مدت “accepted risk” موجودہ exposure کو queue سے صرف چھپاتا ہے۔

ترتیب یہ ہے: affected status ثابت کریں، معلوم exploitation اور reachability سے urgency طے کریں، business impact اور privileges سے نقصان ناپیں، controls سے موجودہ exploit path جانچیں، پھر EPSS اور CVSS سے باقی queue بہتر کریں۔ اسی لیے CVSS 10 اہم ہے، مگر KEV اور asset exposure اس سے پہلے patch ہونے کا فیصلہ بدل سکتے ہیں۔

یہ بھی پڑھیں:

• CVSS 10 اکیلا patch order نہیں، KEV اور affected version پہلے دیکھیں
• Acast اور Kit کی شراکت: پوڈکاسٹ سننے والے ای میل فہرست بن سکتے ہیں
• PaperCut zero-day کے لیے دوسرا emergency patch؛ پہلے والا کافی نہیں