AI-система управления уязвимостями
Сканер находит 3 000 уязвимостей. У 400 из них CVSS Score ≥ 7.0 («High» или «Critical»). Команда из 3 человек не может исправить 400 уязвимостей за разумное время. Классическая ловушка vulnerability management: фокусировка на CVSS score без контекста — это неправильная приоритизация. AI добавляет контекст: реальная эксплуатабельность, наличие патча, критичность актива, активная эксплуатация in the wild.
Проблема CVSS как единственной метрики
CVSS Score — это потенциальная серьёзность. Не реальный риск. CVE с CVSS 9.8, для которой нет публичного эксплоита и сервис не доступен из интернета, — менее приоритетна, чем CVE с CVSS 6.5 с публичным эксплоитом, активной эксплуатацией и критическим сервисом в DMZ.
EPSS (Exploit Prediction Scoring System) — ML-модель от FIRST.org, которая предсказывает вероятность эксплуатации CVE в ближайшие 30 дней. Учитывает: наличие PoC кода, упоминания в threat intelligence, социальные сигналы. EPSS score 0.9 = 90% вероятность эксплуатации.
Комбинация CVSS + EPSS + asset criticality даёт правильную приоритизацию.
AI-enhanced vulnerability management pipeline
Asset inventory и context. Без понимания что именно уязвимо — приоритизация невозможна. Интегрируемся с CMDB (ServiceNow, i-doit), cloud asset discovery (AWS Security Hub, Azure Defender), Kubernetes cluster inventory. Для каждого актива: business criticality, data sensitivity, internet exposure, owner.
Vulnerability aggregation. Nessus, Qualys, Rapid7 InsightVM, OpenVAS — результаты из разных сканеров нормализуются и дедуплицируются. Один хост может появляться в разных сканерах как разные записи.
Risk scoring модель. Не просто CVSS, а composite score:
def calculate_risk_score(vuln: Vulnerability, asset: Asset) -> float:
# Базовый риск из CVSS
base_risk = vuln.cvss_score / 10.0
# Вероятность эксплуатации (EPSS)
exploit_probability = vuln.epss_score # 0-1
# Активная эксплуатация (из TI фидов)
in_the_wild = 1.5 if vuln.is_actively_exploited else 1.0
# Критичность актива
asset_multiplier = {
"CRITICAL": 2.0,
"HIGH": 1.5,
"MEDIUM": 1.0,
"LOW": 0.5
}[asset.criticality]
# Экспозиция
exposure = 1.3 if asset.internet_facing else 0.8
risk = base_risk * exploit_probability * in_the_wild * asset_multiplier * exposure
return min(10.0, risk)
Remediation prioritization. Сортировка по risk score с учётом:
- Patch available (нет смысла приоритизировать то, что нельзя закрыть быстро)
- Remediation effort (одна команда terraform vs. ручная работа на 50 серверах)
- Compensating controls (уязвимость за WAF = меньший приоритет)
Automated patching pipeline
Для cloud и контейнерных сред — автоматическое закрытие:
Container images. При обнаружении CVE в base image — автоматически триггерим rebuild pipeline с обновлённым базовым образом. Trivy или Grype в CI/CD сканируют каждый build. Образы с критическими CVE не деплоятся в production.
Cloud infrastructure. Terraform/Pulumi: при обнаружении неправильной конфигурации (открытый S3 bucket, security group с 0.0.0.0/0) — автоматический PR с исправлением. DevOps approves, система применяет.
OS patches. AWS Systems Manager Patch Manager / Ansible для Linux хостов: автоматическое применение Critical/High security patches по расписанию с pre/post validation.
SLA-based tracking
Vulnerability management без SLA — это просто список. С SLA:
| Severity | Max Time to Remediate | Auto-escalation |
|---|---|---|
| Critical (active exploit) | 24 часа | CISO + CTO |
| Critical | 7 дней | Security Lead |
| High | 30 дней | Team Lead |
| Medium | 90 дней | Developer |
AI-система автоматически отправляет reminders, escalates при просрочке, отслеживает SLA compliance как KPI.
Практический кейс
Страховая компания, 1 200 активов, 2 человека в security team. Qualys давал 4 200 findings еженедельно. Команда закрывала 40–60 уязвимостей в неделю — находки накапливались быстрее, чем устранялись.
После AI-приоритизации:
- Из 4 200 findings: 23 — Critical с активной эксплуатацией и EPSS > 0.7 → немедленное действие
- 180 — High risk по composite score → sprint этой недели
- Остальное — backlog с SLA
- Remediation rate: в 3x выше (правильные вещи делаются быстро)
- Критические уязвимости закрываются в среднем за 3.4 дня vs. 18 дней ранее
Автоматическое закрытие: 34% container image уязвимостей устраняется через auto-rebuild без участия команды.
Сроки: 4–8 недель для базовой AI-приоритизации поверх существующего сканера, 3–5 месяцев для полной VMP с automated patching и SLA-tracking.