Проблемът: всичко е „Critical“
Повечето организации имат vulnerability management програма. Малко от тях имат ефективна такава. Типичният сценарий: сканерът (Tenable, Qualys, Rapid7) върна 50 000 findings тази седмица. 3 000 от тях са CVSS 9+. IT екипът може да затвори 200 на месец. Математиката не работи.
CVSS (Common Vulnerability Scoring System) оценява техническата тежест на уязвимост в изолация — без контекст за вашата среда, без информация дали се експлоатира активно, без отчитане на бизнес критичността на засегнатия актив. Резултатът е патчване на академично „критични“ уязвимости, докато реално експлоатираните остават отворени.
Risk-based приоритизация: отвъд CVSS
EPSS: Exploit Prediction Scoring System
EPSS е вероятностен модел, разработен от FIRST, който предсказва вероятността дадена уязвимост да бъде експлоатирана в рамките на 30 дни. CVE с CVSS 9.8 и EPSS 0.3% трябва да изчака. CVE с CVSS 6.5 и EPSS 94% трябва да се патчне днес. Интегрирайте EPSS в своя vulnerability workflow — API-то е безплатно.
CISA KEV: Known Exploited Vulnerabilities
CISA поддържа публичен каталог на уязвимости, активно експлоатирани in-the-wild. Всяка CVE в KEV каталога трябва да е на топ приоритет — не защото CVSS скорът е висок, а защото нападателите вече я използват. Абонирайте се за KEV feed и автоматизирайте ескалацията на тези findings.
Asset criticality като мултипликатор
Уязвимост на интернет-facing уеб сървър, обработващ клиентски данни, е несравнимо по-критична от същата уязвимост на изолирана тестова машина. Изградете asset inventory с business criticality tier-ове (Critical/High/Medium/Low) и го интегрирайте в scoring модела си. Формулата е проста: Risk = Vulnerability Score x Asset Criticality x Exploitability.
Практична рамка за VM програма
Фаза 1: Видимост
Не можете да защитите това, което не виждате. Continuous asset discovery е предпоставка за всичко останало. Комбинирайте активно сканиране (credentialed scans за пълна видимост), passive discovery (network traffic analysis) и cloud asset inventory (AWS Security Hub, Azure Defender for Cloud).
Фаза 2: Нормализация и дедупликация
Различните сканери докладват едни и същи уязвимости по различен начин. Централизирайте данните в vulnerability management платформа (или SIEM с VM интеграция), нормализирайте по CVE ID и дедуплицирайте по asset + CVE комбинация.
Фаза 3: Приоритизация (CVSS + EPSS + KEV + Asset Criticality)
Приложете многофакторния scoring модел:
- P1 (патч в 24-48 часа): KEV уязвимост на Critical asset или EPSS >50% на High/Critical asset
- P2 (патч в 7 дни): CVSS 9+ с EPSS >10%, или KEV на Medium asset
- P3 (патч в 30 дни): CVSS 7+ без активна експлоатация на бизнес критични системи
- P4 (next patch cycle): Всичко останало — документирано и tracked
Фаза 4: SLA и metrics
Без измерими SLA-та, VM програмата е списък с пожелания. Дефинирайте и следете:
- Mean Time to Remediate (MTTR) по приоритет
- SLA compliance rate (% от P1/P2 затворени навреме)
- Reopen rate (уязвимости, върнали се след патч)
- Coverage rate (% от активите, сканирани в последните 7/30 дни)
Ключов извод: Целта на VM програмата не е да затворите всичко — невъзможно е. Целта е да затворите правилното нещо навреме. Risk-based приоритизацията е механизмът, който прави това постижимо.
Заключение
Ефективният vulnerability management в 2026 г. изисква повече от сканиране и CVSS скорове. Комбинацията от EPSS, CISA KEV, asset criticality и ясни SLA-та трансформира VM от административно упражнение в реален инструмент за намаляване на attack surface. Ресурсите са ограничени — насочете ги там, където рискът е реален и измерим.
