РБПО-016. Термин: динамический анализ кода программы (часть 1/3)

Вид работ по инструментальному исследованию программы, основанный на анализе кода программы в режиме непосредственного исполнения (функционирования) кода. (п. 3.2)

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

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

Программы для динамического анализа различаются по способу взаимодействия с проверяемой программой:
• инструментирование исходного кода. В исходный текст приложения до начала компиляции добавляется специальный код для обнаружения ошибок;
• инструментирование объектного кода. Код добавляется непосредственно в исполняемый файл;
• инструментирование кода на этапе компиляции. Проверочный код добавляется с использованием специальных ключей компилятора;
• не изменяет исходную программу, используются специализированные библиотеки этапа исполнения. Для обнаружения ошибок используются специальные отладочные версии системных библиотек.

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

РБПО-017. Термин: динамический анализ кода программы (часть 2/3)
Достоинства динамического анализа кода:
• в большинстве реализаций появление ложных срабатываний исключено, так как обнаружение ошибки происходит в момент её возникновения в программе. Таким образом, обнаруженная ошибка является не предсказанием, сделанным на основе анализа модели программы, а констатацией факта её возникновения;
• в некоторых случаях не требуется исходный код, это позволяет протестировать программы с закрытым кодом.

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

Дополнительные ссылки:
1. Проверяем код динамического анализатора Valgrind с помощью статического анализатора.
2. Зачем нужен динамический анализ кода, на примере проекта PVS-Studio.

P.S. Кстати, сейчас при разработке PVS-Studio мы используем динамический анализ, регулярно выполняя по ночам прогоны ASan (AddressSanitizer), UBSan (UndefinedBehaviorSanitizer).

РБПО-018. Термин: динамический анализ кода программы (часть 3/3)
Отдельно проясню мысль "не может проверить, что код выполняет то, что задумывал программист". А разве, например, статический анализ может? Да, иногда может.

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

Value buildTernaryFn(TernaryFn ternaryFn, Value arg0, Value arg1, Value arg2)
{
  bool headBool = isInteger(arg0) &&
                  arg0.getType().getIntOrFloatBitWidth() == 1;
  bool tailFloatingPoint =
      isFloatingPoint(arg0) &&
      isFloatingPoint(arg1) &&
      isFloatingPoint(arg2);
  bool tailInteger = isInteger(arg0) &&
                     isInteger(arg1) &&
                     isInteger(arg1);
  OpBuilder::InsertionGuard g(builder);
  builder.setInsertionPointToEnd(&block);
  ....
}

Эту ошибку PVS-Studio нашёл в LLVM. Здесь дважды повторяется arg1: isInteger(arg1) && isInteger(arg1) вместо использования arg2. С точки зрения статического анализатора аномалия очевидно.

С точки зрения динамического анализатора ничего странного. Повторно выполняется какая-то проверка. Ну и что? Это не признак ошибки. Таких повторных проверок в бинарном коде может быть полно при выключенной оптимизации. А при включённой оптимизации компилятор выбросит повторную проверку, и придраться вообще не к чему.

РБПО-019. Термин: поверхность атаки
Важное понятие, которого не было в ГОСТ Р 56939-2016.

Множество подпрограмм (функций, модулей) программного обеспечения, обрабатывающих данные, поступающие посредством интерфейсов, напрямую или косвенно подверженных риску атаки. (п. 3.9).

Определить поверхность атаки необходимо, чтобы рационально использовать силы для анализа кодовой базы.

В общем виде термин "поверхность атаки" включает в себя очень много чего. Пример описания:

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

Однако в рамках РБПО речь идёт именно о слабых местах ПО. Мы ещё вернёмся к этой теме, а пока предлагаю для ознакомления следующую статью: Зачем искать поверхность атаки для своего проекта.

РБПО-020. Термин: статический анализ исходного кода программы (часть 1/3)

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

Небольшое отступление
Обзор кода (code review) — один из самых старых и полезных методов выявления дефектов. Он заключается в совместном внимательном чтении исходного кода и высказывании рекомендаций по его улучшению. В процессе обзора выявляются уже имеющиеся ошибки или же участки кода, которые могут стать ошибочными в будущем. Также считается, что автор кода во время обзора не должен давать объяснений, как работает та или иная часть программы. Алгоритм работы должен быть понятен непосредственно из текста программы и комментариев. Если это условие не выполняется, то код должен быть доработан.

Как правило, обзор кода хорошо работает, так как программисты намного легче замечают ошибки в чужом коде. Более подробно с методикой code review можно познакомиться в замечательной книге Стива Макконнелла "Совершенный код" ("Code Complete", Steve McConnell).

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

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

Дополнительная ссылка: Джон Кармак. Статический анализ кода.

Раз в РБПО мы добрались до статического анализа, время изучить возможности PVS-Studio.
Поддерживает анализ кода на языке C, C++ (и диалекты C++/CLI, C++/CX), C#, Java. Совместим с ГОСТ Р 71207–2024 – Статический анализ ПО.

Применяется испытательными лабораториями, аккредитованными в системах сертификации средств защиты информации ФСТЭК России в рамках работ по сертификационным испытаниям программных продуктов.

От меня промокод firefly для получения лецензии на 1 месяц. Скачать и попробовать.

РБПО-021. Термин: статический анализ исходного кода программы (часть 2/3)
Внедрение статического анализа в процесс разработки это:

1. Выявление ошибок в программах и "кода с запахом" (например, непереносимый или сложный для понимания код).

2. Обнаружение критических ошибок (потенциальных уязвимостей).

3. Один из ключевых процессов для построения РБПО.

4. Рекомендации по оформлению кода. Некоторые статические анализаторы позволяют проверять, соответствует ли исходный код принятому в компании стандарту оформления. Имеется в виду контроль количества отступов в различных конструкциях, использование пробелов/символов табуляции и так далее.

5. Подсчёт метрик. Метрика программного обеспечения — это мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.

6. Проверка соответствия текста программы определённым стандартам кодирования (MISRA, CWE, SEI CERT, и т.д.).

7. Контроль качества кода во времени. Собирая статистику, можно узнать, растёт или уменьшается плотность ошибок со временем. Это позволяет отвечать на вопросы о том, какие изменения в процессе разработки проекта пошли на пользу, а какие нет.

Есть и другие способы использования инструментов статического анализа кода. Например, статический анализ можно использовать как метод контроля и обучения новых сотрудников, ещё недостаточно знакомых с правилами программирования в компании.

4 и 5 июня буду в Москве для участия в вечерних митапах. А днём пока свободен и открыт к предложениям ещё где-то поучаствовать: внезапный подкаст, рассказ вашим коллегам в офисе про статический анализ :). Если есть подходящая идеи - напишите.

РБПО-022. Термин: статический анализ исходного кода программы (часть 3/3)
Как и у любой другой методологии выявления ошибок, у статического анализа есть свои сильные и слабые стороны. Важно понимать, что нет одного идеального метода обеспечения качества кода. Для разных классов программного обеспечения разные методики будут давать разные результаты. Добиться высокого качества программы можно только в случае, если использовать сочетание различных методик.

Главное преимущество статического анализ состоит в возможности существенного снижения стоимости устранения дефектов в программе. Чем раньше ошибка выявлена, тем меньше стоимость её исправления.

Другие преимущества статического анализа кода:
1. Тестирование всего кода. Статические анализаторы проверяют даже те фрагменты кода, которые выполняются крайне редко. Такие участки кода, как правило, не удаётся протестировать другими методами. Это позволяет находить дефекты в обработчиках редких ситуаций, в обработчиках ошибок или в системе логирования.

2. Статический анализ не зависит от используемого компилятора и среды, в которой будет выполняться скомпилированная программа. Это позволяет находить скрытые ошибки, которые могут проявить себя только через несколько лет. Например, это ошибки неопределённого поведения. Они могут проявить себя при смене версии компилятора или при использовании других ключей для оптимизации кода.

3. Можно легко и быстро обнаруживать опечатки и последствия использования copy-paste. Как правило, нахождение этих ошибок иными способами является крайне неэффективной тратой времени и усилий. Обидно после часа отладки обнаружить, что ошибка заключается в выражении вида strcmp(str_a, str_a). Обсуждая типовые ошибки, про такие ляпы, как правило, не вспоминают. Но на практике на их выявление тратится существенное время.

Дополнительные ссылки:
• Как внедрить статический анализатор кода в legacy проект и не демотивировать команду.
• Внедряйте статический анализ в процесс, а не ищите с его помощью баги.

РБПО-023. Термин: уязвимость программы

Недостаток программы, который может быть использован для реализации угроз безопасности информации. (п. 3.22)

Следует разделять понятие потенциальная уязвимость и уязвимость. Уязвимость — это когда дефектом безопасности точно можно воспользоваться или кто-то уже им воспользовался. А когда в коде кто-то нашёл, например, выход за границу массива, это баг или потенциальная уязвимость. Но ещё не уязвимость, пока не будет доказано, что эту проблему можно эксплуатировать. Это код может быть недостижим или же ошибка может приводить к неправильной работе программы, но это никак не связано с вопросом безопасности.

Меня бомбит, когда пишут, что кто-то нашёл 100 уязвимостей в таком-то проекте с помощью инструмента X. Не 100 уязвимостей он нашёл, а 100 ошибок в лучшем случае. Какая-то из них, возможно, действительно является уязвимостью. Но, скорее всего, нет. Найти настоящую уязвимость ещё постараться надо. Понятно, что "нашли много уязвимостей" звучит пугающе, но стоит понимать, что, скорее всего, перед вами жёлтый заголовок. Подобный случай я рассматривал в статье "GPT-3 нашёл 213 Security Vulnerabilities... Или не нашёл".

Кстати, в рамках разработки безопасного ПО вовсе не ставится задача найти у устранить уязвимости. Необходимо выявить критические ошибки (потенциальные уязвимости) и исправить их ещё на этапе разработки. Бессмысленно выяснить, может конкретный баг эксплуатироваться или нет, его надо просто пофиксить и продолжить заниматься полезными делами.

Ещё лучше организовать процесс написания кода так, чтобы потенциальные уязвимости появлялись как можно реже. В этом с точки зрения РБПО поможет обучение сотрудников, стандарт написания кода и т.д.

P.S. Та уязвимость, которая только что была обнаружена, называется уязвимость нулевого дня. Термин означает, что у разработчиков было 0 дней на исправление дефекта: уязвимость или атака становится публично известна до момента выпуска производителем ПО исправлений ошибки.

РБПО-024. Термин: фаззинг-тестирование программы

Вид работ по исследованию программы, основанный на передаче программе случайных или специально сформированных входных данных, отличных от данных, предусмотренных алгоритмом работы программы. (п. 3.22)

Фаззинг-тестирование хоть и является разновидностью динамического анализа, но достаточно обособлено, поэтому его принято рассматривать как отдельный вид тестирования.
• Википедия. Фаззинг.
• Кирилл Мотков. Что такое фаззинг и зачем он нужен?
• Евгений Новиков. Фаззинг драйверов KasperskyOS.
• Максим Бакиров. Фаззинг или тестирование мусорными данными.

При разработке PVS-Studio фаззинг-тестирование мы пока не используем, т.к. его использование выглядит малополезным. Можно тратить большие вычислительные ресурсы, чтобы случайным образом составлять код и пытаться его проверять. Большинство случаев будет заканчиваться ошибкой парсинга (разбора кода). Будут компилироваться и анализироваться редкие случайные сочетания кода, которые будут просты и бессмысленны. Непонятно, что это даст с практической точки зрения.

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

Осмысленным выглядит создание генератора кода, который строит сложные, корректно компилируемые программы. При этом не просто строит, а стремится проверить все возможные сочетания использования какой-то сущности языка. Например, инстанцировать std::vector различными типами, а потом делать над контейнером разные операции (в циклах, выполнять условия, вызывать различные функции). Но это уже будет не классическое фаззинг-тестирование, а нечто иное. Составление такого кода не процесс случайного наполнения файла, а большая работа программистов по написанию объёмного и сложного генератора, в котором будет мало случайного. У нас такого генератора нет, так как задача сложная, и это можно заменить тестированием на большом количестве реальных проектов, что мы и делаем.

Захожу на Habr, а там такая статья! Моё почтение автору.

Как манул единорога в горы водил: запускаем PVS-Studio на российских процессорах Эльбрус.

Запись вебинара "Эффективная разработка с Нейтрино и PVS-Studio: инструменты, безопасность и качество кода".

Нейтрино - POSIX совместимая встраиваемая ОС жесткого реального времени со встроенными средствами защиты информации от несанкционированного доступа.

РБПО-025. Термин: экспертиза исходного кода программы

Вид работ по выявлению недостатков программы в исходном коде программы, направленный на оценку ее свойств и основанный на анализе исходного кода программы в режиме, не предусматривающем реального выполнения кода. (п. 3.23)

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

Поэтому экспертиза (обзор кода) без инструментальной поддержки выполняется только тогда, когда для языка, на котором написан код, нет подходящих инструментов и/или кода мало. Если инструмента нет, а кода много, ручная экспертиза, к сожалению, не выход. Невозможно внимательно изучить миллион строк кода за разумное время.

На практике возможности ручного анализа ещё скромнее. Например, методика выявления уязвимостей и НДВ определяет этот порог в 10 KLOC. Если кода (на языке высокого уровня) больше, то проведение исследования невозможно.

См. также:
• Анастасия Камалова. Поиск уязвимостей в исходном коде с помощью ручного статического анализа.
• Андрей Карпов. Можно автоматизировать обзор кода?

РБПО-026. Раздел 4 – общие требования к разработке безопасного программного обеспечения (часть 1/2)
Четвёртый раздел ГОСТ Р 56939-2024 более подробно раскрывает, что понимается под РБПО и как эта практика описывается в виде процессов. Сформулированы основные цели РБПО:

• выявление недостатков, в том числе уязвимостей, в разрабатываемом ПО;
• снижение количества недостатков, в том числе уязвимостей ПО;
• снижение ущерба от невыявленных уязвимостей ПО;
• оперативное устранение выявляемых уязвимостей в ПО.

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

...С целью подчеркнуть различие между разными формами условий для реализации процессов разработки безопасного ПО в настоящем стандарте используются вспомогательные глаголы «должен», «следует», «рекомендуется» и «может».

Глаголы «должен» и «следует» — для выражения условия, требуемого для соответствия требованию, «рекомендуется» — для выражения рекомендации по реализации, «может» — для того чтобы отразить возможные направления допустимых действий.

Во-вторых, интересно, что в п. 4.4 сделана отсылка на стандарт, которого пока нет:

Методика оценки соответствия реализации процессов разработки безопасного ПО установленным настоящим стандартом требованиям является предметом рассмотрения отдельного национального стандарта.

И действительно, если заглянуть в план ФСТЭК на 2025 год по разработке проектов национальных стандартов, то там есть ГОСТ Р "Защита информации. Разработка безопасного программного обеспечения. Методика оценки уровня внедрения процессов разработки безопасного программного обеспечения". В декабре 2025 года он должен быть направлен на издательское редактирование и подготовку к утверждению проекта национального стандарта. В общем, рекомендую отслеживать введение этого и других стандартов, которые могут сказаться на мире РБПО уже в 2025 и 2026 году.