РБПО-010. Причины введения ГОСТ Р 56939-2024 взамен версии 2016 года (часть 1/3)
ГОСТ Р 56939-2016 разработан закрытым акционерным обществом "Научно-производственное объединение "Эшелон" (ЗАО "НПО "Эшелон"). Обратите внимание, что первопроходцем стала только одна организация. Объять и формализовать всё сразу было трудоёмкой задачей. Поэтому неудивительно, что с годами к стандарту накопились вопросы и пожелания, что и стало поводом к его пересмотру.

Например, в предыдущей версии стандарта отсутствует раздел про технологию композиционного анализа.

Композиционный анализ (Composition Analysis, SCA) — совокупность методов для отслеживания в кодовой базе ПО заимствованных компонентов Open Source и проверки их безопасности. Т.е. получается, что важная, широко применяемая на практике технология, не будучи описанной в ГОСТе, как бы является необязательной. Стандарт начинает расходиться с практикой и реальным обеспечением безопасности.

Нет упоминания процесса непрерывной интеграции (CI/CD) разрабатываемого ПО. Хотя без CI/CD невозможна реализация критических для безопасности мер.

РБПО-011. Причины введения ГОСТ Р 56939-2024 взамен версии 2016 года (часть 2/3)
Недостаточная конкретизация некоторых требований, таких как необходимость контроля/анализа кода сторонних библиотек. В ГОСТ Р 56939—2024 эту тему освещает раздел 5.7 — Моделирование угроз и разработка описания поверхности атаки. Кстати, в ГОСТ Р 56939-2016 и не звучит понятие "поверхность атаки", хотя оно неразрывно связано с РБПО.

Согласно ГОСТ Р 56939—2024 (п. 3.9.),

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

Нет упоминания актуального работающего подхода — багбаунти. Т.е. получается, что и здесь стандарт расходится с реальными способами выявления уязвимостей. В ГОСТ Р 56939-2024 это уже учтено и багбаунти упоминается в п. 5.24.2.1 — Разработать регламент поиска ошибок и уязвимостей в ПО при его эксплуатации:

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

РБПО-012. Причины введения ГОСТ Р 56939-2024 взамен версии 2016 года (часть 3/3)
Невозможно часто и быстро выпускать релизы (и проходить сертификацию). Серая зона с быстрыми правками и фиксами. Непонятно, когда правки перерастают в большие функциональные изменения.

Были и другие моменты, перечислять которые здесь избыточно. Дополнительную информацию, например, можно посмотреть в презентации Падарян В.А. Шарков И.В. "POV органа. Кровью и потом: Сертификация РБПО" (ИСП РАН, 20 сентября 2024). Раньше презентация находилось поиском, но сейчас у меня это не получилось сделать и ссылку привести не могу. Быть может вам повезёт.

Всё перечисленное не значит, что ГОСТ Р 56939-2016 был плохим. Он был нужен, полезен и являлся первой формализацией РБПО. Спасибо авторам из ЗАО "НПО "Эшелон", что они стали первопроходцами в этой теме.

Просто пришло время улучшений, уточнений и переработок. И вот теперь у нас есть ГОСТ Р 56939-2024, созданный уже целым коллективом из различных организаций.

Решил написать ответ на вопрос в формате отдельного поста.

А не боитесь пропустить обработку каких-нибудь проверок (test_connection / test_valid_*)?

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

Можно начать предупреждать обо всех разыменованиях указателей, когда нет уверенности, что указатель точно не нулевой. Можно предупреждать обо всех арифметических операциях, когда нет точной информации о диапазоне значений операндов и нет уверенности, что не произойдёт переполнение. Можно предупреждать о каждом обращении к элементу массива A[b], если не удалось точно понять, каков размер массива или каков диапазон индекса. Это на самом деле очень легко делать. Абстрактно такой анализатор позволит найти все ошибки этих типов. На практике же такой анализатор никому не нужен, так как он будет выдавать предупреждение, наверное, на каждую пятую строчку кода.

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

Например, пожалуй, все анализаторы будут ругаться на доступ к элементу A[b], когда вычислено, что индекс выходит за границу, а не когда он не смог вообще вычислить значение индекса. Однако не всегда получается вычислить диапазон индекса, и анализаторы пропускают ошибку. И многие другие ошибки.

Сейчас вы узнали, что анализатор промолчит на srand в test_x.cpp, и это кажется проблемой. Это просто потому, что вы не знаете про сотни и тысячи различных ограничений в детекторах анализаторов, когда они не могут что-то вычислить или сознательно отбрасывают неубедительные случаи :)

Есть тысяча способов улучшить соотношение польза/шум, дорабатывая разные места. Мы и другие разработчики анализаторов регулярно этим заняты. Но "ругаться как можно больше на всё подозрительное" к этим способам не относится :)

Более подробные рассуждения на эту тему можно найти в публикации "Как и почему статические анализаторы борются с ложными срабатываниями".

РБПО-013. Разработчики ГОСТ Р 56939-2024
В отличии от версии 2016 года в разработке ГОСТ Р 56939-2024 приняли участие сразу несколько организаций. Все они так или иначе занимаются вопросами безопасности, и стандарт вобрал опыт их команд.

Например, у "Позитив Текнолоджиз" уже были наработки в сфере РБПО, которые нашли отражение в руководстве "AppSec Table Top: методология безопасной разработки от Positive Technologies".

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

РБПО-014. Область применения ГОСТ Р 56939-2024 и его структура
Стандарт содержит 5 разделов.

1. Область применения — своего рода небольшая аннотация. Самое основное:

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

2. Нормативные ссылки — отсылки к трём другим ГОСТам. Рассматривать их смысла нет, можно просто заглянуть в стандарт.

3. Термины и определения — 23 термина, часть из которых позаимствована из других стандартов. Далее я рассмотрю некоторые термины, которые показались мне наиболее важными для темы РБПО.

4. Общие требования к разработке безопасного программного обеспечения.

5. Процессы разработки безопасного программного обеспечения. Это основной и самый большой раздел стандарта, где описано 25 процессов. Собственно, в основном мои посты будут посвящены этому разделу. Все описания процессов разработки безопасного программного обеспечения построены по единой схеме:
• цели;
• требования к реализации;
• артефакты реализации требований.

Эта единообразная структура делает чтение и анализ стандарта в целом простым процессом. И позволяет, условно говоря, "разложить ГОСТ на большой чеклист". Спасибо разработчикам стандарта за проделанную работу.

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

Соответствующую закупку осуществит ФСТЭК России в 2025–2026 годах.

Работы выполнит Федеральное государственное бюджетное учреждение науки Институт системного программирования им. В.П. Иванникова Российской академии наук.

Единственный исполнитель сможет привлекать субподрядчиков и соисполнителей при условии личного выполнения не менее 50 % совокупного стоимостного объёма обязательств.

Работы должны быть выполнены не позднее 20 декабря 2026 года.

📄 Распоряжение Правительства РФ от 21.05.2025 № 1266-р

Источник: ЭТП «Фабрикант»

РБПО-015. Термин: безопасное программное обеспечение

Программное обеспечение, разработанное в ходе реализации совокупности процессов (мер), направленных на предотвращение появления и устранение недостатков программы. (п. 3.1)

Обратите внимание, что акцент сделан на меры, направленные на предотвращение дефектов, а не на бесконечное тестирование и правки как можно большего количества багов.

Надёжность программы достигается, в первую очередь, благодаря её правильному проектированию, а не бесконечному тестированию. (Юров В.И.)

Хотя, конечно, никто тестирование и иные методы выявления ошибок не отменяет, и в стандарте они тоже описаны. Но всё-таки важнее постараться построить процессы так, чтобы изначально было меньше проблем. Сюда можно отнести обучение сотрудников, использование стандартов кодирования, использование языков с безопасной моделью памяти и т.п.

Серьёзным программистам я хочу сказать: уделяйте часть рабочего дня изучению и улучшению собственных методик. Хотя на программистов всегда давит какой-то будущий или прошедший срок, методологическая абстракция — мудрая долговременная инвестиция. (Роберт У. Флойд)

Параллельно с циклом публикаций про РБПО решили записать серию рассказов. В первой части рассматриваю причины разработки и выпуска обновлённой версии стандарта. Приятного просмотра!

РБПО-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 июня буду в Москве для участия в вечерних митапах. А днём пока свободен и открыт к предложениям ещё где-то поучаствовать: внезапный подкаст, рассказ вашим коллегам в офисе про статический анализ :). Если есть подходящая идеи - напишите.