Привет, Хабр!
Уже больше 10 лет я работаю с виртуализацией, и за это время успел в разной степени потрогать самые разные платформы. Естественно, до 2022 года это была в большей степени VMware, а параллельно с ней и разный опенсорс, в последние же годы руки добрались и до некоторых наших платформ.
Вообще идея этой статьи у меня зародилась после первых волн санкций, но, видимо, тогда ее время еще не пришло — ничего было непонятно, но очень интересно.
Спустя 4 года российские платформы заметно подросли, обзавелись пользователями и вменяемыми кейсами. С другой стороны, сама по себе тема виртуализации успела обрасти определенным слоем маркетинга и разнообразными мифами.
Зачем я пишу эту статью?
Мне уже давно хочется разобраться, как сейчас обстоят дела с безопасностью виртуализации в разрезе наиболее используемых в РФ платформ — как отечественных, так и не очень. Наверное, в глубине души мне хочется как-то суммировать то, что я сам увидел и осмыслил за это время, и ответить на ряд вопросов — действительно ли так страшно оставаться на иностранных платформах, как об этом говорят, и как обстоят дела у российских вендоров.
Если эта статья кому-то поможет — буду очень рад.
Уязвимости популярных платформ виртуализации
Начать статью я решил с того, чтобы попробовать посмотреть на сложившуюся с платформами виртуализации картину целиком и копнуть информацию об уязвимостях наиболее популярных в России платформ — VMware, Hyper-V, Proxmox, OpenNebula и oVirt. К размышлениям о российских платформах перейдем позже.
На старте хотелось бы обозначить — я не ставил перед собой задачу составить какую-то сводную таблицу проблем безопасности или сравнить различные решения по количеству уязвимостей. На мой взгляд, безопасность платформы далеко не всегда коррелирует с этой цифрой. Нередко бывает так, что какие-то проблемы у одной платформы находят чаще, чем у другой, из-за разницы в интенсивности их изучения и исследования.
VMware
5 марта 2024 года VMware сообщила об обнаружении ряда серьезных уязвимостей в продуктах VMware ESXi, Fusion, Cloud Foundation, Workstation Pro и Workstation Player. Всего было закрыто четыре уязвимости, а наиболее серьезная получила идентификатор CVE-2024-22252. Она относится к ошибке use-after-free в коде для работы с устройствами USB 3.0 (XHCI USB) в виртуальном окружении.
4 марта 2025 года Broadcom выпустила экстренные обновления для устранения сразу трех уязвимостей, которые затрагивают несколько продуктов VMware, включая ESXi.
CVE-2025-22224 (9.3 балла по шкале CVSS) — наиболее серьезная уязвимость, которая позволяет злоумышленнику с локальными административными привилегиями на виртуальной машине выполнить код от имени процесса VMX на хосте (то есть в гипервизоре).
CVE-2025-22225 (8.2 балла по шкале CVSS) — позволяет злоумышленнику записать произвольный код в область ядра (arbitrary kernel write), то есть тоже подразумевает побег из «песочницы».
CVE-2025-22226 (7.1 балла по шкале CVSS) — является утечкой информации в HGFS (CVSS 7.1) и позволяет злоумышленнику с административными привилегиями на виртуальной машине извлекать содержимое памяти процесса VMX.
По информации Broadcom как минимум CVE-2025-22224 эксплуатируется в реальных атаках. Уязвимости позволяют выполнить «побег» из виртуальной машины и выполнить код в гипервизоре ESXi (hypervisor escape).
Hyper-V
RCE-уязвимость (CVE-2024-21407), связанная с отправкой специально созданных запросов на выполнение файловых операций на виртуальной машине к аппаратным ресурсам.
Уязвимость позволяет злоумышленнику, прошедшему проверку подлинности, при определенных условиях использовать гостевую учетную запись виртуальной машины для удаленного выполнения произвольного кода на базовом хост-сервере (8.1 балла по шкале CVSS) .
CVE-2024-21408 — уязвимость, связанная с отказом в обслуживании (DoS).
Позволяет удаленному злоумышленнику, не прошедшему проверку подлинности, вызвать отказ в обслуживании (DoS).
CVE-2025-21333, CVE-2025-21334, CVE-2025-21335 (CVSS – 7.8; высокий уровень опасности)
Все 3 уязвимости — из январского Microsoft Patch Tuesday. Все они были найдены в компоненте, используемом для связи между хостовой ОС и виртуальными машинами контейнерного типа, такими как Windows Sandbox и Microsoft Defender Application Guard (MDAG).
Эксплуатация уязвимостей позволяет получить привилегии System. Microsoft отдельно отмечают, что речь идёт именно о локальном повышении привилегий на хостовой системе, а не о побеге из гостевой системы в хостовую.
CVE-2026-21255 — ошибка неправильного контроля доступа (CWE-284) и представляет собой уязвимость архитектуры.
Проблема в механизмах контроля доступа может позволить злоумышленнику, уже имеющему некоторый доступ к системе, обойти установленные ограничения безопасности. Особенно актуальна такая проблема для корпоративных сред и дата-центров, где Hyper-V активно используется для консолидации серверных нагрузок и изоляции рабочих окружений. Компрометация гипервизора в такой инфраструктуре может привести к масштабной утечке данных или полному параличу работы.
Proxmox VE
Эта уязвимость позволяет злоумышленникам загружать любые файлы с сервера, даже конфиденциальные системные файлы, используя уязвимость API. Для атаки требуются лишь низкоуровневые привилегии (Sys.Audit или VM.Monitor), что делает её критической уязвимостью для компаний, использующих Proxmox.
OpenNebula
CVE-2025-54955
В OpenNebula Community Edition (CE) до версии 7.0.0 и Enterprise Edition (EE) до версии 6.10.3 обнаружена критическая ошибка, которая может привести к захвату учетной записи. Используя эту ошибку, неаутентифицированный злоумышленник может получить действительный JSON Web Token (JWT), принадлежащий легитимному пользователю, не зная его учетных данных.
oVirt
Пользователи с правами администратора, в том числе ReadOnlyAdmin, могли с помощью инструментов разработчика браузера просматривать пароли провайдера в открытом виде.
Уязвимость позволяет обойти аутентификацию — создавать пользователей в системе без аутентификации из-за ошибки в команде CreateUserSession.
XSS-уязвимость — параметр error_description не экранируется, что позволяет внедрять HTML/JS-код
Сборщик логов сохраняет пароль администратора RHV без фильтрации
Race condition при обфускации чувствительных данных в логах может привести к утечке паролей
Обновления и патчи под санкциями
Возникает закономерный вопрос — ок, уязвимости есть у всех, но насколько они критичны для российских пользователей? Очевидно, что раньше все жили в одинаковых условиях — нашли уязвимость, закрыли ее патчем, все, кто своевременно патч установил, — молодцы. Но теперь, как известно, конкретно в нашей стране ситуация немного другая.
Иностранная проприетарщина
Для примера возьмем любимую всеми VMware. Патчи для закрытия новых уязвимостей, естественно, выходят, но скачать их легально не может ни одна российская компания. VMware вообще очень плотно закрутила гайки.
Если читать статью по ссылке лень, вот вам очень краткий пересказ:
2 октября 2025 года наступил end of life поддержки продукта VMware vSphere 7.0. Для этой версии больше не будут выпускать никакие обновления и security-патчи, в том числе по критическим уязвимостям. Именно версия 7.0 была последней из доступных российскому рынку в 2022 году, когда вендор ушел из России.
Вендор вводит новые меры противодействия обходу ограничений.
Купить свежую версию VMware vSphere 8.0 в России невозможно напрямую. После слияния VMware с Broadcom в 2023 году продлить работу продукта можно только по подписке.
Доступ к загрузке любых обновлений требует авторизации на официальном сайте VMware.
При загрузке обновлений с портала генерируются уникальные ссылки, которые могут отслеживаться вендором.
Компании, которые долгое время успешно пользовались серыми схемами, теперь тоже в зоне риска. Если VMware заметит подозрительную активность, возможна деавторизация всех участников пиратской схемы, включая и российских, и зарубежных интеграторов и дистрибьюторов. Это влечет за собой вероятность блокировки уже существующих лицензий и сбоев в работе систем.
Если компания решает остаться на предыдущей версии платформы, у нее начнут копиться уязвимости.
Предположим, гайки VMware вам не страшны, ведь вы используете альтернативное решение. Но тоже иностранное, а значит, патчи нужно где-то искать и скачивать. Хорошо, если у вас есть возможность сделать это через посредника. А если вы — небольшая компания, которая не имеет возможности переплачивать этому посреднику, и теперь использует просто пиратскую версию платформы? Даже если в этой ситуации удасться найти патч, никто не даст гарантии, что скачанный файл действительно оригинальный.
Далеко за примерами ходить не надо. Вот, например, прошлогодний кейс. В марте 2025-го в VMware ESXi нашли уязвимость, которая давала возможность записать произвольный код в ядре и выйти за пределы изолированной виртуальной среды. Закрыли ее спустя пару недель, однако российским пользователям обновление ожидаемо никто не предложил.
Кстати, читая релиз по ссылке выше, я поймал себя на мысли, что хочется задать авторам встречный вопрос. Запомните этот момент, мы к нему вернемся чуть ниже.
«Свободный» опенсорс
С опенсорсом ситуация сложнее и интереснее. С одной стороны, код действительно открыт — бери и качай. Но и здесь есть свои подводные камни. Например, не стоит забывать, что многие популярные проекты нередко развиваются под крылом зарубежных корпораций. Что делать, если их репозитории на серверах в Европе или США, внезапно станут недоступны для российских IP-адресов или разработчики не прекратят принимать патчи от отечественных контрибьюторов, как уже было ранее? Да и в целом могут быть нюансы с обновлениями — случаи уже были, с подробностями можно ознакомиться здесь.
Допустим, в одном из компонентов того же oVirt нашли критическую уязвимость. Как быстро исправление попадет непосредственно в сам дистрибутив? Без коммерческой поддержки остается надеяться на скорость реакции сообщества.
Российские решения
А теперь то, что я оставил на десерт, — отечественные коммерческие платформы.
В рамках одной статьи у меня не получилось бы разобрать все доступные на российском рынке и решения — это вообще бессмысленно и нецелесообразно. Поэтому для выбора кандидатов на разбор я решил обратиться к наиболее очевидному источнику — рейтингу Cnews. Брать все 10 было бы слишком, поэтому в статью попали те, про которые лично я слышу чаще всего.
Важное замечание: Если ваш опыт отличается от моего или вам есть, что добавить (например, вы можете рассказать про не упомянутые в этой статье платформы), давайте подискутируем в комментариях — я открыт к альтернативным мнениям и взглядам, даже если они кардинально отличаются от моих.
zVirt
Все еще держите в голове историю с уязвимостью VMware и недоступностью патча для российских пользователей? Тогда начнем задавать и нашим вендорам неудобные вопросы. А давайте теперь внимательнее посмотрим на их продукты и, чтобы далеко не ходить, начнем со zVirt.
Дисклеймер: Я считаю, что все российские вендоры совершенно справедливо критикуют зарубежных за недоступность патчей. И это абсолютно логично вписывается в политику любого отечественного производителя платформы виртуализации.
Если вы читаете эту статью, то прекрасно знаете, что решение zVirt базируется на опенсорсном oVirt.
Естественно, разнообразные негативные ассоциации zVirt не нужны, особенно после того, как oVirt остался без поддержки Red Hat, поэтому вендор отстраивается от своего опенсорсного предка, как может — рекомендую ознакомиться со статьей «Как zVirt уходит от oVirt: безопасность в приоритете».
Немного пробегусь по самой статье.
Платформа zVirt разработана на базе oVirt — виртуализации с открытым исходным кодом. В 2024 года она осталась без поддержки разработчика Red Hat. Он перестал развивать Open Source-проект и выпускать для него обновления по информационной безопасности.
Если основной проект развивается без гарантий, откуда берутся патчи для российского форка? Насколько быстро они появляются у российских пользователей?
Кстати, вендор проводит и багбаунти:
Orion soft начал тестировать безопасность системы виртуализации zVirt в закрытом режиме с ноября 2024 года, а теперь продлил свое участие в программе багбаунти. Ее основная цель — выявить уязвимости, которые могут привести к эскалации привилегий до уровня суперпользователя (root), нарушению конфиденциальности, целостности или доступности виртуальных машин и данных.
В целом это плюс, но почему в закрытом режиме? Все-таки это не то же самое, что открытая публичная программа.
Basis DynamiX
Может быть, у проприетарных платформ ситуация складывается иначе?
Предлагаю внимательно посмотреть на платформу виртуализации от «Базис», производитель которой позиционирует свой продукт как максимально проприетарное решение, не то что эти ваши опенсорсные конструкторы.
Что же пишет про себя «Базис»? Давайте посмотрим на их сайт:
Обратите внимание на последнее предложение. В то же время, если немного поискать информацию об уязвимостях их продуктов, можно найти вот такую замечательную статью. Предлагаю ее почитать и проанализировать наиболее интересные моменты.
Специалисты ООО "Базис" совместно с сотрудниками Института системного программирования РАН (ИСП РАН) и испытательной лаборатории "Фобос-НТ" провели очередной этап тестирования компонентов с открытым исходным кодом, которые используются в инструментах виртуализации по всему миру, в том числе в продуктах компании. Результатом совместной работы стало обнаружение и последующее устранение 191 дефекта в коде, некоторые из них специалисты оценили как уязвимости.
Лично мне кажется, что такими громкими заявлениями «Базис» пытается создать впечатление, будто бы в составе экосистемы ну вообще никак не используется опенсорс. Хотя мы знаем, что, во-первых, обойтись без открытого кода буквально невозможно, а во-вторых, его наличие в составе какого-либо продукта — абсолютно нормальная ситуация, если это сделано грамотно и помимо опенсорса есть и собственные разработки.
"Безусловно, даже если просто поделить 191 недостаток на пять заявленных компонентов, то выходит примерно по 38 недостатков на каждый, что немало. Но нет информации о степени их критичности, что также имеет значение. Например, на наших проектах в среднем в рамках анализа одной системы мы обнаруживаем две уязвимости высокого уровня риска, три - среднего и пять - низкого. Периодически обнаруживаются критические, но реже, примерно в каждом пятом проекте. Однако здесь речь больше про "не-open-source-системы", над разработкой которых работает определенная команда в рамках основной деятельности", - рассказал руководитель департамента аудита и консалтинга ООО "Ф.А.К.К.Т." (F.A.C.C.T.) Евгений Янов.
Без иронии хотелось бы похвалить «Базис» за работу с уязвимостями. Все-таки компании, которая называет себя первой на рынке импортозамещающего ПО по объему эксплуатируемых мощностей, работать над этим, мягко говоря, необходимо. Тем не менее, некоторые моменты меня все еще смущают. Во-первых, непрозрачность обработки уязвимостей. Базис публикует информацию в формате пресс-релизов, но все равно не очень понятно, как быстро вендор реагирует на новые угрозы. Плюс к этому я не нашел ничего о публичных bug bounty. На мой взгляд это вообще максимально странно для компании, которая заявляет себя практически лидером рынка. И это вдвойне странно при наличии такого количества кейсов — если вы поставляете свои решения крупному российскому бизнесу, неужели их нельзя «потрогать» независимым исследователям?
Ну и еще один момент в копилку прозрачности и открытости. Обратимся к этой статье:
Отвечая на вопрос CNews о судьбе еще 92 дефектов, оставшихся без исправлений, Дмитрий Пономарев заявил, что не все дефекты требуют обязательного устранения.
«Например, могут быть обнаружены баги, которые фактически не влияют на функциональность продукта. В определенной сборке или при стандартных сценариях использования компанией “Базис” протестированного открытого ПО этот баг может вовсе не проявиться», – пояснил Пономарев.
Безусловно, какие-то баги опенсорс-компонентов могут вообще не проявиться в продукте. Но есть ли гарантия, что так будет всегда? Не станет ли это своеобразным выстрелом в ногу своим пользователям? Где конкретика о неисправленных уязвимостях и планах по их устранению? И если прозрачность процессов отсутствует, можно ли вообще доверять вендору безопасность инфраструктуры, особенно когда речь идет о потенциально незакрытых уязвимостях?
SpaceVM
Еще одна очень проприетарная платформа. С ней ситуация еще интереснее — производитель вообще не горит желанием делиться с пользователями информации. Пробежавшись по сайту и документации, подробностей о составе решения я не нашел. Зато на просторах мне попалась вот такая статья с описанием собственных и интегрированных технологий в составе SpaceVM. Давайте пройдемся по ней так же, как выше пробежались по zVirt’у.
Судя по всему, вендор действительно вложился в разработку собственных компонентов:
Проприетарный контроллер SpaceVM открывает широкие перспективы развития функциональных возможностей продуктов и кастомизации потребностей заказчиков.
Благодаря собственным интерфейсам управления Web и API, ресурсно-ориентированному подходу, используемому в API, «ДАКОМ М» реализует взаимодействие с решениями ведущих российских поставщиков технологий, объединенных в глобальную экосистему. Это дает свободу выбора при построении комплексных проектов и расширяет возможности платформы.
Разработанная «ДАКОМ М» инновационная технология FreeGRID обеспечивает работу с лицензионными продуктами NVIDIA в штатном режиме и исключает их возможную блокировку. FreeGRID позволяет задействовать возможности аппаратного ускорения видеокарты и использовать производительность графического адаптера нескольким виртуальным машинам совместно без лицензионных ограничений.
Проприетарный протокол GLINT предназначен для подключения пользователя к удаленному рабочему столу и дает возможность работать с разными операционными системами и клиентскими устройствами из любой точки мира с минимальной задержкой.
Кстати, в статье по ссылке есть еще один интересный нюанс:
В сфере российской виртуализации наблюдается отчетливый тренд отказа от решений open source в пользу технологий и продуктов с высокой добавленной стоимостью. Такие продукты могут стать основой для бизнес-стратегии корпорации-заказчика на ближайшие 5–7 лет. Все дело в том, что вендор такого продукта виртуализации может сосредоточиться на развитии функциональных возможностей с учетом требований заказчика, обеспечить гарантированную и профессиональную техническую поддержку и оперативное исправление ошибок, а также создать технологии, которые конкурентам заказчика будет сложно воспроизвести.
Однако, насколько я понимаю, под капотом SpaceVM находится все тот же KVM. А вендор заявляет об отсутствии иностранных компонентов. Да, KVM — это глобальный опенсорс, поддерживаемый международным сообществом. Но перестает ли он от этого быть иностранным модулем?
Конечно, все это не отменяет того, что производитель вкладывается в разработку — здесь он молодец, но я считаю, что заявление слишком громкое. Если у вас есть сильная команда разработчиков, экспертиза, почему бы открыто не говорить о составе кодовой базы?
И если упомянутый выше «Базис» рассказывает об уязвимостях хотя бы в формате пресс-релизов, то информации об уязвимостях SpaceVM я не нашел вообще никакой. Как и о Bug Bounty.
В документации вендор предлагает отправлять найденный баги в их Багзиллу.
Из актуального там — пара ошибок из категории общих (отсутствие выгрузки информации по сетям и хранилищам и множественное добавление и удаление группы узлов в кластер), пожелания по микросегментации и просьба добавить возможность мониторинга Raid массива локального хранилища сервера из Web интерфейса SpaceVM.
Но активность там тоже довольно странная. Либо пингвин сразу получился идеальный, либо разработчики как-то не горят желанием показывать внутрянку кому-то с улицы (багзиллу я смотрел без авторизации). Возможно, багзилла в этой ситуации — далеко не основной канал получения репортов?
Вызывает сомнения и процесс обработки заявленных ошибок. Например, оба бага из категории общих — довольно старенькие, зарегистрированные еще в 2022 году (SpaceVM 5.1.9), но все еще висят в статусе «Решается».
Сначала я подумал, что разработчики просто не забыли поменять статус, но, видимо, они действительно не отреагировали на запросы пользователей.
Я не знаю, что мотивирует вендора так тщательно скрывать информацию о каких-то исправлениях продукта. Не хочет на публику признавать наличие проблем? Но зачем? Проблемы есть у всех, и показывать — как ты их решаешь, значит, выстраивать доверительную коммуникацию с заказчиками, даже потенциальными.
Вот как, например, не имея на руках лицензию, понять, как вендор работает с проблемами и багами? Возможно, где-то в профильных сообществах SpaceVM и обитают открытые к коммьюнити разработчики продукта, но мне их пока увидеть не удалось, увы.
И, как мне кажется, это играет Space вообще не на руку. Пока вендор тщательно оберегает информацию о составе решения, уязвимостях, в известных TG-чатах обсуждают, есть ли там oVirt. Ссылку давать не буду, скорее всего, вы и сами догадываетесь, о каком чате может идти речь.
Может, все-таки стоит быть чуть более открытым к рынку? Да не, бред какой-то 🙂
И это на фоне того, что амбиции у вендора впечатляющие. Вкупе с закрытостью относительно багов и уязвимостей это вызывает определенные вопросы.
На этом фоне особенно странно выглядит отсутствие сертификата ФСТЭК. Для продукта, который позиционируется как самое надежное решение для виртуализации, это, мягко говоря, маркер. Кстати, это вообще единственная платформа из рейтинга Cnews, у которой его нет. Почему? Не хватает ресурсов на процедуру или есть технические препятствия, которые не позволяют пройти проверку регулятора? Имхо, без плашки «ФСТЭК» подобные заявления остаются пустыми словами, и лично для меня такое несоответствие амбиций и реального положения вещей было бы, извините за выражение, ред флагом.
VMmanager
Итак, по топ-3 платформам из рейтинга Cnews мы прошлись. Дальше разберем еще две платформы, которые хоть и не вошли в тройку лидеров, но лично у меня на слуху чуть больше других участников обзора.
Изначально я планировал построить обзор этой платформы немного иначе, однако прямо в процессе моего расследования выяснилась довольно интересная вещь. Вы не забыли, что мы тут рассматриваем российские платформы с точки зрения безопасности и работы с уязвимостями?
Так вот, совсем недавно разработчик платформы словил весьма неплохой хайп в зарубежной айтишечке... благодаря попаданию в отчет Sophos.
Судя по беглому изучению раздела с кейсами, платформу действительно используют за пределами СНГ (традиционный для нашей страны экспорт ПО в Беларусь и Казахстан предлагаю полноценным экспортом не считать), хотя сам вендор, как и все остальные на нашем рынке, двигается по волне импортозамещения. Никакой роли в нашем мини-исследовании это не играет, но само по себе интересно. Возможно, когда-нибудь мои руки дойдут до обзорной статьи про использовании отечественного софта за границей. Но это не точно.
Раз уж мне на глаза попался такой громкий материал, я решил начать обзор VMmanager прямо с него.
Итак, заголовок отчета выглядит довольно многообещающим — Malicious use of virtual machine infrastructure. У невнимательного читателя наверняка сразу нарисуется перед глазами яркая картинка — незащищенная российская платформа, злоумышленники, они что-то там взламывают и непременно требуют выкуп.
Но что же на самом деле хотел сказать Sophos? Давайте почитаем:
It is highly likely that MasterRDP is one of many BPH providers within the cybercriminal ecosystem that lease ISPsystem virtual machines hosted on abuse-tolerant infrastructure to customers with malicious intentions, including those engaged in ransomware operations and malware delivery. ISPsystem VMmanager is a legitimate commercial virtualization management platform widely used across the hosting industry, and the software itself is not malicious. However, its low cost, low barrier to entry, and turnkey deployment capabilities make it attractive to cybercriminals while its widespread legitimate use provides operational cover among thousands of compliant deployments.
Если кратко, в коде вендора уязвимости нет, злоумышленники использовали виртуалки VMmanager, потому что платформа дешевая и простая в использовании. Вроде все хорошо, но.
Что меня здесь смущает? Лично мне кажется, что эту ситуацию для российской аудитории стоило прокомментировать, — такую новость лучше открыто разъяснить, чем позволить ей обрастать слухами в tg-каналах, курилках и прочих профессиональных сообществах. Ну а вообще, если не триггериться на заголовки, а читать материал, выходит, что речь идет не про проблемы в коде вендора, а (внезапно!) про популярность VMmanager за рубежом. Это как обвинять телеграм в пособничестве мошенникам автозавод, что на его машинах грабят банки.
Ну отчет отчетом, а цель исследования у нас все-таки глобально в другом — понять, как вендор вообще работает с уязвимостями?
Итак, под капотом VMmanager тоже есть опенсорс, пусть и в минимальном количестве — лишь на уровне гипервизора (KVM), что в целом наблюдается у подавляющего большинства решений. А вот кодовая база, судя по информации на сайте, скорее всего, действительно по большей части собственная — по крайней мере, такое впечатление складывается у меня не только в силу возраста продукта (на сайте вендора это 15+ лет), но и довольно объемный роадмап.
Последняя запись о закрытии уязвимости в блоге датирована 2021 годом. Судя по этой публикации, исправляются такие вещи довольно быстро:
10 сентября Мы обнаружили уязвимость платформы VMmanager 6, которую исправили в релизе 2021.09.1-1 от того же дня. Она затрагивает частный случай работы платформы и может быть воспроизведена только в уникальных условиях.
Но если порыться в ченджлоге, можно найти довольно подробную историю разнообразных исправлений, в том числе и ошибок безопасности.
Вообще изначально я хотел прокомментировать этот случай немного в другом ключе — и тоже попросить разработчиков как-то поднять уровень прозрачности. Однако кое-что заставило меня изменить свое мнение в процессе написания статьи.
Оказалось, что у VMmanager доступна публичная программа bug bounty.
Я в целом не совсем понимаю, почему отечественные разработчики довольно редко открывают свои платформы для сторонних исследователей. Тем более, что большинство из них сертифицировано ФСТЭК и уже обросло различными ИБ-фичами. Поэтому VMmanagerу за багбаунти однозначно плюс.
Альт Виртуализация
Мне нравится, что «Базальт» не пытается искусственным образом завысить свой вклад в разработку в глазах пользователей и прямо говорит об активном использовании open source:
ПО основано на международных проектах СПО и выполняет все требования свободных лицензий на используемые компоненты. Исходные коды доступны в репозитории. Дистрибутив «Альт Виртуализация» 11 включен в Единый реестр Минцифры (регистрационный номер ПО 6487).
Тем не менее, как-то негативно оценивать это смысла не вижу — насколько я понимаю, это просто специфика вендора. Они позиционируют себя как «мировой производитель инфраструктурного ПО на базе собственной платформы разработки», но при этом честно признают базу из международных проектов. Это жирный плюс.
Но раз уж вендор активно использует open source, мы должны быть уверены, что это никак не скажется на пользователях, верно?
У Альт есть отдельная страница, посвященная обновлениям безопасности — мне это понравилось. Однако по тегам складывается впечатление, что все перечисленные исправления относятся к Альт СП, а не к Альт Виртуализации.
С одной стороны, видно, что обновления безопасности выпускаются каждые несколько дней. Как мне кажется, это довольно хороший уровень открытости — вендор прямо говорит о том, что строит решения на базе open source, показывает исправление уязвимостей.
С другой, меня немного смутили даты публикации исправлений. Например, уязвимость CVE-2025-32728 была опубликована в апреле 2025 года. А самая ранняя публикация со страницы обновлений безопасности Альт, касающаяся этой уязвимости, датирована мартом этого года. Безусловно, проблема некритичная — я взял ее исключительно как пример — но мне все равно показалось странным, что пользователи Альт потенциально получили обновление безопасности, которое ее закрывает, лишь через год после публикации CVE.
Есть ли выбор?
Давайте я попробую подвести своеобразный итог. Я действительно согласен с тем, что написать решение без единого опенсорс компонента сегодня действительно очень сложно. И, как верно отметили разработчики zVirt, даже VMware использует огромное количество открытых библиотек.
Вообще любая современная платформа виртуализации — это сложный слоеный пирог. Даже если вендор позиционирует своё решение как полностью отечественную разработку, внутри почти всегда оказываются открытые компоненты — libvirt, QEMU, KVM, а иногда и целый oVirt. Написать гипервизор с нуля под силу только единицам, да и экономического смысла в этом, как правило, нет.
Именно поэтому я считаю, что сам факт использования open source не стоит принимать близко к сердцу. Вопрос в другом — как вендор работает с той огромной массой кода, который он не писал сам, но который отвечает за безопасность платформы. Поэтому при выборе платформы нужно смотреть не столько на наличие уязвимостей, сколько на процесс разработки конкретного решения конкретным вендором.
Продолжая использовать по привычке решения иностранных вендоров, вы должны принимать на себя все соответствующие риски безопасности. Что вы будете делать, если завтра в VMware найдется критическая уязвимость? Есть ли у вас уверенность, что вы в нужные сроки получите патч?
Это не значит, что нужно пугаться каждого найденного бага — их наличие в сложном ПО неизбежно.
«Дело не в умении, не в желании, и вообще ни в чём. Дело в самом пришивании подворотничка»
Смотрите на то, как вендор обрабатывает и закрывает найденные ошибки и проблемы. Учитывайте скорость реакции, прозрачность, наличие канала связи с исследователями и его публичность.
В сегодняшнем понимании киберустойчивость — это не поиск наиболее независимого решения без уязвимостей. Это гарантия и предсказуемость получения обновлений, прозрачность разработки, в конце концов, коммуникация с пользователями. И в этом ключе использование ряда российских решений выглядит выгоднее для конечного пользователя, нежели инерция и страдания по ушедшей VMware.