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

Оптимизирующий компилятор вправе удалить последнюю строчку с присваиваниями "l0 = l1 = d[0] = d[1] = 0;", так как с точки зрения языка у неё нет наблюдаемых эффектов. Приватные данные останутся лежать в стековой памяти.

Перед нами разновидность CWE-14. Более распространённый вариант это потенциальной уязвимости – использование "исчезающего" memset.

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

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

if constexpr ( condition )

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

В программировании есть аналогичный "антипаттрен торопыжки". О, кстати, может его так стоит и назвать :) Входной указатель в начале разыменовывается, а потом проверяется. Очень частая ситуация.

Классический пример взят из проекта TDengine. Предупреждение PVS-Studio V595 The 'pHandle' pointer was utilized before it was verified against nullptr. Check lines: 2883, 2887. tsort.c 2883

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

#видеозаписи

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

Но теперь #БезопаснаяСреда публикует запись доклада, где он зашёл особенно далеко: как найти ненаходимое?

YouTube | VK Видео

Скачать презентацию с сайта SafeCode

AppSec.Hub — платформа DevSecOps от AppSec Solutions, которая автоматизирует внедрение инструментов безопасности и управление процессами безопасной разработки. На вебинаре эксперты продемонстрируют возможности продуктов и покажут, как интегрировать PVS-Studio в AppSec.Hub для создания эффективного конвейера DevSecOps.

Запись доклада: https://pvs-studio.ru/ru/blog/video/11322/

Пора по-настоящему испытать себя...

Мы с командой подготовили интересный квиз по мотивам книги "Путеводитель С++ программиста по неопределенному поведению". Тебя ждет 10 кринжовых примеров кода, надо будет найти ошибки.

Только не относись к этому серьезно, просто развлекись 😃

В следующий понедельник 28.04.2025 приглашаю в 11:00 на подкаст, где будем говорить о безопасной разработке - Анонс sysadmins №58. РБПО – тренд 2025.

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

РБПО-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%, что в некоторых сферах деятельности станет неоправданным/нерациональным расходом ресурсов. Позже мы ещё вернёмся к этой теме.