Сегодня за утренним кофе прочитал статью “70% разработчиков считают ИИ-код дырявым, при этом 30% всех опрошенных деплоят его в прод”. Внезапного для меня в этом нет. Я уже писал, что ожидания завышены, а к сгенерированному коду есть избыточное доверие (как и к текстам в целом). Неожиданно другое: проблематику некачественного и ненадёжного ИИ-кода начинают обсуждать как нечто новое. Уже встречал размышления, мол, как теперь строить процессы разработки, чтобы достичь необходимое качество.

Мы подготовили раздел материалов, посвящённых разработке безопасного ПО (РБПО) по ГОСТ Р 56939—2024. Теперь эти материалы представлены в виде бесплатного онлайн-курса из 28 уроков. Такая структура поможет, во-первых, распределить нагрузку при знакомстве с теорией, а во-вторых, проверить свои знания.

Ценность квалифицированного программиста смещается в сторону умения проводить обзоры кода. Генерировать код становится проще, но всё так же важно проверять его с точки зрения качества декомпозиции, корректности реализации, эффективности, безопасности. Посмотрим на примере маленького проекта markus, созданного с помощью Claude Opus, почему важно понимать сгенерированный код и уметь видеть, что скрывает красивый текст программы.

Начал появляться код тех самых навайбкоденных проектов, который изменит мир и т. д. Ну а мы начинаем потихоньку смотреть код этих проектов, в том числе и сквозь призму статического анализа.

О вечном — о разумной длине строк кода. Мы недавно встретили ошибку, которая одновременно демонстрирует, чем плох "код-колбаса", "эффект последний строки" и последствия неудачного copy-paste.

Этот текст для компаний, занимающихся аутсорсом и аутстаффингом. Продвигая статический анализ кода в целом и инструмент PVS-Studio в частности, мы отдельно не выделяем компании этой направленности. Сейчас, в связи с вступлением в силу 1 марта 2026 года приказа №117, всё немного по-другому.

Думаю, вам начинают надоедать тексты про вайб-кодинг. Но не волнуйтесь, мой интерес не в том, чтобы рассказывать о новых невероятных достижениях, меняющих мир, и бла-бла-бла... Интереснее поискать места, в которых начинается сбой при генерации кода. Это позволит адаптировать работу статических анализаторов для новых задач контроля кода, который создаётся с помощью таких систем.

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