Vulnerability Management без хаос: как да приоритизирате правилно, когато сканерът върна 50 000 findings

Проблемът: всичко е „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. Ресурсите са ограничени — насочете ги там, където рискът е реален и измерим.