Управление патчами и уязвимостями

Два конвейера, а не один

Говорят «патчинг» и имеют в виду две разные машины, скрученные вместе. Разделить их — первый зрелый ход, потому что у них разные входы, владельцы и режимы отказа.

Управление уязвимостями (vulnerability management) — это цикл «обнаружить-и-решить»: инвентаризировать каждый актив, непрерывно сканировать, сопоставлять каждую находку с фидом уязвимостей (NVD, бюллетени вендоров, твой SBOM) и затем решать — патчить, смягчить или принять. Управление патчами (patch management) — это исполнительная рука: получить фикс, протестировать в стейджинге, выкатить в продакшен волнами и проверить, что он действительно встал. Первое отвечает на что не так и важно ли это; второе — на как отгрузить фикс, не сломав прод.

Команды тонут, потому что схлопывают эти два в одно. Они позволяют сырому выводу сканера быть очередью работы, и каждый вторник очередь длиной в 4000 пунктов, а боевой дух испаряется. Дисциплина такова: управление уязвимостями триажит поток до ранжированного, конечного списка с дедлайнами, и только потом управление патчами вытягивает из него. Сканер, сваливающий неранжированные находки в очередь тикетов, — это не программа, это DoS-атака на собственных инженеров.

Почему базовый балл CVSS — неверный ключ сортировки

CVSS даёт каждой уязвимости балл 0–10 из внутренних метрик: вектор атаки, сложность, требуемые привилегии и влияние на CIA. Этот базовый балл по-настоящему полезен — это стандартизированный, вендоронезависимый способ сказать «эта уязвимость, в абстракции, серьёзна». Но слово, которое всех губит, — абстракция. Базовый балл намеренно ничего не знает о твоём окружении: ни достижим ли уязвимый путь кода, ни смотрит ли коробка в интернет или зарыта в трёх подсетях вглубь, ни написал ли кто-нибудь когда-либо к ней эксплойт.

Эмпирика жестока. Исследования раскрытых CVE стабильно находят, что лишь малое меньшинство — порядка 5% — вообще когда-либо эксплуатируются вживую, при этом примерно 60% всех CVE имеют CVSS 7.0 или выше («High» или «Critical»). Сортируй по базовому баллу — и «High/Critical» перестаёт что-либо значить: это бо́льшая часть списка. Сам CVSS говорит, что базовый балл — не балл риска, и его надо комбинировать с окружающим и временны́м контекстом, прежде чем действовать, — указание, которое средняя политика «патчить все Critical за 30 дней» тихо игнорирует.

Поэтому зрелый рефрейм — это умножение, а не поиск по таблице. Риск ≈ серьёзность × экспозиция, где экспозиция — это та часть, которую CVSS опускает:

• Эксплуатируемость вживую — есть ли публичный proof-of-concept? Есть ли она в каталоге Known Exploited Vulnerabilities (KEV) от CISA или высоко по EPSS (модель, предсказывающая вероятность эксплуатации CVE в ближайшие 30 дней)? Баг из KEV используют прямо сейчас; это бьёт теоретическую 9.8 каждый раз.
• Достижимость — вызывается ли уязвимая функция твоим кодом и достижим ли актив оттуда, где стоит атакующий? Критичная уязвимость в зависимости, которую ты импортируешь, но никогда не вызываешь, — латентна, а не живая.
• Радиус поражения — чего касается эта коробка? RCE на коробке с клиентской БД — это другая вселенная по сравнению с тем же RCE на изолированном пакетном воркере.

Прочти первые две строки вместе: 6.5 обгоняет 9.8. Любая политика, сортирующая по одной колонке CVSS, отгружает ровно неверный порядок.

SLA превращают приоритет в часы

Ранжированный список без дедлайна гниёт. Механизм, держащий его в движении, — это SLA на устранение: контракт, говорящий, что находка заданного приоритета обязана быть устранена в фиксированном окне, отсчитываемом от обнаружения, и отслеживается. Типичные формы выглядят так: P0/эксплуатируемая Critical → 24–72 часа (или экстренный внеплановый выкат), High → 7–30 дней, Medium → 30–90 дней, Low → следующий плановый цикл или принятие риска.

Две вещи делают SLA реальными, а не театром. Первое: часы стартуют от обнаружения, а не от «когда мы дошли» — так что находка, лежащая нетриажной, уже жжёт свой бюджет, и это та самая нужная тебе пресловутость. Второе: каждому SLA нужен определённый путь исключения: когда ты действительно не можешь пропатчить вовремя (вендорского фикса ещё нет, патч ломает критичный рабочий процесс), ты фиксируешь компенсирующий контроль — правило WAF, сетевую изоляцию, выключенный фичефлаг — и явное, владеемое, ограниченное по времени принятие. SLA без пути исключения не соблюдают; его тихо игнорируют, и тогда у тебя политика, которая врёт. «Среднее время до устранения» против этих SLA — единственная метрика, говорящая, действительно ли программа сужает твоё окно экспозиции или просто плодит тикеты.