По поводу сообщений о двух активно эксплуатируемых 0day RCE-уязвимостях в Citrix NetScaler

Добавить комментарий

По поводу сообщений о двух активно эксплуатируемых 0day RCE-уязвимостях в Citrix NetScaler

По поводу сообщений о двух активно эксплуатируемых 0day RCE-уязвимостях в Citrix NetScaler. NetScaler (Citrix NetScaler, Citrix ADC) - это контроллер доставки приложений (ADC), который анализирует, распределяет, оптимизирует и защищает сетевой трафик на уровнях L4-L7, в том числе выполняет балансировку нагрузки. В составе NetScaler также предусмотрена функциональность NetScaler Gateway, которая обеспечивает защищённый удалённый доступ пользователей к корпоративным приложениям и внутренним ресурсам.

25 сентября появились сообщения в Reddit r/Citrix с рекомендацией выключить NetScaler-ы. Упоминались две уязвимости нулевого дня. Один из пользователей сообщил, что эти сведения поступили из предварительного уведомления NCSC-NL (национального центра кибербезопасности Нидерландов), которое распространялось с ограничениями Traffic Light Protocol (TLP): AMBER+STRICT (разрешает делиться только внутри организации).

26 сентября эксперты watchTowr подтвердили сведения об обеих уязвимостях:

"Нам стало известно о дополнительной информации, которой мы делимся. Мы и понятия не имели, что системные администраторы Citrix как фанаты GTA6 - такие дружелюбные 🙂

Пожалуйста, направляйте дальнейшие вопросы в Citrix. Мы не являемся Citrix PSIRT (хотя иногда это выглядит именно так).

Ожидается, что Citrix опубликуют официальные сообщения и выпустит исправления в начале следующей недели. Две уязвимости - обе позволяют удалённое выполнение кода (RCE).

Уязвимости не пропатчены, это zero-day. Они уже эксплуатируются в реальных атаках - их обнаружили в ходе форензики.

Как всегда, клиенты watchTowr Platform уже имеют доступ к этой информации и располагают всем необходимым, чтобы снизить уровень риска."

П̶о̶ с̶о̶с̶т̶о̶я̶н̶и̶ю̶ н̶а̶ 2̶7̶ с̶е̶н̶т̶я̶б̶р̶я̶ о̶ф̶и̶ц̶и̶а̶л̶ь̶н̶о̶е̶ у̶в̶е̶д̶о̶м̶л̶е̶н̶и̶е̶ о̶т̶ C̶i̶t̶r̶i̶x̶ о̶п̶у̶б̶л̶и̶к̶о̶в̶а̶н̶о̶ н̶е̶ б̶ы̶л̶о̶,̶ и̶с̶п̶р̶а̶в̶л̶е̶н̶и̶я̶ в̶ н̶а̶с̶т̶о̶я̶щ̶е̶е̶ в̶р̶е̶м̶я̶ о̶т̶с̶у̶т̶с̶т̶в̶у̶ю̶т̶.̶

UPD. Вышел бюллетень и обновление для CVE-2026-88771 и CVE-2026-88772.

Пока не установлено, насколько масштабны атаки. 26 сентября исследователь Кевин Бомонт заявил: "История с уязвимостями нулевого дня в Netscaler реальна, они используются в активных атаках. Исправления пока нет, если для вас уязвимости Netscaler чувствительны, выключите его". Публично доступных индикаторов компрометации (IoC) пока нет.

Эти уязвимости нулевого дня, по-видимому, НЕ связаны с CVE-2026-19490 и CVE-2026-19489 - ранее раскрытыми уязвимостями в Citrix NetScaler ADC и NetScaler Gateway, для которых уже доступны исправления. CVE-2026-19490 была добавлена в CISA KEV 9 сентября. Citrix NetScaler исторически был популярной целью атакующих. С учётом CVE-2026-19490 по состоянию на 27 сентября 2026 года в CISA KEV насчитывалось 13 записей, связанных с NetScaler, и 24 записи по продуктам Citrix в целом.

На сайте CISA 22 сентября опубликовали документ "Программа CVE: формирование фреймворка эры качества"

Добавить комментарий

На сайте CISA 22 сентября опубликовали документ Программа CVE: формирование фреймворка эры качестваНа сайте CISA 22 сентября опубликовали документ Программа CVE: формирование фреймворка эры качества

На сайте CISA 22 сентября опубликовали документ "Программа CVE: формирование фреймворка эры качества". В оригинале "CVE Program: Establishing a Quality Era Framework". Основная проблема, которую они там фиксируют: CVE Program быстро масштабируется, вместе с объёмом уязвимостей растёт нагрузка на процессы публикации, проверки и сопровождения CVE-записей.

По состоянию на 18 сентября 2026 года опубликовано более 67 тыс. новых CVE. По данным NVD, число CVE, поступивших на обработку, выросло на 263% в 2020-2025 годах. За первые три месяца 2026 года на обработку поступило на треть больше CVE, чем за тот же период 2025 года.

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

Руководство CISA выделяет четыре направления работы:

🔹 управление CVE Program;
🔹 участие представителей экосистемы - CNA, Roots, CNA-LR, исследователи, вендоры, поставщики инструментов и государственные организации;
🔹 инфраструктура данных - API, схемы, библиотеки проверки и CVE Org;
🔹 качество записей CVE - полнота, точность, своевременность и практическая применимость данных.

Для этих направлений определены показатели качества (на иллюстрации) - от времени принятия управленческих решений и надёжности API до доли записей CVE, соответствующих установленным критериям качества, и количества исправлений после публикации (или скорости внесения исправлений? 🤔 Имхо, тут неоднозначно: "Rate of corrections/updates needed post-publication").

"Эпоха качества требует согласованного развития по четырём направлениям: управление программой CVE, участие представителей экосистемы, инфраструктура данных и содержание записей CVE.

🔻 Улучшение содержания записей CVE зависит от чётких требований к данным, эффективных инструментов и активного участия CNA.
🔻 Развитие инфраструктуры данных требует постоянных инвестиций, защищённых и масштабируемых систем, а также обратной связи от пользователей, которые используют эти данные.
🔻 Расширение участия в экосистеме зависит от широкого представительства технологий, отраслей, регионов и сообществ, которые обслуживает программа CVE.
🔻 Совершенствование управления программой зависит от прозрачного управления, дальнейшего организационного развития, совместного участия, эффективности и способности оперативно реагировать на потребности мирового сообщества, занимающегося управлением уязвимостями."

Этот документ задаёт рамку для следующего этапа развития CVE Program (читай: по большей части вода-водичка, правильные общие слова и благие намерения без какой-либо конкретики 😉). Описания конкретных изменений обещают выложить в ближайшие месяцы: "в этой серии публикаций будут описаны текущие и планируемые улучшения ключевых компонентов инфраструктуры, обеспечивающих работу программы CVE".

Коллегам из ФСТЭК тоже стоит к этой движухе присмотреться и, возможно, что-то перенять для развития БДУ.

Сегодня ходили семьёй в Государственный Дарвиновский музей на детскую экскурсию "Жизнь древнего человека"

Добавить комментарий

Сегодня ходили семьёй в Государственный Дарвиновский музей на детскую экскурсию Жизнь древнего человека

Сегодня ходили семьёй в Государственный Дарвиновский музей на детскую экскурсию "Жизнь древнего человека". На экскурсии рассказывали о родословной человечества, жизни и быте людей каменного века.

Человек относится к отряду приматов, включающему множество современных видов. Колыбелью человечества считается Африка, одним из важнейших регионов ранней эволюции была Восточная Африка. Около 3,9 миллиона лет назад здесь жили афарские австралопитеки - древние гоминины, близкие к предкам человека. Около 2,8–1,5 миллиона лет назад представители рода Homo, в том числе Homo habilis - "человек умелый", изготавливали каменные орудия.

Homo erectus - "человек прямоходящий" - появился около 1,9 миллиона лет назад и просуществовал примерно до 100–300 тысяч лет назад (по некоторым данным, отдельные поздние популяции дожили до 110–140 тысяч лет назад). Он освоил более разнообразные орудия, предположительно умел использовать огонь (это остаётся предметом научных дискуссий) и одним из первых древних людей расселился за пределами Африки. Неандертальцы жили в Европе и некоторых районах Азии в эпоху оледенений примерно с 400 тысяч до 40 тысяч лет назад.

Люди современного типа - Homo sapiens - появились в Африке около 300 тысяч лет назад. В Европе представители Homo sapiens появились примерно 45 тысяч лет назад. Их традиционно называют кроманьонцами. Они создавали сложные орудия, совершенствовали приёмы охоты, изготавливали украшения и создавали произведения искусства.

Особенно интересно было послушать про захоронение в гроте Тешик-Таш. В 1938 году А. П. Окладников обнаружил там останки ребёнка-неандертальца примерно 8-9 лет. Находка датируется примерно 70 тысячами лет назад! Останки находились в неглубокой яме, которую интерпретировали как погребение. Вокруг черепа были расположены пары рогов горных козлов, образуя круг. Это было истолковано как возможный погребальный обряд. Если у неандертальцев было какое-то подобие религии - это очень круто! 😮

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

Также было интересно увидеть гипсовый слепок парного захоронения двух мальчиков на стоянке Сунгирь. Сунгирь - это стоянка Homo sapiens, расположенная на окраине современного Владимира, возрастом около 30-34 тысяч лет. Двух мальчиков захоронили в одной могиле, положив головами друг к другу. Одежда мальчиков была украшена бусинами и браслетами из бивня мамонта. В могиле также нашли подвески, украшения, копья и дротики. Про Сунгирь мы также смотрели очень интересную экспозицию "Сунгирь. Верхний палеолит в центре Русской равнины", когда были во Владимире в прошлом году.

В общем, понравилось. Планируем и на другие экскурсии Дарвиновского музея сходить. 😉

Про уязвимость Remote Code Execution - cPanel (CVE-2026-87899)

Добавить комментарий

Про уязвимость Remote Code Execution - cPanel (CVE-2026-87899)

Про уязвимость Remote Code Execution - cPanel (CVE-2026-87899). cPanel - это коммерческая панель управления Linux-серверами от компании cPanel, L.L.C. (входит в WebPros), которую часто используют хостинг-провайдеры, чтобы клиенты могли управлять хостингом через браузер. Панель работает по платной лицензии: провайдер устанавливает её на свои серверы (выделенные или VPS) и создаёт клиентские аккаунты. Каждый клиент через cPanel управляет своими сайтами, доменами, файлами, базами данных, почтой, SSL-сертификатами и DNS. Согласно описанию вендора, уязвимость CVE-2026-87899 позволяет аутентифицированному злоумышленнику повысить свои привилегии через функциональность CalDAV и CardDAV (протоколы для синхронизации календарей и контактов) в cPanel. Успешная эксплуатация уязвимости приводит к выполнению произвольного кода от root-а, что предоставляет злоумышленнику полный контроль над сервером.

Таким образом, для получения root-доступа к серверу злоумышленнику достаточно иметь аккаунт cPanel. Для компании, предоставляющей услуги shared-хостинга публично и неограниченному кругу лиц, это означает, что уязвимость может эксплуатировать любой клиент. Кроме того, учётные данные для доступа к cPanel могут быть украдены злоумышленниками или приобретены на чёрном рынке. В результате эксплуатации злоумышленник может получить доступ к данным других клиентов shared-хостинга, размещённых на том же сервере. Это, в свою очередь, может привести к утечке персональных данных, использованию сайтов для распространения вредоносного ПО и размещения незаконного контента.

⚙️ Уязвимость затрагивает cPanel/WHM версии 120 и выше. Исправления доступны в сборках 11.134.0.57, 11.136.0.41, 11.138.0.8 и более новых, а для WP Squared - в версии 11.138.1.11 и выше. С 31 марта 2026 года американская компания WebPros, которой принадлежат cPanel и Plesk, прекратила обслуживание хостинг-провайдеров из России и Беларуси, сославшись на требования экспортного и санкционного законодательства. По данным ТАСС, подписки российских клиентов были аннулированы. В таких условиях у российских провайдеров, продолжающих использовать cPanel, могут возникнуть дополнительные сложности со своевременным обновлением этого ПО.

🌐 По данным экспертов Positive Technologies, на shared-хостингах под управлением cPanel могут быть размещены около 35 миллионов веб-сайтов, 27 тысяч из которых - российские. По оценке компании ispmanager, cPanel и Plesk на конец марта 2026 года суммарно занимали около 5% российского рынка панелей для shared-хостинга, что соответствует как минимум 50 тыс. сайтов на cPanel и Plesk в доменных зонах .ru и .рф. Эти оценки могут не учитывать сайты российских компаний, которые размещаются на зарубежных shared-хостингах и используют нероссийские доменные зоны.

🛠👾 Публичных эксплоитов и признаков эксплуатации в реальных атаках пока нет.

💡 При использовании shared-хостинга компания доверяет хостинг-провайдеру обслуживание, обновление и безопасную настройку сервера, на котором размещён её веб-сайт. К выбору хостинг-провайдера стоит подходить ответственно, потому что невыполнение им своих обязанностей может нанести компании крупный ущерб. В этом вопросе лучше не экономить, а выбирать проверенных поставщиков услуг с подтверждёнными компетенциями и хорошей репутацией на рынке. Другой вариант - не использовать shared-хостинг, а заниматься обслуживанием сервера самостоятельно.

🗞 Мой комментарий по этой уязвимости вышел в новости на сайте SecPost.

На Хабре вышла статья о том, как MaxPatrol Carbon использовался при подготовке инфраструктуры для кибербитвы Standoff 17

Добавить комментарий

На Хабре вышла статья о том, как MaxPatrol Carbon использовался при подготовке инфраструктуры для кибербитвы Standoff 17

На Хабре вышла статья о том, как MaxPatrol Carbon использовался при подготовке инфраструктуры для кибербитвы Standoff 17. Главная задача архитектора ИТ-инфраструктуры Standoff - найти баланс между сложностью сценариев атак и временем, необходимым для их реализации атакующими, поскольку соревнования проходят всего несколько дней. Архитектор формализует векторы атак, которые должны быть заложены в инфраструктуру, собирает под них стенды, настраивает активы и ролевую модель, продумывает, где должны быть мисконфигурации и подсказки в виде оставленных данных или специальных условий для успешной реализации сценария атаки. При этом "одна забытая учётная запись, лишний ACL или избыточный сетевой доступ могут существенно сократить маршрут атакующего". Если цепочка из десятков шагов превращается в один-два, весь замысел, заложенный при проектировании, теряется.

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

Архитектор может считать, что всё отладил, а тут - бац! Для какого-то софта в инфраструктуре появляется критичная эксплуатабельная уязвимость, и её нужно патчить, иначе для атакующих появляется незапланированный короткий путь для реализации атаки. При этом патчинг уязвимости не должен поломать запланированные векторы. 🤯

Поддерживать всю эту картину вручную, особенно когда активов много, практически невозможно. Поэтому коллеги из Standoff решили использовать MaxPatrol Carbon в качестве инструмента для:

🔹 проверки запланированных сценариев;
🔹 поиска непредусмотренных путей атаки.

Продукт показывает, где появились лишние связи, привилегии, новые уязвимости или побочные векторы, которых быть не должно. В статье приводится несколько кейсов, выявленных с помощью MaxPatrol Carbon, которые могли существенно сократить атакующим путь до целевого актива:

🔻 возможность компрометации дополнительной учётки;
🔻 возможность эксплуатации уязвимости Nginx;
🔻 ошибка в настройке правил сетевого доступа.

Оказалось, что MaxPatrol Carbon, изначально предназначенный для поддержания инфраструктуры в максимально безопасном состоянии, можно использовать и для ещё более сложной задачи - поддержания её в "контролируемо уязвимом" состоянии. 😉

На конференции IT Elements эксперты компании Инфосистемы Джет представили "Фреймворк антихрупкой ИТ-архитектуры", учитывающий состояние процесса Управления Уязвимостями в организации

Добавить комментарий

На конференции IT Elements эксперты компании Инфосистемы Джет представили Фреймворк антихрупкой ИТ-архитектуры, учитывающий состояние процесса Управления Уязвимостями в организации

На конференции IT Elements эксперты компании Инфосистемы Джет представили "Фреймворк антихрупкой ИТ-архитектуры", учитывающий состояние процесса Управления Уязвимостями в организации. Фреймворк включает в себя 7 стратегий по четырём направлениям:

🔹 Подготовка к вторжению - 1. Системное развитие и контроль, 2. Подготовка и прогнозирование.
🔹 Слева от вторжения - 3. Вовлечение и нападение, 4. Защита, замедление, сдерживание.
🔹 Справа от вторжения - 5. Обнаружение и реагирование.
🔹 После вторжения - 6. Восстановление, 7. Адаптация и перестройка.

Эти стратегии раскладываются в 33 домена, которые, в свою очередь, раскладываются в 390 практик.

Чтобы замерить индекс антихрупкости для своей организации, можно воспользоваться специальным интерактивным опросником. Индекс оценивает способность компании пережить кибератаку, продолжать работу в её условиях и восстановиться после неё. По итогам заполнения опросника получаем индекс от 0 до 100%, разбор по направлениям защиты и сравнение с другими участниками. Отраслевой уровень обновляется автоматически по мере накопления ответов респондентов. Индекс рассчитывается по открытой методике. Опросник должен заполнять CISO. Вопросы однотипны, варианты ответов: "Да", "Частично", "Нет", "Неприменимо", "Не знаю".

Теперь пройдёмся по 13 практикам, которые непосредственно связаны с Управлением Уязвимостями. Они находятся в разделе Слева от вторжения -> 4. Защита, замедление, сдерживание -> 4.4 Непрерывная работа с уязвимостями.

📄 Формализация процесса, ответственные за устранение и сроки устранения

4.4-1 Регламентирован и реализуется процесс управления уязвимостями, определяющий порядок их выявления, оценки критичности, планирования и контроля устранения. Определяются ответственные за устранение уязвимостей и реализацию исправлений, а также целевые сроки, согласованные службами ИБ и ИТ

В опроснике: 49. Регламентирован и реализуется процесс управления уязвимостями. Определены ответственные за устранение уязвимостей и реализацию исправлений, а также целевые сроки, согласованные службами ИБ и ИТ

📄 Задачи на сканирование

4.4-2 Определен перечень, приоритеты и сроки сканирования каждого актива/типов активов. В область сканирования включены все активы, обеспечивающие критически значимые процессы организации

В опроснике нет.

📰 Отслеживание информации об уязвимостях

4.4-3 Определены источники информации об уязвимостях (например, БДУ ФСТЭК России, уведомления от регуляторов, сайты производителей ПО, каналы СМИ и др.). Информация из этих источников систематически анализируется на предмет применимости к активам организации, выявленные релевантные уязвимости регистрируются

В опроснике нет.

🚨 Экстренная обработка уязвимостей

4.4-4 Документирована и реализуется процедура экстренной обработки критических уязвимостей, определяющая порядок оповещения ИБ и ИТ, экстренной оценки применимости уязвимости, реализации временных защитных мер и координации действий с процессом кризисного реагирования.

В опроснике: 50. Документирована и реализуется процедура экстренной обработки критических уязвимостей, определяющая порядок оповещения ИБ и ИТ, экстренной оценки применимости уязвимости, реализации временных защитных мер и координации действий с процессом кризисного реагирования.

🔎 Сканирование на наличие уязвимостей

4.4-5 Функционирует процесс регулярного автоматизированного поиска уязвимостей. Поиск выполняется автоматизированными средствами, использующими актуальные базы данных (сканеры уязвимостей).

В опроснике: 51. Функционирует процесс регулярного автоматизированного поиска уязвимостей. Поиск выполняется автоматизированными средствами, использующими актуальные базы данных.

💿 Базовые образы

4.4-6 Процесс управления уязвимостями включает процедуры проверки и устранения уязвимостей в базовых образах инфраструктуры, используемых для развертывания корпоративных информационных систем.

В опроснике нет.

⚖️ Продвинутая приоритизация уязвимостей

4.4-7 Приоритизация устранения уязвимостей выполняется по риск-ориентированным критериям, включая критичность актива, последствия эксплуатации, наличие доступных способов эксплуатации и техническую оценку уязвимости. Приоритеты используются для определения сроков устранения и контроля выполнения.

В опроснике: 52. Приоритизация устранения уязвимостей выполняется по риск-ориентированным критериям. Приоритеты используются для определения сроков устранения и контроля выполнения.

🔐 Сканирование с аутентификацией

4.4-8 Для обнаружения уязвимостей применяется аутентифицированное сканирование узлов, при котором средство сканирования получает контролируемый доступ к системе для более точного выявления уязвимых компонентов и конфигураций.

В опроснике нет.

🔗 Интеграция с GRC

4.4-9 Данные об уязвимостях автоматически синхронизируются с реестром рисков или системой управления рисками (GRC-системой). Изменение статуса уязвимости приводит к пересчету параметров риска и созданию или обновлению карточки риска.

В опроснике нет.

🎫 Интеграция с Task Tracker

4.4-10 Реализована интеграция инструментов сканирования уязвимостей с системой управления задачами. Задачи на устранение уязвимостей формируются автоматически, приоритет задач определяется критичностью уязвимости и значимостью актива.

В опроснике нет.

↪️ Компенсирующие меры

4.4-11 Для уязвимостей, устранение которых невозможно или небезопасно, определяется и применяется набор компенсирующих мер, выбор которых документируется и привязывается к конкретной уязвимости и активу.

В опроснике нет.

💭 План снижения риска

4.4-12 Для унаследованных систем, которые невозможно привести к актуальному уровню безопасности, разработаны и выполняются планы снижения риска. Планы определяют целевое состояние системы (вывод из эксплуатации или замена) и устанавливают временные меры защиты на период ее эксплуатации.

В опроснике нет.

⏱️ Отслеживание сроков устранения

4.4-13 Осуществляется системный контроль соблюдения целевых сроков устранения уязвимостей. Устранение выявленных уязвимостей периодически контролируется, результаты контроля регистрируются.

В опроснике: 53. Осуществляется периодический контроль соблюдения целевых сроков устранения уязвимостей. Устранение выявленных уязвимостей периодически контролируется.

В целом, довольно толковый набор практик. 👍 Единственное, не очень понятно, почему практик больше, чем вопросов в опроснике. Возможно, отобрали самое важное, а может, опросник будут расширять. 🤷‍♂️

В начале сентября коллеги из Cloud Advisor выпустили исследование "Состояние облачной безопасности в России. Анализ защищённости инфраструктур, развёрнутых в российских публичных облаках"

Добавить комментарий

В начале сентября коллеги из Cloud Advisor выпустили исследование Состояние облачной безопасности в России. Анализ защищённости инфраструктур, развёрнутых в российских публичных облаках

В начале сентября коллеги из Cloud Advisor выпустили исследование "Состояние облачной безопасности в России. Анализ защищённости инфраструктур, развёрнутых в российских публичных облаках". Cloud Advisor - это вендор отечественного CNAPP (Cloud-Native Application Protection Platform) решения, позволяющего искать на облачных активах (виртуальных машинах и Kubernetes) уязвимости, вредоносный код, секреты и мисконфигурации. Отчёт о состоянии облачной безопасности в России опирается на реальные данные десятков организаций, имеющих не менее 80 виртуальных машин в публичном облаке (Cloud Ru и Yandex Cloud). Всего было проанализировано более 40 000 виртуальных машин. Период исследования - первое полугодие 2026 года.

По уязвимостям результаты следующие:

🔻 83% виртуальных машин имеют уязвимости с CVSS выше 9,0;
🔻 88% организаций имеют на публично доступных машинах уязвимости с CVSS выше 9,0;
🔻 27% организаций до сих пор уязвимы к Log4Shell (CVE-2021-44228);
🔻 42% организаций имеют хотя бы одну виртуальную машину на периметре с ОС, находящейся в статусе EOL (всего EOL-систем в облаках около 9%).

В части Управления Уязвимостями эксперты Cloud Advisor рекомендуют:

🔹 Внедрить регулярное сканирование виртуальных машин и образов контейнеров на уязвимости, используя для этого безагентные cloud native-решения. "Таким образом можно обеспечить 100% покрытие без трудозатрат на установку агентов и настройку SSH-доступов".

🔹 Приоритизировать уязвимости по контексту, а не только по CVSS. Помимо CVSS и наличия эксплойтов рекомендуют учитывать "публичную доступность ресурса, наличие на нём секретов в открытом виде, его права и другие факторы".

🔹 Установить и соблюдать SLA на устранение уязвимостей в зависимости от их критичности. "Без фиксированных сроков CVE накапливаются годами - как это произошло с Log4Shell".

Также эксперты Cloud Advisor обращают внимание, что наибольшую опасность представляют цепочки уязвимостей, ошибок конфигураций и прав доступа, которые в совокупности создают критические пути атаки. Именно такие связки должны стать приоритетом в защите облачной инфраструктуры.