Vulnerability Management

Я регулярно вижу две типичные ошибки в команде с vulnerability management. Первая — «сканер поставили, галочку поставили, готово»: Snyk шлёт PR’ы, никто их не мержит, через полгода у каждого репозитория висит по четыре десятка предупреждений, и от усталости их перестают замечать. Вторая — «патчим всё, что CVSS ≥7.0»: недели уходят на малорисковые уязвимости в инструментах разработчика, а на критичные времени не остаётся. Между ними лежит дисциплина: измеримый процесс с явным жизненным циклом, прозрачный триаж (CVSS, EPSS, контекст актива), свой срок под каждую степень тяжести. Третий лист под L1 Secure Development. Граница с Threat Modeling: моделирование угроз ищет, что может пойти не так, а этот лист разбирается с тем, что уже не так. Обязательное условие — SBOM: нельзя починить то, о существовании чего вы не знаете.

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

Главный навык на уровне L4 — триажить уязвимости в совокупности, а не по одному только CVSS. Балл 7,5 в инструменте разработчика и тот же балл в платёжном сервисе, открытом наружу, — это разные риски, и срок починки у них разный. CVSS плюс EPSS (Exploit Prediction Scoring System) плюс критичность актива — боевой сервис в интернете, внутренний стенд, локальный инструмент — дают очередь, с которой можно работать. Я регулярно вижу команды, которые патчат подряд по CVSS: выходит медленнее и хуже, чем с учётом контекста.

Знает, что такое CVE / CWE, как читать CVSS score, понимает разницу vulnerability (потенциал) vs threat (actor + exploit). Своевременно накатывает патчи на свой сервис.
Понимает, зачем нужен SBOM: какие зависимости у его сервиса, как их обновлять (настройка Renovate или Dependabot), почему меньше прямых зависимостей — меньше поверхность атаки.

Триажит уязвимости в совокупности: CVSS, EPSS и контекст (боевой сервис в интернете, внутренний стенд, локальный инструмент); по этому и выстраивает очередь починки.
Держит инструменты в конвейере: SCA в CI (Snyk, Dependabot, Trivy), SAST для своего кода (Semgrep, CodeQL), сканирование образов (Trivy, Grype).
Катит патчи через progressive delivery: критичный патч безопасности едет канарейкой с гейтом по здоровью. Экстренный путь сокращает сроки, но не отменяет процесс.

Проектирует процесс для команды: откуда приходят находки, по какой рубрике их триажат (CVSS, EPSS, критичность актива), какие сроки на каждую степень (критичные — неделя, высокие — месяц, средние — квартал), как оформляется принятие риска для исключений.
Подключает каталог CISA KEV (Known Exploited Vulnerabilities): то, что попало туда, идёт вне общей очереди. Отслеживание CVE, применимых к вашему стеку, автоматическое, а не «зашёл посмотрел».
Стыкует это с безопасностью цепочки поставок: SBOM собирается в CI (SPDX или CycloneDX), подписи внешних артефактов проверяются (Sigstore cosign), гигиена зависимостей описана политикой.

L6+

Внедряет систему на уровне организации: единый источник находок (связка с SOC), приоритизация по критичности активов (связка с CMDB), отчётность для аудита (SOC 2, ISO 27001, PCI-DSS), программа раскрытия уязвимостей, при желании — bug bounty.
Принимает стратегические решения: экономика bug bounty, сроки раскрытия перед регулятором, что с этим у страховщиков, что докладывать совету директоров по существенным рискам.

Материалы

Книги

Andrew Magnusson — Practical Vulnerability Management (No Starch Press, 2020). Прикладная книга про жизненный цикл: обнаружение, оценка, реакция, отчётность. Конкретные шаблоны политики, сроков и матриц эскалации.
Heather Adkins et al. — Building Secure and Reliable Systems (O’Reilly, 2020), главы 10–11. Взгляд Google на реакцию на уязвимости в большой системе.

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

NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management Planning. Канонический документ NIST: как планировать управление патчами в масштабе организации.
OWASP Vulnerability Management Guide. Короткая памятка OWASP, сфокусированная на приложениях; годится как стартовый шаблон политики.
CISA Known Exploited Vulnerabilities (KEV) Catalog. Список уязвимостей с подтверждённой эксплуатацией в дикой природе. Для американских ведомств это обязательное требование, отрасль подхватила его как хорошую практику.
EPSS — Exploit Prediction Scoring System (FIRST.org). Современное дополнение к CVSS: вероятность того, что уязвимость начнут эксплуатировать в ближайшие тридцать дней. Считается по данным, а не выставляется экспертом на глаз.
Snyk — State of Open Source Security Report. Ежегодные данные о том, насколько распространены уязвимости в открытом коде.
Apache Log4Shell — CVE-2021-44228 + CISA Log4j guidance. Главный публичный кейс — см. ниже.

Инструменты

SCA (Software Composition Analysis): Snyk, Dependabot (встроен в GitHub), Renovate, OWASP Dependency-Check, Trivy. По моим наблюдениям, Trivy чаще выбирают в OSS-сценариях из-за широкого покрытия.
SAST: Semgrep (работает по правилам, быстрый), CodeQL (глубокий семантический анализ, GitHub), SonarQube, Checkmarx.
DAST: OWASP ZAP (открытый), Burp Suite.
Container scanning: Trivy, Anchore Grype, Aqua, Sysdig.
Оценка защищённости облака (CSPM): Wiz, Orca Security, AWS Inspector, GCP Security Command Center. Lacework из самостоятельных игроков выбыл — Fortinet купила его в 2024 и продаёт под своим брендом.
Vuln databases: NVD, CVE Details, Vulners, GHSA (GitHub Security Advisory).
Площадки для VDP и bug bounty: HackerOne, Bugcrowd, Synack. Минимум для любой продуктовой компании — security.txt (RFC 9116) на сайте.
SBOM tools: Syft, cdxgen, SPDX tools.

Best practices

Главный публичный кейс — Log4Shell (CVE-2021-44228, декабрь 2021). Уязвимость в Apache log4j, библиотеке логирования почти из каждого Java-проекта, давала удалённое выполнение кода через одну строку в любом логируемом поле. Библиотека была везде. Каскадно затронуло буквально тысячи компаний и сервисов. Урок не в том, что логгеры опасны. Если у вас нет SBOM, вы не знаете, где у вас log4j — вот и весь урок. Команды с SBOM нашли все места использования библиотеки за часы и пропатчили за дни; команды без SBOM искали неделями и не всегда успевали до того, как уязвимость начали эксплуатировать по их адресам. Если в вашей команде нет процесса генерации SBOM в CI каждого артефакта — это первое, что я бы начал чинить, не дожидаясь следующего log4shell.

Дальше всё держится на трёх опорах. Первая: CVSS сам по себе мало что значит. «Патчим всё, что ≥7.0» ставит в одну очередь internet-facing prod и локальный dev tool с одинаковым баллом, хотя риски у них несопоставимые. EPSS добавляет вероятность эксплуатации, посчитанную по данным, а не по ощущениям эксперта, контекст актива добавляет операционный приоритет — и только сумма трёх даёт очередь, с которой можно работать.

Вторая опора — каталог CISA KEV. Тут приоритет не обсуждается: совпадение со стеком означает патч или митигацию вне очереди, а не «в следующий спринт». Подтверждённая эксплуатация в дикой природе — просто другая категория событий, поэтому фид подписывается, а проверка встраивается в CI или в инвентаризацию активов.

Третья — SBOM, и она не последняя по важности, а первая по порядку. Нельзя патчить то, о существовании чего вы не знаете. SBOM в формате SPDX или CycloneDX генерируется в CI каждого сервиса (Syft, cdxgen) и агрегируется на уровне организации. Без него всё остальное не работает — ровно это и показал Log4Shell.

Сроки починки по степеням — измеряются и соблюдаются. «Мы патчим все уязвимости» — позиция без сроков, а значит без результата: долг копится тихо. Базовая шкала выглядит так: критичные — неделя, высокие — месяц, средние — квартал; дальше её подгоняют под требования SOC 2, PCI-DSS или FedRAMP, если они над вами есть. MTTR выносится на дашборд безопасности с трендом. Без срока «когда-нибудь поправим» читается как «никогда».

Патч — это тот же деплой: канарейка, а не «руками ночью». «Патч критичный, катим в обход конвейера» — так теряют прод. Патчи ломают системы не реже обычных релизов: меняется поведение аутентификации, автор библиотеки втихую ломает API, вылезают регрессии. Никакой разницы. Канарейка и гейт применяются к ним ровно так же, как к обычной фиче. Экстренный путь сокращает время: от процента трафика до всего за час, а не за сутки. Но процесс он не отменяет, откат, гейт и наблюдаемость остаются на месте.

Гигиена зависимостей — заранее, а не по факту. Обновлять зависимости в тот момент, когда в них нашли уязвимость, — поздно. Renovate или Dependabot с разумной частотой, минимальный возраст версии перед приёмом (обычно от недели до двух выдержки, чтобы не втащить только что выпущенное), проверка того, что пакет вообще поддерживается: последний коммит год назад в критичной зависимости — сам по себе риск. Всё это уменьшает поверхность до того, как появится CVE.

Программа раскрытия уязвимостей (VDP) обязательна для продуктовой компании. Нет канала — есть проблема. Исследователь, которому некуда написать, либо публикует zero-day, либо уносит находку туда, где заплатят, либо просто проходит мимо, и вы узнаёте об уязвимости последними. VDP — это публичная политика: что входит в область, какой срок до раскрытия (стандартом стали девяносто дней от Project Zero), как отмечают заслуги нашедшего. Минимум — security.txt (RFC 9116) на сайте с рабочим контактом.

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

Secrets Management — уязвимость часто оборачивается утечкой секрета: закоммиченный ключ, утёкший токен. Ротация и узкая область действия снижают цену такой утечки.
Threat Modeling — граница: моделирование угроз ищет, что может пойти не так, а этот лист разбирается с тем, что уже не так.
Supply Chain Security — этот лист реагирует на известные CVE, соседний защищает сам процесс «собрали — распространили — проверили». Оба опираются на SBOM.
CI/CD — SCA, SAST, DAST и сканирование образов живут в конвейере; SBOM собирается там же.
Progressive Delivery — патчи катятся так же постепенно и с тем же гейтом, что и обычные изменения.
Incident Response — проэксплуатированная уязвимость — это уже инцидент безопасности; отсюда берутся и словарь, и процесс для таких инцидентов.
Service Ownership — каталог сервисов хранит и список зависимостей, чтобы патчить прицельно.
Access Control & IAM — неверная настройка IAM сама по себе даёт поверхность атаки; сканеры давно умеют её проверять.
Workload Identity — убирает целый класс уязвимостей, избавляясь от общих секретов: федерация OIDC вместо долгоживущих ключей API.
Compliance Frameworks — сроки патчинга по severity прямо следуют из SOC 2 CC7.1, PCI-DSS Req 6 и ISO 27001 A.8.8.
Security Code Review — граница: ревью ловит дефекты в своём коде до мержа, этот лист реагирует на известные CVE в зависимостях. Инструменты SAST и SCA общие.
Security Chaos Engineering — здесь ищут уязвимости, там проверяют, что контроли, ловящие их эксплуатацию, реально работают.

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

Access Control & IAM, Workload Identity, Compliance Frameworks и Security Chaos Engineering выросли отсюда в отдельные листья — ссылки в разделе выше.

Экономика bug bounty — когда запускать, какие ставить границы, как устроены выплаты, кого брать площадкой.

Хорошей публичной модели расчёта этих сроков под конкретную команду я не знаю. В литературе кочуют «отраслевые стандарты» вроде семи дней на критичные, но выведены они не из моделирования рисков вашей системы, а из чужой практики и требований аудита. Если у вас SLA посчитан по данным — расскажите PR’ом.