Наступательная кибербезопасность: что мы нашли за этот год
В период с июля 2025‑го по июль 2026 года мы провели более сотни проектов по тестированию на проникновение, анализу защищенности мобильных и веб‑приложений, red teaming и анализу защищенности встраиваемых систем. Затем изучили данные и выявили закономерности.
В материале делимся:
- ключевыми трендами в области наступательной кибербезопасности за прошедший отчетный период;
- статистикой по каждому типу проекта: что изменилось за год, кто заказывает работы чаще всего и почему;
- недостатками в киберзащите компаний из разных отраслей;
- рекомендациями, как снизить риски, вызванные взломом и компрометацией систем.
- В этот период найдено 823 уязвимости, из них 213 — высокого и критического уровня.
- Самая частая проблема — нарушение контроля доступа.
- Злоумышленники стали чаще атаковать через цепочки уязвимостей и изнутри. Для полного компрометированного доступа к системе может быть достаточно одной уязвимости.
- Больше всего проектов заказывали компании из IT, финансов, услуг, медиа и госсектора.
- В 90% red team — проектов их цели адаптировались под специфику конкретной организации. При этом в 93% проектов эксперты успешно проникали во внутренний периметр компаний, а в 85% — полностью достигали поставленных задач.
- AI становится частью продуктов, внутренних сервисов и критически важных бизнес‑процессов.
Услуги наступательной кибербезопасности не взаимозаменяемые: они решают разные задачи. Ниже — краткое описание видов и задач проектов. Подробное сравнение услуг вы можете скачать здесь.
| Услуга | Что проверяем | Что делаем |
|---|---|---|
| Внешнее тестирование на проникновение |
Можно ли взломать компанию извне |
Ищем возможные пути проникновения в инфраструктуру из интернета |
| Внутреннее тестирование на проникновение |
Что сможет сделать злоумышленник после проникновения в инфраструктуру |
Проверяем, как далеко атакующий сможет продвинуться по инфраструктуре и к каким критичным активам сможет получить доступ |
| Анализ защищенности веб‑приложений |
Насколько защищено веб‑приложение |
Находим уязвимости в бизнес‑логике, API, клиентской и серверной части приложения |
| Анализ защищенности мобильных приложений |
Насколько защищено мобильное приложение |
Выявляем в приложении, API и их взаимодействии уязвимости, которые могут привести к компрометации данных и систем |
| BI.ZONE Red Team |
Готова ли компания к реальной атаке |
Проверяем эффективность обнаружения и реагирования, а также готовность SOC/IR отражать целевые атаки |
| BI.ZONE ESSA |
Насколько защищенно устройство на всех уровнях его работы: от аппаратных компонентов до встроенного ПО и интерфейсов |
Комплексно оцениваем защищенность устройства или встраиваемой системы на всех уровнях их работы. Помогаем выявить уязвимости и определить возможные сценарии их эксплуатации |
Основная доля проектов пришлась на внешнее тестирование, на втором месте — анализ веб-приложений. Вместе они составили 71% от всех проведенных работ.
Наша статистка показывает, что компании предпочитают начинать с понятных и прикладных форматов проверки: оценивают устойчивость внешнего периметра и возможное развитие атаки внутри инфраструктуры. Бизнес воспринимает тестирование на проникновение как устоявшийся инструмент, который позволяет не только найти отдельные уязвимости, но и проверить наиболее значимые сценарии компрометации.
Тестирование мобильных и веб‑приложений составило около трети от всех проектов, что подтверждает устойчивый спрос на поиск уязвимостей в цифровых сервисах.
Доля red team — проектов составила 5%, что объясняется особенностями услуги. Такие проверки требуют более высокого уровня зрелости заказчика, в том числе — собственных команд SOC и IR, способных выявлять действия атакующих и реагировать на них. Тем не менее, по нашим наблюдениям, число red team — проектов растет из года в год. Все больше компаний переходят от проверки отдельных систем к комплексной оценке защищенности и способности команды противостоять целевым атакам.
Чаще всего проверку защищенности проводили компании из следующих отраслей:
-
IT — 36% проектов
Для IT‑организаций критична скорость разработки. У них множество внешних сервисов, к тому же такие компании несут ответственность за инфраструктуру и данные клиентов: компрометация одного поставщика может затронуть сразу несколько организаций.
-
Финансы — 19% проектов
В финансовой отрасли дополнительную роль в выборе услуги играют регуляторные требования, работа с платежными и персональными данными, риск мошенничества и высокая стоимость даже кратковременного простоя.
-
Услуги — 13% проектов
Компании активно развивают клиентские приложения, личные кабинеты и интеграции с внешними системами, что постепенно расширяет поверхность атаки.
Доли проектов в промышленности, госсекторе, медиа, образовании, телекоме, ритейле, медицине и фармацевтике оказались небольшими. Эти значения отражают структуру нашей проектной выборки, а не общий уровень защищенности отраслей. Для государственных организаций важны регуляторные требования и защита значимых информационных систем, для промышленности — устойчивость производственных процессов, систем и безопасность объектов критической информационной инфраструктуры (КИИ). В медиа даже один скомпрометированный аккаунт или внутренний сервис может привести к подмене публикаций, распространению дезинформации и серьезному репутационному ущербу. Поэтому меньшая доля проектов в этих и остальных отраслях (ритейл, телеком, медицина и фармацевтика) не означает, что им не нужно проводить проверки по анализу защищенности систем и бизнес‑процессов.
Основные заказчики — крупные компании (64%). У крупного бизнеса масштабная IT‑инфраструктура, высокая регуляторная нагрузка и цена возможного инцидента, поэтому он проводит проверку защищенности регулярно, а не только перед запуском отдельных систем. Кроме того, крупные организации готовы предоставлять для тестирования сложные и критичные элементы инфраструктуры. Они рассчитывают получить не формальный перечень находок, а проверенные сценарии атак и практические рекомендации по устранению рисков.
Интерес среднего и малого бизнеса к проектам говорит о более ответственном, чем раньше, отношении компаний к защите собственных систем, исполнению обязательств перед клиентами и снижению рисков для бизнеса. У них постепенно формируется привычка регулярно обращаться к практикам наступательной кибербезопасности.
Уязвимости критического и высокого уровня составили 26% от общего числа находок. Атакующий может их использовать, чтобы получить несанкционированный доступ, закрепиться в инфраструктуре, нарушить работу систем, украсть и скомпрометировать чувствительные данные.
Основная часть выявленных уязвимостей относится к среднему и низкому уровням критичности. Но их не стоит недооценивать: на практике атаки часто строятся на комбинированной эксплуатации нескольких недостатков. Уязвимость низкого уровня сама по себе может не представлять серьезной угрозы, но в составе цепочки способна вызвать тяжелые последствия для компании.
По результатам проектов составили рейтинг уязвимостей, которые встречались чаще всего. Он показывает, на что бизнесу стоит обратить внимание в первую очередь.
- Broken access control (BAC) — нарушение контроля доступа. Уязвимость, из‑за которой злоумышленник может получить доступ к данным или функциям, которые должны быть ограничены, изменить критичную информацию или выполнить действия с повышенными правами.
- Security misconfiguration — нарушение безопасности конфигураций. Ошибки конфигурации в веб‑приложениях или серверных системах, такие как неправильные настройки безопасности, ненадежные заголовки безопасности или избыточные разрешения. Cоздают дополнительные точки входа в систему и могут привести к раскрытию служебной информации или несанкционированному доступу.
- Injection — инъекции. Уязвимости (например, SQL‑, OS‑ или LDAP‑инъекции), при которых вредоносные данные вводятся в систему. Это может привести к исполнению нежелательных команд.
- Vulnerable and outdated components — уязвимые и устаревшие компоненты. Использование таких компонентов, библиотек и фреймворков подвергает систему риску компрометации.
- Authentication failures — сбои аутентификации. Связаны с проблемами аутентификации (например, слабые пароли), уязвимостями в процессах подтверждения личности или отсутствием многофакторной аутентификации. Повышают риск, что злоумышленник захватит учетные записи и получит доступ к системам от имени легитимных пользователей.
- LLM prompt injection — промпт‑инъекция. Уязвимость, при которой злоумышленник вводит вредоносные команды или текст в запросы к моделям машинного обучения, чтобы манипулировать результатами. Может заставить AI‑модель раскрыть конфиденциальную информацию, обойти ограничения или выполнить нежелательное действие.
- Cryptographic failures — криптографические уязвимости. Ошибки, такие как использование слабых шифров или плохое управление ключами. Могут привести к раскрытию паролей, персональных данных и другой чувствительной информации.
- Cross‑site scripting (XSS) — межсайтовый скриптинг. Уязвимость, при которой злоумышленник вставляет вредоносный JavaScript‑код в веб‑страницу, который затем выполняется в браузере пользователя. Такой код позволяет похищать данные сессии или подменять содержимое страницы.
- Security logging and monitoring failures — отсутствие (или недостаточность) логирования и мониторинга безопасности. Уязвимость мешает своевременно обнаружить атаку, восстановить ее ход и сократить последствия инцидента.
- Sensitive data exposure — раскрытие конфиденциальных данных. Уязвимость, при которой чувствительные данные, например пароли, номера карт и личные сведения пользователей, передаются или хранятся без должного шифрования.
Если сопоставить текущую версию рейтинга с данными 2024 года, заметно, что ядро наиболее распространенных проблем практически не изменилось. Верхние позиции все еще занимают ошибки управления доступом, небезопасные настройки, инъекции и использование уязвимых компонентов. Это показывает, что основные риски по‑прежнему связаны не с редкими и сложными техниками, а с системными недостатками в разработке, настройке и сопровождении IT‑систем.
При этом состав рейтинга постепенно меняется вслед за развитием технологий и поверхности атаки. В топ‑10 вошли проблемы журналирования и мониторинга, XSS и LLM prompt injection. Последняя категория отражает появление новых рисков, связанных с внедрением AI‑сервисов, для которых компании пока только формируют устойчивые практики защиты. В рассматриваемый период DoS и ошибки бизнес‑логики встречались реже, чем другие классы уязвимостей, но это не означает, что такие угрозы исчезли.
Доля выявляемых уязвимостей критического уровня сократилась с 23% в период с 2024 по 2025 год до 14%. Процент уязвимостей высокого уровня критичности тоже уменьшился — с 28% до 24%. Снизилось количество таких уязвимостей, как Zerologon и MS17‑010, которые часто встречались в прошлый период.
Доли уязвимостей среднего (38%) и низкого (11%) уровней критичности выросли в 2026 году до 50% и 12%. Перекос в сторону уязвимостей среднего уровня связан с тем, что за этот отчетный период мы намного чаще находили системы с паролями, установленными по умолчанию, но получение доступа к ним не создавало существенных рисков для компаний.
В проектах по внутреннему тестированию выявили несколько критичных уязвимостей, эксплуатация которых могла привести к значительным последствиям для бизнеса. Так, все еще встречаются уязвимые шаблоны сертификатов и мисконфигурации в различных инфраструктурных сервисах (например, опубликованные Docker API, пароли по умолчанию и т. д.).
Вот три наиболее частые угрозы для корпоративной безопасности:
-
AD CS ESC — уязвимость в Active Directory Certificate Services (ADCS). Позволяет злоумышленнику получить несанкционированный доступ к компонентам Enrollment Services Control (ESC). С ее помощью злоумышленник может манипулировать процессами аутентификации, создавать и управлять сертификатами, а также снижать уровень защищенности всего окружения.
Что позволяет злоумышленнику:
- Повысить привилегии в домене Active Directory.
- Полностью скомпрометировать домен.
Как предотвратить:
- Регулярно обновлять AD CS.
- Проверять корректность конфигурации ролей и политик доступа.
- Применять многофакторную аутентификацию.
- Ограничивать доступ к ключевым серверам.
- Проводить регулярные аудиты и пентесты.
-
Default credentials — использование стандартных учетных данных для доступа к базам данных. Часто такие данные остаются в системе после первоначальной настройки.
Что позволяет злоумышленнику:
- Получить полный доступ к базе данных.
- Изменить или удалить данные.
- Развить дальнейшую атаку в сети.
Как предотвратить:
- Менять дефолтные учетные данные сразу после установки.
- Применять сложные пароли и системы управления паролями.
- Внедрить многофакторную аутентификацию для администраторов.
- Регулярно обновлять компоненты с известными уязвимостями.
-
Несанкционированный доступ к кластеру 1С. Уязвимость, при которой злоумышленник может обойти механизмы аутентификации.
Что позволяет злоумышленнику:
- Извлечь конфиденциальные данные, включая настройки кластера и данные пользователей.
- Получить доступ с правами администратора.
- Скомпрометировать безопасность всей системы, нарушив нормальную работу бизнес‑процессов.
Как предотвратить:
- Ввести строгую аутентификацию и контроль доступа.
- Регулярно обновлять системы и настройки безопасности.
- Защищать коммуникации с помощью шифрования.
Более подробно о методах обнаружения подобных атак мы рассказывали в нашем исследовании.
Отдельно выделили уязвимости, которые встречались в отраслях:
-
IT и SaaS
Уязвимости:
- SQL‑инъекция. Часто встречается в веб‑приложениях, где неконтролируемые данные передаются в запросы к базе данных. Может привести к утечке, изменению данных или полной компрометации системы.
- PostgreSQL weak password. Внутренний доступ к базам данных с использованием слабых или дефолтных паролей позволяет злоумышленнику получить полный контроль над критичной информацией.
Как их предотвратить:
- Проверить корректность прав доступа в СУБД.
- Внедрить шифрование данных и хеширование паролей.
- Регулярно обновлять компоненты для предотвращения известных уязвимостей.
-
Финансы
Уязвимости:
- ADCS ЕSC.
- XSS. Позволяет манипулировать веб‑формами и внедрять скрипты для выполнения вредоносных операций через клиента.
Как их предотвратить:
- Проверить настройки и политики доступа в Active Directory для предотвращения утечек через уязвимости в сертификатах.
- Оценить эффективность многофакторной аутентификации и средств мониторинга.
- Проверить безопасность серверов баз данных и приложений для защиты от утечек через API и веб‑приложения.
-
Услуги
Уязвимости:
- Брутфорс. Атака путем перебора паролей от учетных записей сотрудников и клиентов с целью получить доступ. В сфере услуг часто эксплуатируется через публичные порталы самообслуживания, личные кабинеты и системы бронирования, если у них нет механизмов защиты от автоматизированного подбора.
- Broken access control.
Как их предотвратить:
- Ограничить количество неудачных попыток входа с введением задержек и капчи.
- Внедрить многофакторную аутентификацию для всех пользователей.
- Строго контролировать доступ с проверкой принадлежности объектов текущему пользователю.
- Регулярно проводить аудит прав доступа, применять принцип минимальных привилегий.
- Логировать и мониторить подозрительной активности.
Более подробно о методах обнаружения подобных атак мы рассказывали в нашем исследовании.
Вот список базовых правил для организаций, которые заботятся о своей безопасности:
- Использование принципа наименьших привилегий. Применяйте минимальные права доступа (least privilege) для всех пользователей и приложений внутри сети, чтобы снизить риски от компрометации.
- Мониторинг и аудит безопасности. Настройте их, чтобы отслеживать подозрительную активность в сети и своевременно реагировать на угрозы.
- Регулярная проверка прав доступа. Убедитесь, что пользователи имеют доступ только к необходимым для работы ресурсам.
- Защита внутренних данных и конфиденциальности. Не хранить пароли в открытом виде.
- Проверка на уязвимости в Active Directory и других критичных системах. Проводите тесты для предотвращения проникновения злоумышленников.
В сравнении с прошедшим отчетным периодом уязвимостей критического уровня стало на 2% больше, а высокого — на 3%, что, скорее всего, является погрешностью выборки. Количество уязвимостей среднего уровня уменьшилось на 9%, причина — небольшой рост во всех остальных классах критичностей.
Мы находили следующие угрозы:
-
SQL‑инъекция. Возникает из‑за недостаточной фильтрации входных данных. Это позволяет атакующему модифицировать SQL‑запросы и манипулировать данными в базе.
Что позволяет злоумышленнику:
- Получить доступ к базе данных компании и конфиденциальной информации.
- Изменить, удалить или украсть данные.
- Получить права администратора.
- Выполнить произвольные команды на сервере.
Как предотвратить:
- Использовать подготовленные выражения (prepared statements) для обработки входных данных.
- Валидировать и фильтровать пользовательские данные.
- Применять принцип наименьших привилегий в доступах к базе данных.
- Регулярно обновлять программное обеспечение и использовать патчи для устранения известных уязвимостей.
-
Использование слабых или легко угадываемых паролей. Это значительно повышает вероятность успешной атаки (подбора пароля).
Что позволяет злоумышленнику:
- Извлечь учетные данные, включая пароли пользователей и администраторов.
- Использовать полученные данные для выполнения несанкционированных действий (изменение настроек, кража данных и т. д.).
- Получить доступ к системе и использовать учетные записи для проведения дальнейших атак.
Как предотвратить:
- Внедрить политику сильных паролей.
- Использовать многофакторную аутентификацию пользователей.
- Регулярно проверять и обновлять учетные данные.
-
Использование устаревших или уязвимых компонентов, библиотек и фреймворков. Это может привести к эксплуатации уже известных уязвимостей, которые не были устранены.
Что позволяет злоумышленнику:
- Использовать уязвимости в сторонних компонентах для выполнения произвольного кода на сервере.
- Получить доступ к конфиденциальным данным и системным настройкам.
- Скомпрометировать целостность системы и вызвать ее сбои или отказ в обслуживании (DoS).
Как предотвратить:
- Регулярно обновлять компоненты и библиотеки.
- Использовать системы управления уязвимостями для мониторинга безопасности.
Выделили уязвимости, которые нашли в компаниях из следующих отраслей:
-
IT и SaaS
Уязвимости:
- Sensitive data exposure.
- Broken access сontrol.
- Брутфорс.
Как их предотвратить:
- Надежно шифровать данные.
- Внедрить многофакторную аутентификацию для всех публичных сервисов.
- Проводить регулярный аудит прав доступа, применять принцип минимальных привилегий.
- Логировать и мониторить попытки получить несанкционированный доступ или провести брутфорс‑атаку.
-
Финансовый сектор
Уязвимости:
- SMTP user enumeration — перечисление пользователей по протоколу SMTP. Позволяет через систему определить, существует ли учетная запись на почтовом сервере. Используется для подготовки целевых атак.
- Утечки информации. Сюда включаются скрытые сообщения об ошибках, раскрывающие важные данные или пути к конфиденциальной информации.
- SQL‑инъекции.
Как их предотвратить:
- Показывать одинаковые сообщения об ошибках для всех запросов (исключение — перечисления пользователей).
- Ограничить число неудачных попыток входа с введением задержек.
- Реализовать многофакторную аутентификация для всех пользователей, особенно с привилегированным доступом.
- Ввести строгую валидацию входных данных с использованием prepared statements или ORM‑библиотек.
- Проводить регулярные пентесты веб‑приложений, централизованный мониторинг безопасности.
- Шифровать чувствительные данные в транзите и в покое.
- Внедрить средств защиты от фишинга и социальной инженерии.
-
Медиа
Уязвимости:
- Reflected XSS. Вредоносный код внедряется в URL или параметры запроса и исполняется в браузере жертвы. Часто эксплуатируется через ссылки в комментариях, формы поиска и редиректы на медиаресурсах.
- SMTP user enumeration.
- Mass asignmen. Позволяет массово изменять атрибуты модели (права доступа, роль пользователя, статус публикации) путем передачи неожиданных параметров в запросах. Особенно актуальна для платформ с пользовательским контентом и системами комментирования.
Как их предотвратить:
- Внедрить строгую валидацию, а также экранирование пользовательского ввода.
- Ввести Content Security Policy (CSP).
- Показывать одинаковые сообщения об ошибках для исключения перечисления пользователей.
- Указывать разрешенные атрибуты при массовом присвоении (allowlist).
- Подключить многофакторную аутентификацию для учетных записей сотрудников.
Что нужно сделать в первую очередь:
- Использование многофакторной аутентификации. Внедрите для всех публичных сервисов и учетных записей с высокими правами доступа.
- Регулярные обновления и патчи. Вовремя обновляйте ПО и устраняйте известные уязвимости.
- Контроль внешнего периметра. Используйте системы класса EASM.
- Безопасная разработка (SSDLC). Применяйте практики безопасной разработки. Чем раньше уязвимость будет найдена, тем дешевле ее исправить.
- Проведение пентестов и проверок кода (AppSec). Регулярно проводите с учетом стандартов безопасности приложений для выявления уязвимостей на ранних стадиях разработки и эксплуатации.
Относительно результатов прошлого анализа ситуация не изменилась. Причина в отсутствии глобальных технических изменений в мобильной разработке. Растет уровень зрелости приложений, а потому более серьезные уязвимости встречаются все реже.
В этом отчетном периоде чаще всего находили ошибку race condition (состояние гонки). Еще часто встречаются уязвимые механизмы локальной аутентификации и слабые механизмы защиты на клиенте, в числе которых обфускация, проверка кастомных прошивок, защита от инструментации и т. д.
Мобильные приложения стали популярной мишенью для атак — именно в них пользователи сегодня ведут переписку, хранят личные сведения и переводят средства.
Выделили три наиболее опасные уязвимости:
-
Race condition
Что позволяет злоумышленнику: манипулировать процессами, которые выполняются одновременно, но не синхронизированы должным образом. Как следствие — получить несанкционированный доступ к защищенным объектам, изменить или повредить данные, обойти защитные механизмы системы.
Как предотвратить:
- Использовать корректные механизмы синхронизации и блокировок.
- Тестировать приложение на устойчивость к гонкам (race testing).
-
Возможность брутфорс‑атак на локальную аутентификацию
Что позволяет злоумышленнику: извлечь учетные данные, получить несанкционированный доступ к системе и полный контроль над локальной учетной записью, включая выполнение вредоносных действий.
Как предотвратить:
- Ограничить количество попыток ввода пароля.
- Использовать CAPTCHA и другие механизмы защиты от автоматических атак.
- Внедрить многофакторную аутентификацию.
-
Missing runtime app signature verification — отсутствие проверки цифровой подписи приложения во время работы (выполнения)
Что позволяет злоумышленнику: установить модифицированное приложение для обхода системы безопасности, изменить функциональность приложения для доступа к защищенным данным.
Как предотвратить:
- Внедрить проверку подписи приложения на runtime.
- Обфусцировать код для усложнения реверс‑инжиниринга.
- Использовать защиту от вредоносных модификаций.
- Интегрировать проверку целостности файлов.
Финансовому сектору, IT и сфере услуг нужно обратить особое внимание на следующие уязвимости:
-
Финансы
Уязвимость: missing runtime app signature verification
Как предотвратить:
- Проверять подписи на runtime для предотвращения несанкционированных изменений в приложении.
- Внедрить многоуровневую аутентификацию и шифрование данных для защиты транзакций и конфиденциальной информации.
- Использовать сертифицированные методы защиты в приложении, чтобы гарантировать защиту от подмены кода.
-
IT и SaaS
Уязвимость: application allows you to set a weak PIN code — приложение, которое позволяет пользователям устанавливать слишком слабые ПИН‑коды. Их легко угадать (например, 1234 или 0000), что повышает риск несанкционированного доступа к личной информации или аккаунтам.
Как предотвратить:
- Установить требования к сложности ПИН‑кода, например минимальную длину.
- Внедрить многофакторную аутентификацию для защиты ключевых операций в приложении.
- Шифровать все данные, передаваемые через приложение, для их защиты от перехвата.
-
Услуги
Уязвимость: missing brute force protection — отсутствие защиты от брутфорс‑атак. Приложение не ограничивает количество попыток входа с неверными паролями или PIN‑кодами. Это позволяет злоумышленникам многократно пробовать различные комбинации данных для доступа к учетной записи.
Как предотвратить:
- Ввести защиту от брутфорса: ограничить количество попыток входа и временно блокировать пользователя, если несколько попыток подряд были неудачными.
- Настроить многофакторную аутентификацию для защиты от несанкционированного доступа.
- Использовать рекапчу или аналогичные решения для защиты от автоматизированных атак.
Главные инструменты для защиты мобильных приложений от злоумышленников:
- Шифрование данных. Обеспечьте шифрование, а также хеширование всех конфиденциальных данных в процессе их передачи и при хранении на устройстве.
- Многофакторная аутентификация. Защитите учетные записи, особенно в приложениях, где хранятся чувствительные данные пользователей.
- Обфускация кода. Применяйте для защиты от реверс‑инжиниринга и модификации кода приложения.
- Проверка подписи приложения на runtime. Убедитесь, что приложение не было изменено после установки.
- Безопасное хранение данных. Храните чувствительные данные только в защищенных хранилищах (например, Keychain на iOS или Keystore на Android).
Относительно прошлого отчетного периода количество уязвимостей критического уровня снизилось на 5%, а высокого — на 4%. При этом число уязвимостей среднего уровня выросло на 8%.
Багбаунти и SSDLC все больше проникают во внутренние процессы компаний по управлению уязвимостями. Как следствие, с 2025 по 2026 год количество уязвимостей на одно приложение в среднем уменьшилось на 15% по сравнению с предыдущим отчетным периодом.
Веб‑приложения, как и их мобильные версии, обрабатывают конфиденциальную информацию пользователей, например личные данные, учетные записи и финансовые транзакции. Эти сведения — желанная цель злоумышленников.
На какие возможные бреши в защите стоит обратить внимание:
-
Broken access control
Что позволяет злоумышленнику:
- Получить доступ к данным или объектам других пользователей, которые должны быть защищены.
- Изменить, удалить или украсть данные, не имея на это прав доступа.
- Скомпрометировать конфиденциальность информации и целостность системы.
Как предотвратить:
- Внедрить контроль доступа на уровне объектов.
- Реализовать контроль за ролевой моделью.
- Проверить права доступа для всех параметров запроса.
- Использовать уникальные идентификаторы, недоступные для манипуляции.
-
Account takeover — угон аккаунта
Что позволяет злоумышленнику:
- Захватить учетную запись пользователя или администратора.
- Использовать ее для проведения несанкционированных действий.
- Скомпрометировать безопасность всей системы: украсть данные, установить вредоносное ПО.
Как предотвратить:
- Внедрить многофакторную аутентификацию.
- Мониторить аномальные действия с учетными записями.
- Использовать сильные пароли и регулярно их менять.
-
XSS
Что позволяет злоумышленнику:
- Выполнить произвольный код на стороне клиента.
- Украсть cookie‑файлы, перехватить сессию.
- Внедрить вредоносный код для внешнего управления сервером.
Как предотвратить:
- Проверять и фильтровать входные данные, чтобы предотвратить внедрение нежелательных скриптов.
- Применять Content Security Policy (CSP) для защиты от исполнения нежелательных скриптов в браузере.
- Экранировать все пользовательские данные, выводимые на веб‑страницах.
Наиболее уязвимыми отраслями являются:
-
Финансы
Уязвимости:
- Broken access control leading to privilege escalation — нарушение контроля доступа, ведущее к повышению привилегий. Возникает, когда неправильная настройка системы управления доступом позволяет злоумышленникам получить допуск к функциям, на которые у них не должны быть прав. В финансовых приложениях это может привести получению доступа к счетам или административным правам.
- Multiple broken access control — множественные нарушения управления доступом. Если система имеет несколько слабых точек в контроле доступа, с их помощью злоумышленник может скомпрометировать всю инфраструктуру безопасности.
- Server‑side request forgery (SSRF) — подделка запроса со стороны сервера. Позволяет заставить сервер выполнить запросы к другим ресурсам внутри или за пределами сети. Может использоваться злоумышленниками, чтобы обойти межсетевые экраны, атаковать внутренние системы или получить доступ к конфиденциальным данным.
Как их предотвратить:
- Ввести строгие правила контроля доступа на основе ролей (RBAC).
- Регулярно проводить аудиты безопасности и проверки конфигурации системы.
- Фильтровать запросы и ограничить внутренние ресурсы для защиты от SSRF‑атак.
-
Услуги
Уязвимости:
- XSS leading to RCE — межсайтовый скриптинг, приводящий к удаленному исполнению кода. Крайне опасна: позволяет злоумышленникам внедрить вредоносный JavaScript‑код в веб‑приложение. В результате RCE может выполниться произвольный код. Это дает атакующему выполнять команды на сервере.
- Broken access control. Может привести к утечке конфиденциальных данных и уязвимостям на более высоких уровнях системы.
- User enumeration — перечисление пользователей. Позволяет определить, существует ли учетная запись в системе. Может использоваться для брутфорс‑атак и фишинга.
Как их предотвратить:
- Фильтровать и экранировать данные для предотвращения XSS.
- Проверять настройки контроля доступа и защиты всех ресурсов от несанкционированного доступа.
- Ограничить попытки входа и ввести стандартные сообщения об ошибках.
-
IT и SaaS
Уязвимости:
- Missing rate limiting — отсутствие ограничений на количество запросов. Позволяет проводить брутфорс или DDoS‑атаки.
- Hiding impersonate from the end user — скрытие факта имперсонации от конечного пользователя. Уязвимость, при которой приложение скрывает или неправильно отображает, когда пользователь или администратор выполняет действия от имени другого пользователя. Может привести к фальсификации действий или маскировке атак.
- Stored XSS — хранимый межсайтовый скриптинг. В отличие от XSS, где скрипты выполняются в ответ на действия пользователя, эта уязвимость сохраняет вредоносный код в базе данных. Это приводит к тому, что код выполняется при каждой загрузке страницы. Может привести к серьезной утечке данных и компрометации серверов.
Как их предотвратить:
- Ввести ограничение для запросов (rate limiting).
- Применять обработку пользовательского ввода и регистрировать действия для предотвращения использования аккаунтов.
- Использовать Content Security Policy (CSP), регулярно очищать данные на стороне клиента и сервера.
Снизить риски успешной атаки помогает:
- Использование защиты от SQL‑инъекций. Применяйте подготовленные выражения (prepared statements) и ORM‑библиотеки.
- Регулярное обновление компонентов и библиотек. Это необходимо для устранения уязвимостей и обеспечения безопасности.
- Безопасная разработка (SSDLC). Применяйте практики безопасной разработки. Чем раньше уязвимость будет найдена, тем дешевле ее исправить.
- Защита от атак XSS и CSRF. Внедрите защиту от межсайтовых скриптовых атак (XSS) и межсайтовых подделок запросов (CSRF), используя безопасные методы валидации и фильтрации данных.
- Мониторинг и анализ безопасности веб‑приложений. Регулярно проводите анализ и настройте системы мониторинга для отслеживания аномальной активности в приложении.
Начальными точками проникновения, как и в прошлый период, остаются уязвимые сервисы на внешнем периметре, мисконфигурации при настройке Wi‑Fi, фишинг и физический доступ в офис.
Симуляции атак на цепочки поставок и атак с физическим доступом становятся популярнее. При этом общий процент достигнутых нами в рамках red teaming целей снизился, потому что бизнес стал лучше понимать риски и глубже их прорабатывать.
Выделили главные закономерности:
-
Проекты стали занимать больше времени, а векторы проводимых работ усложнились
Компании хотят проводить более комплексные работы по различным моделям злоумышленников. Ранее модели обычно включали только внешнего злоумышленника с целями внутри. Теперь заказчикам также интересны более специфичные сценарии: внутренние злоумышленники с различными правами доступа (инсайдеры), атака на цепочку поставок через дочерние и связанные организации, внешние партнеры с различными интеграциями.
Цели проводимых работ стали более точечными, теперь они направлены на бизнес‑риски. Так как модели злоумышленников сильно отличаются, для каждой из них составляются свои списки. В 90% проектов необходимо было достигнуть уникальные для конкретной компании цели.
-
Изменения в регуляторных требованиях стимулируют спрос на red team — проекты
В 2025‑м Минцифры РФ утвердило к Указу Президента РФ № 250 новое типовое ТЗ на выполнение работ по оценке уровня защищенности информационной инфраструктуры. В нем уточнились обязательные модели злоумышленника: теперь это внешний и внутренний нарушитель с более четкими требованиями к минимальному необходимому набору проверок. Кроме того, появились требования к анализу защищенности AI‑моделей. Подробный разбор изменений в подходе регуляторов — в записи вебинара «Указ Президента РФ № 250: от отчетов к реальной защите».
В 93% проектовполучали доступ во внутреннюю сеть или повышали привилегии внутри системыВ 85% проектоввыполняли цель или полностью компрометировали системы, важные бизнесу -
Бизнес использует множество решений для кибербезопасности, но в его сетях много слепых зон
На участках инфраструктуры разработки нас обычно не обнаруживали — там удавалось закрепиться и развить атаку.
Нас находили при активных действиях во внутренней сети, но часто слишком медленно. Это позволяло успешно провести атаку и достичь поставленные цели до того, как команда защиты примет меры.
2 часав среднем нужно нашей команде, чтобы попасть в сеть компании через атаку на Wi‑Fi2 неделизанимает преодоление внешнего периметра через уязвимости в сервисах и приложениях -
Переход на отечественное ПО
Сфера разработки отечественного ПО продолжает активно развиваться. С июля 2025‑го по июль 2026 года мы эксплуатировали множество российских продуктов на внешнем и внутреннем периметре. В рамках red team — проектов мы все чаще исследуем их как часть реальной инфраструктуры компании. Найденные уязвимости помогают не только достигать целей проекта, но и повышать безопасность отечественных решений для кибербезопасности.
Чаще всего red team — проекты проводились в финансовой, промышленной и медийной отраслях. Для них характерна высокая критичность бизнес‑процессов, зрелая функция кибербезопасности и потребность не только находить уязвимости, но и проверять, насколько компания способна обнаружить, сдержать и остановить целенаправленную атаку.
-
Финансы
Этот сектор — один из самых зрелых и регулируемых. Финансовые компании постоянно инвестируют в защиту, мониторинг и реагирование. Для них red teaming — способ комплексно проверить, насколько их службы SOC/IR способны обнаружить и отразить реальную целевую атаку.
-
Промышленность
У промышленных компаний часто сложная распределенная инфраструктура, много дочерних организаций, технологических сегментов и подрядчиков. Red teaming помогает оценить, как атака может развиваться между сегментами и какие риски возникают из‑за связности инфраструктуры.
-
Медиа
Организации из этого сектора отличаются высокой чувствительностью к компрометации информации, доступов и публичных каналов коммуникации. Последствия атаки могут нанести ущерб не только IT‑инфраструктуре, но и репутации, например из‑за утечки, подмены контента, нарушения работы редакционных и цифровых сервисов.
- Мониторинг угроз. Покрывайте мониторингом все критичные зоны инфраструктуры, включая внешние сервисы, внутренние сегменты, привилегированные учетные записи и средства удаленного доступа.
- Регулярные учения по реагированию на угрозы. Отрабатывайте сценарии: во многих red team — проектах активность команды замечали, но не успевали быстро предпринять действия для защиты. В итоге атакующий успевал достичь бизнес‑цели.
- Тестирование командного взаимодействия. Проверяйте не только технологии, но и процессы: эскалацию инцидентов, взаимодействие команд SOC, IT и кибербезопасности, владельцев систем.
- Комплексный подход. Выполняйте рекомендации по внешнему и внутреннему периметру вместе: отдельные уязвимости редко критичны сами по себе, но в цепочке могут привести к реализации сценария атаки.
В период с 2025 по 2026 год критический уровень получили уязвимости, которые невозможно исправить, потому что они обнаружены в масочной памяти SoC или на уровне аппаратной реализации (fault‑injection‑атаки, атаки по сторонним каналам).
К критическим мы также отнесли уязвимости, которые требуют модификации печатной платы устройства, административных мер (например, ограничения физического доступа) и т. д.
В процентном отношении количество таких уязвимостей небольшое, но популярность SoC, в которых они были обнаружены, позволяет злоумышленникам атаковать множество устройств, выполненных на их базе. Стоит отметить, что сложность эксплуатации подобных уязвимостей требует от атакующих высокого уровня подготовки.
За период с июля 2025‑го по июль 2026 года мы выполнили несколько десятков проектов, а также исследовали разные классы устройств и встраиваемых систем. Ниже — наши основные наблюдения.
-
Рост спроса на оценку уровня защищенности отечественных устройств
Ужесточение требований к переходу на отечественное ПО и доверенные программно‑аппаратные комплексы (ПАК) для объектов КИИ стимулирует спрос на российские решения. Однако в основе большинства таких продуктов — зарубежные микроконтроллеры. Как правило, отечественные производители устройств самостоятельно разрабатывают высокоуровневое ПО, а низкоуровневые загрузчики поставляются производителями микроконтроллеров в виде бинарных, а не исходных кодов. Это усложняет аудит и внесение изменений в случае необходимости. Поэтому вместе со спросом на российские решения растет и спрос на проверку наличия недокументированных возможностей и комплексную оценку уровня защищенности.
-
Смещение безопасности на ранние этапы разработки и внедрение secure by design
Все больше производителей встраиваемых систем выбирают подход secure by design — рассматривают вопросы кибербезопасности не как отдельный этап после выпуска устройства, а как обязательную часть проектирования. Если раньше оценка уровня защищенности чаще проводилась уже для готовых устройств, находящихся в продаже, то сегодня все чаще запрос на анализ возникает значительно раньше — на стадии технического задания, проектирования или разработки прототипов.
Этот сдвиг отражает повышение зрелости рынка: производители стремятся заранее учитывать требования к защите данных, доверенной загрузке, обновлению, физической безопасности и устойчивости к аппаратным и программным атакам. В результате кибербезопасность становится встроенным элементом инженерного процесса, влияющим на архитектуру устройства, выбор компонентов и модель жизненного цикла продукта.
-
Производители стали чаще задумываться о защите интеллектуальной собственности
Производители встраиваемых систем уделяют внимание не только общей устойчивости устройства к атакам, но и защите самого программного кода, который на нем выполняется. Это связано с тем, что многие компании разрабатывают собственные алгоритмы обработки данных, уникальные модели искусственного интеллекта, специализированную логику управления и другие программные компоненты, представляющие собой ценную интеллектуальную собственность.
В таких условиях растет спрос на проверку корректности реализации механизмов защиты кода и данных, включая защиту от несанкционированного чтения, извлечения, модификации и анализа исполняемых компонентов. Для производителей критически важно исключить ситуации, при которых злоумышленник сможет получить доступ к внутренней логике работы устройства, восстановить алгоритмы, извлечь модель или использовать полученные сведения для копирования решения.
-
Снижение порога входа в аппаратные атаки
Аппаратные атаки на встраиваемые системы перестают быть областью, доступной исключительно специализированным лабораториям и государственным структурам. Причины — снижение стоимости отладочного и измерительного оборудования, распространение открытых аппаратных платформ, развитие инструментов реверс‑инжиниринга и публикация методик исследований.
Сегодня для анализа устройства, извлечения содержимого памяти, исследования интерфейсов отладки или поиска уязвимостей в механизмах защиты не обязательно иметь уникальное дорогостоящее оборудование. В результате расширяется круг потенциальных нарушителей, способных проводить атаки с физическим доступом к устройству. Например, извлечение прошивки, анализ механизмов доверенной загрузки, вмешательство в процесс обновления и исследование защищенных областей памяти.
Разберем слабые места киберзащиты, которые чаще всего встречались в практике за последний год. Мы не привязываем уязвимости к конкретным типам устройств: такие проблемы могут встречаться в разных классах оборудования, например в сетевых устройствах, системах контроля доступа, видеонаблюдении, промышленных контроллерах, терминалах, датчиках, IoT‑ и IIoT‑устройствах.
-
Переполнение буфера (на стеке, в куче). Уязвимость, при которой программа некорректно обрабатывает данные от пользователя, из‑за чего злоумышленник может нарушить работу устройства или получить возможность выполнить свой код.
Возможности эксплуатации определяются тем, где расположен уязвимый код:
-
Масочная память. Что позволяет злоумышленнику:
- получить полный контроль над устройством в обход встроенных механизмов защиты;
- нарушить цепочку доверия устройства целиком;
- выполнить код с максимальным уровнем привилегий;
- извлечь с устройства критичные данные пользователя;
- подменить прошивку.
Механизмы защиты по типу рандомизации базового адреса (ASLR, KSLR) здесь не применимы.
-
Загрузчики. Что позволяет злоумышленнику: выполнить код с чуть меньшим уровнем привилегий, чем на уровне масочной памяти. При этом ущерб может быть сравним с предыдущим уровнем. ASLR, KSLR здесь также не работают. Загрузчиков может быть несколько.
-
ОС. Что позволяет злоумышленнику: получить непривилегированным приложениям доступ к памяти более привилегированных или повысить права до root.
-
Приложения. Что позволяет злоумышленнику: провести атаку на отказ в обслуживании некоторых из запущенных сервисов. Может быть критичной для заказчика.
Как предотвратить:
- Внимательно изучать предупреждения, выдаваемые компилятором.
- Проводить фаззинг‑тестирование.
- Выполнять независимый аудит безопасности устройств.
- Своевременно отслеживать и применять выпускаемые производителем обновления безопасности.
-
-
Ошибки в проверке целостности прошивки. Из‑за такой уязвимости устройство может принять измененную прошивку как легитимную, что позволяет обойти механизм безопасной загрузки и запустить недоверенный код.
Возможности эксплуатации определяются тем, где расположен уязвимый код:
-
Масочная память. Что позволяет злоумышленнику:
- Получить полный контроль над устройством в обход встроенных механизмов защиты.
- Нарушить цепочку доверия устройства целиком.
- Выполнить код с максимальным уровнем привилегий.
- Извлечь с устройства критичные данные пользователя.
- Подменить прошивку.
-
Загрузчики. Что позволяет злоумышленнику:
- Выполнить код с чуть меньшим уровнем привилегий, но при этом ущерб может быть сравним с предыдущим уровнем.
- Незаметно для пользователя встроить злонамеренный код на одном из этапов цепочки поставок.
Как предотвратить:
- Выполнять независимый аудит безопасности устройств.
- Своевременно отслеживать и применять выпускаемые производителем обновления безопасности.
- Проводить фаззинг‑тестирование.
-
-
Некорректные права доступа. Чем больше у процесса прав, которые не требуются для его нормальной работы, тем безопасность ниже. Такой недостаток может привести к изменению файлов, получению доступа или компрометации устройства. Возможность доступа в определенные каталоги (на чтение или запись) для непривилегированных пользователей (например, shell) также может позволить скомпрометировать устройство.
Что позволяет злоумышленнику:
- Выполнить код с высокими привилегиями при обнаружении уязвимости.
- Выдать права на исполнение скриптам и другим бинарным файлам на USB‑накопителе, если права в fstab настроены некорректно.
- Модифицировать конфигурационные файлы.
- Считывать критические данные пользователя.
Как предотвратить:
- Использовать SELinux, AppArmor и другие системы контроля прав доступа.
- Выдавать только минимально необходимые права для работы сервисов.
- Отключить ненужные службы.
-
Автоматически исполняемые скрипты. Уязвимость возникает, если устройство может автоматически выполнить команды с подключенного USB‑носителя без достаточных проверок.
Что позволяет злоумышленнику: скомпрометировать безопасность устройства через исполнение недоверенного кода.
Как предотвратить:
- Внимательно изучать логи загрузки устройства на предмет поиска недокументированных скриптов на подключенных носителях.
- Выполнять независимый аудит безопасности устройств.
-
Включенные, неотключаемые или незаблокированные отладочные интерфейсы. Дают воздействовать на встроенные механизмы защиты устройства.
Что позволяет злоумышленнику:
- Физически подключиться к оставленным включенными механизмам отладки и чтения логов, таких как JTAG, SWD, UART, ADB и т. д.
- Получить доступ к памяти запущенных процессов с любым уровнем привилегий.
- Обойти встроенные механизмы безопасности.
- Выполнить собственный код.
- Извлечь критичные данные, в том числе пользовательские.
Как предотвратить: выключить на релизных устройствах любые отладочные интерфейсы, встроенные в управляющий чип.
Встраиваемые системы во многом наследуют те же проблемы безопасности, что и традиционное программное обеспечение: ошибки управления памятью, недостатки проверки входных данных, уязвимости в механизмах аутентификации и логические ошибки встречаются как в прикладном ПО, так и в прошивках устройств. Однако последствия их эксплуатации зачастую оказываются значительно серьезнее.
Если уязвимость находится в низкоуровневых компонентах, устранить ее без замены аппаратной платформы крайне сложно или вовсе невозможно. Ошибки, допущенные на ранних этапах разработки встраиваемых систем, могут сопровождать устройство на протяжении всего жизненного цикла и создавать долгосрочные риски для производителей и пользователей.
Комплексный анализ защищенности — необходимый инструмент управления рисками на протяжении всего жизненного цикла устройства. Проведение оценки безопасности до вывода продукта на рынок позволяет своевременно выявить критические недостатки архитектуры, прошивки и аппаратной платформы, исправлять которые после начала эксплуатации многократно дороже.
Не менее важен и анализ уже выпускаемых устройств. Развитие методов атак, обнаружение новых уязвимостей и появление новых инструментов исследования требуют регулярной переоценки уровня защищенности, чтобы своевременно выявлять риски и принимать меры по их минимизации.
-
Периодическое тестирование на проникновение
- Проводите не реже одного раза в год, особенно после крупных изменений в инфраструктуре или внедрения новых технологий. Это поможет выявить новые уязвимости и проактивно снизить риски.
- Тестируйте и внешнюю, и внутреннюю инфраструктуру. Важно учитывать как уязвимости, исходящие из интернета, так и внутренние угрозы, возникающие при недостаточной защите сети и данных.
-
Использование лучших практик безопасности в процессе разработки
- Включите тестирования на проникновение в цепочку CI/CD. Это помогает обнаружить уязвимости на ранних стадиях и минимизировать риски, связанные с их эксплуатацией в продуктивной среде.
- Обучайте IT‑команду безопасной разработке и принципам защищенного кода, а также работе с инструментами статического и динамического анализа безопасности для регулярной проверки на уязвимости.
-
Мониторинг и реагирование на инциденты
- Убедитесь, что системы мониторинга безопасности настроены для выявления аномальной активности и вторжений в реальном времени. Быстрая реакция на инциденты помогает минимизировать ущерб от успешных атак.
- Регулярно обновляйте правила обнаружения угроз и проверяйте эффективность защиты с использованием тестов на проникновение и других методов анализа.
-
Обновление и патч‑менеджмент
- Применяйте план обновлений и патчей для всех компонентов системы, включая операционные системы, серверы, приложения и сторонние библиотеки. Обеспечьте быструю реакцию на новые уязвимости и своевременное обновление всех критичных компонентов.
- Автоматизируйте патч‑менеджмент. Это поможет оперативно реагировать на угрозы и уменьшить временные окна для возможных атак.
-
Обучение и повышение осведомленности сотрудников
- Организуйте регулярные тренинги по кибербезопасности для сотрудников из всех отделов, чтобы они могли эффективно выявлять и предотвращать угрозы, например фишинг и атаки с использованием методов социальной инженерии.
- Включите в обучение пользователей основы безопасного использования паролей, правильную настройку аутентификации и защиты данных.
-
Управление уязвимостями
- Внедрите регулярные аудиты и оценку уязвимостей в используемых технологиях.
- Проводите классификацию уязвимостей по степени опасности и рискам для бизнеса. Это позволит правильно расставить приоритеты и уделить внимание наиболее критичным проблемам.
-
Защита AI‑моделей
- Внедрите AI observability и AI‑фаервол. Контролируйте загрузку данных в сторонние SaaS‑решения с AI. Это необходимо для предотвращения утечек коммерческой тайны, защиты интеллектуальной собственности и обеспечения соответствия нормативным требованиям (комплаенсу).
- Обратите внимание на API конечных точек, которые используются в приложении для взаимодействия с AI. Защитите AI‑эндпоинты авторизацией и настройте валидацию входящих данных.
Итоги проектов за отчетный период показывают, что фундамент ландшафта киберугроз не изменился. Существенные последствия для бизнеса по‑прежнему возникают не из‑за принципиально новых техник, а из‑за сочетания известных инфраструктурных и организационных недостатков: слабой сегментации, ошибок конфигурации, уязвимостей приложений, избыточных привилегий и недостаточной зрелости процессов безопасной разработки.
Компании стали уделять больше внимания базовым мерам защиты. Однако ключевые риски по‑прежнему связаны не с количеством уязвимостей, а с возможностью их комбинированной эксплуатации. В большинстве проектов атака становилась успешной за счет цепочек уязвимостей, ошибок конфигурации и недостаточного контроля доступов. Поэтому киберустойчивость организации определяется не столько защищенностью отдельных систем, сколько качеством системного управления цифровыми рисками.
Конец 2025‑го и первая половина 2026 года обозначили изменение экономики противостояния между атакующими и защитниками. Распространение агентных AI‑систем и развитие агентных харнессов снижает стоимость автоматизации разведки, процесса поиска уязвимостей и построения сценариев атак. В кибербезопасности конкурентным преимуществом становится способность быстрее противника объединять автоматизацию и экспертные знания в единый непрерывный процесс принятия решений.
Отдельно отметим влияние AI на ландшафт кибербезопасности. Искусственный интеллект становится частью продуктов, внутренних сервисов и критически важных бизнес‑процессов. Это превращает его из инструмента повышения эффективности в самостоятельный объект управления рисками. Однако уязвимости моделей, а также их доступ к данным и инфраструктуре формируют новый класс угроз, который необходимо учитывать.
По состоянию на середину 2026 года AI не заменяет специалистов и не отменяет фундаментальные принципы построения защиты. В ближайшие годы преимущество получат организации, способные встроить искусственный интеллект в процессы управления цифровыми рисками и одновременно сохранить контроль над собственной AI‑инфраструктурой. Поэтому безопасность и применение AI для обеспечения безопасности становятся взаимосвязанными направлениями, значение которых будет расти в 2027 году.