Всем привет. Напоминаю про подкаст сегодня и приглашаю к участию.

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

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

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

РБПО-002. Общий план постов.
Думаю, я сделаю около 150-200 постов, но это не точно :) На данный момент, мне видится следующая последовательность и структура публикаций:
• Почему я решил опубликовать серию постов про РБПО.
• Что такое РБПО и как она связана с сертификацией ФСТЭК.
• Причины разработки и выпуска нового ГОСТ Р 56939-2024 на замену версии 2016 года.
• О содержании стандарта и его структуре.
• Основная и самая большая часть – разбор 25 процессов, описанных в 5 главе стандарта.
• Вопросы сертификации.
• Итоги и дополнительные ссылки.

РБПО-003. Андрей Карпов. Несколько слов о себе.
Чтобы перейти к тому, как я заинтересовался темой РБПО, стоит рассказать немного про себя. Я один из основателей проекта PVS-Studio (который начинался как проект Viva64 для поиска 64-битых ошибок). За 17 лет существования проекта я исполнял множество ролей, часто совмещая их: писал первый код ядра анализатора, затем много лет выполнял роль технического директора (CTO). Активно участвовал, да и продолжаю участвовать, в продвижении PVS-Studio с помощью статей и докладов. Возглавлял отдел маркетинга в роли CMO, правда не очень любил писать эти буквы.

Программисты скептически относятся к статьям/презентациям, когда их рассказывает не такой же технарь, а кто-то из мира маркетинга с подписью "СМО" :) Встречают по одёжке названию должности. Поэтому я предпочитал подписываться как DevRel.

Сейчас моя основная деятельность — развитие компании в широком смысле этого слова: задание некоторых векторов развития проекта и его сопровождение. Примером одного таких из векторов как раз является РБПО. Ну а текущая моя должность называется "Директор по развитию бизнеса" (CBDO), что полностью соответствует реалиям. Впрочем, при подаче докладов я по-прежнему планирую иногда указывать себя как DevRel или Developer Advocate :)

Кстати, если интересно побольше узнать про историю проекта PVS-Studio и нашего единорога, вот несколько ссылочек:

Доклад: Как потратить 10 лет на разработку анализатора кода.
Публикации: Как 10 лет назад начинался проект PVS-Studio; Неожиданная статья про нашего единорога: кто такой маскот PVS-Studio?
Подкасты: Анализатор кода / Блажь или необходимость? / История успеха компании из глубинки; LTE № 27. Судьба стартапа.

От теории к практике. Вот что получается, когда не думаешь про безопасность разработки и не используешь статический анализ кода :) Необходимость статического анализа для РБПО на примере 190 багов в TDengine.

РБПО-004. Почему я решил опубликовать серию постов про РБПО.
Наметился тренд на больший контроль безопасности разрабатываемого ПО для критической информационно инфраструктуры (КИИ), автоматизированных систем управления (АСУ ТП) и т.п. Происходит уточнение и формализация требований. Например, в конце 2024 года вышел новый ГОСТ Р 56939, который я как раз и буду здесь разбирать. Вышел ГОСТ Р 71207-2024 про статический анализ кода. На подходе ещё ряд стандартов, например на композиционный анализ (SCA), динамический анализ (DAST).

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

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

А вторая — заниматься обучающим маркетингом. Мы рады делиться с сообществом нашей экспертизой на тему анализа кода, безопасной разработки и т.д. Конечно, это и повод про возможности PVS-Studio упомянуть :) В задуманной серии постов я как раз и расскажу много полезного и интересного для тех, кто столкнулся или столкнётся с РБПО.

РБПО-005. РБПО или БРПО?
Встречается как термин "разработка безопасного программного обеспечения" (РБПО), так и "безопасная разработка программного обеспечения" (БРПО).

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

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

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

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

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

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