Директор по развитию бизнеса
Думаю, вам начинают надоедать тексты про вайб-кодинг. Но не волнуйтесь, мой интерес не в том, чтобы рассказывать о новых невероятных достижениях, меняющих мир, и бла-бла-бла... Интереснее поискать места, в которых начинается сбой при генерации кода. Это позволит адаптировать работу статических анализаторов для новых задач контроля кода, который создаётся с помощью таких систем.
Так или иначе, вайб-кодинг становится, — а где-то уже стал, — частью процесса разработки программного кода. Команда 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 в выявлении разнообразнейших ошибочных паттернов.