Разработка безопасного программного обеспечения (РБПО) по ГОСТ Р 56939—2024

• Предисловие
• ГОСТ Р 56939—2024
• Быстрый обзор ГОСТ Р 56939—2024
• РБПО или БРПО?
• Причины введения ГОСТ Р 56939—2024 взамен версии 2016 года
• Разработчики ГОСТ Р 56939—2024
• Область применения ГОСТ Р 56939—2024 и его структура
• Разберём некоторые термины из третьего раздела
  • Безопасное программное обеспечение
  • Динамический анализ кода программы
  • Фаззинг-тестирование программы
  • Поверхность атаки
  • Статический анализ исходного кода программы
  • Экспертиза исходного кода программы
  • Уязвимость программы
• Общие требования к разработке безопасного программного обеспечения (4-й раздел стандарта)
• Итак, нас ждут 25 процессов
• 5.1. Планирование процессов разработки безопасного программного обеспечения
• 5.2. Обучение сотрудников
• 5.3. Формирование и предъявление требований безопасности к программному обеспечению
• 5.4. Управление конфигурацией программного обеспечения
• 5.5. Управление недостатками и запросами на изменение программного обеспечения
• 5.6. Разработка, уточнение и анализ архитектуры программного обеспечения
• 5.7. Моделирование угроз и разработка описания поверхности атаки
• 5.8. Формирование и поддержание в актуальном состоянии правил кодирования
• 5.9. Экспертиза исходного кода
• 5.10. Статический анализ исходного кода
• 5.11. Динамический анализ кода программы
• 5.12. Использование безопасной системы сборки программного обеспечения
• 5.13. Обеспечение безопасности сборочной среды программного обеспечения
• 5.14. Управление доступом и контроль целостности кода при разработке программного обеспечения
• 5.15. Обеспечение безопасности используемых секретов
• 5.16. Использование инструментов композиционного анализа
• 5.17. Проверка кода на предмет внедрения вредоносного программного обеспечения через цепочки поставок
• 5.18. Функциональное тестирование
• 5.19. Нефункциональное тестирование
• 5.20. Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения
• 5.21. Безопасная поставка программного обеспечения пользователям
• 5.22. Обеспечение поддержки программного обеспечения при эксплуатации пользователями
• 5.23. Реагирование на информацию об уязвимостях
• 5.24. Поиск уязвимостей в программном обеспечении при эксплуатации
• 5.25. Обеспечение безопасности при выводе программного обеспечения из эксплуатации
• Дополнительные вебинары и ссылки
  • Сертификация ПО согласно требованиям ФСТЭК и Минобороны
  • Системы с конструктивной информационной безопасностью
  • Сертификация процессов РБПО: требования ФСТЭК России, новые стандарты и практика
  • Статический анализ кода в методическом документе ЦБ РФ "Профиль защиты"
  • Дополнительные ссылки
• Послесловие

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

Предисловие

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

Подборку материалов подготовил Карпов Андрей Николаевич — директор по развитию бизнеса ООО "ПВС".

ГОСТ Р 56939—2024

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

• он вышел недавно и поэтому наиболее полно описывает современные практики/подходы к созданию безопасного ПО;
• он имеет юридическое значение на территории РФ;
• на него ссылаются другие документы, например приказ ФСТЭК №117, методический документ ЦБ РФ "Профиль защиты".

Полное название стандарта:

Защита информации

РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Общие требования

Дата введения: 20.12.2024 (взамен ГОСТ Р 56939—2016).

Документ на сайте ФГБУ "Российский институт стандартизации" – ГОСТ Р 56939-2024.

Быстрый обзор ГОСТ Р 56939—2024

Если вы хотите составить общее впечатление о ГОСТ Р 56939—2024 и принципах безопасной разработки, не погружаясь сразу в детали, то можно начать с этих пяти обзорных докладов (суммарное время изучения — около двух часов):

• Причины разработки и выпуска нового ГОСТ Р 56939—2024 на замену версии 2016 года.
• Содержание ГОСТ Р 56939—2024 и его структура.
• Процессы РБПО 5.1-5.10 в ГОСТ Р 56939—2024.
• Процессы РБПО 5.11-5.25 в ГОСТ Р 56939—2024.
• Вопросы сертификации, выводы и дополнительные ссылки.

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

РБПО или БРПО?

Я буду часто использоваться сокращение РБПО. Однако в статьях и на других ресурсах можно встретить и другое сокращение — БРПО. Давайте разберёмся.

РБПО — разработка безопасного программного обеспечения.

БРПО — безопасная разработка программного обеспечения.

Новый ГОСТ Р 56939—2024 делает акцент на совершенствовании процессов разработки, то есть если применить стандарт, то разработка программного обеспечения (РПО) станет безопасной. Отсюда, как мне кажется, и появляется вариант написания БРПО.

С другой стороны, конечная цель — создать безопасное программное обеспечение (БПО), и тогда логичнее звучит РБПО.

На мой взгляд, допустимы оба варианта написания. Однако раз ГОСТ называется "Разработка безопасного программного обеспечения" (РБПО), то будем придерживаться этого варианта.

Причины введения ГОСТ Р 56939—2024 взамен версии 2016 года

Примечание. Этот раздел также представлен в виде вводного доклада "Причины разработки и выпуска нового ГОСТ Р 56939—2024 на замену версии 2016 года".

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

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

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

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

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

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

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

Были и другие моменты, перечислять которые здесь избыточно.

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

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

Разработчики ГОСТ Р 56939—2024

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

В разработке ГОСТ Р 56939—2024 приняли участие:

• ФСТЭК России;
• АО "Лаборатория Касперского";
• ИСП РАН;
• АО "ИнфоТеКС";
• АО "Позитив Текнолоджиз";
• ООО "РусБИТех-Астра";
• АО "Сбер-Тех";
• ООО НТЦ "Фобос-НТ";
• ООО "ЦБИ";
• АО НПО "Эшелон".

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

Благодаря вкладу группы компаний, новый стандарт включает в себя все актуальные технологии, хорошо структурирован и глубже проработан.

Область применения ГОСТ Р 56939—2024 и его структура

Стандарт содержит пять разделов.

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

Раздел №2. Нормативные ссылки. Отсылки к трём другим ГОСТам:

• ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.
• ГОСТ Р 50922 Защита информации. Основные термины и определения.
• ГОСТ Р 58412 Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения.

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

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

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

• цели;
• требования к реализации;
• артефакты реализации требований.

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

Разберём некоторые термины из третьего раздела

Здесь перечислены и разобраны только некоторые термины. С остальными вы можете познакомиться в третьем разделе ГОСТ Р 56939—2024.

Безопасное программное обеспечение

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

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

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

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

Динамический анализ кода программы

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

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

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

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

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

Достоинства динамического анализа кода:

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

Недостатки динамического анализа кода:

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

Имея свои сильные и слабые стороны, динамический анализ наиболее эффективно может быть использован вместе со статическим анализом кода.

Дополнительные ссылки:

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

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

Отдельно проясню мысль "не может проверить, что код выполняет то, что задумывал программист". А разве, например, статический анализ может? Да, иногда может.

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

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. С точки зрения статического анализатора аномалия очевидна.

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

Фаззинг-тестирование программы

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

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

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

Поверхность атаки

Важное понятие, которого не было в ГОСТ Р 56939—2016. В стандарте 2024 года появилось следующее определение:

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

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

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

Статический анализ исходного кода программы

Небольшое отступление

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

Статический анализ можно рассматривать как автоматизированный процесс обзора кода

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

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

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

Внедрение статического анализа в процесс разработки это:

• Выявление ошибок в программах и "кода с запахом" (например, непереносимый или сложный для понимания код).
• Обнаружение критических ошибок (потенциальных уязвимостей).
• Один из ключевых процессов для построения РБПО.
• Рекомендации по оформлению кода. Некоторые статические анализаторы позволяют проверять, соответствует ли исходный код принятому в компании стандарту оформления. Имеется в виду контроль количества отступов в различных конструкциях, использование пробелов/символов табуляции и т. д.
• Подсчёт метрик. Метрика программного обеспечения — это мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.
• Проверка соответствия текста программы определённым стандартам кодирования (MISRA, CWE, SEI CERT, и т. д.).
• Контроль качества кода во времени. Собирая статистику, можно узнать, растёт или уменьшается плотность ошибок со временем. Это позволяет отвечать на вопросы о том, какие изменения в процессе разработки проекта пошли на пользу, а какие нет.

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

Сильные и слабые стороны

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

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

Другие преимущества статического анализа кода:

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

Дополнительные ссылки:

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

Экспертиза исходного кода программы

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

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

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

Дополнительные ссылки:

• Анастасия Камалова. Поиск уязвимостей в исходном коде с помощью ручного статического анализа.
• Андрей Карпов. Можно автоматизировать обзор кода?
• Google Engineering Practices Documentation. How to do a code review.

Уязвимость программы

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

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

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

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

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

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

Общие требования к разработке безопасного программного обеспечения (4-й раздел стандарта)

Четвёртый раздел ГОСТ Р 56939—2024 более подробно раскрывает, что понимается под РБПО и как эта практика описывается в виде процессов. Сформулированы основные цели РБПО:

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

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

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

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

Когда я читал ГОСТ Р 56939—2024, первым местом, где я испытал уважение к описываемым в нём вещам, стал пункт 4.3:

Это говорит о том, что стандарт не оторван от реальности и действительно нацелен на улучшение процессов, не навязывая формальности.

И последнее, на чём остановимся, прежде чем перейдём к рассмотрению 25 процессов, это "артефакты", которые присутствуют в описание каждого из них. Пункт 4.11:

Артефакты — это, во-первых, декомпозированный до конкретных сущностей процесс. Например, способы выбора именования переменных в стандарте кодирования (регламенте оформления кода) в п. 5.8.3.1. Во-вторых, подтверждение, что процесс реализован, когда придёт время сертификации.

Итак, нас ждут 25 процессов

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

• Планирование процессов разработки безопасного программного обеспечения.
• Обучение сотрудников.
• Формирование и предъявление требований безопасности к программному обеспечению.
• Управление конфигурацией программного обеспечения.
• Управление недостатками и запросами на изменение программного обеспечения.
• Разработка, уточнение и анализ архитектуры программного обеспечения.
• Моделирование угроз и разработка описания поверхности атаки.
• Формирование и поддержание в актуальном состоянии правил кодирования.
• Экспертиза исходного кода.
• Статический анализ исходного кода.
• Динамический анализ кода программы.
• Использование безопасной системы сборки программного обеспечения.
• Обеспечение безопасности сборочной среды программного обеспечения.
• Управление доступом и контроль целостности кода при разработке программного обеспечения.
• Обеспечение безопасности используемых секретов.
• Использование инструментов композиционного анализа.
• Проверка кода на предмет внедрения вредоносного программного обеспечения через цепочки поставок.
• Функциональное тестирование.
• Нефункциональное тестирование.
• Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения.
• Безопасная поставка программного обеспечения пользователям.
• Обеспечение поддержки программного обеспечения при эксплуатации пользователями.
• Реагирование на информацию об уязвимостях.
• Поиск уязвимостей в программном обеспечении при эксплуатации.
• Обеспечение безопасности при выводе программного обеспечения из эксплуатации.

Начнём!

5.1. Планирование процессов разработки безопасного программного обеспечения

Вебинар №1 цикла "Вокруг РБПО за 25 вебинаров. ГОСТ Р 56939—2024". Вместе с приглашённым экспертом Виталием Вареница, руководителем сертификационной лаборатории ЗАО "НПО "Эшелон", обсудили тему планирования процессов разработки безопасного программного обеспечения. На YouTube. Слайды презентаций.

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

Некоторые эксперты в публикациях озвучивают оценку, что внедрение РБПО увеличивает стоимость разработки на 10-15%. На мой взгляд, оценка правдоподобна. Эта наценка складывается из затрат на приобретение лицензий на различные дополнительные инструментальные средства и времени, которое будут затрачивать сотрудники на новые процессы и обязанности.

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

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

В стандарте описаны полезные практики, которые улучшат качество любого проекта. Но вопрос: насколько глубоко их стоит реализовывать с точки зрения затрат? Одно дело — воодушевиться чтением ГОСТ и внедрить в некритический проект несколько практик для повышения качества кода, и другое дело — внедрять его всеобъемлюще на уровне, предполагающем дальнейшую сертификацию во ФСТЭК.

То, что внедрение РБПО по ГОСТ Р 56939—2024 требует планирования и выделения ресурсов, звучит ожидаемо и естественно. Стоило ли делать для этого отдельный пункт в стандарте?

Думаю, да. ГОСТ — это в том числе язык общения между исполнителями и заказчиками, между разными уровнями управления в больших компаниях. В этом смысле ГОСТ может оказаться помощником исполнителей и формализовать, что изменения требуют значительных вложений. Затраты времени и денег можно будет расписать и обосновать по пунктам, основываясь на 25 процессах ГОСТа. Они защищают от необоснованных ожиданий руководства/заказчиков получить РБПО в рамках прежних бюджетов.

Примечание. Кстати, схожая мысль описана в статье "Зачем нужны ГОСТы для программной документации?".

Один из способов, который поможет совладать с ГОСТ Р 56939—2024

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

На помощь приходят специализированные системы, раскладывающие РБПО на составные части. Они помогут как внедрить новые процессы, так и сопровождать их в дальнейшем. Примером такой системы является SGRC SECURITM.

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

Почему я вспомнил именно про SGRC SECURITM? Всё просто: мы знакомы с этой системой, её разработчиками и интегрируемся с ней. Отчёты статического анализатора PVS-Studio могут загружаться и обрабатываться в ней. Подробнее эта тема раскрыта в вебинаре "Внедрение процессов безопасной разработки. Интеграция PVS-Studio и SGRC SECURITM".

Совместно с экспертом SECURITM Евгенией Карповой мы поговорили о том, как обеспечить соблюдение требований ГОСТ в области безопасной разработки программного обеспечения. Показали реальные примеры использования PVS-Studio и SECURITM, дали рекомендации по настройке инструментов и рассказали, как оптимизировать процессы разработки для достижения высокого уровня безопасности. На YouTube. Слайды презентаций.

5.2. Обучение сотрудников

Вебинар №2. Вместе с приглашёнными экспертами Виталием Вареница (руководитель сертификационной лаборатории ЗАО "НПО "Эшелон") и Романом Кимом (заведующий кафедрой МАИ, кандидат технических наук, доцент) разобрали ключевые вопросы темы "Обучение сотрудников". На YouTube. Слайды презентаций.

Если сотрудники не заботятся о безопасности, так как просто не знают, что это означает; не понимают, что пишут уязвимый код, то все остальные меры малоэффективны. Процессы РБПО требуют от команды определённой зрелости, осознанности решений и знаний инструментов/практик.

Бессмысленно просить сотрудника разработать правила кодирования (регламент оформления исходного кода и безопасного кодирования), если он понятия не имеет, что это такое, и не читал такие книги, как "Совершенный код" Стива Макконнелла и "Как написать безопасный код на C++, Java, Perl, PHP, ASP.NET" Ховарда М., Лебланка Д, Виега Д. Ну или хотя бы "Верёвка достаточной длины, чтобы выстрелить себе в ногу" Алена Голуба. Впрочем, именно эта книга мне не нравится, но это лучше, чем ничего.

Если он не в курсе обсуждаемых там подходов и рекомендаций, что он составит? Надёргает случайных рекомендаций из интернета? Попросит LLM сгенерировать что-то складное, но малоосмысленное? Просто опишет тот стиль, который у вас уже есть? Это можно сделать, но такой документ несёт формальный характер и не будет иметь отношения к безопасной разработке проектов. Зачем тогда вообще его делать? Уж если заниматься РБПО, то надо делать это всерьёз и для реальной пользы. Нет смысла обманывать самих себя.

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

Условно обучение сотрудников можно разделить на два типа: самообразование и внешнее обучение. Собственно, это указано и в примечании ГОСТ Р 56939—2024 (п. 5.2):

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

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

Во-вторых, может возникнуть необходимость подтверждать компетенции сотрудников не только для себя. В случае сертификации необходимо предоставить соответствующие артефакты. Например (п.5.2.3.3):

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

Давайте попробуем составить список задач и ссылок, на основе которых можно реализовать в компании процесс "Обучение сотрудников разработке безопасного ПО". Для этого оттолкнёмся от списка артефактов, приведённых в ГОСТ Р 56939—2024 в п. 5.2.3. Пройдусь по пунктам этого раздела, по возможности комментируя их.

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

Из книг могу предложить:

• Талантов С.В. Безопасный С++. Руководство по безопасному проектированию и разработке программ. — Москва: Издательство АСТ, 2025. — 416 с.
• Ховард М., Лебланк Д, Виега Д. Как написать безопасный код на C++, Java, Perl, PHP, ASP.NET. — М.: ДМК Пресс, 2014. — 288 с.: ил.
• Грег Хогланд, Гари Мак-Гроу. Взлом программного обеспечения: анализ и использование кода / пер. с англ. — М.: Издательский дом "Вильямс", 2005. — 400 с.: ил.
• Макконнелл С. Совершенный код. Мастер-класс / пер. с англ. — М.: Издательско-торговый дом "Русская редакция"; СПб.: Питер, 2005. — 896 стр.: ил. (Книга не про РБПО как таковое, но хорошо описывает подходы к написанию качественного кода в целом. Будет полезна для общего повышения культуры написания кода и даст пищу для размышлений при разработке регламента оформления кода (правил кодирования) — см. п. 5.8.)
• Фаулер М. Рефакторинг: улучшение проекта существующего кода / пер. с англ. — СПб: Символ-Плюс, 2005. — 432 с.: ил.
• Мартин Р. Чистый код: создание, анализ и рефакторинг. Библиотека программиста. — СПб.: Питер, 2011. — 464 с.: ил.

Касательно курсов могу предложить сайт Учебного центра МАСКОМ. Мы с ними знакомы, проводили совместные мероприятия и записали цикл вебинаров, который вы сейчас изучаете.

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

• М БРПО-Спец. Специалист по процессам разработки безопасного программного обеспечения. 200 часов / 20 дней.
• М БРПО-01. Внедрение процессов разработки безопасного программного обеспечения в организации (для руководителей и ответственных). 40 часов/4 дня.
• М БРПО-02. Внедрение процессов разработки безопасного программного обеспечения для специалистов по информационной безопасности. 50 часов/5 дней.
• М БРПО-03. Сертификационные испытания с учётом требований по разработке безопасного программного обеспечения для экспертов органов по сертификации (испытательных лабораторий) различных систем сертификации средств защиты информации. 140 часов/14 дней.
• М БРПО-04. Формирование практических навыков по разработке безопасного программного обеспечения для разработчиков и программистов. 140 часов/14 дней.
• М БРПО-05. Методология подготовки предприятия к сертификации процессов безопасной разработки программного обеспечения средств защиты информации в соответствии с требованиями ФСТЭК России. 30 часов/3 дня.

Примечание. ФСТЭК России согласовал программу повышения квалификации М-БРПО "Специалист по процессам разработки безопасного программного обеспечения".

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

Стоит ли читать описания потенциальных уязвимостей?

Имеются такие подборки, как как CWE (Common Weakness Enumeration), OWASP Application Security Verification Standard (ASVS), SEI CERT Coding Standard.

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

Исключение, пожалуй, только OWASP Top 10 — про самые распространённые уязвимости стоит быть в курсе всем.

Лучше посвятить время общим практикам написания качественного кода, например, чтению всё той же книги "Совершенный код", которую я не устаю рекомендовать.

Однако это не значит, что данные подборки не заслуживают внимания. С ними стоит ознакомиться тем, кто в вашей компании будет отвечать за РБПО и информационную безопасность. Обычно это называется "отделом безопасности". Зная описанные там антипаттерны, они могут выявить часть дефектов безопасности на обзорах кода и консультировать других программистов, поясняя, почему стоит избегать определённых конструкций/подходов при написании кода.

Примечание. Статический анализатор PVS-Studio может выявить многие дефекты безопасности, описанные в этих стандартах. Для удобства можно включить показ соответствующих идентификаторов согласно классификациям CWE, OWASP, SEI CERT, ГОСТ Р 71207. Однако это не означает, что можно игнорировать обзоры кода с привлечением специалистов безопасности, которые могут выявить не только ошибки в коде, но и наличие высокоуровневых проблем проектирования и реализации алгоритмов.

Дополнительные ссылки:

• AppSec Table Top: методология безопасной разработки от Positive Technologies.
• Раздел "Информационная безопасность" на сайте Нabr. Там стало много фонового шума, но встречаются и хорошие полезные публикации, например от ИСП РАН.
• Цикл из 15 видеолекций на сайте ФСТЭК.

Теперь рассмотрим артефакты процесса обучения, перечисленные в ГОСТ Р 56939—2024.

Перечисленное говорит само за себя, но не забывайте, что речь идёт про процесс, а не про разовую акцию повышения квалификации сотрудников. Есть смысл "вшить" это в матрицы компетенций. Это будет помогать адаптировать (обучать) как новых сотрудников, так и постепенно повышать уровень компетенций опытных членов команды. Заодно естественным образом разделится, что должен изучать программист, а что — специалист ИБ. У них будут разные матрицы компетенций.

Тема матриц компетенций интересная, но большая и выходит за рамки этой подборки материалов. Думаю, на эту тему можно многое почерпнуть из записей докладов конференций TeamLead Conf и подобных (например 1, 2, 3). Ещё добавлю, что мы её внедрили и довольны результатами.

Когда вас условно (или буквально) посетит команда аудиторов, вам должно быть, что ей показать :) Начинайте централизовано собирать отчётную информацию. Есть смысл назначить кого-то ответственным за этот процесс, иначе в нужный момент будет сложно вспомнить всё, что происходило, и предоставить подтверждающие документы.

Это вновь пересекается с темой разработки матрицы компетенций, про которую я говорил выше.

5.3. Формирование и предъявление требований безопасности к программному обеспечению

Вебинар №3. Посвящён разбору темы формирования и предъявления требований безопасности к ПО. Приглашённый эксперт — Артём Павлов, начальник отдела управления испытаниями и контроля качества в департаменте испытаний ООО "ЦБИ". На YouTube. Слайды презентаций.

Цели третьего процесса по ГОСТ Р 56939—2024 (п. 5.3.1.1):

Необходимо спланировать и разработать регламент, как будет ставиться ТЗ для внутренних/внешних команд и контролироваться ход выполнения работ. Управление процессом рекомендуется осуществлять с использованием средств автоматизации: системы управления изменениями, системы управления задачами и т. д.

Оговаривается состав команды, чтобы не было такого, что в начале обсуждают команду высокооплачиваемых квалифицированных специалистов, а затем важные части делают стажёры :)

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

5.4. Управление конфигурацией программного обеспечения

Вебинар №4. Прошёл совместно с Антоном Недогарком — преподавателем УЦ МАСКОМ. Вместе с другими экспертами он погрузился в одну из ключевых тем стандарта ГОСТ Р 56939—2024 — управление конфигурацией программного обеспечения. На YouTube. Слайды презентаций.

Цели четвёртого процесса по ГОСТ Р 56939—2024:

Для небольших компаний с одним-двумя проектами под одну платформу пункт 5.4.1.1 может смотреться избыточным. Нумеруем релизы и всё, что ещё нужно?

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

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

При разработке регламента идентификации ПО (версий ПО, модулей ПО) можно оттолкнуться от ГОСТ 19.103—77 "Единая система программной документации. Обозначение программ и программных документов".

ГОСТ Р 56939—2024 даёт следующее определение управлению конфигурацией программного обеспечения:

Если честно, это определение мало что поясняет. Поэтому вот дополнительные ссылки:

• Иэн Бьюкэнэн. Управление конфигурацией.
• Википедия. Конфигурационное управление.

5.5. Управление недостатками и запросами на изменение программного обеспечения

Вебинар №5. Прошёл при участии Веры Багно, AppSec-инженера компании Swordfish Security. Вместе с экспертами она рассмотрела тему "Управление недостатками и запросами на изменение программного обеспечения". В ходе встречи также проводилась демонстрация работы с AppSec.Hub. На YouTube. Слайды презентаций.

Примечание. PVS-Studio интегрируется с AppSec.Hub. Подробнее:

• Документация PVS-Studio. Интеграция PVS-Studio с AppSec.Hub.
• Совместный вебинар. Интеграция статического анализа и DevSecOps: PVS-Studio и AppSec.Hub в действии.

Цели пятого процесса по ГОСТ Р 56939—2024:

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

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

Теперь рассмотрим артефакты пятого процесса ГОСТ Р 56939—2024.

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

У нас в команде PVS-Studio нет именно документа-регламента, так как мы пока не планируем проходить сертификацию, но есть заготовленные чек-листы для различных типов задач. Если до этого дойдёт, то, думаю, эти чек-листы как раз и станут основой регламента. Как я понимаю, основная идея регламента — не пропустить этап (например, тестирование) и быть уверенным, что если задача закрыта, значит она сделана. Для этого и нужны чек-листы.

Пример одной нашей заготовки, из которой формируется задача, когда выходит новая версия IDE Qt Creator. То есть на основании заготовленного чек-листа ставится задача проверить совместимость PVS-Studio с новой версией Qt Creator и в случае необходимости что-то доработать. Ссылки заменил на жирный шрифт.

Примечание. Представленный ниже список не является описанием задачи. Как и что делать описано отдельно во внутренней статье. Это именно чек-лист, чтобы что-то не забыть. И нормально, что вне контекста отдельные пункты смотрятся непонятно.

Продолжим рассматривать артефакты пятого процесса ГОСТ Р 56939—2024.

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

Каждой задаче (тикету) автоматически присваивается уникальный идентификатор. Краткая характеристика запроса на изменение ПО, естественно, должна присутствовать при постановке задачи. Если кто-то напишет в названии задачи "Сделать X", а в описании "см. subj", то тут надо... принять административные меры :)

Естественно, указывается версия ПО, модуля и т. д., когда описывается баг, чтобы его можно было воспроизвести. Ну или где какая новая функциональность нужна. Здесь вроде всё тоже очевидно. Достаточно сформулировать всё это в виде регламента и договориться, как что называется и нумеруется (см. четвёртый процесс в ГОСТ Р 56939—2024 и ГОСТ 19.103—77 — Обозначение программ и программных документов).

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

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

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

Дополнительные ссылки:

• Александр Мешков. Как выстроить эффективный процесс управления дефектами?
• Wikipedia. Система управления версиями.
• ИН-КОМ. Что такое управление изменениями в разработке программного обеспечения?
• AppSec Table Top: методология безопасной разработки от Positive Technologies (см. инициативы: "Система контроля версий" — стр. 49, "Порядок работы с дефектами" — стр. 78).

5.6. Разработка, уточнение и анализ архитектуры программного обеспечения

Вебинар №6. Приглашённым экспертом стал Игорь Хмелёв, заместитель директора специальных разработок НПО "Эшелон". В рамках мероприятия участники обсудили ключевые аспекты темы "Разработка, уточнение и анализ архитектуры программного обеспечения". На YouTube. Слайды презентаций.

Цели шестого процесса по ГОСТ Р 56939—2024:

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

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

Чтобы не забыть про какой-то важный элемент построения безопасной архитектуры, полезно предварительно обратиться к другим документам. Некоторые примеры.

Проектируя ГИС, следует сразу ознакомиться с приказом ФСТЭК №117. Он вступил в силу 1 марта 2026 года.

Создавая ПО для встраиваемых систем, стоит сразу заглянуть в ГОСТ Р 51904—2002 "Программное обеспечение встроенных систем. Общие требования к разработке и документированию".

Не забыть про какую-то из угроз поможет ГОСТ Р 58412—2019 "Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения".

Описать архитектуру и другие сущности поможет ГОСТ Р 58609—2019 "Состав и содержание информационных элементов жизненного цикла (документации)" (см. раздел 10.74 — Описание архитектуры программного продукта).

Для финтеха важен методический документ ЦБ РФ "Профиль защиты прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций". Последняя редакция вышла в конце 2025 года.

5.7. Моделирование угроз и разработка описания поверхности атаки

Вебинар №7. Прошёл вместе с приглашённым экспертом — Екатериной Рудиной, аналитиком Департамента перспективных технологий "Лаборатории Касперского". На YouTube. Слайды презентаций.

Цели седьмого процесса по ГОСТ Р 56939—2024:

При построении этого процесса важным документом является уже упомянутый в предыдущей главе ГОСТ Р 58412—2019 "Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения".

Собственно, ГОСТ Р 56939—2024 прямо на него ссылается в примечании к п.5.7.3.1:

Зачем определять поверхности атаки? Давайте просто всё защищать, проверять и тестировать... В том-то и дело, что так не получится, так как ресурсы и время ограничены. Современные программные системы содержат огромные объёмы собственного и стороннего кода. Педантично изучать и проверять весь код — невозможно и избыточно. Необходимо выделить функции/модули, которые взаимодействуют с внешним миром и, скорее всего, будут подвергаться атаке. На них и следует сосредоточиться в первую очередь с точки зрения противостояния угрозам и более тщательного анализа/проверки/тестирования.

Каковы основные способы определения поверхности атаки?

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

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

Инструменты поиска точек входа:

• Attack Surface Analyzer;
• Nikto web server scanner.

Динамический анализ кода. Основным представителем является инструмент Natch, разработанный в ИСП РАН:

• Павел Довгалюк. Как найти поверхность атаки незнакомых приложений с помощью Natch.
• Павел Довгалюк. Разглядываем CodeScoring с помощью Natch.
• SafeCode. Иван Васильев. Пример практического использования Natch для анализа.

Теперь рассмотрим применение статических анализаторов кода вообще и PVS-Studio в частности с точки зрения выявления поверхности атаки.

Многие статические анализаторы умеют выполнять taint-анализ для выявления проблемы использования недостоверных данных. В терминологии ГОСТ Р 71207—2024 это называется анализ помеченных данных (п.3.1.3):

Taint-анализ помогает выявлять код, неустойчивый к XSS-атакам (межсайтовый скриптинг), XEE-атакам (billion laughs attack), XXE-атакам (XML External Entity) и т. д.

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

Мы в анализаторе PVS-Studio тоже так делаем. Он знает о многих функциях записи и чтения, передачи данных по сети и т. д.

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

Поэтому в ГОСТ Р 71207—2024 явно написано (п.7.6):

В PVS-Studio, например, эта разметка истоков и стоков данных реализована для всех поддерживаемых языков (C, C++, C#, Java).

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

Однако не совсем точно говорить, что "статические анализаторы выявляют поверхность атаки". Скорее, поверхность атаки им нужно подсказать, и тогда они смогут выдать дополнительные полезные предупреждения.

Дополнительные ссылки:

• Павел Довгалюк. Зачем искать поверхность атаки для своего проекта.
• SafeCode 2024. Павел Довгалюк. Анализ поверхности атаки приложений и программных систем.
• Сигалов Даниил. Диссертация. Методы выявления поверхности атаки веб-приложений при помощи анализа клиентского JavaScript-кода.
• OWASP. What is Attack Surface Analysis and Why is it Important.

5.8. Формирование и поддержание в актуальном состоянии правил кодирования

Вебинар №8. Посвящён разбору темы "Формирование и поддержание в актуальном состоянии правил кодирования" совместно с приглашённым экспертом — Анной Мелеховой, старшим архитектором программного обеспечения отдела развития архитектуры операционной системы KasperskyOS. На YouTube. Слайды презентаций.

Цели восьмого процесса по ГОСТ Р 56939—2024:

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

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

Есть сразу несколько причин, почему так происходит:

• В большом (legacy) проекте чаще нужно изменить старое поведение, а не создать что-то принципиальное новое. Все основные функции в каком-то виде уже существуют, и речь, скорее, идёт о их развитии или изменения поведения. Получается, прежде чем что-то изменить, нужно найти соответствующий код и понять, как он работает.
• Часто приходится сопровождать чужой код, из-за чего бывает трудно найти нужное место и понять, как всё устроено.
• В большом проекте, если вы долго с ним работаете, даже ваш собственный код со временем становится "чужим". Во-первых, через несколько лет вы его забываете и не помните деталей реализации. Во-вторых, ваши коллеги за это время тоже могли вносить в него правки или рефакторить.
• В legacy-проектах можно по аналогии с годичными кольцами деревьев наблюдать изменения в стиле написания кода. Чаще всего это связано с появлением новых версий языка и библиотек. Эта разнородность тоже добавляет сложность к пониманию старых частей проекта.
• Известно, что с ростом проекта плотность ошибок растёт нелинейно, то есть чем больше кода, тем выше вероятность, что при его написании или изменении будет внесена ошибка. Это объясняется ростом взаимосвязей разных частей проекта, которые сложно учитывать. Рост сложности понимания влияет и на рост процента времени, который приходится тратить человеку, прежде чем сделать правку.
• Думаю, вы и сами сможете добавить пару пунктов к этому списку.

Из сказанного вытекает, что требуется делать код по возможности простым для восприятия (чтения). Также очень важно, чтобы весь код был единообразно оформлен. Если оформление единообразно, то проще прочитать, понять и исправить код коллег.

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

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

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

В любом случае код должен оформляться единообразно, иначе неизбежны проблемы при совместной разработке и поддержке проекта. А мы в рамках темы РБПО говорим о проектах, где участвуют много разработчиков, а не об индивидуальном пет-проекте.

Есть ещё одна проблема, которая возникает, если нет единого подхода к написанию и оформлению кода: как вносить правки в код коллег, оформленный в их собственном стиле? Хорошего варианта нет:

• Написать нужный код в своём стиле. Постепенно получится каша из несвязанных стилей. Это то же самое, что и отсутствие стиля написания кода. Код со временем при совместной работе будет становиться всё хуже и непонятнее для всех.
• Постараться подстроиться под код коллег и написать в их стиле. На практике не сработает, так как на самом деле программист не знает, что это за стиль. А если даже ему расскажут, он всё равно забудет или запутается, ведь сложно запомнить все варианты написания. В общем, и это нерабочий подход.
• Отрефакторить код коллег под свой стиль. Пустая трата времени и большие diff'ы, в которых будет невозможно понять, где рефакторинг стиля, а где нужные изменения.

См. также "Вредный совет N48. У каждого свой стиль".

Надеюсь, что у вас в компании уже давно принят стандарт кодирования. В таком случае достаточно это просто переоформить в регламент, а всё, что я здесь пишу, прочитать по диагонали. Если стандарта кодирования нет, внедрение РБПО — хороший момент наконец создать эту полезную вещь! Впрочем, стандарт кодирования однозначно принесёт пользу даже вне контекста РБПО. Так что если у вас его нет, прямо сейчас откройте задачу на его создание :)

Если я всё ещё не убедил, расскажу последнюю историю. Общаясь с одним человеком, который проработал в коммерческой компании почти с момента её основания до становления успешным большим бизнесом, я спросил, что бы он устроил по-другому в работе, если бы вернулся лет на 15 назад? Ответ, в том числе, содержал следующий момент:

Я бы настоял принять единый стандарт кодирования на всю компанию. Мы упустили этот момент, и сейчас мы по факту имеем свои собственный стандарты кодирования для С++ и Java в разных командах, работающих над своими проектами. Это очень неудобно, но сейчас внедрять единый стиль и переформатировать код всех этих проектов нереально.

В общем, чем раньше вы позаботитесь о единообразии, тем лучше!

Артефакты реализации требований (что, собственно, представляет собой регламент):

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

C++ программисты могут почерпнуть идеи из вот этого документа с хорошими мыслями и отсылками к другим стандартам: Coding Standards.

Если говорить про "перечень запрещённых способов кодирования, конструкций и т. п." и "примеры опасных и безопасных конструкций для используемых языков программирования", то можно взять некоторые идеи из таких стандартов, как MISRA C и MISRA C++. Однако надо понимать, что это специализированные стандарты из мира встраиваемых систем, и заимствовать что-то оттуда для других сфер программирования может быть неуместно.

Стоит отметить, что существует множество разных стандартов кодирования, таких как MISRA C/C++, CWE (Common Weakness Enumeration), OWASP Application Security Verification Standard (ASVS), SEI CERT Coding Standard и т. д. Но с точки зрения рационального использования времени бессмысленно их читать для составления правил кодирования, а затем вручную контролировать их выполнение. Для этого есть статические анализаторы кода. Собственно, в восьмой главе стандарта есть даже их упоминание:

Но статический анализ — это отдельный процесс (5.10). Восьмая же глава всё-таки про регламент написания кода, его оформление и выравнивание, правила именования переменных, функций и т. д.

Вообще, лучше всего начать с такой замечательной книги, как "Совершенный код" Стива Макконнелла ("Code Complete", Steve McConnell).

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

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

Пример рефакторинга длинной строки можно посмотреть в статье "Учимся рефакторить код на примере багов в TDengine, часть 1: про колбасу".

Ограничение на длину строк — это один из примеров, что можно включить в стандарт кодирования.

Заметить опечатку мешают не только длинные строки, но и неаккуратно отформатированные. На второй картинке пример функции из проекта Apache Flink.

@Override
public boolean equals(Object o) 
{
  ....
  CheckpointStatistics that = (CheckpointStatistics) o;
  return id == that.id &&
    savepoint == that.savepoint &&
    triggerTimestamp == that.triggerTimestamp &&
    latestAckTimestamp == that.latestAckTimestamp &&
    stateSize == that.stateSize &&
    duration == that.duration &&
    alignmentBuffered == that.alignmentBuffered &&
    processedData == processedData &&
    persistedData == that.persistedData &&
    numSubtasks == that.numSubtasks &&
    numAckSubtasks == that.numAckSubtasks &&
    status == that.status &&
    Objects.equals(checkpointType, that.checkpointType) &&
    Objects.equals(
      checkpointStatisticsPerTask, 
      that.checkpointStatisticsPerTask);
}

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

Наш анализатор подсвечивает её предупреждением: V6001 There are identical sub-expressions 'processedData' to the left and to the right of the '==' operator. CheckpointStatistics.java 229.

Вот она:

processedData == processedData

Переменная сравнивается сама с собой. Хотя ошибка найдена, лучше заниматься не её поиском, а профилактикой. Если оформить код таблицей, как показано на ниже, ошибка более заметна:

  return id                 == that.id &&
         savepoint          == that.savepoint &&
         triggerTimestamp   == that.triggerTimestamp &&
         latestAckTimestamp == that.latestAckTimestamp &&
         stateSize          == that.stateSize &&
         duration           == that.duration &&
         alignmentBuffered  == that.alignmentBuffered &&
         processedData      == processedData &&
         persistedData      == that.persistedData &&
         numSubtasks        == that.numSubtasks &&
         numAckSubtasks     == that.numAckSubtasks &&
         status             == that.status &&
         Objects.equals(     checkpointType,
                        that.checkpointType) &&
         Objects.equals(     checkpointStatisticsPerTask, 
                        that.checkpointStatisticsPerTask);

Конечно, это не гарантирует, что ошибку не пропустят. Речь о том, чтобы снизить вероятность допустить её и просмотреть на обзорах кода.

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

  return    id                 == that.id
         && savepoint          == that.savepoint
         && triggerTimestamp   == that.triggerTimestamp
         && latestAckTimestamp == that.latestAckTimestamp
         && stateSize          == that.stateSize
         && duration           == that.duration
         && alignmentBuffered  == that.alignmentBuffered
         && processedData      == processedData
         && persistedData      == that.persistedData
         && numSubtasks        == that.numSubtasks
         && numAckSubtasks     == that.numAckSubtasks
         && status             == that.status
         && Objects.equals(     checkpointType,
                           that.checkpointType)
         && Objects.equals(     checkpointStatisticsPerTask, 
                           that.checkpointStatisticsPerTask);

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

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

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

Кроме того, можно настроить и использовать инструменты автоматизированного форматирования кода:

• ClangFormat;
• Uncrustify;
• Prettier;
• go fmt.

Дополнительные ссылки:

• Лекция 8. Стандарт кодирования PVS-Studio и приёмы при разработке эффективных С++ диагностик (видео 2019 года, поэтому кое-что у нас уже поменялось. Сейчас я бы рассказал немного по-другому и привёл бы иные примеры. Тем более учитывая, что за это время мы переписали ядро C++ анализатора. Но в целом полезно, предлагаю к просмотру).
• Для примера предлагаю познакомиться со стандартом кодирования на языке C++, который используется командой PVS-Studio на момент 2025 года.
• Wikipedia. Стандарт оформления кода (см. отсылки на стандарты).

5.9. Экспертиза исходного кода

Вебинар №9. Эксперты PVS-Studio и УЦ "МАСКОМ" обсудили экспертизу исходного кода, "запахи в коде" и рефакторинг. На YouTube. Слайды презентаций.

Цели девятого процесса по ГОСТ Р 56939—2024:

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

Первый вид работ — экспертиза кода, создаваемого в компании штатными разработчиками. Другими словами, это классические обзоры кода (code review), только более упорядоченные, чем обычно это бывает при разработке ПО. Именно к этому относятся артефакты из п 5.9.3, такие как "описание основных проверок (например сценариев, шаблонов, чек-листов) и т. д. К этой теме я вернусь в следующей части.

Про второй и третий вид работ говорит вот этот комментарий:

Второй вид работ — экспертиза стороннего кода, который команда включает в проект. Понятно, что нереально проводить полноценный обзор кода подключаемых библиотек. Здесь, скорее, идёт речь о таких вещах, как определение для заимствованного кода поверхности атаки (см. процесс 7) с помощью инструментов и привлечения экспертов.

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

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

Что делать, если подключается сторонняя библиотека на языке, для которого у вас нет анализатора? Смотрите, с точки зрения РБПО, если вы включили в проект сторонний код, то теперь это ваш код, за который вы ответственны. Следовательно, вы должны выбрать дополнительный инструмент статического анализа и включить его в свои процессы разработки.

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

Продолжим читать девятый раздел ГОСТ Р 56939—2024. Требования к реализации:

На языке программистов: разработать порядок и чек-листы проведения обзоров кода (code review). Скорее всего, практика обзоров кода так или иначе уже существует в вашей компании, а с внедрением РБПО просто пришло время её формализовать, сделать более чёткой/строгой и обязательной.

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

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

Дениел Фридмен и Джеральд Вайнеберг (Daniel Freedman and Gerald Weinberg)

Далее.

Речь про системы автоматизирования обзоров кода — не путать со статическим анализом, — в том числе позволяющие делать это удалённо.

Примером такой системы является RBCommons. Мы пробовали её в далёком 2016 году, но она не прижилась. Сейчас единого подхода нет, действуем из соображений удобства: кто-то собирается просто в офисе возле компьютера, кто-то созванивается в Zoom с демонстрацией экрана, кто-то в GitHub смотрит PR коллег. В общем, мы ценим процесс обзор кода, но пока не чувствуем потребности в жёсткой автоматизации. Возможно, коллектив ещё относительно небольшой, квалифицированный, и у нас просто нет проблемы, что кто-то игнорирует процессы обзора кода.

Теперь перейдём к артефактам реализации требований девятого процесса ГОСТ Р 56939—2024:

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

Проводя обзор кода, важно не забывать про такие высокоуровневые задачи, как:

• обучение членов команды, передача опыта и знаний о проекте новым сотрудникам;
• поиск высокоуровневых ошибок, недостатков выбранных архитектурных решений, неэффективных/опасных подходов в реализации.

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

Здесь, думаю, программистам тоже всё понятно. Остановлюсь только на пункте "вопросы к частям кода, экспертиза которых затруднена и требует дополнительных разъяснений".

Считается, что на обзорах кода тот, кто написал код, не может давать разъяснения о его работе. Если код непонятен коллегам, его надо переписать или снабдить комментариями. Код должен стать самодостаточным для понимания.

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

P.S. Про написание комментариев. Комментарии должны отвечать не на вопрос "что делаем?", а на вопрос "зачем/почему делаем?". Подробнее — в главе N53 "60 антипаттернов для С++ программиста".

5.10. Статический анализ исходного кода

Вебинар №10. Эксперт PVS-Studio Глеб Асламов выступил с подробным разбором возможностей инструментов статического анализа. Особое внимание уделили ГОСТ 71207—2024, который посвящён вопросам статического анализа, а также его связи с 10-м процессом из ГОСТ Р 56939. Участники обсудили, как эти стандарты дополняют друг друга, а также ключевые вопросы интеграции инструментов статического анализа в новые и существующие проекты. На YouTube. Слайды презентаций.

Цели 10-го процесса по ГОСТ Р 56939—2024:

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

Попробую сделать что-то среднее. Начну с ссылок, а затем всё же бегло пройдусь по пунктам 10-го процесса.

Начнём с темы статического анализа в целом:

• Терминология. Статический анализ кода.
• Почему обзоры кода — это хорошо, но недостаточно.
• Как внедрить статический анализатор кода в legacy проект и не демотивировать команду.

Рассмотрение 10-го процесса в ГОСТ Р 56939—2024 неразрывно связано с другим ГОСТ Р 71207—2024 "Статический анализ программного обеспечения". В нём говорится о том же, только более подробно и конкретно.

В общем-то, можно сразу идти изучать ГОСТ Р 71207—2024 и внедрять описанные в нём рекомендации и процессы, а затем уже вернуться к артефактам ГОСТ Р 56939—2024 (п. 5.10.3).

Про ГОСТ Р 71207—2024 мы много писали и рассказывали. Начать можно с обзорного доклада, с которым я выступал на конференции GigaConf 2024.

Использование статического анализатора в разработке безопасного программного обеспечения (ГОСТ Р 71207—2024) на примере PVS-Studio. При разработке безопасного программного обеспечения должны использоваться статические анализаторы кода. Однако оставались открытыми некоторые вопросы: какими свойствами необходимо обладать инструментам анализа? какие ошибки обязаны выявлять и как в целом должны выполняться проверки кода? Разъяснения даёт введённый в действие 1 апреля 2024 года ГОСТ Р 71207—2024 "Статический анализ программного обеспечения". Рассмотрим, что на практике означают некоторые приведённые в нём термины, как выглядят критические ошибки и как правильно при разработке использовать инструментальные средства для анализа кода. Слайды презентации.

Если вам в первую очередь интересен язык C++, то знакомство с стандартом лучше начать с доклада "Cтатический анализ C++ кода по ГОСТ Р 71207—2024 на примере PVS-Studio". Слайды презентации.

Если обзорных докладов недостаточно и хочется познакомиться с ГОСТ Р 71207—2024 более детально, то предлагаю этот цикл из пяти вебинаров:

• Общее описание и актуальность;
• Терминология;
• Критические ошибки;
• Технологии анализа кода;
• Процессы.

Вернёмся к ГОСТ Р 56939—2024. По порядку пройдёмся по артефактам.

Здесь предлагаю открыть ГОСТ Р 71207—2024 и заимствовать рекомендации для составления регламента из пятого раздела "Требования к внедрению и порядку выполнения статического анализа". На тему критических ошибок предлагаю заглянуть в 6-м разделе ГОСТ Р 71207—2024 "Классификация критических ошибок, находимых статическими анализаторами". Про периодичность — см. раздел 5.

Важный и сложный пункт "критерии выбора инструментов статического анализа".

Выбор — интересный вопрос. Статических анализаторов много: List of tools for static code analysis.

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

В данный момент нет явных ограничений на используемые инструменты. Однако к выбору надо подходить вдумчиво. Подробнее эта тема раскрыта в "Методической рекомендации № 2025-07-011". В том числе там говорится про испытания статических анализаторов кода, которые прошли в 2025 году.

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

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

Одним из таких анализаторов как раз является PVS-Studio. О его соответствии стандартам подробно описано в статье "Статический анализатор кода PVS-Studio в 2026: ГОСТ Р 71207, ГОСТ Р 56939, приказ ФСТЭК №117".

Продолжаем рассматривать артефакты 10-го процесса ГОСТ Р 56939—2024.

Про настройку анализаторов см. п.5.4 в ГОСТ Р 71207—2024.

Что такое критические ошибки, я уже разбирал, но на всякий случай ещё раз дам ссылки:

• В ГОСТ Р 71207—2024 см. раздел 6.
• Страница терминология PVS-Studio: критические ошибки (потенциальные уязвимости).
• Вебинар "Критические ошибки".

Анализатор PVS-Studio выявляет все типы критических ошибок и помечает их специальным маркёром. Подробнее про разметку критических ошибок и работу с ними можно прочитать в статье "Фильтрация предупреждений PVS-Studio, выявляющих критические ошибки (согласно классификации ГОСТ Р 71207—2024)".

На тему разметки можно за основу взять "Инструкцию по проведению разметки результатов статического анализа ядра Linux", составленную "Центром исследований безопасности системного программного обеспечения".

Для расширенной работы с результатами анализа и их разметки мы предлагаем решение — PVS-Studio Atlas. С ним вы можете познакомиться в дополнительном вебинаре "PVS-Studio Atlas — новая платформа контроля качества кода".

Команда PVS-Studio представила новый продукт — PVS-Studio Atlas, предназначенный для работы с результатами анализа кода: просмотра, аналитики, разметки и формирования отчётов для сертификационных лабораторий и ФСТЭК. На YouTube. Слайды презентаций.

Проект имеет две редакции: Atlas Viewer и Atlas Server.

Atlas Viewer — десктопное приложение для работы с одним отчётом анализатора PVS-Studio. Основные возможности:

• Запуск на любой ОС: Windows, macOS, Linux (включая российские дистрибутивы).
• Открытие и просмотр отчётов от анализатора PVS-Studio в форматах .json и .plog.
• Фирменная таблица PVS-Studio для навигации по предупреждениям.
• Разметка результатов с помощью изменения уровня критичности, статуса и комментирования.
• Сохранение отчёта в формате .pvsmap с разметкой и исходными файлами (при необходимости).
• Сохранение отчёта с разметкой результатов (актуально для сертификационных лабораторий, ФСТЭК и отделов безопасности).

Atlas Server — серверное решение для работы с отчётами статических анализаторов кода в многопользовательском режиме. Основные возможности:

• Все возможности PVS-Studio Atlas Viewer.
• Управление качеством проектов (включая ветки разработки).
• Загрузка регулярных отчётов анализа для ведения статистики.
• Назначение исполнителей по исправлению предупреждений.
• Поддержка отчётов в формате SARIF.

P.S. Отзывы о PVS-Studio:

• Как крупнейший в РФ производитель сетевого оборудования Eltex сделал разработку безопаснее благодаря PVS-Studio.
• Как СВД ВС использует PVS-Studio в сертифицируемой разработке защищённой ОС.Системы с конструктивной информационной безопасностью.

5.11. Динамический анализ кода программы

Вебинар №11. Эксперты Центра сертификации АО "НПО "Эшелон" — Никита Чуманов и Артём Ежов, а также руководитель группы разработки СЗИ компании "СВД Встраиваемые системы" Евгений Дужак поделились профессиональными знаниями и практическим опытом, подробно раскрыв ключевые особенности процесса "Динамический анализ кода программы". На YouTube. Слайды презентаций.

Также вместе с Михаилом Парфеновым (AppSec Lead, DPA Analytics) мы организовали дополнительный вебинар, посвящённый разновидностям динамического анализа для frontend-приложений.

Безопасность frontend-приложений: особенности, угрозы и анализаторы класса FAST (Frontend Application Security Testing). Frontend-приложения (личные кабинеты, онлайн-банки, маркетплейсы, сайты, лендинги и т. д.) выполняются в браузере пользователя — традиционной "слепой" зоне для безопасности. В вебинаре рассмотрены актуальные угрозы, крупнейшие инциденты, построение модели угроз и то, как применение анализатора класса FAST (Frontend Application Security Testing) снижает риски и делает frontend-приложения безопасными. Объясняется, почему классические анализаторы имеют низкую достоверность для frontend-приложений, и как использовать FAST-анализатор в процессах РБПО по ГОСТ Р 56939—2024. На YouTube. Слайды презентаций.

Цели 11-го процесса по ГОСТ Р 56939—2024:

В том числе этот процесс подразумевает и фаззинг-тестирование (п.5.11.2.2):

Определение этих терминов в ГОСТ Р 56939—2024:

Термин динамический анализ кода программы мы рассматривали ранее.

Инструментов достаточно много, например:

• Valgrind;
• AddressSanitizer;
• ThreadSanitizer;
• MemorySanitizer;
• ИСП Fuzzer.

Но учтите, что очень скоро выйдет ГОСТ "Динамический анализ программного обеспечения". Описанные в нём требования к инструментальным средствам могут сказаться на подходе к их выбору. Однако на момент подготовки этого материала стандарт не опубликован, и говорить про него рано.

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

О проблематике, что динамический анализ — это широкое понятие, хорошо написал Дмитрий Пономарёв в статье "Многоликий динамический анализ". Кстати, эта статья опубликована в третьем номере журнала BIS Journal за 2025 год, которой как раз посвящён динамическому анализу.

Видимо, из-за этих разночтений в понимании темы динамического анализа недавно вышла методическая рекомендация №2025-07-010, уточняющая, что должно включать фаззинг-тестирование:

Дополнительные ссылки:

• Лекция про фаззинг от ИПС РАН. "Особенности фаззинг-тестирования при проведении сертификационных испытаний", "Подходы к фаззинг-тестированию управляемого кода" и т. д.
• Осипов Станислав. Особенности подачи входных данных при фаззинге в режиме Persistent Mode на примере Libfuzzer + CURL.
• Positive Hack Days. Фаззинг как основа эффективной разработки на примере LuaJIT.
• Центр исследований безопасности системного программного обеспечения. Методика фаззинг-тестирования ядра.
• Никита Догаев. Fuzzing-тестирование. Практическое применение.
• Николай Шаплов. Как работает fuzzing-тестирование. Рассказ простым языком.
• Цикл статей по фаззингу сокетов.
• Подборка материалов по фаззингу, опубликованная к канале Динамика::Доверенная разработка (чат сообщества ФСТЭК России и ИСП РАН в области разработки безопасного и качественного ПО).
• Максим Пелевин. Анатомия фаззинга для ядра Linux.

5.12. Использование безопасной системы сборки программного обеспечения

Вебинар №12. Специалисты Игорь Хмелев (АО "НПО "Эшелон") и Алексей Захаров (Axiom JDK) представили анализ темы использования безопасной системы сборки программного обеспечения, основанный на практических кейсах и профессиональном опыте. На YouTube. Слайды презентаций.

Цели 12-го процесса по ГОСТ Р 56939—2024:

Упрощённо: разработать регламент использования ключей оптимизации, чтобы в последний момент кто-то не решил: "А давайте при сборке релиза впишем -o3 вместо -o2" (имеются в виду настройки оптимизации). Такие непродуманные и непроверенные действия могут приводить к неожиданным сбоям в работе приложений.

В стандарте ГОСТ Р 56939—2024 не сказано про использование безопасных компиляторов или ГОСТ Р 71206—2024: "Разработка безопасного программного обеспечения. Безопасный компилятор языков С/С++. Общие требования", но его уместно здесь вспомнить.

Область применения ГОСТ Р 71206—2024 (раздел 1):

На данный момент существуют следующие компиляторы, выполняющие требования к функциям безопасности из ГОСТ Р 71206—2024:

• SAFEC (на основе GCC);
• Safelang (на основе Clang).

Впрочем, безопасные системы сборки — это не только С/С++ и ГОСТ Р 71206. В вебинаре как раз рассматривался и мир Java. См. также статью "Безопасность приложений: инструменты и практики для Java-разработчиков".

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

Дополнительные ссылки:

• Рекомендации по обеспечению безопасности системы сборки.
• Как обеспечить безопасность сборки ПО: управляем внешними зависимостями.

5.13. Обеспечение безопасности сборочной среды программного обеспечения

Вебинар №13. Экспертом выступил Роман Байталов, архитектор системных решений в GitFlic. На YouTube. Слайды презентаций.

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

• Новость. GitFlic и PVS-Studio: интеграция для безопасной разработки.
• Документация PVS-Studio. Запуск PVS-Studio в GitFlic.

Цели 13-го процесса по ГОСТ Р 56939—2024:

Это отчасти схоже с процессом 12, но только здесь не про сборку ПО, а про среду/инфраструктуру сборки в целом. Речь идёт о предотвращении проблем, связанных с неожиданным изменением этой среды, или использовании каких-то опасных инструментов/компонентов.

Для этого требуется в первую очередь:

• Утвердить права доступа к среде сборки ПО и хранилищу результатов сборки ПО. Такие образом снижаются риски воздействия на цепочку поставки или подмену дистрибутива изнутри компании;
• Обеспечивать регистрацию всех выполняемых действий при сборке ПО в журналах аудита. Также должны быть прописаны сроки хранения этих журналов;
• Результаты сборки ПО должны помещаться в выделенное хранилище;
• Если проект этого требует, обеспечивать возможность повторяемости сборки ПО;
• Обеспечивать защиту каналов связи с внешними источниками данных для обеспечения конфиденциальности информации, обрабатываемой в сборочной среде.

Требуется также разработать схематическое изображение сборочной среды: серверы, узлы, контейнеры, связи, позволяющие отследить порядок сборочных действий, компоненты сборочной среды, инструменты статического анализа и т. д. Рекомендуется использовать UML, IDEF, С4.

В целом польза такой схемы мне понятна: она поможет понять новым сотрудникам и тем, кто занят аудитом, как устроена среда сборки. Здесь всплывает мой личный опыт времён обучения в университете, где IDEF в курсовых использовался просто потому, что он должен там быть :) Я к тому, что надо постараться, чтобы такая схема была действительно полезна, а не просто нарисована. Что будет отличать одно от другого, к сожалению, затрудняюсь подсказать. Попробуйте показать схему стороннему человеку и спросите, добавляет ли она ясности.

См. также "Ларец" — импортозамещённая система хранения собственных сборок и проксирования корпоративных репозиториев артефактов в экосистеме "Лукоморье".

5.14. Управление доступом и контроль целостности кода при разработке программного обеспечения

Вебинар №14. Экспертом вновь выступил Роман Байталов, архитектор системных решений в GitFlic. Была продемонстрирована интеграция GitFlic с PVS-Studio. На YouTube. Слайды презентаций.

Примечание. Во время демонстрации работы GitFlic с PVS-Studio часть срабатываний не попала в SARIF-отчёт, потому что при запуске утилиты plog-converter не был указан флаг -a. Без него утилита включает в отчёт только срабатывания диагностических правил общего назначения уровней 1 и 2. Чтобы сохранить все срабатывания из исходного отчёта, нужно передать флагу -a значение ALL. Подробнее о флагах утилиты plog-converter можно прочитать в нашей документации.

Цели 14-го процесса по ГОСТ Р 56939—2024:

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

В том числе это и про систему контроля версий и правила работы с ней. Причём, выбирая систему контроля версий, теперь стоит учитывать, кто её разрабатывает. Рационально отдавать предпочтением отечественным разработкам, например, GitFlic.

Проблема, что кто-то добавит закладку в код, может показаться надуманной, если обзор кода внедрён как обязательный процесс (процесс 9 — "Экспертиза исходного кода").

Но можно придумать, как скрыть закладки. Например, можно вспомнить приём использования невидимых символов, получивший название Trojan Source. За подробностями и примерами можно заглянуть в документацию PVS-Studio: V1076. Code contains invisible characters that may alter its logic. Consider enabling the display of invisible characters in the code editor.

Сейчас этот метод уже не очень актуален, так как редакторы и другие инструменты показывают такие символы. Но всегда придумают ещё что-то новое.

Дополнительные ссылки:

• Atlassian. Что такое контроль версий?, Управление исходным кодом и т. д.
• Yandex Cloud. Система контроля версий.
• Wikipedia. List of version-control software.
• Wikipedia. Comparison of version-control software.
• Positive Technologies. Контроль целостности кода функций.

5.15. Обеспечение безопасности используемых секретов

Вебинар №15. Посвящён теме "Обеспечение безопасности используемых секретов". В качестве экспертов выступили Антон Володченко, руководитель разработки продуктов в CodeScoring, и Пётр Козленков, руководитель службы информационных технологий в PVS-Studio. На YouTube. Слайды презентаций.

Цели 15-го процесса по ГОСТ Р 56939—2024:

Что является секретом, а что — нет, зависит от проекта и подхода к разработке. Кроме того, хранить что-то в открытом виде в файлах, работа над которыми ведётся в закрытом контуре, скорее всего, более безопасно, чем хранить это на внешних ресурсах. Но это не точно :) Всё зависит от многих "если". Собственно, поэтому в стандарте есть примечание:

Выявлять "лежащие, где не надо" секреты можно, во-первых, внутренним аудитом. Во-вторых, стандарт рекомендует регулярно применять для этого средства статического и композиционного анализа и другие специализированные инструменты (Gitleaks, TruffleHog, OWASP DeepSecrets, Kingfisher и т. п.)

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

Примером простых систем для решения некоторых задач являются всем знакомые утилиты хранения паролей, такие как KeePass. Про комплексные решения можно легко найти информацию в интернете. Статьям в духе "10 лучших программ для управления секретами" я не очень доверяю, так что лучше сами :) Для начала можно заглянуть сюда:

• Как управлять секретами, чтобы избежать утечки данных.
• Управление секретами: путь от Opensource до Enterprise.
• Обзор StarVault 1.2, системы управления секретами и защиты доступа.
• StarVault + Postgres Pro: тестирование связки для безопасного управления секретами.

5.16. Использование инструментов композиционного анализа

Вебинар №16. Проведён вместе с экспертами компании CodeScoring — Алексеем Смирновым, основателем и генеральным директором, и Антоном Володченко, руководителем разработки продуктов. Их участие позволило углубить анализ темы и дополнить обсуждение практическими рекомендациями. На YouTube. Слайды презентаций.

Англоязычное название и сокращение — Software Composition Analysis (SCA).

Цели 16-го процесса по ГОСТ Р 56939—2024:

И этот, и следующий 17-ый процесс касаются темы уязвимостей, связанных с цепочками поставок. Разница в том, что, говоря про композиционный анализ (SCA), имеется в виду выявление ставших уже известными непреднамеренных — и иногда преднамеренных — уязвимостей в используемых библиотеках. Некую ошибку, оказалось, можно эксплуатировать, и она стала новой уязвимостью. Про неё узнали и теперь задача SCA — уведомить разработчиков об этом. Задача разработчиков, соответственно, обновить старую уязвимую версию библиотеки на новую, где уязвимость устранена.

Процесс 17 — "Проверка кода на предмет внедрения вредоносного программного обеспечения через цепочки поставок". Это предупредительная мера как от случайных ошибок, так и злонамеренных закладок, которые иногда могут маскироваться под ошибки. Когда такие уязвимости будут обнаружены, композиционный анализ также поможет их устранить в различных проектах. Но это будет потом. Задача 17-го процесса — подстраховать от этого (снизить риски). Более того, если речь идёт о внешних, но не открытых компонентах, то ждать помощи со стороны SCA не приходится. Впрочем, про этот процесс мы поговорим позже.

К цепочкам поставок нужно относиться очень внимательно. Количество атак через них всё увеличивается, и этот тренд, видимо, ещё долго будет сохраняться. Сейчас 1/3 в OWASP Top 10 за 2025 — Software Supply Chain Failures. Свежий пример: "В ходе атаки GhostAction скомпрометировано 817 репозиториев на GitHub".

Недавний круглый стол на рассматриваемую тему: "Цепочка поставок как угроза: как контролировать риски стороннего ПО".

Иногда неприятности могут прийти оттуда, откуда и не ждёшь. Например, масла в огонь могут подливать AI-агенты, заимствующие несуществующие пакеты, которые можно заранее подготовить и подсунуть. См. интересный доклад Алексея Смирнова "О влиянии применения ассистентов программиста на процессы безопасной разработки".

Выбирая себе SCA инструмент, следует учитывать, что скоро появится ГОСТ "Композиционный анализ программного обеспечения". Уже есть проект этого стандарта. На мой взгляд, стоит обратить внимание на Codescoring.

P.S. В стандарте не упоминается SBOM (Software Bill of Materials), но это важная сущность в задаче контроля цепочек поставок. Это перечень компонентов, библиотек и зависимостей, которые входят в состав программного приложения, а также информация о лицензиях, версиях и других метаданных, связанных с этими компонентами. SBOM улучшает прозрачность (обеспечивает понимание того, из чего состоит программный продукт), ускоряет реагирование на инциденты, помогает управлять безопасностью.

Дополнительные ссылки:

• Wikipedia. Software composition analysis.
• SCA на языке безопасника.
• Алексей Смирнов. Проверка open source: защита цепочки поставок и эффективный композиционный анализ.
• Инструкция по SCA: генерация SBOM, инструменты, отличия.
• Алексей Смирнов. Построить SBoM, вырастить SDL-политики, воспитать культуру безопасной разработки.
• Алексей Смирнов. Не проверив Open Source "под капотом" продукта, нельзя утверждать, что он безопасен.
• Practical Guide to NTIA Compliant SBOM.
• Атаки через репозитории кода: что мешает сделать Open Source безопаснее.
• Методическая рекомендация №2025-09-012. Алгоритм представления перечня заимствованных программных компонентов с открытым исходным кодом (далее — SBOM).

5.17. Проверка кода на предмет внедрения вредоносного программного обеспечения через цепочки поставок

Вебинар №17. Его нам вновь помог провести Алексей Смирнов — основатель и генеральный директор CodeScoring. На YouTube. Слайды презентаций.

Цели 17-го процесса по ГОСТ Р 56939—2024:

Для этого требуется (п. 5.17.2.1):

А иначе "Красивая иконка оказалась приманкой. Разработчик Ethereum потерял всё за один клик". Причём есть прогноз, что подобный обходной путь атаки будет набирать популярность.

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

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

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

Здесь уместно вспомнить 50-й пункт приказа ФСТЭК №117 от 11.04.2025. Вот что там говорится:

См. также публикацию "Аутсорсинг и приказ ФСТЭК №117, теория РБПО, инструменты".

Из взыскательного подхода к РБПО выбивается п.5.17.3.5:

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

Дополнительные ссылки:

• Атаки на цепочки поставок: как защитить своё программное обеспечение?
• Open software supply chain attack reference (OSC&R).
• AppSec Каталог - OSA.
• Supply-Chain Фаервол.
• Впервые цепочки поставок ПО были атакованы с использованием открытого кода (2023).
• Ошибка в обработчике GitHub Actions привела к публикации вредоносных релизов Ultralytics.
• Атака s1ngularity взломала 2180 GitHub-аккаунтов и раскрыла тысячи секретов.

5.18. Функциональное тестирование

Вебинар №18. Эксперты PVS-Studio и Учебного Центра "МАСКОМ" теоретически и на практике рассмотрели виды функционального тестирования. На YouTube. Слайды презентаций.

Цели 18-го процесса по ГОСТ Р 56939—2024:

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

Включает разные виды тестирования, позволяющие убедиться, что "ПО делает то, что должно делать".

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

Автоматизированное тестирование. Используются программные средства для выполнения тестов и проверки их результатов, что помогает сократить время тестирования и упростить его процесс.

Дымовое тестирование. Минимальный набор тестов на явные ошибки в основной функциональности. Дымовые тесты позволяют за короткое время определить, готова ли программа к более глубокому тестированию.

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

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

Интеграционные тесты. Проверяют взаимодействие и правильную работу двух или более программных модулей, компонентов или систем при их совместной работе. Примером такой проверки может служить тестирование совместимости плагина PVS-Studio с новой версией Qt Creator, которая упоминалась при рассмотрении пятого процесса.

Для функционального тестирования PVS-Studio мы больше всего внимания уделяем регрессионным тестам. Это связано с особенностями проекта. Важно следить, что после правки, например, сбора какой-то информации из AST-дерева, не пропадут полезные срабатывания или не вылезут бессмысленные (ложные). Для этого у нас написаны специальные вспомогательные программы, которые запускают анализаторы на наборах открытых проектов (ядра анализаторов и наборы проектов различны для разных языков), а затем позволяют быстро изучать изменения в отчётах, которые выдают ядра анализатора. Если интересно, чуть подробнее ознакомиться с нашей внутренней кухней тестирования можно в докладе "Специфика разработки и тестирования статического анализатора".

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

Дополнительные ссылки:

• Евгений Балыков. Тестирование программных средств.
• Блог IBS. Что такое функциональное тестирование?
• Терминология PVS-Studio. Тестирование.
• Телеграм-канал "Тестировщики нужны".
• Алина Медник. Функциональное тестирование: что это, этапы, виды и инструменты использования.
• Записи докладов конференции SQA Days (конференция в области обеспечения качества программного обеспечения).
• Записи докладов конференции Heisenbug (конференция по тестированию программного обеспечения не только для тестировщиков).

5.19. Нефункциональное тестирование

Вебинар №19. Эксперты PVS-Studio и Учебного центра "МАСКОМ", обсудили ключевые вопросы, касающиеся нефункционального тестирования. На YouTube. Слайды презентаций.

Цели 19-го процесса по ГОСТ Р 56939—2024:

Можно сказать так: функциональное тестирование проверяет, что ПО делает то, что должно делать. А нефункциональное проверяет:

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

В рассматриваемом разделе под нефункциональным тестированием понимаются следующие проверки:

Дополнительные ссылки:

• QA_Bible. Нефункциональное тестирование (Non-Functional testing).
• Илья Рубцов. Нефункциональное тестирование: цели, инструменты, виды нефункциональных тестов.
• Нефункциональные проверки при тестировании мобильных приложений.
• Wikipedia. Non-functional testing.
• Алексей Симкин. Гайд по тестированию локализации и интернационализации, а также большой и полезный checklist.

5.20. Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения

Вебинар №20. Приглашённым спикером выступил Игорь Хмелёв, заместитель директора по специальным разработкам НПО "Эшелон". Совместно с экспертами он детально рассмотрел тему обеспечения безопасности при выпуске эксплуатационной версии программного обеспечения. На YouTube. Слайды презентаций.

Цели 20-го процесса по ГОСТ Р 56939—2024:

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

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

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

Также процесс предписывает обеспечить возможность проверки целостности ПО (п.5.20.2.3-5.20.2.4):

Речь идёт о подписи в исполняемых файлах и/или контрольных суммах, которые можно проверить.

Дополнительные ссылки:

• Мазеин Михаил. Задача готова! Или нет? Definition of Done и зачем он нужен.
• Что такое приёмочное тестирование?
• Wikipedia. Подпись исполняемого кода.
• Автоматизация подписи кода в современных условиях.
• УБИ.145. Угроза пропуска проверки целостности программного обеспечения.

5.21. Безопасная поставка программного обеспечения пользователям

Вебинар №21. Разобраться в вопросах безопасной поставки ПО нам помогли коллеги из компании Swordfish Security — Мария Рачёва, ведущий аналитик процессов безопасной разработки, и Александр Гадай, руководитель службы консалтинга. На YouTube. Слайды презентаций.

Цели 21-го процесса по ГОСТ Р 56939—2024:

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

Например, меры защитят от того, чтобы кто-то в компании подменил дистрибутив. Это реализуется за счёт того, что:

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

Я затрудняюсь оставить интересные комментарии по этому процессу. У нас самих, например, всё относительно просто, так как у нас одна ветка релизов и нет деления на разные кастомные сборки для разных клиентов. Это упрощает поставку и сопровождение.

Зато из-за технической сложности продукта у нас и документация большая и сложная. При сборке всей документации в PDF-файл получается более 1200 страниц. На её обновление и пополнение тратится немало сил. Но по-другому нельзя, так как это неотъемлемая часть поставки, про что говорит и ГОСТ в требованиях (п.5.21.2.4):

5.22. Обеспечение поддержки программного обеспечения при эксплуатации пользователями

Вебинар №22. Эксперты PVS-Studio и Учебного Центра "МАСКОМ" рассмотрели вопросы поддержки программного обеспечения при его эксплуатации пользователями. На YouTube. Слайды презентаций.

Цели 22-го процесса по ГОСТ Р 56939—2024:

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

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

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

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

Вернёмся обратно к теме построения процесса поддержки. На эту тему есть следующие хорошие материалы:

• ГОСТ Р ИСО/МЭК 14764-2002. Информационная технология. Сопровождение программных средств.
• Wikipedia. Сопровождение программного обеспечения.
• Роль технической поддержки программного продукта в SDLC.

Примеры разделов на сайте компаний про сопровождение ПО:

• Лаборатории Касперского. Правила поддержки Программного Обеспечения Лаборатории Касперского.
• Открытая мобильная платформа. Техническая поддержка программных продуктов.
• РЕД СОФТ. Положение о технической поддержке операционной системы "РЕД ОС".
• Киберпротект. Положение о сопровождении ПО.
• Securitm. Правила технической поддержки.

5.23. Реагирование на информацию об уязвимостях

Вебинар №23. Приглашённым экспертом стал Дмитрий Частухин, важный технический директор Hexway (да, у него такая должность — прим.). Его экспертиза позволила с практической точки зрения рассмотреть вопросы реагирования на информацию об уязвимостях. На YouTube. Слайды презентаций.

Цели 23-го процесса по ГОСТ Р 56939—2024:

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

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

Часто этот процесс отсутствует. Вернее, к полученной информации об угрозах относятся точно так же, как и к сообщениям об ошибках. Дефекты безопасности попадают в багтрекеры наравне с другими багами и ждут своей очереди... иногда очень долго. Другими словами, часто в компаниях выстроен 22-й процесс "Обеспечение поддержки программного обеспечения при эксплуатации пользователями", но не выстроен 23-й.

На практике это может выглядеть следующим образом. Я открываю задачу в багтрекере проекта о том, что в некоторых функциях не происходит очистка приватных данных. Компилятор в процессе оптимизации удалит вызов функции memset для зануления буфера, так как затем этот буфер более не используется. В общем, речь про CWE-14: Compiler Removal of Code to Clear Buffers.

Я не утверждаю, что это прям ужас-ужас какая ошибка. Она может ни на что не влиять и, скорее всего, эти незатёртые данные невозможно как-то заполучить и использовать. И тем не менее это вполне себе дефект безопасности, который согласно ГОСТ Р 71207—2024 можно классифицировать как критическую ошибку (6.3.г — "Ошибки некорректного использования системных процедур и интерфейсов, связанных с обеспечением информационной безопасности (шифрования, разграничения доступа и пр.)"). Если речь идёт о РБПО, то такую ошибку следует просто на всякий случай сразу исправить и жить дальше спокойно. Тем более, что правка несложная.

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

Чтобы такого не происходило, согласно ГОСТ Р 56939—2024 следует разработать и внедрить регламент (п.5.23.3.1):

Рассматриваемый процесс также пересекается c композиционным анализом, если речь идёт о нахождении уязвимостей в сторонних используемых компонентах.

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

Дополнительные ссылки:

• Терминология. Уязвимость нулевого дня.
• Станислав Мриль. Всё об управлении уязвимостями в 2025: Vulnerability Management.
• Positive Technologies: раскрытие уязвимостей и опыт взаимодействия исследователей и вендоров в 2022–2023 годах.
• Сергей Уздемир. Управление уязвимостями: ожидание – реальность и рекомендации.
• Руслан Рахметов. Поиск и предотвращение уязвимостей в ПО: эффективные методики.
• Порядок подачи уязвимости в базу ФСТЭК России: пошаговая инструкция.

5.24. Поиск уязвимостей в программном обеспечении при эксплуатации

Вебинар №24. С помощью приглашённых экспертов — Артёма Храмых (AKTIV.CONSULTING), Алексея Морозова и Алины Ким (ГК "Эшелон") — разобрались в вопросах поиска уязвимостей в программном обеспечении при эксплуатации. На YouTube. Слайды презентаций.

Цели 24-го процесса по ГОСТ Р 56939—2024:

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

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

Во-первых, SCA инструменты могут быть ещё не в курсе выявления и эксплуатации какой-то уязвимости. И если вдруг удалось выяснить, например, на форуме хакеров, что некий компонент уязвим, то можно предпринять действия, не дожидаясь появления соответствующей CVE. Собственно, можно стать инициатором пополнения базы CVE новой уязвимостью и тем самым обезопасить не только свой проект, но и помочь другим.

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

В-третьих, угрозы безопасности могут представлять не только ошибки/уязвимости в коде, но и неправильная конфигурация систем, слабые/скомпрометированные пароли пользователей и т. д. Таким образом, система может быть взломана альтернативными способами. Соответственно, одним из направлений работ может быть непрерывный мониторинг системы с точки зрения таких угроз.

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

Ещё одним способом упреждения уязвимостей являются публичные программы поиска уязвимостей за вознаграждение:

К сожалению, пока Госдума отклонила законопроект о легализации "белых" хакеров:

В общем, имейте в виду, что сейчас этот метод, к сожалению, не регламентируется и не оформлен юридически.

Дополнительные ссылки:

• Елена Дмитриева. Обзор программ и площадок баг-баунти в России: практика, кейсы, суммы гонораров.
• TAdviser. Подборка: Белые хакеры в России.
• Круглые столы. Bug bounty: взгляд разработчиков, пользователей, хакеров, Зачем компаниям выходить на багбаунти: опыт hh.ru и Rambler&Co, Зачем компаниям выходить на багбаунти: опыт Ozon и Wildberries на Standoff Bug Bounty.
• Как пентестеры помогают бизнесу найти уязвимости в IT-системах.

5.25. Обеспечение безопасности при выводе программного обеспечения из эксплуатации

Вебинар №25. На нём был рассмотрен последний 25-й процесс "Обеспечение безопасности при выводе программного обеспечения из эксплуатации". На YouTube. Слайды презентаций.

Это новый процесс, который отсутствовал в ГОСТ Р 56939—2016. Поэтому, хотя цели и важность процесса понятны, найти по нему какую-то информацию/рекомендации пока затруднительно.

Цели 25-го процесса по ГОСТ Р 56939—2024:

Самый короткий раздел в стандарте, поэтому приведу требования и артефакты целиком:

Для некоторых приложений/сфер данный процесс не очень существенен, а для других наоборот. Например, слышал в одном из докладов на Kaspersky Certification Day, что вывод ПО из эксплуатации может быть непростым процессом для изделий по линии Министерства обороны.

Примеры мер, которые может включать вывод ПО из эксплуатации:

• Выгрузка данных, которые не должны быть утеряны при завершении эксплуатации ПО;
• Полное удаление (затирание) данных, учётных записей, настроек ПО;
• Или, в противоположность второму пункту, сбор/архивирование данных с целью использования их в других системах. Шифрование архивов. Создание плана миграции данных;
• Строгий контроль доступа к архиву (принцип минимальных привилегий);
• Физическое уничтожение носителей информации;
• Проверка, что разработанные процедуры соответствуют требованиям, установленным нормативными документами и ТЗ;
• Проверка, что соблюдены юридические, нормативные и договорные обязательства по хранению данных;
• Создание плана коммуникации для уведомления пользователей и заинтересованных сторон;
• Освобождение ресурсов, например отключение виртуальных машин и серверов (back end);
• Возможно освобождение доменных имён. Или, наоборот, продление их использования с целью предотвращения захвата этих имён злоумышленниками и распространения через них вредоносного ПО под видом обновлений/новых версий выведенного из эксплуатации ПО.
• Формирование акта о выводе. Документ, подтверждающий, что все этапы плана выполнены, данные обработаны в соответствии с политиками, а риски сведены к минимуму.

Дополнительные вебинары и ссылки

В процессе создания цикла "Вокруг РБПО за 25 вебинаров. ГОСТ Р 56939—2024" мы записали несколько дополнительных (бонусных) вебинаров.

Сертификация ПО согласно требованиям ФСТЭК и Минобороны

В вебинаре обсуждается, что на самом деле даёт сертификат и почему он не гарантирует безопасность ПО. Какие программы обязаны проходить проверку, а какие — нет. Чем отличается сертификация от аттестации, и что происходит после получения сертификата. На эти и другие вопросы ответили в бонусном вебинаре цикла с Виталием Вареницей, ведущим специалистом ЗАО "НПО "Эшелон" по сертификации и тестированию на проникновение ПО. На YouTube. Слайды презентаций.

Дополнительные ссылки по теме сертификации:

• Подкаст linkmeup. Процесс сертификации в системе ФСТЭК России — взгляд со стороны участников.
• Статьи компании eXpress на Habr. Сертификация ФСТЭК: самый подробный гайд. Часть первая — подготовка. Часть вторая — процесс сертификации.
• Роман Карпов. Зачем Java-разработчику знать регуляторику: часть 1, часть 2.

Системы с конструктивной информационной безопасностью

Дополнительный вебинар посвящён конструктивной информационной безопасностью (КИБ), которая закладывается в систему с момента её проектирования и поддерживается на протяжении всего жизненного цикла.

С помощью приглашённого эксперта Екатерины Рудиной, аналитиком департамента перспективных технологий "Лаборатории Касперского", мы разобрались, в чём сходство и различие таких систем с безопасным ПО, как соотносятся создание систем с КИБ и разработка безопасного ПО, чем полезен в работе специалистов по ИБ новый ГОСТ Р 72118—2025 "Защита информации. Системы с конструктивной информационной безопасностью. Методология разработки". На YouTube. Слайды презентаций.

Сертификация процессов РБПО: требования ФСТЭК России, новые стандарты и практика

Финальный дополнительный вебинар масштабного цикла "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939—2024" прошёл при участии ведущих экспертов: Дмитрия Шмойлова, Алексея Щербакова и Виталия Вареницы.

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

Статический анализ кода в методическом документе ЦБ РФ "Профиль защиты"

Вебинар посвящён методическому документу "Профиль защиты прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций". Этот вебинар не вошёл в цикл по РБПО, но поскольку методический документ тесно связан с ГОСТ Р 56939—2024, уместно его привести здесь для разностороннего раскрытия темы. На YouTube. Слайды презентаций.

Новая редакция документа опубликована Центральным Банком Российской Федерации 26.12.2025 в информационном письме №ИН-017-56/118. В документе явно указано, что учтены положения рассматриваемого нами стандарта:

Дополнительные ссылки

• Андрей Карпов. Компетенция: теория разработки безопасного ПО (РБПО).
• Канал Андрея Карпова "Бестиарий программирования": Телеграм / MAX.
• Информационный ресурс Центра компетенций ФСТЭК России и ИСП РАН "РБПО.РФ".
• Подкаст linkmeup. РБПО.
• Телеграм-канал "Технологический Болт Генона".
• Телеграм-канал "Новости информационной безопасности".
• Ресурсы под эгидой Центра компетенций ФСТЭК России и ИСП РАН (список телеграм-каналов).
• Методическая рекомендация №2025-07-011. Тип недостатка: Необоснованный выбор инструментов, в том числе инструментов статического анализа исходного кода, для выстраивания и выполнения процессов РБПО.
• Методическая рекомендация №2026-03-013. Типы недостатков: Неполная инвентаризация реализуемых средством защиты информации (далее - СЗИ) ФБ, недостаточный объем тестирования реализующего ФБ программного кода.
• Методическая рекомендация №2026-03-014. Тип недостатка: Отсутствие поддержки разработчиком безопасности эксплуатируемых СЗИ, в том числе устранения известных уязвимостей программных компонентов СЗИ.
• Центр исследований безопасности системного ПО. Инструкция по проведению разметки результатов статического анализа ядра Linux.
• Рекомендации ФСТЭК России.
• ТБ Форум 2026. Подходы и инструменты управления процессом РБПО.
• ТБ Форум 2026. Инструменты управления процессом РБПО.
• ТБ Форум 2026. Актуальные вопросы защиты информации.
• Система нормативных правовых, методических и информационных документов по проблематике обеспечения безопасности критической информационной инфраструктуры Российской Федерации. Подборка.
• Экосистема Альфа. Как автоматизировать создание новых документов по требованиям 117 приказа ФСТЭК России.

Послесловие

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

Также приглашаю всех познакомиться с нашим статическим анализатором PVS-Studio, который может закрыть не только 10-й процесс, но и будет полезен по другим направлениям:

• Обучение сотрудников (п.5.2). Формирование у программистов понимание антипаттернов и уязвимых конструкций, что улучшает их техническую экспертизу;
• Моделирование угроз и разработка описания поверхности атаки (п.5.7). Дополняет процесс, выявляя потенциальные уязвимости, которые формируют поверхность атаки;
• Экспертиза исходного кода (п.5.9). Позволяет усилить проверку стороннего кода, который команда включает в проект. Например, его можно использовать для выбора сторонних библиотек, оценивая качество их кода;
• Поиск уязвимостей в программном обеспечении при эксплуатации (п.5.24). Можно просматривать ранее отключённые предупреждения PVS-Studio с целью дополнительного выявления дефектов в коде.

PVS-Studio — статический анализатор кода для поиска критических и типовых ошибок.

Скачать PVS-Studio.

Основные характеристики:

• Поддерживает: C, C++, C#, Java, (скоро Go, JavaScript, TypeScript).
• Совместим с ГОСТ Р 71207—2024 (Статический анализ кода).
• Может применяться для РБПО согласно ГОСТ Р 56939—2024.
• Соответствует требованиям "Методики выявления уязвимостей и недекларированных возможностей в программном обеспечении" от 25 декабря 2020 г.
• Удовлетворяет требованиям к статическим анализаторам, приведённых метеорическом документе ЦБ "Профиль защиты".
• Включён в Реестр российского ПО: запись № 9837.
• Имеет сертификат технической совместимости с Astra Linux — №31190/2025.
• Полная информацию и характеристики: Статический анализатор кода PVS-Studio в 2026: ГОСТ Р 71207, ГОСТ Р 56939, приказ ФСТЭК №117.