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

2. РБПО по ГОСТ Р 56939-2024 требуется для получения сертификата ФСТЭК.

Вообще, можно сказать, что безопасная разработка так или иначе полезна всем компаниями, создающим приложения. Так почему все ещё не внедрили РБПО или не занимаются этим сейчас? Ответ прост: внедрение РБПО приводит к удорожанию процесса разработки на 10-15%, что в некоторых сферах деятельности станет неоправданным/нерациональным расходом ресурсов. Позже мы ещё вернёмся к этой теме.

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

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

РБПО-007. Определения: сертификация и аттестация ФСТЭК
Для начала немного уточним термины, т.к. лицензии, сертификаты и аттестаты ФСТЭК это не одно и то же.

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

Аттестат тоже дают организациям, чтобы подтвердить, что они соблюдают требования ФСТЭК по защите персональных данных (ПД).

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

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

РБПО-008. Кому требуются сертификаты ФСТЭК?

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

Обязательная сертификация средств защиты информации касается:
• государственных информационных систем (ГИС);
• персональных данных (ЗПДн);
• автоматизированных систем управления технологическим процессом (АСУ ТП);
• сфер деятельности с обязательной сертификацией средств защиты информации;
• государственной тайны (ЗГТ);
• критической информационной инфраструктуры (КИИ);
• конфиденциальной (служебной) информации.

Тяжела и неказиста жизнь простого программиста статических анализаторов кода
Команда PVS-Studio, содействуя разработке методики испытаний статических анализаторов под руководством ФСТЭК, составляла некоторые синтетические тесты. Писать синтетические тесты сложнее, чем кажется, и с их достоверностью всегда масса нюансов. Я никогда не любил синтетические тесты и продолжаю их не любить. Но что делать, они тоже нужны, когда речь заходит о необходимости подтвердить, что в анализаторах реализован определённый набор технологий.

Даже зная и понимая нюансы составления синтетических тестов, мы всё равно наступили на собственные грабли! Переиграли сами себя :)

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

Когда тесты подготавливались в Compiler Explorer, всё работало: PVS-Studio выдавал предупреждение V1057. А сейчас, когда код мило и скромно лежит в файлах, не работает. На Compiler Explorer работает, а вне — нет. Магия. Уже собрались баг в анализаторе искать.

Ах нет, всё просто. Файлы с тестами называются test_err_*.cpp. И в детекторе срабатывает исключение N4: "Находимся в файле, содержащем в названии слова check/test/bench". Тьфу. Причём получается, что анализатор прав: это действительно тест, а не настоящий баг :) Вот оно, несовпадение реальности и синтетических проверок в действии. Выкрутимся как-нибудь, но решил описать, так как случай интересный.

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

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

Был рад поведать немного интересного из жизни разработчиков статических анализаторов кода. А если хочется послушать что-то ещё, приглашаю на подкаст "Статический анализ по серьёзному" с моим участием 27 мая в 19:00 по Москве.

РБПО-009. ГОСТ Р 56939-2024
Методология разработки безопасного программного обеспечения (РБПО) описана в ГОСТ Р 56939-2024. Вернее, различные её вариации описываются и в других документах или зарубежных стандартах. Однако ГОСТ Р 56939-2024 сейчас наиболее актуален для рассмотрения по следующим причинам:
• он вышел совсем недавно и поэтому наиболее полно описывает современные практики/подходы к созданию безопасного ПО;
• он имеет юридическую силу на территории РФ.

Полное название стандарта ГОСТ Р 56939-2024:

Защита информации
РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Общие требования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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