CVE — ommaga ma’lum cybersecurity zaifliklarini yagona identifikator bilan nomlash tizimi. To‘liq nomi Common Vulnerabilities and Exposures. CVE yozuvi turli vendor, scanner, advisory va xavfsizlik jamoalariga ayni zaiflik haqida bir xil ID orqali gapirish imkonini beradi.
CVE identifikatori zaiflikning mavjudligini nomlaydi. U o‘z-o‘zidan risk darajasi, exploit mavjudligi yoki tashkilotga real ta’sirni to‘liq ifodalamaydi.
Identifikator formati
CVE ID odatda quyidagi ko‘rinishda bo‘ladi:
CVE-YIL-RAQAM
Masalan:
CVE-2026-12345
Yil identifikator ajratilgan yoki public qilingan davrga bog‘liq bo‘lishi mumkin. U zaiflik aynan shu yilda yaratilganini anglatmaydi.
CVE Record
CVE record odatda:
- CVE ID;
- qisqa tavsif;
- affected productga oid ma’lumot;
- reference;
- assigner yoki CNA metadata’si;
- record holati
kabi elementlarga ega bo‘lishi mumkin.
Batafsil patch, workaround va severity vendor advisory yoki boshqa vulnerability database’da kengroq beriladi.
CNA
CVE Numbering Authority ma’lum scope doirasida CVE ID ajratish va record publish qilish vakolatiga ega tashkilot.
CNA vendor, security organization yoki boshqa vakolatli entity bo‘lishi mumkin.
U o‘z mahsuloti yoki belgilangan scope’dagi zaifliklarni boshqaradi.
Root va program boshqaruvi
CVE ekotizimida ID ajratish, CNA koordinatsiyasi, record format va policy uchun markaziy program boshqaruvi mavjud.
Turli CNA’lar distributed tarzda ishlagani sabab bir xil zaiflikka duplicate ID ajratmaslik uchun koordinatsiya talab qilinadi.
Reserved holat
CVE ID oldindan ajratilib, record tafsilotlari hali public bo‘lmasa reserved holatda ko‘rinishi mumkin.
Bu vendor patch va disclosure jarayonini tayyorlayotganini anglatishi ehtimoli bor.
Reserved ID haqida yetarli public ma’lumot bo‘lmasligi mumkin.
Published holat
Record ommaga chiqarilganda tavsif va reference’lar mavjud bo‘ladi.
Published record keyinchalik yangi reference, affected version yoki tavsif bilan yangilanishi mumkin.
Security toollar record update’larini kuzatishi kerak.
Rejected holat
CVE record keyinchalik rejected deb belgilanishi mumkin.
Sabablar:
- duplicate;
- zaiflik emasligi;
- noto‘g‘ri ajratish;
- boshqa IDga birlashtirish.
Rejected ID qayta boshqa zaiflik uchun ishlatilmaydi.
CVE va CVSS
CVE zaiflikni identifikatsiya qiladi.
CVSS esa uning texnik severity xususiyatlarini ball va vector orqali ifodalaydi.
Bitta CVE turli manbada vaqt yoki kontekstga qarab boshqa CVSS bahoga ega bo‘lishi mumkin.
CVE IDning o‘zida severity yo‘q.
CVE va CWE
CWE software weakness turlarini tasniflaydi.
Masalan, access control yoki input validationdagi umumiy xato turi.
CVE esa ma’lum product va holatdagi konkret zaiflikni nomlaydi.
Bitta CVE bir yoki bir nechta CWE bilan bog‘lanishi mumkin.
Affected version
Zaiflik qaysi product, package va versiyalarga ta’sir qilishi eng muhim ma’lumotlardan biri.
Version range turli ecosystemlarda murakkab:
Faqat upstream versiyaga qarab xulosa qilish noto‘g‘ri bo‘lishi mumkin.
Vendor advisory
Vendor advisory odatda:
haqida aniqroq ma’lumot beradi.
CVE record reference sifatida shu advisoryga havola qilishi mumkin.
Scanner
Vulnerability scanner installed package yoki service versiyasini CVE ma’lumotlari bilan solishtiradi.
Muammolar:
- version aniqlash xatosi;
- backported patch;
- package nomi mos kelmasligi;
- feature o‘chiq bo‘lishi;
- false positive;
- credential yetishmasligi.
Scanner natijasi tekshiriladi.
Prioritization
Tashkilot CVE’larni faqat CVSS bo‘yicha tartiblamaydi.
Hisobga olinadi:
- asset internetga ochiqmi;
- exploit amalda ishlatilayaptimi;
- vulnerable feature yoqilganmi;
- data va privilege;
- compensating control;
- business criticality;
- patch mavjudligi.
Past ballli, ammo internetga ochiq zaiflik yuqori prioritet bo‘lishi mumkin.
SBOM bilan aloqa
Software Bill of Materials product ichidagi component va versiyalarni ko‘rsatadi.
CVE feed bilan solishtirib qaysi application affected ekanini aniqlash mumkin.
Component mavjud bo‘lsa ham vulnerable code path ishlatilmasligi mumkin; exploitability tahlili kerak.
Disclosure
Zaiflik topilganda researcher, vendor va coordinator patch hamda public disclosure vaqtini muvofiqlashtirishi mumkin.
CVE ID kommunikatsiyani birlashtiradi.
Public disclosure’dan oldin ma’lumotni boshqarish va foydalanuvchilarga patch tayyorlash muhim.
CVE cheklovi
Har security muammo CVE olmaydi.
Masalan:
- noto‘g‘ri local konfiguratsiya;
- fraud;
- stolen credential;
- umumiy design risk;
- end-of-life holat;
- policy buzilishi
CVE tizimidan tashqarida bo‘lishi mumkin.
CVE yo‘qligi mahsulot xavfsizligini kafolatlamaydi.
Duplicate
Bir zaiflik turli researcher yoki vendor tomonidan alohida report qilinsa duplicate CVE ajratilishi mumkin. Tahlildan keyin bittasi asosiy record bo‘lib, boshqasi rejected va duplicate reference bilan belgilanadi. Asset tizimi ikkisini ikki mustaqil patch deb hisoblamasligi kerak.
Product identifier
Vendor, product va version nomlari turli database’da bir xil yozilmasligi mumkin. Package manager nomi, OS distribution va upstream loyiha orasida mapping talab qilinadi. Noto‘g‘ri mapping false positive yoki missed vulnerability yaratadi.
Exploited status
CVE public bo‘lishi exploit amalda ishlatilayotganini anglatmaydi. Aksincha ayrim zaifliklar disclosure’dan oldin hujumda qo‘llangan bo‘lishi mumkin. Threat intelligence va exploitation cataloglari patch prioritetini aniqlashga yordam beradi.
Internal vulnerability
Tashkilot o‘z private applicationida topilgan zaiflikka CVE olmasligi mumkin. Shunga qaramay ichki ID, severity, owner, deadline va remediation holati vulnerability management tizimida yuritiladi.
Bog‘liq tushunchalar
Common Vulnerabilities and Exposures, CVSS, CWE, CNA, Vulnerability, Security advisory, Patch management, SBOM, Vulnerability scanner, Responsible disclosure