Бестиарий программирования

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

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

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

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

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

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

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

Вы уже знаете, чем займетесь вечером? Если нет, то вот вам занятие - посмотреть онлайн-трансляцию подкаста Pure Virtual Cast! 🎤 О чем подкаст: Возможные подходы к парсингу C++ в НЕ компиляторах. Нужен ли полноценный парсер, если нужен, то почему. Можно ли использовать готовые парсеры, в том числе из компиляторной инфраструктуры (типа clang). Зачем может понадобиться собственный парсер, и с какими проблемами придется столкнуться при создании оного. 📅 Сегодня в 19:30 Трансляция доступна по этой ссылке 🔗 #подкаст #cpp

⚡Напоминалка! Скоро состоится наш совместный вебинар с экспертами из AppSec Solutions. Расскажем, как повысить безопасность вашего кода с помощью современных инструментов. 📅16 апреля 12:00 Подробности и регистрация 🔗 #вебинар

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

#видеозаписи Андрей Карпов не первый год рассказывает о поиске ошибок статическим анализом. Но теперь #БезопаснаяСреда публикует запись доклада, где он зашёл особенно далеко: как найти ненаходимое? YouTube | VK Видео Скачать презентацию с сайта SafeCode

🎙Друзья, рады поделиться с вами записью прошедшего вебинара! Совместно с экспертом SECURITM мы поговорили о том, как обеспечить соблюдение требований ГОСТ в области безопасной разработки программного обеспечения. Показали реальные примеры использования PVS-Studio и SECURITM, дали рекомендации по настройке инструментов и рассказали, как оптимизировать процессы разработки для достижения высокого уровня безопасности. Приятного просмотра! 👍 #вебинар #PVS_Studio

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

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

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

if constexpr ( condition )

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

Кто на C++Russia, приходите общаться! Заодно новый мерч наберёте. Книжку подарю, кто на прошлой конференции не получил :)