Многоликий динамический анализ

BIS Journal №3(58)2025

3 октября, 2025

Многоликий динамический анализ

Дмитрий Пономарёв, замгендиректора — директор департамента внедрения и развития практик РБПО ООО НТЦ «Фобос-НТ», сотрудник ИСП РАН, преподаватель МГТУ им. Н. Э. Баумана ИУ10, модератор испытаний статических анализаторов исходного кода

Второй блок статей из серии «Три кита РБПО» посвящен технологиям и инструментам динамического анализа программного обеспечения. На первый взгляд интуитивно понятное определение «динамический анализ» на практике оказывается одним из самых «крепких орешков» при выборе подходов и инструментов динамических исследований программного обеспечения.

Определение их применимости и достаточности, в условиях ограниченности ресурсов (и кадров), с учетом необходимости выполнения регуляторных требований, является типовой задачей, регулярно решаемой как разработчиками ПО, так и специалистами в области ИБ и РБПО, в том числе сотрудниками испытательных лабораторий. В статье приведен обобщенный взгляд на существующие технологии динамического анализа (далее – ДА), требования и особенности их применения. Цель статьи – подготовить читателя к последующему знакомству с конкретными инструментами динамического анализа, помочь в определении их полезности и применимости.

Раздумывая несколько месяцев над наполнением статьи, я в очередной раз столкнулся с обозначенной в аннотации проблемой. Казалось бы тривиальный в понимании термин «динамический анализ», или, в соответствии с ГОСТ Р 56939-2024 [1] «динамический анализ кода программы», определяемый как «вид работ по инструментальному исследованию программы, основанный на анализе кода программы в режиме непосредственного исполнения (функционирования) кода», на самом деле не дает ответа на большую часть практических вопросов, возникающих у исследователя, которому поставлена задача по проведению ДА. Пытаться ответить на них все единолично в рамках одной небольшой статьи, еще и в формате стройной, формально-выверенной картины – задача заведомо нерешаемая. Поэтому решено действовать другим – уже проверенным в предшествующих материалах [2] – способом, а именно перечислить типовые вопросы, с которыми уважаемые разработчики периодически «влетают» в эксперта испытательной лаборатории, а также некоторые апробированные временем и практикой тезисы ответов.

Динамический анализ это же DAST?

Мой «любимый» тезис, регулярно всплывающий при общении с представителями разработчиков и исследователей безопасности кода. Сильно упрощая, для большого числа инженеров-безопасников ДА примерно тождественен «походить по API c помощью условного OWASP Zap» [3]. Действительно, являясь одним из полезных и распространенных видов ДА, комплекс подходов и инструментов анализа, в обиходе известный как DAST, сконцентрирован в первую и основную очередь на анализе API (в первую очередь в отношении web-фреймворков). Данный комплекс, как правило, ориентирован на поиск известных уязвимостей – как составляющих API компонентов, так и безопасности их конфигураций – либо, на выявление «нехороших» API (Shadow, Orphan и Zombie [4]) и их параметров. Практики и инструменты DAST в наибольшей степени применимы при работе команд пентестеров (Red Team), а также при создании и постоянном контроле защищенности микросервисных (зачастую разрабатываемых в парадигме API-First) приложений, по своей природе предполагающих частые внесения изменений. Тем не менее вышеуказанные практики составляют только подмножество существующих и требуемых в ряде случаев практик ДА.

Что требует и что не требует ФСТЭК России, когда упоминает динамический анализ?

Дискутируя с коллегами, мы, как правило, делим РБПО-практики на «вширь» и «вглубь» [5]. «Вширь» определяется ГОСТ Р 56939-2024, в котором вводятся 25 процессов, составляющих комплексный процесс РБПО, при этом сами описания процессов достаточно верхнеуровые и зачастую оставляют на усмотрение разработчика выбор инструментов и детали (в т. ч. численные критерии) реализации процессов. «Вглубь» – а именно более конкретные требования к технологическим возможностям инструментов и численные критерии – определяется Методикой выявления уязвимостей и недекларированных возможностей в ПО ФСТЭК России [6], доступной для использования в работе лицензиатам ФСТЭК России, а также частично приказом №76 ФСТЭК России «Требования, устанавливающие уровни доверия...».

В область требуемых практик ДА с точки зрения Методики (для испытаний по 4 – самому типовому – уровню контроля) попадают как минимум:

функциональное тестирование (иначе: «пользовательское» тестирование функций безопасности);
модульное тестирование (основным доп. требованием которого является запуск тестов с комплектами датчиков срабатывания ошибок в тех случаях, когда это применимо);
генетическое фаззинг-тестирование (о нем ниже);
комплексный сбор информации об объекте в динамике оценки, совмещенный с тестированием на проникновение (на пальцах этот процесс можно охарактеризовать как совмещение практик DASTи анализа в песочнице);
а также ряд специальных практик, таких как динамический анализ потоков распространения чувствительных данных (в т. ч. полносистемный).

В область требуемых практик ДА с точки зрения ГОСТ явно попадают динамический анализ (процесс №11) и функциональное тестирование (процесс №18). При этом в процессе №11 в явном виде упоминается необходимость фаззинг-тестирования, пусть и без указания требования «генетического» свойства, однако с введением комплексного примечания, в настоящей редакции ГОСТ пока что рекомендующего добровольно подходить к решению задачи ДА с должным энтузиазмом:

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

Также процессы определения поверхности атаки (процесс №7) и нефункционального тестирования (процесс №19) не требуют, но подразумевают использование различных, характерных для ДА, подходов.

Начиная с апреля 2025 ФСТЭК России также публикует методические рекомендации по проведению тех или иных видов испытаний в Телеграм-канале @sdl_inform, входящем в группу информационных ресурсов РБПО-сообщества ФСТЭК России и ИСП РАН [7]. Вопросы применимости и требований методик и инструментов динамического анализа рассмотрены представителем ФСТЭК России И. С. Гефнер в рамках большого эфира [8], посвященного тематике РБПО.

Фаззинг, что это за зверь?

Самое простое определение фаззинга – это подача на вход тестируемому объекту случайных данных (в надежде обнаружить какое-либо неожиданное – вплоть до аварийного завершения – поведение тестируемого объекта или даже системы в целом). Простейшие инструменты фаззинга – мутаторы значений параметров запросов как правило включены в комплект поставки упоминавшихся выше DAST-инструментов.

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

Как правило, в тех случаях, когда регуляторикой требуется фаззинг, подразумевается именно генетический фаззинг. Более подробный рассказ о данной технологии будет представлен в статье ИСП РАН в данном блоке, также различные материалы публикуются в Телеграм-канале @sdl_dynamic [9]. При этом важность (и сложность) технологии в целом подчеркивает в том числе тот факт, что именно упоминанию вопросов генетического фаззинга посвящено наибольшее число методических рекомендаций ФСТЭК России, публикуемых в Телеграм-канале @sdl_inform.

Может быть все-таки сделать единый стандарт по динамическому анализу?

Отличное предложение! В настоящий момент помимо «большого» ГОСТ Р 56939-2024 вступили в силу и действуют «инструментальные» ГОСТы: статический анализ исходного кода [10]; безопасный компилятор языков С/С++ [11]. Также на финальной стадии подготовки находится стандарт по композиционному анализу программного обеспечения [12]. В планах ТК362 на 2025 год среди прочих значится разработка стандарта «Динамический анализ программного обеспечения» [13], автором стандарта является ИСП РАН. Работа над первой редакцией стандарта уже ведется, на текущий момент с высокой степенью вероятности можно утверждать о попадании в редакцию стандарта как минимум следующих областей динамического анализа: модульное (и возможно комплексное функциональное) тестирование, фаззинг-тестирование, анализ потоков помеченных данных (как для уточнения поверхности атаки, так и для выявления утечек чувствительных данных).

И это все? А как же X, Y и ИИ?

Разумеется, нет! Список типов инструментов, выполняющих виды динамического анализа полезные как на этапе создания ПО, так и на этапе его эксплуатации, можно продолжать достаточно долго – упомянем для примера следующие из них:

инструменты динамического определения поверхности атаки по коду (например, Natch от ИСП РАН);
платформы контроля и безопасности контейнерной инфраструктуры, использующие движок eBPF (например, Luntry от Лантри);
инструменты комплексного динамического исследования RESTAPI (например, ПроAPI от Вебмониторэкс);
полноценные песочницы, совмещенный со средствами антивирусной защиты (например, Sandbox от Лаборатории Касперского).

Отдельным и весьма актуальным является создаваемый прямо на наших глазах тип инструментов ДА, предназначенный для различных динамических исследований работы моделей систем искусственного интеллекта. Составить верхнеуровневое представление о созданных и развивающихся методах и инструментах анализа можно на основе доклада Вартана Падаряна (ИСП РАН) «Разработка безопасных технологий искусственного интеллекта» [14].

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

[1] ГОСТ Р 56939-2024

[2 BIS Journal №1 (56) 2025, статья «РБПО-2024. ИТОГИ И ПЕРСПЕКТИВЫ»

[3] Видеозапись моего выступления на Kaspersky Certification Day (08:08:00)

[4] https://habr.com/ru/companies/webmonitorx/articles/804489/

[5] выступление Елены Быхановой НТЦ Фобос-НТ, видео доступно по ссылке

[6] ссылка на презентацию, ссылка на просмотр

[7] https://t.me/sdl_community/7859

[8] https://t.me/sdl_community/8407

[9] https://t.me/sdl_dynamic/9103

[10] https://docs.cntd.ru/document/1304734159

[11] https://docs.cntd.ru/document/1304734158

[12] https://t.me/sdl_community/8716