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

Классический патч-менеджмент в крупных компаниях часто превращается в войну: ИБ заваливает айтишников тысячами CVE из сканера, а ИТ-отдел включает режим глухой обороны. Понять, почему уязвимости годами живут в сетях и как выстроить реальное управление рисками, попытались авторы «BELYAEV PODCAST».

Кибер Медиа выступил генеральным медиапартнером этого выпуска. Ведущий проекта Дмитрий Беляев и его соведущий Рустам Гусейнов, основатель «РАД КОП», встретились с Александром Леоновым, главным экспертом русскоязычного комьюнити по Vulnerability Management. Вместе они разобрали главные боли индустрии: от иллюзий вокруг метрик CVSS, EPSS и KEV до возможностей ИИ-агентов и хайпа вокруг exposure-менеджмента. С полной видеоверсией подкаста «BELYAEV PODCAST» можно познакомиться тут.

Дмитрий Беляев: Справедливо ли мнение, что CVSS как основная метрика приоритизации — это технология 2002 года? Почему в 2026 году компании все еще сортируют по CVSS, игнорируя трендовые EPSS и KEV? Это инерция, лень или незнание?

Александр Леонов: Среди метрик приоритизации нет однозначно плохих, у каждой своя специфика. Главная проблема CVSS — субъективность. Это опросник, заполняемый аналитиком в NVD, который далеко не всегда глубоко погружен в контекст конкретной CVE. Кроме того, базовый CVSS не учитывает реальные факты эксплуатации «вживую» и наличие зрелого эксплойта. Но CVSS давно на рынке, и инерция здесь колоссальная.

У трендовых альтернатив свои минусы:

• EPSS прогнозирует вероятность появления эксплойта в ближайшие 30 дней. Плюс в том, что фид от FIRST бесплатен и доступен для всех CVE. Но на практике модель часто сбоит: уязвимость может вовсю эксплуатироваться, а ее вероятность по EPSS будет околонулевой.
• KEV фиксирует железные факты реальных атак. Но база обновляется с задержками до полугода, а источники данных засекречены. Это чисто американская история для контроля дедлайнов в госсекторе, которая в наших реалиях работает со скрипом, хотя учитывать ее нужно.

Рустам Гусейнов: Насколько эффективно нейросети справляются с триажем и приоритезацией? Есть ли перспектива появления инструмента, который будет выводить интегральную оценку по разным шкалам с учетом их погрешностей?

Александр Леонов: Сейчас с этим экспериментируют все. Отчет об уязвимостях можно отправить в условный ChatGPT и спросить, что критично. Если нейросеть видит RCE с эксплойтом на периметре, она прямо скажет: «Обрати внимание». Но возникают вопросы. Во-первых, насколько это надежно и нет ли галлюцинаций, ведь цена ошибки в ИБ велика. Во-вторых, нужно ли это в простых кейсах? Если перед нами эксплуатируемая RCE на периметре, нейросеть не требуется — все понятно и без нее.

С другой стороны, если посмотреть, куда идет VM на Западе, последний год все говорят про автономных агентов для автоматического патчинга и разбора отчетов. Некоторые компании презентуют их как цифровую рабочую силу под конкретные задачи: контроль периметра или разбор обновлений в рамках Microsoft Patch Tuesday. Подразумевается, что это снизит потребность в VM-специалистах. Это понятные и решаемые задачи.

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

Рустам Гусейнов: Бытует мнение, что западные технологии автоматического System Hardening с применением ИИ-агентов опережают наши на 3–5 лет. Стали ли они геймчейнджером на практике?

Александр Леонов: Мне кажется, автономные агенты пока этот вопрос не закрывают. Раньше аналитик смотрел отчет, видел незахарденные хосты и выяснял у владельца причины. Эту часть работы, где нужна нечеткая логика, нейросеть способна взять на себя.

Но может ли она сейчас сама разобраться, что поломается в бизнес-приложении при харденинге? Здесь ИИ выступает пока просто помощником, который подсвечивает: «Вот это не делай, потому что поломается». До полностью автоматического харденинга мы еще не дошли.

Зато автоматический патчинг — настоящий мейнстрим. Тренд связан с тем, что скорость атакующей стороны тоже растет за счет ИИ. Вендоры используют этот инфопоток — например, кейсы с EPSS или еженедельные линуксовые LPE-уязвимости, показывают скорость появления эксплойтов и говорят: «Вам нужно патчиться еще быстрее, а для этого у нас есть автономные агенты».

Дмитрий Беляев: Насколько справедливо утверждение, что exposure-менеджмент — это не просто VM-2.0, а действительно другой взгляд на управление риском? В твоем понимании это эволюция или все-таки революция, но с новым ценником?

Александр Леонов: Здесь нужно разделить понятия. С одной стороны, присутствует элемент маркетинговой игры в стиле Gartner. Мне нравится фраза из фильма: «Крутон — это та же гренка, просто гренка не может стоить 100 долларов, а крутон может». Вендорам нужно продавать продукт дороже, поэтому они берут привычный VM, слегка расширяют область видимости и заявляют, что полностью закрывают потребности CTEM. Проблема в том, что термин «exposure» обтекаемый, у него десятки вариантов перевода, а четкого определения в западной методологии нет. Все играют в маркетинг, и результат этого не очень хороший.

Если же подходить правильно, у exposure-менеджмента есть два важных столпа, отличающих его от VM:

1. Расширенный скоуп. Если классическая vulnerability — это конкретная CVE, то exposure — это уязвимость в широком смысле: мисконфигурации, избыточная сетевая связность, проблемы с учетными записями и все, что хакер может использовать для атаки. Объем проблем здесь несоизмеримо больше.
2. Приоритизация через пути атаки. Нужно устранять не просто бреши на сервере, а моделировать полноценные графы действий злоумышленника от точки входа до целевого актива, компрометация которого приведет к недопустимому событию. Речь идет не о банальной проверке открытых портов, а о глубоком моделировании с учетом реальных уязвимостей.

Когда развернута полная картина путей атаки, мы четко видим, устранение уязвимостей на каких именно узлах сильнее всего «обрежет» маршруты для взломщика и принесет максимальный профит. Именно расширенный скоуп проблем и приоритизация через графы атакующих путей составляют основу настоящего exposure-менеджмента, если отбросить маркетинговый шум.

Рустам Гусейнов: На ЦИПР-2026 обсуждали концепцию Secure by Design — сдвиг влево и зашивание безопасности в ИТ на стадии проектирования. Веришь ли ты, что так можно снизить вероятность уязвимостей до нуля?

Александр Леонов: Я бы разделил вопрос. Не согласен с тем, что нужно убрать ИБшников и все отдать айтишникам. Модель с выделенной ролью безопасника возникла не просто так — это конкурентная среда, где ИТ отвечает за работоспособность, а ИБ — за защищенность. Без этого баланса компании будут ломать еще сильнее.

С другой стороны, текущая ситуация в разработке ненормальна. В линуксовом ядре разграничение прав регулярно сбоит, и получить рута можно простым скриптом. Сдвигаться влево нужно в саму разработку софта. Сейчас доминирует тренд на быстрый и дешевый код (вайб-кодинг) силами джунов, и на безопасность всем наплевать. Параллельно растет скорость атакующей стороны: вендоры используют инфопоток вокруг еженедельных LPE-уязвимостей в Linux и продвигают ИИ-агентов для ускорения патчинга. Но в рамках своего проекта Linux Patch Tuesday я вижу, что в Linux Kernel ежемесячно обнаруживают около 500 новых CVE, и еще 300–400 — в остальном софте.

Рустам Гусейнов: Собирал ли ты статистику по динамике роста критических уязвимостей в Linux? Нет ли ощущения, что ядро настолько разрослось, что это просто издержки гигантской системы, где даже Линус Торвальдс перестал все понимать? Может, пора написать новое ядро с чистого листа на абсолютно новой платформе?

Александр Леонов: Я бы это приветствовал. Рост числа уязвимостей в Linux отчасти связан с бюрократией: команде Linux Kernel дали статус CNA, и они стали заводить CVE практически на каждый баг — это их официальная позиция.

С другой стороны, ядро стали активнее копать новым инструментарием, из-за чего после Dirty Pipe пошло целое семейство уязвимостей вроде Copy Fail. Кроме того, в опенсорсе критические бреши не закрываются из-за отсутствия мотивации: для коммерческого софта вроде Chrome есть масштабные программы Bug Bounty, а в линуксовом софте выплаты символические, и независимые ресерчеры туда не идут.

Что касается разработки с нуля — у «Лаборатории Касперского» есть коммерческая микроядерная ОС. Ее внедрение требует совершенно иного подхода к написанию софта с акцентом на безопасность. Нужно ли нам свое ядро для отечественных операционок? Я не эксперт по разработке ядра, и мне возразят, что там зарыты миллиарды долларов и ядро должно быть единым. Но в основную ветку нас все равно не пускают. Я считаю, нам нужно делать форк — условный Runux — и развивать его самостоятельно с акцентом на безопасность.

Дмитрий Беляев: Если завтра появится идеальный ИИ, который с точностью в 99% предсказывает, что уязвимость будет эксплуатироваться в течение 30 дней, правда ли, что роль VM-специалиста все равно не исчезнет? В чем тогда останется человеческая зона ответственности?

Александр Леонов: Такой ИИ станет аналогом «космического оракула» EPSS. Это круто, но решит только вопрос приоритизации — мы просто поймем, что брать в первую очередь. При этом уязвимости все равно нужно как-то детектировать в инфраструктуре, а это задача колоссальной сложности.

Затем задачи нужно заводить, согласовывать SLA, а если они буксуют — разбираться почему, и додавливать исправления. Нужно общаться с айтишниками, выяснять, почему приложение невозможно обновить безболезненно, менять архитектуру. Настоящий VM — это именно процессы. Было бы неплохо иметь ИИ, который, как мамочка, приглядывал бы за всей инфраструктурой, но человеческая зона ответственности останется именно в менеджменте.

В лоб задачу просчета путей атаки алгоритмически не решить, хотя процесс можно оптимизировать, отсекая тупиковые маршруты. Западная аналитика пугает заявлениями, что среднее время появления эксплойта — «минус один день». Я скептичен: там часто искусственно сужают выборку до 0-day для красивой статистики. Но если поток моментальных атак станет массовым, у нас не останется выбора, кроме как ускорять реагирование и в чем-то довериться автоматизации.

Все говорят, что автопатчинг — это плохо. Согласен, если делать его огульно. Но если превратить его в автоматизированный патч-менеджмент, где внедрены четкие политики под управлением айтишников, то мы получаем неплохое решение. Нельзя просто дать ИИ волшебную кнопку, чтобы в случае падения систем заявить: «Безопасник не виноват, виноват айтишник». Но если решение будет зрелым, то почему бы и нет?

Дмитрий Беляев: Насколько справедливо утверждение, что ИТ-отделы часто фактически саботируют VM? Как это выглядит на практике — это злой умысел, защита своих интересов или просто боль от перегрузки?

Александр Леонов: В зрелых компаниях есть понимание, что патчить нужно просто потому, что это правильно. В незрелых организациях процесс выглядит иначе. Туда приходит VM-специалист со сканером и начинает заводить задачи. В месяц обнаруживается около 500 уязвимостей, из которых критичных — штук 5. То есть ИТ-отделу нужно регулярно ставить обновления или перезагружать машины, а потом проверять, не разъехалось ли приложение.

Сталкиваясь с лавиной требований, айтишник включает защиту. Фантазия здесь рождает стандартный набор тактик:

• Формальный барьер. «Нам непонятны ваши отчеты. Распишите под каждую уязвимость конкретные патчи и команды». На согласование этого формата могут уйти месяцы.
• Атака на инструмент. «Ваш сканер работает неправильно, это ложноположительные срабатывания, докажите обратное».
• Требование доказательств. «Докажите, что уязвимость эксплуатируема именно на нашем хосте и приведет к чему-то плохому». VM-специалист тратит время на демонстрацию эксплойта вместо улучшения инфраструктуры.
• Изоляция кейса. Когда все доказано, айтишник соглашается: «Хорошо, эту конкретную уязвимость на этом сервере я пропатчу. Теперь давай точно так же доказывай оставшиеся 50 тысяч».

Это не злой умысел, а естественная реакция на перегрузку. Я рекомендую VM-специалистам не играть в эти игры. Некоторые верят, что демонстрация эксплойта впечатлит айтишников и они все поймут. Намного лучше работает формальный подход: «Вот приказ руководства, вот регуляторика, с понедельника мы живем по-новому, выделяйте ресурсы». Это здравый разговор, а попытки договориться «внизу» обычно ни к чему не ведут.

Дмитрий Беляев: И в продолжение темы — вопрос от нашего генерального медиа-партнера Кибер Медиа. В крупной инфраструктуре встречаются системы (будь то Legacy, критические бизнес-приложения или специфическое «железо»), которые попросту запрещается патчить или даже активно сканировать, потому что они могут «лечь» от любого вмешательства. Как выглядит VM-процесс в таких зонах?

Александр Леонов: Процесс выглядит грустно, VM-специалист на этом месте просто плачет. Если в инфраструктуре есть сверхважный объект «Х», который трогать нельзя, у меня возникает вопрос: а кто в итоге принимает риски? Владелец ресурса — наемный специалист, сегодня он есть, а завтра его нет.

В таких условиях лучшее, что можно сделать, — формально обложиться бумагами и доказательствами того, что вы свою часть работы выполнили. Параллельно нужно внедрить компенсирующие меры: сделать жесткую сетевую сегментацию и поставить дополнительные средства защиты. Выше головы тут не прыгнешь. Если в организации не считают нужным содержать ИТ в порядке, то нужно быть готовым однажды увидеть скриншоты этой системы в анонимном Telegram-канале.

А ведь содержать инфраструктуру в порядке и ставить патчи — это в том числе требование вендора по правильной эксплуатации систем. В таких разговорах я очень люблю упоминать статью 274 УК РФ. Не знаю, насколько это применимо юридически в каждом кейсе, но как инструмент психологического внушения на ИТ-отдел работает отлично.

Рустам Гусейнов: Есть ли у тебя примеры практик мотивации айтишников думать более ориентированно с точки зрения ИБ? Есть ли успешные кейсы?

Александр Леонов: На практике все упирается в разнородность ИТ-инфраструктуры. У одного айтишника на участке стоит куча сложного legacy, которое физически нельзя трогать, а у другого — современные контейнеры, которые можно безболезненно обновлять хоть каждый день.

Если начать депремировать или шеймить людей за невыполнение SLA на сложных участках, это будет просто несправедливо. Внедрять такие системы мотивации можно, но нужно подходить к оценке адекватно и учитывать специфику конкретных систем.

Дмитрий Беляев: Насколько сильно отличается подход к детектированию и управлению уязвимостями в Linux-контейнерах, Kubernetes и облаках от классического сканирования Windows-хостов? Где сегодня самые большие слепые зоны?

Александр Леонов: Если сравнивать классический Linux и Windows, то подходы различаются не кардинально. В Linux мы смотрим в основном на пакеты, в Windows — на системные обновления и сторонний софт. Это просто разная специфика написания детектов. А вот контейнеризация — это уже отдельный класс решений. Здесь нужно работать на опережение и проверять сами образы. Ловить уязвимости в конкретном запущенном контейнере часто нет смысла: он сейчас крутится, а через пять минут его уже нет. Заходить сканером внутрь контейнера на хосте стоит только в том случае, если они долгоживущие.

С облаками похожая история. Относиться к ним как к обычному хостингу, раскатывая агенты или запуская классический сканер — это неэффективно. Правильнее «срезать углы» и собирать данные через API облачных провайдеров. Но тут надо понимать, что облака на Западе и в России — разные вещи. Там это абсолютный мейнстрим, а у нас пока довольно нишевая история.

Тем не менее на отечественном рынке развиваются специализированные CNAPP-решения. Они используют API облака для эффективного поиска уязвимостей. Если у вас действительно много облачной инфраструктуры, такие инструменты необходимы.

Дмитрий Беляев: Согласен ли ты с формулировкой, что детектирование — это только начало, и вся драма начинается после? Какие этапы после детекции чаще всего рассыпаются в реальных компаниях?

Александр Леонов: Детекция — это очень важно. Когда вы выбираете VM-решение, смотрите не на красивые дашборды, а на то, что конкретно оно умеет или не умеет детектировать. Со всем, что сканер пропустил, вам потом придется разбираться ручками. Но детектированием все, конечно, не ограничивается. Самая важная часть — чтобы уязвимости реально устранялись, и это большое ИБ-искусство, где нет стандартного шаблона. Процесс почти всегда стопорится именно на стадии непосредственного патчинга.

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