AppSec 2025: тренды, которые будут популярны, и методы, которые уйдут в прошлое

К 2025 году безопасность приложений перестает быть просто технической необходимостью — она становится стратегическим приоритетом для бизнеса. С ростом облачных технологий, искусственного интеллекта ^[1] и постоянной автоматизации процессов эволюционируют и угрозы, а традиционные методы защиты не всегда эффективны. В этой статье мы обсудим тренды в AppSec, которые будут задавать тон в 2025 году, а также рассмотрим практики, которые утратят свою актуальность.

Статистика атак в 2024 году

Ежегодно наблюдается рост числа атак как на веб, так и на мобильные приложения. По исследованиям «Лаборатории Касперского» в 2024 году на 12% выросло количество атак, связанных с мобильными устройствами Android.

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

Наиболее популярными в прошлом году были следующие типы атак:

• атаки на бизнес-логику приложений: злоумышленники не просто эксплуатировали уязвимости, но и начали искать их в логике ^[2] приложений;

• атаки на цепочки поставок (supply chain атаки);

• атаки ботов: боты выполняют различные типы атак — брутфорс-атаки, DDoS-атаки, атаки на формы, SQL-инъекции и так далее;

• адресная работа по популярным ресурсам: злоумышленники не только рассылают спам, вирусы и так далее, но и выбирают наиболее интересные цели и на протяжении долгого времени начинают их прорабатывать;

• атаки с использованием искусственного интеллекта (ИИ): при разборе инцидентов искусственный интеллект способен разбирать по частям слабо защищенный API всего за пару часов.

Атаки в 2025 году

Что мы ожидаем в 2025 году?

1. Рост кибератак: злоумышленники умнеют, находят новые векторы атак, придумывают ранее не использованные способы взлома приложений.

2. Рост интереса ^[3] злоумышленников к мобильным приложениям за счет повсеместной цифровизации и мобильности как пользователей, так и сотрудников компании.

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

4. Использование API-интерфейсов для атак, так как разработчики, используя API, не уделяют внимания ^[4] безопасности этих интерфейсов, что создает дополнительный вектор атаки для злоумышленника.

5. Появление первых атак, нацеленных на большие языковые модели (LLM) или искусственные интеллекты, которые уже используются в бизнес-процессах компаний: искусственный интеллект находит широкое применение в разных сферах — в здравоохранении, финансах, производстве и многих других. В связи с этим растет и интерес злоумышленников к эксплуатации уязвимостей в этих системах.

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

Тренды в обеспечении безопасности приложений

Приложение с конструктивной безопасностью

Такие приложения изначально создаются с участием команды безопасности для выполнения требований безопасности.

На сегодняшний день рынок предлагает несколько решений для создания приложений с конструктивной безопасностью:

• Security API Gateway — встроенные непосредственно в приложение инструменты безопасности API. Решение объединяет в себе несколько функций: API-шлюз, фильтрацию трафика на разных уровнях, обработку DDoS и многое другое.

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

• Identity-based secrets management — встроенная в приложение система обеспечения безопасности конфиденциальной информации, такой как токены, пароли, ключи и так далее.

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

Тренды в области безопасной разработки

Повсеместно все чаще ИИ и машинное обучение ^[5] (ML) внедряется не только для атак, но и для защиты приложений. Искусственный интеллект используется в качестве ассистентов AppSec-инженеров.

Типы инструментов безопасной разработки увеличиваются с каждым годом. Решения класса «ASOC/ASPM» появляются в мире безопасной разработки для того, чтобы помочь централизованно управлять инструментами и обрабатывать те результаты, которые они выдают.

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

Цепочки поставок все чаще подвергаются атакам и требования к поставщикам ПО растут.

Постоянная цифровая трансформация приводит в облака, в K8s. Сложность этих систем не позволяет нанять молодого специалиста, быстро его обучить и через месяц считать, что это опытный специалист.

Сегодня мир ИБ стал понимать, что устранить все уязвимости невозможно, поэтому от служб ИБ требуется разработка новых методов приоритезации.

AI и ML в мире безопасности приложений

AI и ML уже сейчас могут помогать специалистам:

• LLM эксплуатирует известные уязвимости: по данным исследования 2024 года от Google ^[6] LLM делает это с 87% вероятностью успеха и самостоятельно может определить вектор эксплуатации;

• LLM помогает искать и приоритизировать уязвимости и дает советы по их устранению;

• ИИ помогает архитектору безопасности: компания Addepar проводила исследование ^[7] в 2024 году, в котором научили модель выделять из описания релиза ключевые нововведения и изменения; как результат — уменьшение количества запросов на внесение изменений в исходный код (pull requests), которые необходимо анализировать вручную;

• ИИ помогает создавать правила для обнаружения атак в процессе анализа защищенности, пишет и патчит код за разработчиков.

Цепочки поставок

На графике ниже показано количество зараженных пакетов ^[8], которое растет с каждым годом.

Один из показательных примеров произошел в апреле 2024 года. Инцидент был связан с пакетом XZ Utils — специальной Linux-утилитой для сжатия данных без потерь. Злоумышленник на протяжении нескольких лет сотрудничал с разработчиком, помогая в доработке этой Open Source утилиты. Через два года злоумышленника сделали совладельцам репозитория, после чего он на протяжении года вносил в утилиту вредоносное содержание. Затем утилита начала распространяться по различным альфа-версиям Linux-систем. Случайно сотрудник Microsoft заметил, что время обработки SSH-логина увеличилось на несколько секунд. В ходе расследования он выяснил, что утилита перехватывает ключи. После этого репозиторий и пакеты, конечно, удалили, но какой мог бы быть ущерб, если бы этого не заметил в дистрибутиве Linux сотрудник Microsoft? Если бы он этого не заметил, то оценить ущерб, наверное, сейчас было бы сложно.

Чего ожидать в 2025 году?

1. Ужесточение требований от крупных корпораций к подрядчикам: эксперты УЦСБ уже наблюдают такой тренд среди своих заказчиков.

2. Рост атак на небольшие компании разработчиков: взламывать крупные банки или огромные корпорации сложно, т.к. они имеют достаточно высокий уровень защищенности, а небольшие компании и поставщиков ПО взламывать намного проще.

3. Рост количества зависимостей, содержащих в себе критичные уязвимости.

4. Рост количества атак на публичные репозитории.

Облачные технологии и оркестраторы

Цифровая трансформация неизбежно настигнет каждого, cloud native приложения — это настоящее, но мало кто знает, как их безопасно использовать

Атаки на облака и Kubernetes (K8s) не станут основными в 2025 году, но ожидается рост их числа. Злоумышленники не просто эксплуатируют уязвимости в K8s или в облачных системах, а делают сложные многоступенчатые таргетированные атаки, связанные с эксплуатацией проблем конфигурации и комбинаций техник, направленных на цепочки поставок, краже учетных данных и так далее.

Поэтому ожидается рост интереса к российским системам оркестрации. Их главное преимущество — встроенные инструменты ИТ и ИБ, которые можно получить «из коробки».

Управление рисками

По статистическим данным ^[9] компании XM Cyber крупнейшие организации имеют более 250 000 уязвимостей, а устраняется из этого количества только 10%. Причем 75% из всех уязвимостей не ведут к другим активам компании и только 2% могут привести к критически важным активам.

Отказ от анализа только Common Vulnerability Scoring System (CVSS) и переход на методологию оценки комплекса условий позволит выстроить эффективную защиту. Поэтому для приоритезации исправления уязвимостей предлагаем пользоваться формулой:

Критичность актива * Поверхность атаки * Граф атаки * Отслеживание угроз в реальном времени

По полученному значению мы принимаем решение, идти ли сейчас устранять эту уязвимость или нет.

Для управления проблемами безопасности ПО используется класс решений «ASOC/ASPM». Они позволяют специалистам по безопасности приложений приоритизировать уязвимость и отправлять разработчикам на доработку наиболее критичные уязвимости.

Нормативные требования

На сегодняшний день уже принято несколько нормативных документов по безопасной разработке:

• ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования»;

• ГОСТ Р 71207-2024 «Защита информации. Разработка безопасного программного обеспечения. Статический анализ программного обеспечения. Общие требования»;

• ГОСТ Р 71206-2024 «Защита информации. Разработка безопасного программного обеспечения. Безопасный компилятор языков С/С++. Общие требования»;

• Приказ ФСТЭК России от 4 июля 2022 г. №118 «Требования по безопасности информации к средствам контейнеризации»;

• Приказ ФСТЭК России №239 от 25 декабря 2017 г. «Об утверждении требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» в части безопасности внедряемого прикладного ПО.

Анти-тренды: уйдут или будут пересмотрены

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

2. Традиционные решения ИБ: они плохо работают для облачных и оркестрационных систем. Все больше средств защиты встраиваются непосредственно в объект защиты.

3. Пассивное реагирование ^[10]: возрастающий объем атак требует от служб ИБ проактивных механизмов реагирования.

4. Один сканер для всего: нельзя установить только SAST, SCA или DAST-сканер и быть уверенным в безопасности своего приложения.

5. Разработка приложений без учета требований ИБ: безопасность — это такой же показатель качества, как и остальные, поэтому разработчики должны понимать, какие риски могут появиться в случае некачественного написания кода.

Таким образом, методы, полагающиеся на ручную проверку и изолированные процессы, уходят в прошлое, уступая место гибким, адаптивным подходам. Но остается очевидным, что будущее AppSec принадлежит тем, кто готов не просто защищаться, а предугадывать атаки и строить безопасность «по умолчанию».

Авторы:

Анастасия Камалова, пресейл-инженер направления безопасной разработки УЦСБ

Евгений Тодышев, руководитель направления безопасной разработки УЦСБ