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

Цикл, а не скан

Самый частый провал в управлении уязвимостями — не пропущенный CVE, а отношение к скану как к результату. Скан — это начало работы, а не её конец. NIST SP 800-40r4 описывает всё это как корпоративное управление патчами и уязвимостями — непрерывный процесс с явными фазами — именно потому, что одноразовый отчёт устаревает в тот же момент, когда выходят новые CVE и поднимаются новые хосты. Состояние мира меняется ежедневно; ежеквартальный PDF протух раньше, чем закончилась встреча.

У цикла четыре подвижные части, и ценность живёт в связях между ними:

• Обнаружить — знать, что у тебя есть и что с этим не так. Сначала инвентаризация активов (нельзя пропатчить хост, о котором ты забыл), затем аутентифицированные сканы, телеметрия агентов, проверки зависимостей по SBOM и обзор внешней поверхности.
• Приоритизировать — превратить поток находок в ранжированную очередь по эксплуатируемости и доступности, а не по сырой серьёзности.
• Устранить — пропатчить, перенастроить, изолировать или компенсировать — с привязанными часами (SLA).
• Проверить — пересканировать и подтвердить, что находка действительно исчезла, затем вернуть результат в обнаружение.

Пропусти проверку — и у тебя не цикл, а бесконечный список, где «мы это пропатчили» и «это исправлено» — два разных утверждения, которые ты никогда не сверяешь. В день, когда аудитор спросит «покажи, что этот CVE закрыт на всех 200 хостах», команда, которая проверяла, ответит за минуты; команда, которая просто выкатила патч, теперь сканирует под давлением.

Приоритизируй по эксплуатируемости и доступности, а не по сырому CVSS

Вот число, которое перестраивает мышление зрелого инженера: из всех CVE, опубликованных за год, лишь малая доля — исследования и данные CISA KEV дают существенно меньше 5% — вообще когда-либо эксплуатируются в дикой природе. И всё же наивная программа считает каждый CVSS 9.8 одинаково горящим. Так и сжигают спринт, патча критичный по рейтингу RCE в библиотеке, которая вкомпилирована, но недостижима, пока «средняя» ошибка конфигурации на твоём интернет-фейсинг логине стоит открытой.

CVSS даёт базовую серьёзность — вендоронезависимый балл 0–10 о том, насколько плох изъян, если его эксплуатируют. Он действительно полезен, и FIRST (кто ведёт спецификацию) явно говорят: базовый балл — это серьёзность, а не риск. Чтобы дойти до риска, ты накладываешь сверху две вещи, которые один базовый CVSS не схватывает:

• Эксплуатируемость — есть ли рабочий эксплойт и используется ли он? Временны́е метрики CVSS v3.1 и метрики угрозы v4.0 кодируют это, но самый острый сигнал — каталог Known Exploited Vulnerabilities (KEV) от CISA и EPSS (вероятность, что CVE будет проэксплуатирован в ближайшие 30 дней). CVE из KEV прыгает в начало очереди почти независимо от своего базового балла.
• Доступность (exposure) — действительно ли затронутая вещь достижима и запущена в твоём окружении? Интернет-фейсинг бьёт внутренний; нагруженный, слушающий сервис бьёт спящий код; хост с чувствительными данными бьёт одноразовую коробку. Это твой контекст, и ни один внешний фид его не знает.

Зрелый рефлекс: ранг = серьёзность × эксплуатируемость × доступность, применяемые в этом порядке как фильтры. Начни с пересечения KEV-и-доступно — и 311 критичных схлопываются в очередь, которую реально разгрести.

Две строки с CVSS 9.8 — это весь урок: одинаковые базовые баллы, противоположные приоритеты, потому что эксплуатируемость и доступность растаскивают их в стороны. Ранжируй только по базовому баллу — и будешь брать их в порядке подбрасывания монетки; ранжируй по полной картине — и очередь очевидна.

SLA: часы, делающие «потом» подотчётным

Приоритет без срока — это пожелание. SLA на устранение — это обязательство, что находка заданной серьёзности будет закрыта в фиксированном окне, и оно существует, чтобы остановить медленную утечку, где «мы до этого доберёмся» тихо становится «оно открыто уже 400 дней». Типичные уровни выглядят так: критично / активно эксплуатируется → 7–15 дней, высоко → 30 дней, средне → 90 дней, низко → следующий плановый цикл. (Обязывающие директивы CISA для федеральных агентств используют ровно эту форму — записи KEV на жёстких фиксированных сроках — и это здравый дефолт, чтобы перенести в частный SLA.)

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

Проверь, затем замкни цикл

«Пропатчено» — это событие деплоя. «Исправлено» — это наблюдаемое состояние. Разрыв между ними — место, где программы тихо проваливаются: патч, не применившийся на 12 из 200 хостов, изменение конфига, откаченное следующим деплоем, образ контейнера, пересобранный из всё ещё уязвимого базового. Проверка пересканирует затронутые активы и подтверждает, что находка действительно исчезла — и только тогда тикет закрывается. Результат проверки утекает обратно в обнаружение, что и делает это циклом, а не списком: тот же скан, что подтверждает сегодняшний фикс, выявляет завтрашнюю новую находку.

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