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

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