Почему уязвимости годами живут в инфраструктуре: честный разговор

Дмитрий Беляев, CISO, подкастер, человек, который устал читать красивые отчёты

Я провёл подкаст с двумя людьми, которых в нашем цеху представлять не нужно. Александр Леонов — тот самый, кого первым вспоминают, когда речь заходит об управлении уязвимостями в русскоязычном сообществе. И Рустам Гусейнов, основатель кооператива специалистов по ИБ “Раткоп”, один из немногих, кто умеет говорить о безопасности языком денег, а не чек-листов.

Разговор вышел неудобным. Таким и должен был.

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

---

CVSS 2002 года: почему в 2026-м мы всё ещё по нему живём

Начали с провокации. Я спросил Александра прямо: CVSS — это технология 2002 года. Почему в 2026-м компании по-прежнему сортируют уязвимости по этой метрике, когда давно есть EPSS, KEV, трендовые оценки?

Ответ был честным:

“Нет совсем уж плохих метрик. CVSS плох тем, что он субъективен. Это опросник, который заполняет аналитик — насколько он сам разбирается в уязвимости, которую разбирает? Может, разбирается. Может, нет. Плюс две структурные проблемы: он не учитывает реальную эксплуатацию вживую и не учитывает наличие зрелого эксплойта.”

Дальше — про EPSS. Идея хорошая: предсказывает вероятность появления эксплойта в течение 30 дней. Проблема — не работает. Зачастую эксплойт уже давно существует, уязвимость активно эксплуатируется, а EPSS показывает вероятность около нулевой. Организация FIRST выпускает новые версии и каждый раз обещает “теперь будет красота”. Каждый раз — мимо…

KEV (Known Exploited Vulnerabilities от CISA) — показывает реальную эксплуатацию, но делает это с задержкой. Флажок могут поставить через месяц или полгода после того, как уязвимость уже вовсю используется в атаках. При этом CISA не объясняет, какие именно доказательства у них есть. Просто “добавлено в каталог” — и всё.

Как Шварценеггер: “Какие ваши доказательства?”

Практический вывод: не нужно выбирать одну метрику и делать из неё религию. Комбинируйте. CVSS — для первоначальной оценки тяжести. KEV — для понимания, что уже активно эксплуатируется. Трендовые метрики вашего VM-решения — для операционной приоритизации. И никогда не забывайте проверять, есть ли публичный эксплойт.

---

ИИ придёт и всё сделает за нас. Нет.

Рустам задал вопрос про нейросети. Насколько триаж и приоритизация уязвимостей делаются лучше с помощью ИИ?

Ответ Александра был трезвым и немного саркастичным:

“Все экспериментируют. Берёшь отчёт, подаёшь в ChatGPT, спрашиваешь: что из этого критично? Она даже что-то похожее на правду выдаст. Если видит RCE с эксплойтом на периметре, скажет: RCE на периметре, обрати внимание.”

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

Другой момент — автономные агенты. На Западе это сейчас мейнстримный нарратив: агенты для автоматического патчинга, для разбора отчётов, для контроля периметра. Microsoft продвигает Patch Tuesday Agent, который молотит именно эту задачу.

Я не удержался от комментария:

“Главное, чтобы после слова “автономная рабочая сила” штат не сократили.”

Александр согласился, что это вполне вероятный исход. Но добавил важное: автоматизированный патчинг — не то же самое, что “нажали кнопку и надеемся на лучшее”. Правильный автопатчинг требует политик: что можно патчить автоматически, что нельзя, какой софт на каких хостах. Если всё это подложить под систему — вполне рабочая история. Если назвать это “автопатчинг, включаем для всей инфры” — добро пожаловать в ночной инцидент.

---

Exposure Management: маркетинг или реально что-то новое?

Я спросил Александра: Exposure Management — это VM 2.0 с новым ценником или что-то принципиально другое?

Ответ получился развёрнутым. Сначала про маркетинг:

“Это гартнеровская игра. Как «крутон» не может стоить 100 долларов, а круасан — может. Рисуют плюс-минус тот же Vulnerability Management Lifecycle, расширяют скоуп, добавляют практическое подтверждение эксплуатабельности.”

Но если убрать лишнее, остаются два реальных столпа:

Первый. Exposure — это уязвимость в широком смысле. Не только CVE-шки. Это мисконфигурации, избыточная сетевая связанность, проблемы с учётками, всё, что злоумышленник может проэксплуатировать. Скоуп проблем гораздо шире, чем в классическом VM.

Второй. Новый подход к приоритизации: устранять не просто уязвимости на конкретном хосте, а те, которые участвуют в путях атаки. Моделируешь пути от точки входа (периметр, фишинг) до целевого актива. Смотришь, какие уязвимости на каких узлах нужно закрыть, чтобы максимально обрубить эти пути. Получаешь реальный приоритет — не “у этого хоста CVSS 9.8”, а “вот эти три уязвимости перекрывают 60% путей атаки до учётной системы”.

Если внедрять именно это - дело стоящее. Если покупать “exposure management” как новый шильдик на старый сканер - деньги на ветер.

---

Linux ядро патчится 500 раз в месяц. Это нормально?

У Александра есть проект Linux Patch Wednesday — он каждый месяц смотрит, какие уязвимости патчатся в Linux-ядре и остальном Linux-стеке. Цифры неожиданные: порядка 500 CVE в ядре ежемесячно, плюс 300-400 в остальном софте.

Это что — система вышла из-под контроля?

Александр объяснил: часть роста — бюрократическая. Linux Kernel получил доступ к CVE-системе и теперь заводит CVE на каждый баг. Это их осознанная политика — “бай-дизайн”. Но это не отвечает на вопрос, почему каждую неделю появляются суперэксплуатабельные уязвимости с готовыми эксплойтами — LPE (Local Privilege Escalation), “грязная труба” (Dirty Pipe) и целые их семейства.

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

“Я бы это приветствовал,” — ответил Александр, — “Форкнем, пусть будет не Linux, а Рунукс :D, будем развивать с акцентом на безопасность. А основная ветка — ну её.”

Здесь же всплыл KasperskyOS: микроядро, написанное с нуля с акцентом на безопасность. Есть Community Edition. Требует, чтобы приложения писались иначе — с безопасностью как первым требованием, а не последним.

Почему в опенсорсе так много критических уязвимостей? Потому что нет bug bounty. В Chrome платят много денег за конкретные баги — исследователи туда и бегут. В большинстве критичного Linux-стека bug bounty нет или оно символическое. Значит, исследователи туда не идут, уязвимости не находятся и не закрываются.

---

IT-шники “саботируют” VM. Или нет?

Я задал Александру провокационный вопрос: IT-отделы фактически саботируют VM-процесс?

Он разложил по полочкам тактики, которые использует любой айтишник, когда к нему приходит VM-щик с требованиями патчить:

1. “Нам непонятно. Принесите в другом формате, с конкретными командами.” Пока согласовывают формат — проходит два месяца.

2. “Ваш сканер врёт. Это ложные срабатывания.” Пока доказываешь, что не врёт — ещё месяц.

3. “Ладно, уязвимость есть, но она неэксплуатабельна.” Доказываешь работающий эксплойт. Следующий этап:

4. “Докажи, что с помощью этой уязвимости можно что-то плохое сделать именно на этом хосте.”

5. “Окей, доказал. Давай теперь разберём остальные 50 000 уязвимостей из твоего отчёта.”

Саботаж это или нет? Александр честно сказал: фиг его знает. Айтишник тоже человек. Он решал свои задачи, жил спокойно, а тут пришёл какой-то человек с огромным отчётом и требует непонятно чего.

Главный вывод — демонстрация “реальной эксплуатабельности” как метод убеждения работает плохо. Работает другое: формальный процесс, подкреплённый приказом, регуляторикой и конкретными SLA. Не “смотри, как красиво я взломал твой хост на стенде”, а “с понедельника у нас новый регламент, вот приказ, вот сроки, вот ответственность”.

“Бумага не решает всё, но помогает в 50% случаев. А это уже что-то.”

Про 274-ю статью УК (неправомерное воздействие на критическую информационную инфраструктуру) Александр сказал, что иногда её упоминание работает как внушение. Насколько это рабочий инструмент с точки зрения реального права — вопрос отдельный, но психологический эффект есть.

---

Что делать с системами, которые нельзя ни патчить, ни сканировать

Это больная тема. В любой крупной инфраструктуре есть legacy: старые АСУ ТП, медицинское оборудование, специфическое железо с ПО, которому 15 лет и более. Патчить нельзя — упадёт. Даже сканировать нельзя — упадёт от трафика сканера.

Как живут VM-процессы в таких зонах?

“Очень грустно,” — ответил Александр. — “VM-щик на этом плачет.”

Рецепт реалистичный и без иллюзий:

• Обложиться бумагами. Зафиксировать, что вы указали на риск, владелец актива это видел, риск принят осознанно.

• Внедрить компенсирующие меры: сетевая сегментация, мониторинг трафика вокруг этих систем, ограничение доступа.

• Понимать, что это “возможный исход” — и когда скриншоты из вашей инфраструктуры однажды появятся в анонимном Telegram-канале, вы будете к этому морально готовы.

Кто принимает риск? Я спросил напрямую. Владелец ресурса? Но владелец ресурса — наёмный специалист, сегодня есть, завтра нет. Рустам добавил точный вопрос: а есть ли вообще формальный процесс, закрепляющий ответственность?

Ответ подразумевается сам собой. Во многих компаниях — нет.

---

Контейнеры, Kubernetes и облака: где слепые зоны

Классический VM плохо работает в контейнеризованной среде. Основная причина: контейнер сегодня есть, через пять минут его нет. Ловить конкретный контейнер и его сканировать — задача сомнительная.

Правильный подход — работать с образами. Сканируешь образ до деплоя, находишь уязвимости там, не даёшь уязвимому образу уйти в production. Это другой класс решений и другой класс детектов.

Для облаков: если просто раскидать агенты на облачные хосты и ходить сканером как во внутренней инфре — неэффективно. Правильнее работать через API облаков. В России этим, в частности, занимается CloudAdvisor.

Разница между Западом и Россией здесь принципиальная. На Западе облака — абсолютный мейнстрим, и умение работать с cloud-нативными уязвимостями критично. В России это пока нишевая история. Но рынок движется.

---

Детекция — это не победа. Это только начало

Последний вопрос из основного блока: “Детектирование — это только начало, и вся драма начинается после?”

Александр согласился без колебаний:

“Самая важная часть VM — чтобы уязвимости реально устранялись. Всё остальное — это подготовка к главному событию.”

Инфраструктуру покрыть сканами — решаемо. Отобрать критичные уязвимости — тоже. Завести тикеты — не rocket science. А вот разбираться, почему конкретная уязвимость не закрывается три месяца — вот это настоящий VM. Это фигово масштабируется. Если вы один VM-щик в организации — вы будете сходить с ума именно на этом этапе.

Процесс стопорится на стадии устранения. Всегда. И именно там нужны не красивые дашборды, а живые разговоры с айтишниками, понятные SLA и формальная поддержка от руководства.

---

Блиц: честные ответы на неудобные вопросы

В финале я задал Александру 10 вопросов в формате “да/нет”. Вот самые интересные ответы:

Без актуального инвентаря активов VM-процесс превращается в стрельбу по невидимым мишеням. Вы не знаете, что у вас вообще есть — значит, не знаете, что сканировать, и не можете корректно приоритизировать.

---

Чек-лист, если дочитали до этого места:

По метрикам:

• Не живите по CVSS в одиночку. Добавьте KEV и трендовые метрики.

• Смотрите, есть ли публичный эксплойт. Если есть — это первый приоритет, независимо от CVSS.

• EPSS используйте с осторожностью — как вспомогательный сигнал, не как оракул.

По процессу:

• Asset management первичен. Если не знаете, что у вас есть — VM не работает.

• Формализуйте всё через регламенты и приказы. Договорённости “на уровне разговора” не масштабируются.

• SLA на устранение должны быть конкретными: критичная уязвимость с публичным эксплойтом — X дней. Без исключений.

По legacy:

• Зафиксируйте всё письменно. Риск принят? Пусть это подпишет тот, кто принимает.

• Компенсирующие меры обязательны: сегментация, мониторинг трафика.

• Регулярно пересматривайте список того, что “нельзя патчить” — иногда оказывается, что уже можно.

По контейнерам:

• Сканируйте образы, не контейнеры. Встройте это в CI/CD.

• Долгоживущие контейнеры — отдельная история, туда тоже нужно заглядывать.

По взаимодействию с IT:

• Не доказывайте эксплуатабельность как спортивное достижение. Идите сразу к формальному процессу.

• Security Champion работает только если инфраструктура у разных айтишников сопоставима по сложности. Иначе штрафовать одного за legacy, а другого хвалить за контейнеры — несправедливо.

---

Уязвимости живут в инфраструктуре годами не потому, что безопасники плохо работают. И не потому, что айтишники злые саботажники. Они живут, потому что у компании нет зрелого процесса, где ответственность чётко распределена, приоритеты понятны всем участникам, а устранение обеспечено ресурсами.

Инструменты — вторичны. Культура и процесс — первичны.

Следить за остальными выпусками и моими медиа можно тут и тут.