#mem_PVS #programming #cpp

#Задача_PVS #programming #csharp

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

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

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

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

#Задача_PVS #programming #cpp

#mem_PVS #programming

#Задача_PVS #programming #java

Тяжела и неказиста жизнь простого программиста статических анализаторов кода
Команда 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 по Москве.

#Задача_PVS #programming #csharp

Коллеги, рады поделиться с вами записью прошедшего вебинара - "Регулярный статический анализ по ГОСТу"!

Разобрали часть требований стандартов 56939-2024 и 71207-2024 в части регулярного статического анализа, объяснили, как выстроить этот самый регулярный статический анализ в рамках РБПО, автоматизировать его через системы CI и значительно ускорить пайплайн за счёт эффективных подходов. Рассказали, как интеграция анализа в процесс разработки поможет найти уязвимости раньше и сэкономить ресурсы команды.

Приятного просмотра!

#вебинар #видео