Практический ProdSec Vuln Triage playbook: triage → applicability → exposure → reachability → exploitability → blast radius → business impact → treatment → verification.

Когда я работал SecOps инженером, одна из самых полезных вещей, которую мне пришлось усвоить, была довольно простой: красная цифра на счетчике CVSS или алерт Hight Impact в отчете сканера — это еще не доказуемый факт бага.

По классике все выглядит примерно так: Сканер уязвимостей или другая тула ассесмента может сказать, что у нас, например, рейт CVSS 9.8. Далее SCA может подсветить vulnerable dependency. А SAST может найти потенциальный sink. И еще круче, DAST может подтвердить поведение на работающем приложении. CNAPP может показать misconfiguration в инфраструктуре. Ну, а Bug bounty researcher может прислать PoC и запросить денежку:)

Только вот, как оказалось, это "не все" что нужно для принятиях технического решения. Нормальная адекватная инженерная работа — это не переслать finding разрабу со словами «Critical, fix ASAP». Инженерная работа Mid+\Senior SecOps — понять, что именно найдено, применимо ли это к продукту, достижим ли vulnerable path, кто может его атаковать, какие права получит атакующий, куда он сможет pivot’нуться дальше, что реально потеряет бизнес и какой response уменьшит риск быстрее всего.

Именно этим mindset я хочу поделиться в этой статье.

Главная идея такая:

CVSS — это severity signal. Приоритет ремонта появляется только после добавления контекста.

И современный контекст — это не одна дополнительная колонка в треке Jira. Это целая live цепочка: applicability, exposure, reachability, exploitability, threat intelligence, asset criticality, blast radius, compensating controls, business impact и confidence.

Разберем все по косточкам! Погнали!:)

DISCLAIMER

Архитектуры и часть scenarios в статье намеренно упрощены и используются как учебные модели. Реальные CVE и vendor statements отмечены отдельно. Reachability verdict никогда не должен строиться только на одном scanner signal: качество решения зависит от полноты evidence и понимания конкретного runtime environment.

Field card: карта triage, которую удобно держать перед глазами

Если нужно быстро объяснить весь mindset одним скрином, я бы оставил себе такую карточку:

FINDING
   |
   v
[Real / Valid?]
   |
   v
[Affected in our build / runtime?]
   |
   v
[Where is it deployed?]
   |
   v
[Who can reach it?]
   |
   v
[Is the vulnerable path reachable?]
   |
   v
[Possible -> Feasible -> Weaponized -> Active?]
   |
   v
[What identity / privileges does compromise give?]
   |
   v
[What can the attacker reach next?]
   |
   v
[Business impact / blast radius]
   |
   v
[Which control can break the path now?]
   |
   v
[Priority -> Treatment -> Owner -> SLA / Expiry]
   |
   v
[Verify -> Reassess -> Reopen if assumptions change]

Это не checklist. Это короткая модель мышления (т.е. ты можешь ее адаптировать под свой стек\архитектуру\продукт). Если на одном из шагов нет ответа, то просто пишем Unknown, а не автоматически превращаем неизвестность в Low risk.

Еще один полезный operational signal из реальной работы — age / time at risk: сколько finding уже живёт в production и сколько времени актив остается под экспозицией. Возраст проблемы\бага сам по себе не превращает Medium в Critical, но помогает управлять очередью, метриками SLA breaches и накопленным security debt (что очень важно для Lead и Head).

Почему классическая модель «CVSS = Priority» больше не работает

Модель старой школы (лет так 10 назад) выглядела просто:

Scanner -> CVE -> CVSS -> SLA -> Patch

Например:

CVSS 9.0-10.0 -> Critical -> fix in 24/48h
CVSS 7.0-8.9  -> High     -> fix in 7 days
CVSS 4.0-6.9  -> Medium   -> fix in 30 days
CVSS < 4.0     -> Low      -> backlog

Для отчетности это красиво. Для реальной Product Security — слишком грубо, не качественно. Нужен экспертный взгляд, парсинг профессионала.

Метода FIRST в актуальном CVSS v4.0 прямо подчёркивает, что CVSS-B измеряет severity, а не risk. В версии 4.0 (актуальна на на момент написания материала) появились отдельные Base, Threat, Environmental и Supplemental metrics, и сама модель фактически говорит потребителю: Base Score — это только начало анализа.

То есть даже стандарт, который часто ошибочно используют как готовый risk score, говорит обратное.

Смотрим практический пример:

• CVSS 9.8 в library, которую приложение физически не вызывает, может быть ниже по operational priority;
• CVSS 6.5 на internet-facing API, который позволяет cross-tenant data exposure, может быть для бизнеса гораздо опаснее;
• CVSS 8.x на внутреннем CI/CD controller может стать P0, если через него доступны signing keys, registry, production deploy tokens и Kubernetes;
• CVSS 10.0 на package, которого нет в runtime artifact, вообще может оказаться false positive или not_affected для данного продукта.

Поэтому предпочитаю мыслить вот так:

Priority = f(
    Technical Severity,
    Applicability,
    Exposure,
    Reachability,
    Exploitability,
    Threat Intelligence,
    Asset Criticality,
    Blast Radius,
    Compensating Controls,
    Business Impact,
    Confidence
)

Это не математическая формула и не предложение умножать один subjective score на другой. Это скорее список вопросов, которые инженер должен пройти до того, как назвать vulnerability «Critical для нас\продукта».

Полевая терминология

Если вы только входите в Product Security, то часть терминов сначала звучит как корпоративная магия. На практике они довольно конкретны. Ценим ниже, разбираем по косточкам.

Mindset инженера: не «закрыть CVE», а доказать (бизнес) риск

Когда я разбирал vulnerability, я старался не начинать с фразы:

«У нас Critical». «Нужен фикс от разрабов, включаем тикет в спринт»

Я начинал с другого, а точнее спрашивал себя и коллег по SecOps:

«Что именно должно произойти, чтобы attacker превратил этот finding в реальный impact?»

Это резко меняет качество анализа. Вместо красной карточки в scanner dashboard появляется attack story:

Actor
  -> Entry point
  -> Trust boundary
  -> Vulnerable component/function
  -> Required privileges/configuration
  -> Exploit primitive
  -> Initial impact
  -> Pivot
  -> Crown jewel / data / production
  -> Business consequence

Если я не мог хотя бы приблизительно построить эту цепочку, значит triage ещё не закончен. И надо парсить дальше, искать доп инфу, консультироваться, а сейчас даже перетереть это с ИИ:)

Восемь вопросов, которые я задаю до назначения priority

1. Finding настоящий?

Сначала sanity check:

• правильный ли package/version;
• не stale ли SBOM;
• не false positive ли fingerprint;
• попадает ли binary/image, который реально деплоится, под affected range;
• совпадает ли OS/distro/build;
• не vendor-patched ли package при старом upstream version string;
• присутствует ли component только в build stage, но не в runtime image.

Это applicability.

Плохой triage начинается, когда команда тратит два дня на CVE, которого в production artifact вообще нет.

2. Где этот компонент живёт (слой, сегмент, сервис)?

Дальше нужен deployment context.

Например:

repo -> build -> image -> registry -> Kubernetes -> pod -> service -> route

Нужно понимать про:

• dev / test / staging / prod;
• public или internal;
• tenant-facing или back-office;
• container, VM, serverless, bare metal;
• ephemeral worker или long-lived controller;
• есть ли state, secrets, customer data;
• какие identities/service accounts привязаны к workload.

Слово asset criticality начинается именно здесь. Да, мэн, держать четкую карту продукта\инфраструктуры в голове.

3. Есть ли exposure?

Exposure — это не только «торчит ли порт 443 в Интернет».

Вот полезная шкала оценки в процессе рассуждения:

Internet unauthenticated
        ↓
Internet authenticated
        ↓
Partner / customer private network
        ↓
VPN / corporate network
        ↓
Internal service-to-service
        ↓
Namespace / host local
        ↓
Offline / build-only

Иногда internal system опаснее public endpoint, потому что у него намного больше downstream privileges. Например, Jenkins может быть доступен только через VPN, но иметь:

• GitLab token;
• kubeconfig;
• registry credentials;
• AWS role;
• artifact signing key.

В таком случае «internal only» — не аргумент для автоматического downgrade. Можно найти решение гибче.

4. Reachable ли vulnerable path?

ЗАПОМНИ: Package presence не равна exploitability. Это аксиома. Нужно уметь отличать несколько уровней доказательства. Юзаем шпаргалку ниже.

Лестница reachability evidence

Чем выше уровень evidence, тем сильнее вывод. Но важно и обратное: отсутствие статического path не всегда доказывает невозможность эксплуатации. Reflection, dynamic loading, plugin systems, native calls, dependency internals, runtime code generation могут ломать простые call graph assumptions.

Поэтому хороший verdict инженера выглядит не так:

NOT REACHABLE = SAFE

а больше вот так:

No reachable path found with current evidence; confidence: Medium. Reassess if feature/config/runtime changes.

Из open-source tooling хороший пример такого подхода — OSV-Scanner с call analysis: он умеет отделять vulnerabilities в вызываемом коде от package findings, где affected code path не обнаружен. OWASP dep-scan также развивает reachability-aware prioritization и VEX output.

5. Насколько exploit weaponizable?

Technical severity отвечает не на всё. Это тоже аксиома. Запомни это.

Поэтому я смотрю на еще и:

• есть ли public PoC;
• есть ли functional exploit;
• насколько exploit stable;
• нужен ли rare prerequisite;
• pre-auth ли это;
• можно ли автоматизировать массовый scanning;
• попал ли CVE в CISA KEV;
• какой EPSS probability и percentile;
• есть ли vendor warning об active exploitation;
• есть ли exploitation в threat reports.

EPSS: probability != percentile

Здесь есть одна ловушка, на которой регулярно спотыкаются даже люди, уже работающие с vulnerability data. Эти два термина похоже, но сука, по разному воспринимаются м путать их НИ-Ни!

EPSS probability и EPSS percentile — не одно и то же.

• Probability — абсолютная модельная вероятность наблюдаемой эксплуатации CVE в ближайшие 30 дней. Значение 0.10 означает примерно 10%, а не «низкий балл 0.1 из 10».
• Percentile — относительный rank этой probability среди всех CVE, для которых FIRST публикует EPSS. Например, percentile = 0.95 означает, что score выше примерно 95% текущей популяции, а не 95% вероятность эксплуатации.

Из-за того что большая часть CVE никогда не наблюдается в реальной эксплуатации, distribution сильно смещён к нулю. Поэтому даже на первый взгляд небольшая probability может находиться очень высоко по percentile.

Я обычно сохраняю оба значения вместе:

EPSS probability:  0.10 (10%)
EPSS percentile:   0.95 (95th percentile)
EPSS checked_at:   YYYY-MM-DD

checked_at полезен потому, что EPSS обновляется ежедневно: threat signal — не статический атрибут CVE.

И еще одно важное правило: не надо умножать EPSS на CVSS и называть результат risk score. EPSS — калиброванная probability, а CVSS Base — severity model. Такое перемножение создаёт красивое число без понятной статистической интерпретации — FIRST прямо относит подобную практику к misuse.

Здесь полезно различать:
Possible — теоретически возможно.
Feasible — практически реализуемо.
Weaponized — есть готовый exploit / tooling.
Active — уже эксплуатируется in the wild.

Эти состояния требуют разного operational response. Но это уже несколько другая тема и выхолит за скоуп статьи.

6. Что получит attacker после первого шага?

Это вопрос про privilege context. Например, RCE в pod не всегда равно cluster compromise.

Нужно проверить:

• UID/root/non-root;
• privileged container;
• Linux capabilities;
• hostNetwork / hostPID / hostPath;
• service account token;
• Kubernetes RBAC;
• cloud IAM role;
• mounted secrets;
• access to metadata service;
• outbound egress;
• access to control plane;
• registry permissions;
• CI/CD secrets.

Один и тот же RCE, который:

RCE in isolated non-root pod

и который:

RCE in privileged deployment controller with cluster-admin

— два разных бизнес-события. Вот тут то видно кто Jun, кто Mid, а кто скиловый прошедший огонь и воду Senior:)

7. Какой blast radius?

После initial access я мысленно спрашиваю себя:

«Что attacker сможет сделать следующим?»

Ценим пример:

Internet
   |
   v
[Nginx]
   |
   v
[API Pod]
   |
   +--> service account
   |
   +--> internal DB
   |
   +--> internal admin API
   |
   +--> container registry
   |
   +--> secrets

Если vulnerability дает только локальный DoS одного stateless replica — один риск. Если она открывает путь к:

• cross-tenant data;
• production secrets;
• signing keys;
• build system;
• registry write;
• IAM privilege escalation;
• production deployments;
• customer PII;

ТО приоритет резко РАСТЕТ. Это и есть blast radius analysis.

8. Как быстрее всего разорвать attack path?

Здесь важный инженерный shift у себя в мозгу: remediation не равно patch. Patch — это , да, отличный вариант, но не единственный.

Иногда самый быстрый risk reduction:

• отключить feature flag;
• закрыть route;
• убрать Internet exposure;
• выключить CLI;
• применить WAF/gateway rule;
• заблокировать egress;
• deny access к metadata;
• урезать IAM/RBAC;
• убрать secret mount;
• изолировать namespace;
• rollbackнуть component;
• удалить vulnerable package;
• rotate credentials;
• поставить vendor hotfix;
• временно вывести node/service из эксплуатации.

А потом спокойно сделать permanent fix. Именно поэтому хороший Security Engineer влияет не только на что чинить, как закинуть таск в спринт, но и на как уменьшить risk прямо сейчас.

Полный processing chain: как finding превращается в решение

Ниже — pipeline, который я бы дал junior engineer как рабочую карту.

[SCA / SAST / DAST / CNAPP / Pentest / Bug Bounty / Vendor Advisory]
                              |
                              v
                    1. Intake / Normalize
                              |
                              v
                    2. Validate / Dedupe
                              |
                              v
                       3. Applicability
                              |
                              v
                  4. Exposure / Reachability
                              |
                              v
                5. Exploitability / Threat Intel
                              |
                              v
                 6. Asset / Identity / Blast Radius
                              |
                              v
                     7. Business Impact
                              |
                              v
                 8. Compensating Controls
                              |
                              v
                    9. Priority Decision
                              |
                              v
                 10. Treatment / Ownership
                              |
                              v
                    11. Fix Verification
                              |
                              v
               12. Evidence / Exception / Recheck

Теперь разберём, что происходит на каждом шаге. По сути, тебе можно держать эту табличку как шпаргалку

Как выглядит хороший triage ticket

Один из лучших навыков Senior Engineer — уметь превратить шумный scanner output в короткий decision-ready record.

Я бы использовал примерно такой шаблон:

Finding ID:
Source: SCA / SAST / DAST / Pentest / Vendor / Bug Bounty
Asset / Service:
Environment: prod / staging / dev
Owner:

CVE / CWE:
Affected component + version:
CVSS-B / vector:
EPSS probability / percentile:
CISA KEV: yes/no
Public PoC: yes/no/unknown
Active exploitation: yes/no/unknown

Exposure:
Authentication required:
Entry point:
Reachability evidence:
Exploit prerequisites:
Assessment confidence: High / Medium / Low

Runtime identity:
IAM / RBAC context:
Secrets available:
Downstream systems:
Blast radius:
Data classification:

Existing controls:
Control verification evidence:
Residual risk:

Final priority:
Recommended treatment:
Security owner:
Engineering owner:
Due date / SLA:
Exception expiry:
Reopen triggers:

Сравни два handoff’а. И ты поймешь в чем разница:)

Плохой ответ

Critical CVE 9.8. Please patch ASAP.

Хороший ответ

CVE-X присутствует в production image orders-api:v312. Package affected, но vulnerable XML import function не reachable из published routes; feature disabled, call graph path отсутствует, runtime trace не показывает загрузку parser. Internet exposure сервиса есть, но affected route отсутствует. CVE не в KEV; public exploit не обнаружен. Impact при гипотетическом exploit высокий из-за customer data. Priority: P2. Upgrade dependency в ближайшем release train; VEX not_affected/code_not_reachable с expiry 30 дней. Reopen при включении import feature, появлении KEV/working exploit или изменении route table.

Второй вариант позволяет Tech Lead принять решение. Первый — работает либо Jun либо олух. Либо происходит что-то еще:) но не очень хорошее:))

Severity, Risk и Priority — не путайте эти слова

Это одна из самых частых проблем на интервью и в реальной работе.

Severity

Насколько тяжёлым может быть technical impact vulnerability. Обычно здесь CVSS.

Risk

Комбинация likelihood + impact в конкретном контексте организации.

Priority

Насколько быстро мы должны действовать относительно других задач, рисков и ресурсов.

Можно иметь:

High Severity + Low Reachability + Strong Controls = Medium Priority

или:

Medium Severity + Internet Exposure + High Exploitability + Crown Jewel Impact = Critical Priority

И это не противоречие. Это нормальная risk-based prioritization.

Risk Priority != Remediation Difficulty

Это Lead-level нюанс, который очень легко потерять, когда security и engineering начинают спорить о сроках.

То, что vulnerability сложно исправить, не делает её менее рискованной. Сложность fix влияет на treatment plan, но не должна задним числом переписывать assessment.

Я стараюсь держать отдельно минимум пять осей:

Это даёт гораздо более честную decision model:

Самая опасная ошибка выглядит так:

“Да, это P0, но patch сложный, поэтому давайте назовём finding Medium.”

Нет. Если risk действительно P0, он остаётся P0. Просто immediate response может быть не patch, а containment / mitigation, который быстро разрывает attack path, пока engineering готовит безопасный permanent fix.

И обратная сторона тоже важна: дешёвый fix не обязан автоматически становиться P0. Его можно сделать как quick win, но remediation convenience не является measure of risk.

Смог это объяснить на тех интервью!? Поздравляю, мен, +15% к базовой ставке оффера!

Практическая decision matrix

Я не люблю псевдоточность вида Risk Score = 8.736 из десяти субъективных коэффициентов. Что б**ть за цифры, мы же люди, не машины, говорить нужно понятно. Для инженерной коммуникации часто лучше прозрачная qualitative matrix. Вот она, цени ниже.

Я бы затем переводил это в operational class. Разберем их ниже.

P0 / Critical

Типичный профиль:

• Internet-facing или easy lateral reach;
• pre-auth / unauth;
• reachable vulnerable path;
• KEV / active exploitation / reliable weaponized exploit;
• crown-jewel asset;
• большой blast radius;
• controls отсутствуют или обходятся.

Action: containment сейчас, remediation emergency lane, incident-assumption при необходимости, credential rotation, IOC review.

P1 / High

• exploit path реален;
• asset важный;
• exploitation feasible;
• impact высокий;
• есть частичный mitigation или active exploitation пока не подтверждена.

Action: expedited fix, short SLA, named owner, tracking до closure.

P2 / Medium

• vulnerability применима;
• требует authentication/config/prerequisite;
• blast radius ограничен;
• controls действительно работают.

Action: normal release cycle с конкретной датой.

P3 / Low / Temporarily Accepted

• component присутствует, но affected function недостижима с хорошим evidence;
• feature отключена;
• required configuration отсутствует;
• exposure минимален;
• compensating controls подтверждены.

Action: документированный exception/risk acceptance, owner, expiry и reopen conditions.

Risk acceptance без срока пересмотра — это не risk management. Это архивирование проблемы.

Где здесь CVSS v4, EPSS, KEV, SSVC и VEX и как, с*ка это все запомнить

Эти инструменты не конкурируют. Они отвечают на разные вопросы. Если забыл про один, но помнишь два других - ОК. Важно не столько "помнить" сколько "понимать", никто не запрещает юзать шпоры) Да же я когда преподавал в универе, то разрешал ребятам на экзамене использовать конспекты

CISA SSVC особенно полезен как mindset: вместо «score worship» он использует decision tree и учитывает состояние эксплуатации и impact. В модели CISA возможны outcomes вроде Track, Track*, Attend, Act.

Я не предлагаю копировать SSVC один в один в любую компанию. Но сама идея очень правильная: цель assessment — не получить красивое число, а принять response decision.

Кейс 1: CVSS 9.8, но attack path отсутствует

Представим production platform. Анонимно, детали под NDA, но суть сохранена.

                         Internet
                            |
                            v
                       [Cloud LB]
                            |
                            v
                     [Nginx Ingress]
                            |
                            v
                     [Istio Gateway]
                            |
                            v
                  +-------------------+
                  | orders-api Pod    |
                  | app + sidecar     |
                  +-------------------+
                     |            |
                     v            v
                [PostgreSQL]   [Kafka/MQ]

CI/CD:
Developer -> GitLab -> Jenkins -> Registry -> Kubernetes

SCA находит vulnerable XML parsing dependency с CVSS 9.8. Scanner dashboard становится красным. Формальный SLA говорит «Critical».

Что делает inexperienced engineer

Создаёт Jira:

Upgrade immediately. CVSS 9.8.

Что делает Senior Product Security Engineer

Проверяет applicability и path.

1. Package действительно есть в runtime image.
2. Affected function используется только модулем legacy XML import.
3. Feature flag xml_import=false в production.
4. Route для import отсутствует в Nginx/Istio config.
5. Static call graph не находит path от HTTP handlers к affected parser.
6. Runtime tracing не показывает загрузку этого parser за наблюдаемый период.
7. NetworkPolicy не является главным justification, но дополнительно ограничивает lateral path.
8. Нет KEV / active exploitation signal, который бы заставил пересмотреть conservative assumptions.

Reachability verdict

Package present:        YES
Affected version:       YES
Imported:               YES
Affected function:      NOT REACHED by current static evidence
Published route:        NO
Feature enabled:        NO
Runtime observed path:  NO
Confidence:             MEDIUM-HIGH

Решение

Technical severity остаётся Critical.

Operational priority может стать P2, потому что текущий deployed product не предоставляет attacker path к affected function.

Но я бы не делал close and forget.

Я бы сделал:

• upgrade dependency в ближайшем release train;
• VEX statement not_affected с justification типа code_not_reachable, если ваша схема VEX это поддерживает;
• приложил evidence;
• назначил expiry;
• добавил reopen triggers.

Например:

Reopen if:
- XML import feature enabled;
- route published;
- dependency behavior changes;
- working exploit changes assumptions;
- CVE enters KEV;
- architecture / call path changes.

Урок: мы не «проигнорировали Critical». Мы доказали текущую неэксплуатируемость с заданным confidence и поставили автоматические условия пересмотра.

Кейс 2: формально «не RCE», но priority становится Critical

Теперь противоположный пример. Ценим, мотаем на ус:)

Internet
   |
   v
[CDN / WAF]
   |
   v
[Nginx Ingress]
   |
   v
[image-preview API]
   |
   |  outbound fetch
   v
[internal/cloud endpoints]
   |
   +--> metadata / workload identity (if reachable)
   +--> internal admin services
   +--> storage
   +--> registry

В функции preview обнаружен SSRF.

Первое впечатление:

• прямого RCE нет;
• endpoint «всего лишь качает картинку»;
• scanner может присвоить Medium/High;
• команда хочет положить issue в обычный backlog.

Теперь context review.

Exposure

• endpoint Internet-facing;
• account не требуется;
• requests легко автоматизировать.

Reachability

• attacker controls URL;
• URL попадает в outbound HTTP client;
• egress unrestricted;
• allowlist отсутствует.

Identity context

Workload имеет cloud identity и доступ к internal resources.

Blast radius

Успешный SSRF потенциально превращается в:

Internet actor
   -> SSRF primitive
   -> internal/cloud endpoint access
   -> credentials / internal service access
   -> data or registry compromise

Что делать

Патчить код нужно. Но fast containment может быть быстрее:

• disable preview feature;
• outbound allowlist;
• block link-local/metadata destinations;
• egress NetworkPolicy;
• reduce workload IAM;
• separate fetcher into isolated workload;
• require auth/rate limits если это соответствует продукту;
• затем permanent code fix.

Итог

Technical severity:   Medium/High
Internet exposure:    Critical signal
Reachability:         Confirmed
Exploit automation:   High
Business impact:      High/Critical
Controls:             Weak
Priority:             P0/P1

Урок: отсутствие RCE не делает vulnerability «некритичной». В Product Security важен exploit chain, а не название CWE.

Кейс 3: TeamCity CVE-2023-42793 — когда почти все сигналы смотрят в одну сторону

Теперь реальный пример. Можешь сам погуглить:)

В 2023 году вендор JetBrains раскрыл CVE-2023-42793 в TeamCity On-Premises. Vendor описал scenario, при котором unauthenticated attacker с HTTP(S) access мог получить RCE и административный контроль TeamCity server. JetBrains выпустила исправление в 2023.05.4 и patch plugin для старых версий. Херовая бага... для них:) И сейчас поймешь почему.

Позже JetBrains сообщила о наблюдаемой эксплуатации, включая активность nation-state actors. CISA добавила CVE в KEV.

Представим enterprise deployment:

Internet / Corp Network
          |
          v
   [TeamCity Server]
          |
          +----> GitLab repos
          |
          +----> Build agents
          |
          +----> Docker Registry
          |
          +----> Artifact repository
          |
          +----> Kubernetes deploy token
          |
          +----> Cloud secrets / IAM

Здесь contextual signals:

• Severity: Critical;
• Exposure: если public — Critical; если internal — всё равно material;
• Reachability: direct HTTP(S);
• Auth requirement: pre-auth/unauth в vulnerable scenario;
• Threat intel: active exploitation;
• KEV: yes;
• Asset criticality: CI/CD crown jewel;
• Blast radius: source + artifacts + deployments + secrets;
• Supply-chain impact: возможен downstream compromise.

В этот момент спор «9.8 или 10.0?» практически бесполезен.

Хороший response

1. Contain — убрать public exposure/ограничить access, если patch не мгновенный.
2. Patch/upgrade — применить vendor fix.
3. Hunt — проверить IOCs, логи, abnormal behavior.
4. Assume credential exposure where justified — оценить, какие secrets были доступны TeamCity.
5. Rotate — deployment tokens, registry creds, cloud credentials при необходимости.
6. Inspect downstream — build agents, artifacts, releases.
7. Restore — только после проверки.

Урок: mature vulnerability management иногда должен перейти из обычного remediation в incident-response mode.

Ещё три коротких real-world anchor’а

Jenkins CVE-2024-23897

Jenkins описал arbitrary file read через CLI, который в определённых условиях мог приводить к более серьёзным последствиям, включая RCE scenarios. Vendor отдельно описал prerequisites и workaround: временное отключение CLI могло предотвратить exploitation до upgrade.

Что это хорошо показывает:

• название finding’а «file read» может недооценивать downstream impact;
• prerequisites важны;
• configuration и encoding могли влиять на практическую exploitability;
• temporary mitigation может быть правильным first response, пока идёт patching.

XZ Utils CVE-2024-3094

XZ backdoor показал другую сторону contextual analysis: громкое событие не означает, что every Linux host одинаково affected.

Нужно было выяснять:

• exact version;
• distro/build;
• package provenance;
• runtime interaction;
• присутствует ли malicious build в конкретной системе.

Red Hat, например, отдельно указывала affected Fedora builds и то, что RHEL не был затронут.

Урок: inventory + provenance + applicability могут быть важнее самой headline severity.

HTTP/2 Rapid Reset CVE-2023-44487

Для public high-volume edge сервисов availability issue может быть P0, даже если речь не идёт о code execution или data theft.

Урок: CIA impact должен оцениваться относительно business function. Availability иногда важнее Confidentiality.

Compensating controls: не верьте архитектурной диаграмме на слово

Одна из самых опасных фраз на triage call:

«У нас же WAF».

Хорошо. Какой rule? Какой exploit primitive он блокирует? Проверяли ли bypass? На каком edge? Доходит ли traffic в обход него? Есть ли alternate route?

То же самое с:

• NetworkPolicy;
• service mesh authz;
• VPN;
• MFA;
• EDR;
• runtime protection;
• least privilege;
• egress deny;
• secret isolation.

Compensating control должен быть связан с attack path. Иначе, простите, это Г**но, а не контроль:))

Например:

Attacker
   |
   v
[Ingress]
   |
   v
[API Pod]
   |
   +------X------> Metadata
          |
      egress deny
      VERIFIED

Здесь control действительно ломает конкретный edge в attack graph. А запись «WAF enabled» без proof — почти ничего не значит.

Что значит «влиять на решение» как Senior Engineer

Когда я говорю, что инженер должен влиять на решение, я не имею в виду, что Security единолично решает судьбу релиза. Хорошая модель выглядит так:

Security приносит описание\расшифровку

• exploit mechanics;
• reachability evidence;
• threat intel;
• likely attack path;
• blast radius;
• mitigation options;
• residual risk.

Engineering (DEV) приносит

• implementation reality;
• release constraints;
• regression risk;
• patch complexity;
• feature dependencies.

Product / Business owner приносит

• customer impact;
• contractual commitments;
• revenue/availability context;
• acceptable downtime;
• risk appetite.

Leadership принимает или делегирует decision

• fix now;
• ship with mitigation;
• feature off;
• rollback;
• emergency maintenance;
• documented exception;
• accept residual risk.

Security Engineer здесь — decision enabler, а не человек, который только генерирует "красные тикеты". Короче, хоть грейд у него и ниже, а ЗП меньше чем у Head, без его оценки никуда, без его работы никак!

Risk treatment: у вас больше вариантов, чем «patch / no patch»

В NIST risk management обычно встречаются базовые стратегии: mitigate, avoid, transfer, accept. В vulnerability workflow их можно перевести в более инженерный язык.

Очень важно: mitigation должен снижать either likelihood or impact. Если он не меняет attack path и не уменьшает последствия — это не mitigation, а чувство безопасности.

Кто участвует в assessment

Хороший triage редко делается одним человеком. Это вероятно только для очень не зрелых команд и маленктих компаний\стартапов.

Зрелость (mature) — это не когда Security знает все и может процитировать на память. Зрелость — когда процесс быстро собирает нужный context у правильных владельцев. Дальше это все коллегиально обсуждается, принимается общее решение основанное на фактах, верстается оно в action plan. И далее раздается на уровни ниже для реализации (Sec, Dev, Ops, QA, etc)

Три уровня мышления: Junior, Senior, Lead

Если вы Junior / кандидат, новичок

Ваша цель — научиться не верить одному scanner output.

Минимальный набор:

1. понять CVE/CWE;
2. найти affected version;
3. определить asset;
4. проверить exposure;
5. понять auth/prerequisites;
6. проверить PoC/KEV/EPSS;
7. поговорить с developer о code path;
8. описать impact;
9. предложить remediation + mitigation.

Если вы это умеете, вы уже мыслите намного ближе к Product Security Engineer, чем человек, который просто сортирует CVEs по CVSS.

Если вы Senior Engineer

От вас ждут:

• ownership triage;
• attack-path reasoning;
• confidence-based conclusions;
• хорошую коммуникацию с dev/platform;
• business translation;
• viable treatment options;
• verification after fix;
• правильный exception process.

Senior не просто говорит «все плохо или все норм». Senior говорит:

«Вот path, вот evidence, вот impact, вот три способа снизить risk, вот самый дешёвый по времени, вот residual risk.»

Если вы Tech Lead / Security Lead

Вопрос уже не только про один finding. Нужно построить систему:

• common triage rubric;
• risk taxonomy;
• ownership model;
• SLAs;
• exception workflow;
• KEV/EPSS enrichment;
• SBOM/VEX integration;
• duplicate suppression;
• re-open triggers;
• metrics качества.

Полезные lead-level metrics:

• MTTR по risk class, а не просто CVSS;
• age of reachable Critical/High findings;
• KEV exposure time;
• Internet-exposed exploitable findings;
• exceptions past expiry;
• percentage findings with confirmed owner;
• false-positive/duplicate rate;
• percentage SCA findings с reachability evidence;
• time from finding to containment;
• recurrence rate по CWE/root cause.

Это уже vulnerability management как engineering system, а не spreadsheet. Вообщем, здесь уже меньше технарьщины и больше про outcomes.

Рекомендации для молодого инженера

Если завтра получил finding, не спеши говорить «Critical». Пройдите этот mini-checklist:

[ ] Is it real?
[ ] Are we affected?
[ ] Where is it deployed?
[ ] Who can reach it?
[ ] Can input reach the vulnerable sink?
[ ] Is there a PoC / EPSS / KEV signal?
[ ] What identity/privileges does the workload have?
[ ] What can attacker reach next?
[ ] What is the business impact?
[ ] Which controls actually break the path?
[ ] What is the fastest safe treatment?
[ ] Who owns it and when do we recheck?

Если можешь ответить на эти вопросы — то уже есть основа для defensible risk decision. Иначе искать доп материал, парсить и\или качать профессиоанльный скилл.

Как ответить на интервью: «How do you prioritize vulnerabilities?»

Короткий хороший ответ на уровне Product Security:

«Я не использую CVSS как единственный priority signal. Сначала подтверждаю applicability и deployment context, затем смотрю exposure и reachability до vulnerable function, после этого добавляю exploit intelligence — EPSS, KEV, public PoC и active exploitation. Дальше оцениваю asset criticality, runtime identity, blast radius и business impact, проверяю compensating controls и только потом назначаю remediation priority. Для меня главное — построить attack path и выбрать response, который быстрее всего снижает residual risk: patch, isolation, feature disablement, IAM reduction или временный documented exception.»

Если кандидат отвечает примерно так — я понимаю, что он уже мыслит не scanner’ом, а risk system. И это Mid как минимум, а то и Mid+ or Senior. Больше скилл = больше экспертизы = больше ответственности = больше salary:)

Что автоматизировать, а что оставить человеку

Автоматизация (ИИ в том числе) отлично справляется с:

• inventory;
• SCA/CVE matching;
• CVSS enrichment;
• EPSS;
• KEV flags;
• Internet exposure signals;
• cloud asset metadata;
• basic reachability;
• duplicate correlation;
• SLA routing.

Человек всё ещё нужен для:

• business impact;
• strange architecture;
• dynamic code paths;
• exploit-chain reasoning;
• control validation;
• exception justification;
• trade-off между risk и delivery;
• confidence assessment.

Поэтому ASPM/CNAPP/SCA evolution идёт в сторону context correlation, но полностью «автоматический risk score» всё ещё нужно воспринимать осторожно.

Типовые ошибки\заблуждения, которые могут сэконоить время

Ошибка 1. CVSS = риск

Нет. Это severity input.

Ошибка 2. Package present = vulnerable path reachable

Нет. Нужен applicability/reachability analysis.

Ошибка 3. Internal = safe

Нет. Internal crown jewel может быть опаснее edge service.

Ошибка 4. Есть WAF = mitigated

Только если конкретный rule действительно ломает exploit primitive.

Ошибка 5. Нет public PoC = можно забыть

Нет. PoC — только один threat signal.

Ошибка 6. Patch deployed = ticket можно закрыть

Нет. Нужен verification: новая версия, rescan/retest, отсутствие vulnerable artifact/path.

Ошибка 7. Risk accepted = навсегда

Нет. Нужны owner, expiry и reopen trigger.

Ошибка 8. Security должен всегда требовать fix

Нет. Security должен обеспечить правильное решение по риску.

Небольшой practical model для команды

Если строишь процесс с нуля (from scratch), я бы начал не с сложного scoring engine, а с пяти обязательных полей:

1. Exposure
2. Reachability
3. Exploit status
4. Asset/business criticality
5. Verified controls

И добавил meta-field:

Assessment Confidence: Low / Medium / High

Почему confidence важен?

Потому что:

"Not reachable, confidence HIGH"

и

"Not reachable, because scanner didn't find anything, confidence LOW"

ТУТ, как видишь, совершенно разные решения.

Финальная модель

Я бы визуализировал современный vulnerability triage так:

                    +----------------------+
                    | Finding / CVE / CWE  |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Applicability        |
                    | version/build/runtime|
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Exposure             |
                    | Internet/Auth/Trust  |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Reachability         |
                    | route/call/taint     |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Exploitability       |
                    | CVSS/EPSS/KEV/PoC    |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Identity + Blast     |
                    | Radius + Crown Jewels|
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Business Impact      |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Verified Controls    |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Risk / Priority      |
                    | P0 / P1 / P2 / P3    |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Treatment            |
                    | Fix/Mitigate/Accept  |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Verify + Reassess    |
                    +----------------------+

И здесь CVSS остаётся важным. Просто он больше не сидит на вершине трона. Он занимает своё правильное место: один из входных signals в инженерную систему принятия решений.

Главное

Когда я был инженером, моя задача не сводилась к тому, чтобы найти vulnerability и назвать её Critical.

Моя задача была сделать проблему понятной и помочь команде принять правильное решение.

Иногда правильное решение — emergency patch.
Иногда — выключить feature за 15 минут и patch сделать завтра.
Иногда — закрыть Internet route.
Иногда — урезать IAM и разорвать exploit chain.
Иногда — задокументировать, что vulnerable code path в нашем продукте реально недостижим, и спокойно исправить dependency в следующем release.

Но любое из этих решений должно быть основано на evidence, а не на ощущении.

Не спрашивай только: «Какой CVSS?»

Спрашивай: «Это применимо к нам? Может ли attacker добраться до vulnerable path? Насколько вероятна эксплуатация? Что он получит после первого шага? Какой blast radius? Что потеряет бизнес? И как быстрее всего разорвать attack path?»

Вот в этот момент vulnerability management перестаёт быть сортировкой красных строк в dashboard и становится настоящей Product Security engineering discipline.

Бесплатный toolbox: куда я захожу во время vulnerability triage

Ни один внешний портал не знает вашу architecture, identities, trust boundaries и business impact. Но несколько бесплатных источников могут очень быстро закрыть часть fact-finding.

И я всё равно держу рядом NVD как хороший baseline для CVE/CVSS/CWE/CPE и references. Сам NVD отдельно подчёркивает, что CVSS — это severity, а не risk.

Zero-budget triage в Excel / Google Sheets

Если ASPM/VM platform пока нет, можно собрать surprisingly useful workflow буквально из CSV и нескольких enrichment sources.

1. Выгрузить findings из SCA/VM/scanner в CSV.
2. Подтянуть EPSS probability + percentile из FIRST API/CSV.
3. Добавить флаг KEV.
4. Заполнить руками или из asset inventory локальный context.
5. Фильтровать backlog уже не только по CVSS.

Я бы использовал такие колонки:

CVE / Finding ID
Asset / Service
Environment
Owner
CVSS + Vector
EPSS Probability
EPSS Percentile
EPSS Checked At
KEV Y/N
Public PoC / Exploit Y/N
Internet Exposure
Authentication Required
Reachability
Reachability Evidence
Runtime Identity / Privileges
Asset Criticality
Blast Radius
Business Impact
Compensating Controls
Assessment Confidence
Risk Priority
Remediation Effort
Change Risk
Treatment
SLA / Due Date
Exception Expiry
Reopen Triggers

FIRST публикует EPSS как API и daily CSV, поэтому его легко JOIN-нуть по CVE даже без коммерческого tooling. Главное — не пытаться превратить spreadsheet в магический formula engine: таблица должна сохранять evidence и помогать принять решение, а не скрывать reasoning за непрозрачным score.

References and further reading

1. FIRST — CVSS v4.0 User Guide https://www.first.org/cvss/v4.0/user-guide
2. FIRST — CVSS v4.0 Specification https://www.first.org/cvss/v4.0/specification-document
3. FIRST — Exploit Prediction Scoring System (EPSS) https://www.first.org/epss/
4. FIRST — EPSS FAQ https://www.first.org/epss/faq
5. CISA — Known Exploited Vulnerabilities Catalog https://www.cisa.gov/known-exploited-vulnerabilities-catalog
6. CISA — Stakeholder-Specific Vulnerability Categorization (SSVC) https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
7. CISA — SBOM / VEX Resources Library https://www.cisa.gov/topics/cyber-threats-and-advisories/sbom/sbomresourceslibrary
8. CycloneDX — Vulnerability Exploitability eXchange (VEX) https://cyclonedx.org/capabilities/vex/
9. NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management Planning https://csrc.nist.gov/pubs/sp/800/40/r4/final
10. NIST IR 8179 — Criticality Analysis Process Model https://csrc.nist.gov/pubs/ir/8179/final
11. NIST IR 8286B — Prioritizing Cybersecurity Risk for Enterprise Risk Management https://www.nist.gov/publications/prioritizing-cybersecurity-risk-enterprise-risk-management-0
12. OWASP — Risk Rating Methodology https://owasp.org/www-community/OWASP_Risk_Rating_Methodology
13. OWASP — Vulnerable Dependency Management Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html
14. Google — OSV-Scanner Call Analysis https://google.github.io/osv-scanner/output/
15. OWASP dep-scan — Reachability-aware dependency analysis https://github.com/owasp-dep-scan/dep-scan
16. JetBrains — CVE-2023-42793 TeamCity security issue https://blog.jetbrains.com/teamcity/2023/09/critical-security-issue-affecting-teamcity-on-premises-update-to-2023-05-4-now/
17. JetBrains — CVE-2023-42793 exploitation update https://blog.jetbrains.com/teamcity/2023/10/cve-2023-42793-vulnerability-in-teamcity-october-18-2023-update/
18. Jenkins — Security Advisory 2024-01-24 / CVE-2024-23897 https://www.jenkins.io/security/advisory/2024-01-24/
19. Red Hat — CVE-2024-3094 / XZ Utils alert https://www.redhat.com/en/blog/urgent-security-alert-fedora-40-and-rawhide-users
20. FIRST — EPSS Get the Data (API + daily CSV) https://www.first.org/epss/data
21. Rapid7 — Vulnerability & Exploit Database https://www.rapid7.com/db/
22. ProjectDiscovery — CVEMap https://github.com/projectdiscovery/cvemap
23. NIST — National Vulnerability Database (NVD) https://nvd.nist.gov/