Так или иначе, вайб-кодинг становится, — а где-то уже стал, — частью процесса разработки программного кода. Команда PVS-Studio видит в этом новые задачи для статических анализаторов по поиску ошибок в коде, возникающих при использовании ИИ-ассистентов и т.п. Первый шаг — собрать примеры реальных дефектов для изучения.

Отношение к вайб-кодингу и его вариациям неоднозначное. Я разделяю мнение, что использование сгенерированного кода, особенно без полного его понимания программистом, плохо скажется на надёжности и безопасности приложений. Так что работы у статических анализаторов только прибавляется :)

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

Тема безопасной разработки программного обеспечения интересует всё большее количество разработчиков и руководителей. Дополнительным стимулом стал вышедший в конце 2024 года обновлённый ГОСТ Р 56939, в котором описано 25 процессов (мер) для построения безопасной разработки. Это хороший список, но что он означает на практике, например, для Java-разработчиков? Поговорим о сути некоторых процессов и инструментарии.

Статья является переработкой совместного вебинара компаний ООО "ПВС" и АО "АКСИОМ". Текстовый вариант содержит дополнительные ссылки, а некоторые моменты рассмотрены более подробно. Полную запись вебинара доступна здесь: "Безопасность приложений: инструменты и практики для Java-разработчиков".

Статья построена так же, как и вебинар: первую часть подготовил Андрей Карпов, затем слово передаётся Алексею Захарову (@AlexZ0).

Обычно я пишу про статический анализ, баги и оформление кода. Однако сейчас меня притянуло к тематике РБПО (разработка безопасного программного обеспечения). Это связано с тем, что статический анализ является одним из основополагающих процессов безопасной разработки.

Всё началось с цикла публикаций про ГОСТ Р 56939-2024 в моём Telegram-канале "Бестиарий программирования". Мой внимательный читатель Виталий Пиков из УЦ МАСКОМ, увидев это, пришёл и сказал: "А давай больше!" Он предложил запустить целый цикл совместных вебинаров, где последовательно разобрать все 25 процессов, описываемых в ГОСТ Р 56939-2024. И идея мне понравилась.

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

Проверяя код проекта TDengine с помощью PVS-Studio, можно встретить код с запахом, канонические ошибки и опечатки. Многое из этого можно избежать, если изначально аккуратно оформлять код, делать логику простой и избегать макросов. Давайте рассмотрим некоторые фрагменты кода и подумаем, как можно провести его рефакторинг так, чтобы багам просто не было там места.

В этот раз поговорим про написание кода методом Copy-Paste. С одной стороны, программисты знают, что копирование кода с последующей его модификацией провоцирует ошибки и опечатки. С другой — набирать каждый раз фрагмент кода, похожий на уже написанный, скучно и непродуктивно. Здесь важно соблюдать некий баланс, который сложно сформулировать и понимание которого приходит с опытом.

Проверяя код проекта TDengine с помощью PVS-Studio, можно встретить код с запахом, канонические ошибки и опечатки. Многое из этого можно избежать, если изначально аккуратно оформлять код, делать логику простой и избегать макросов. Давайте рассмотрим некоторые фрагменты кода и подумаем, как можно провести его рефакторинг так, чтобы багам просто не было там места.

Проверяя код проекта TDengine с помощью PVS-Studio, можно встретить канонические ошибки и опечатки. Многих из них можно избежать, если изначально аккуратно оформлять код, делать логику простой и избегать макросов. Давайте посмотрим на эти ошибки и подумаем, как можно повести рефакторинг кода так, чтобы им просто не было там места.

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

Вашему вниманию предлагается полный список разделов электронной книги (12 из 11 :)), посвящённой неопределённому поведению. Книга не является учебным пособием и рассчитана на тех, кто уже хорошо знаком с программированием на C++. Это своего рода путеводитель C++ программиста по неопределённому поведению, причём по самым его тайным и экзотическим местам. Автор книги — Дмитрий Свиридкин, редактор — Андрей Карпов.

Инструментальное средство PVS-Studio разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207–2024, выявляет критические ошибки и может использоваться при разработке безопасного программного обеспечения. Рассмотрим функциональные возможности, реализованные в PVS-Studio на конец 2024 года в отношении анализа исходного кода программного обеспечения, написанного на компилируемых языках программирования C, C++, C#, Java.

Статический анализатор PVS-Studio способен находить ошибки даже в таком качественном и протестированном проекте, как LLVM. Чтобы это не было пустыми словами, мы время от времени перепроверяем проект и публикуем такие заметки, как эта.

В своей обители в Р'лайхе мёртвый Ктулху спит в ожидании своего часа. А в C коде проекта DPDK спит множество ошибок, и тоже в ожидании своего часа. Давайте посмотрим, какие из них может выявить анализатор PVS-Studio.

Давно хотелось написать статью, что юнит-тесты — это хорошо, но не стоит забывать, что они тоже могут содержать ошибки. Сейчас встретился проект DPDK, тесты которого хорошо демонстрируют этот нюанс. Давайте посмотрим, как выглядят типичные ошибки в юнит-тестах, и как они выявляются с помощью статического анализа кода.

Сразу предупреждаю, мои вкусы очень специфичны. Красота ошибки в том, что человеку её очень сложно найти. Я не верю, что её можно заметить при обзоре кода. Если только заранее знать, что она есть, и искать её целенаправленно.

Ошибку я нашёл в проекте DPDK. В нём есть и другие ошибки, но про них потом. Они меркнут перед этим алмазом. Только не ждите чего-то эдакого. Ошибка проста до безобразия. Вот только найти её, просматривая код, ой как непросто. Собственно, попробуйте сами.

Помню 100500 лет назад (ну ладно, всего 12), я писал на Хабре, что мне не хватает в России хардкорной C++ конференции. Затем появилась C++Russia. Навизуализировал.

Пару лет назад я начал грустить, что нет подходящей конференции на тему безопасности. Статью на эту тему я не писал, но желание исполнилось и даже побыстрее, чем с C++. Хочу познакомить вас с конференцией SafeCode.

1 апреля 2024 года введён в действие новый ГОСТ "Статический анализ программного обеспечения". Если в ГОСТ Р 56939–2016 говорится о необходимости использования статического анализа при разработке безопасного программного обеспечения (РБПО), то ГОСТ Р 71207–2024 уточняет, что именно это означает.

В стандарте:

• перечислены требования к инструментам статического анализа;
• указано, какие ошибки они должны находить;
• какие технологии использовать;
• описан порядок внедрения в процесс разработки;
• описан процесс регулярного использования;
• и так далее.

Информация в ГОСТ очень плотная, и её тяжело сразу воспринять, если вы ранее не имели дело со статическим анализом кода и РБПО. Поэтому я подготовил и провёл цикл из 5 вебинаров, где разобрал различные аспекты ГОСТ и примерами пояснил некоторых термины.

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

Если спросить программиста, какие баги чаще всего можно встретить в C и C++ коде, он назовёт разыменование нулевого указателя, неопределённое поведение, выход за границу массива и другие, на его взгляд, типовые паттерны ошибок. Скорее всего, он назовёт и случайное присваивание в условии. Но действительно ли эта ошибка распространена в наше время?

В этой статье мы рассмотрим, как правильно разрушать объекты в ООП программе на языке C++, не выполняя избыточных операций. Этим мы завершим цикл публикаций, посвящённый обзору ошибок в игровом движке qdEngine.

В первой статье про qdEngine было рассмотрено 10 ошибок, выбранных плагином PVS-Studio. Однако есть ещё 10 багов, заслуживающих внимания. Как говорится, лучше учиться на чужих ошибках. Заодно они хорошо демонстрируют возможности PVS-Studio в выявлении разнообразнейших ошибочных паттернов.

В этой статье мы рассмотрим, как статический анализатор PVS-Studio воодушевляет заняться рефакторингом кода. Ведь чем короче, проще и понятнее код, тем меньше в нём ошибок.