Перейти к содержимому
The Way of SRE

Vulnerability Management

Я регулярно вижу две типичные ошибки в команде с vulnerability management. Первая — «scanner поставили, галочку поставили, готово»: Snyk шлёт PR’ы, никто их не мержит, через 6 месяцев у каждого репозитория ≈40 alerts, alert fatigue делает их невидимыми. Вторая — «патчим всё, что CVSS ≥7.0»: команда теряет недели на низкорискованных vulnerabilities в dev tools и не успевает на критичных. Между ними — дисциплина: измеримый процесс с явным lifecycle, прозрачный triage (CVSS + EPSS + asset context), SLA per severity. Третий лист под L1 Information Security. Граница с Threat Modeling: threat modeling identifies what could go wrong (proactive), vulnerability management addresses what already is wrong (reactive). Пре-условие — SBOM: нельзя патчить то, чего не знаешь, что у тебя есть.

Что должен уметь

Заголовок раздела «Что должен уметь»

Главный навык на уровне L4 — триажить vulnerabilities комплексно, не только по CVSS. CVSS 7.5 в dev tool и CVSS 7.5 в internet-facing prod payment service — это разные риски, и SLA должен быть разный. CVSS + EPSS (Exploit Prediction Scoring System) + asset criticality (internet-facing prod / internal staging / local dev tool) даёт actionable приоритизацию. Я регулярно вижу команды, патчущие подряд по CVSS — это медленнее и хуже, чем patch hygiene с context.

L3

  • Знает, что такое CVE / CWE, как читать CVSS score, понимает разницу vulnerability (потенциал) vs threat (actor + exploit). Применяет patches на свой сервис в timely manner.
  • Понимает SBOM — какие dependencies в своём сервисе, как их обновлять (Renovate / Dependabot config), почему минимизация direct dependencies снижает поверхность атаки.

L4

  • Триажит vulnerabilities комплексно — CVSS + EPSS + контекст (internet-facing prod vs internal staging vs local dev tool), приоритизирует remediation.
  • Использует tooling в pipeline — SCA в CI (Snyk / Dependabot / Trivy), SAST для своего кода (Semgrep / CodeQL), container scanning (Trivy / Grype).
  • Применяет patches через progressive delivery — критичный security patch через canary с health gate. Emergency-path обходит cadence, но не process.

L5

  • Проектирует vulnerability management process команды — discovery sources, triage rubric (CVSS + EPSS + asset criticality), SLA per severity (critical 7 days, high 30 days, medium 90 days), risk acceptance process для exceptions.
  • Связывает с CISA KEV (Known Exploited Vulnerabilities catalog) — vulnerabilities из KEV приоритизируются вне обычного triage. Мониторинг CVE applicable к stack — автоматический, не «зашёл — посмотрел».
  • Координирует с supply chain security — SBOM генерация в CI (SPDX / CycloneDX), validation upstream artifact signatures (Sigstore cosign), dependency hygiene policy.

L6+

  • Внедряет org-level framework — единая система discovery (SOC integration), prioritization по asset criticality (CMDB integration), compliance reporting (SOC 2 / ISO 27001 / PCI-DSS), VDP (Vulnerability Disclosure Program), опционально bug bounty.
  • Принимает strategic decisions — bug bounty economics, regulatory disclosure timing, insurance implications, board-level reporting для material security risks.

Материалы

Заголовок раздела «Материалы»

Книги

Заголовок раздела «Книги»
  • Andrew Magnusson — Practical Vulnerability Management (No Starch Press, 2020). Прикладная книга про lifecycle: discovery → assessment → response → reporting. Конкретные шаблоны policy, SLA, escalation matrices.
  • Heather Adkins et al. — Building Secure and Reliable Systems (O’Reilly, 2020), главы 10–11. Google-perspective на vulnerability response в крупной системе.

Статьи и доклады

Заголовок раздела «Статьи и доклады»

Инструменты

Заголовок раздела «Инструменты»

Best practices

Заголовок раздела «Best practices»

Главный публичный кейс — Log4Shell (CVE-2021-44228, декабрь 2021). Vulnerability в Apache log4j (logging library, используется почти везде в Java-экосистеме) позволяла remote code execution через единую строку в любом логируемом поле. Каскадно затронула буквально тысячи компаний и сервисов. Главный урок не «лог-библиотеки опасны» — а «если у вас нет SBOM, вы не знаете, где у вас log4j». Команды с SBOM нашли все места использования log4j за часы, патчили за дни. Команды без SBOM — за недели, и не всегда успевали до active exploitation. Если в вашей команде нет процесса генерации SBOM в CI каждого артефакта — это первое, что я бы начал чинить, не дожидаясь следующего log4shell.

Короткие правила:

  • CVSS — не единственная метрика; смотри EPSS + context + asset criticality. «Патчим всё что CVSS ≥7.0» без context — internet-facing prod и локальный dev tool с CVSS 7.5 получают одинаковый приоритет. EPSS показывает data-driven вероятность эксплуатации; asset context даёт операционный приоритет. Combined CVSS + EPSS + asset context = actionable очередь.
  • CISA KEV catalog — non-negotiable приоритет. Любой match KEV в стеке → out-of-band patch / mitigation, не следующий sprint. Active exploitation в дикой природе — это другая категория. Subscribe to feed + automated check в CI / asset inventory.
  • SBOM как пре-условие — нельзя патчить то, чего не знаешь, что есть. SBOM (SPDX / CycloneDX) генерируется в CI каждого сервиса (Syft / cdxgen), агрегируется в org-level vuln management tool. Foundation для всех остальных practices — без SBOM остальное не работает (см. Log4Shell кейс выше).

Подробнее:

Patch SLA per severity — измеряется и enforced. «Мы патчим все vulnerabilities» без сроков — типичная позиция, при которой old vulnerabilities накапливаются (vulnerability debt). SLA per severity как baseline: critical 7 days, high 30 days, medium 90 days (adjust под compliance — SOC 2 / PCI-DSS / FedRAMP имеют свои). MTTR (mean time to remediate) — измеряемая метрика в security дашборде с trend visibility. Без SLA «когда нибудь поправим» означает «никогда».

Patch как deploy — progressive delivery, не «вручную ночью». «Security patch критично — катим manually в обход pipeline» — антипаттерн. Patches ломают системы не реже регулярных deploys: auth changes, breaking API changes upstream, regressions. Progressive delivery (canary + health gate) применяется и к security patches. Emergency-path обходит cadence («скорая канарейка» 1% → 100% за час, а не за сутки), но не process (rollback strategy, health gate, observability остаются).

Dependency hygiene — proactive, не reactive. «Обновим dependencies, когда найдут vulnerability» — слишком поздно. Auto-updates (Renovate / Dependabot) с reasonable cadence + minimum acceptable age для версий (обычно 7–14 дней cool-off — не использовать только что вышедшее) + minimum maintained status (не использовать packages с last commit > 12 месяцев для critical deps). Reduces vulnerability surface до того, как CVE появится.

Vulnerability Disclosure Program (VDP) обязателен для product companies. «У нас нет официального канала для security reports — пусть пишут на support@» — security researchers без канала либо публикуют zero-day, либо сдают конкуренту, либо игнорируют. VDP — public policy: scope, disclosure timeline (90 days как стандарт от Project Zero), recognition. Минимум — security.txt (RFC 9116) на сайте с контактом security team.

Связанные листья

Заголовок раздела «Связанные листья»
  • Secrets Management — vulnerability часто = secret leak (committed key, leaked token); rotation + scoping снижают impact compromised secret.
  • Threat Modeling — граница: threat modeling identifies what could go wrong; vulnerability management addresses what already is wrong.
  • Supply Chain Security — VM реагирует на known CVE; Supply Chain Security защищает процесс build → distribute → verify. Оба используют SBOM как foundation.
  • CI/CD — SCA / SAST / DAST / container scanning живут в pipeline; SBOM генерация — там же.
  • Progressive Delivery — patches накатываются как progressive deployment с health gate.
  • Incident Response — exploited vulnerability = security incident; vulnerability management даёт vocabulary и process для security incidents.
  • Service Ownership — каталог сервисов включает dependency inventory для targeted patching.
  • Access Control & IAM — IAM misconfiguration сам является vulnerability surface; VM tools часто scan’ят IAM-уязвимости.
  • Workload Identity — убирает целый класс уязвимостей через elimination shared secrets; OIDC federation вместо long-lived API keys.
  • Compliance Frameworks — патч SLA per severity напрямую следует из SOC 2 CC7.1 / PCI-DSS Req 6 / ISO 27001 A.8.8.
  • Security Code Review — граница: SCR ловит дефекты в своём коде до merge (proactive); VM реагирует на known CVE в dependencies (reactive). SAST / SCA tooling общий.
  • Security Chaos Engineering — VM ищет уязвимости; SCE проверяет, что контролы, ловящие их эксплуатацию (detection, response), реально работают.

Открытые вопросы

Заголовок раздела «Открытые вопросы»
  • Access Control & IAM — выделен в отдельный лист (см. Связанные листья).
  • Workload Identity — выделен в отдельный лист.
  • Compliance Frameworks — выделен в отдельный лист.
  • Security Chaos Engineering — выделен в отдельный лист (см. Связанные листья).
  • Bug Bounty Program Economics — когда launch, какие scopes, payout structure, vendor selection.
  • Я не знаю хорошей публичной модели расчёта оптимальных SLA per severity для конкретной команды — в литературе чаще даются «индустриальные стандарты» (critical 7 days и т.д.), но они выводятся не из risk-modeling вашей конкретной системы. Если в вашей команде есть data-driven SLA — расскажите PR’ом.