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

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

Неудивительно, что такая же идея пришла в голову не только мне. Так что всё уже сделано. Держите ссылку: Не вставляй мне нейросеть, пожалуйста.

Раз речь зашла об использовании ИИ для подготовки материалов, хочу законспектировать ещё одну мысль: ИИ можно использовать для поиска данных, анализа материала, исследований и т. д.

Но надо чётко понимать, что исследования являются, во-первых, "археологическими" (что было в интернете, книгах, ...), а во-вторых, ограничено доступным для ИИ материалом. Если нет материала, не будет и никакого исследования, а только словоблудие. Боюсь, что не все и не всегда это понимают, создавая "обзоры продуктов", "сравнение с конкурентами", "исследования рынка" и так далее.

Попробую объяснить на примере. Если начать делать с помощью ИИ сравнение PVS-Studio и Cppcheck, то не будет никакого исследования на самом-то деле! Вернее, будет, на основе того, что написано в интернете, и не более того. Неизвестно, насколько это старая/полная информация и насколько полученный вывод будет соответствовать действительности. Ведь ИИ не пойдёт сам скачивать анализаторы, смотреть их интерфейс и запускать на разных проектах.

Можно сказать, что это всё и так понятно, но наблюдая безудержный рост ИИ-статей, в том числе "исследовательских", стоит лишний раз проговорить банальную вещь. Ответы ИИ – это переваренный материал из интернета. Кто больше/громче про себя написал, тот в исследовании и будет лучше. Вот и вся достоверность.

Между исследованием и "ИИ, сравни эти штуки" может лежать пропасть. Например, если говорить об испытаниях анализаторов, несколько компаний занимались этим год и то не сделали всё, что хотели (Кратко об итогах испытаний статических анализаторов исходного кода в 2025 году). Это можно назвать исследованием, а не вот это вот всё...

P.S. Ради интереса задал пару вопросов DeepSeek про детекторы утечек памяти: 1, 2. Как пафосно он нахваливает PVS-Studio! :) Я бы постеснялся быть таким безапелляционным. А ему-то что — про PVS-Studio подробно написано, вот и результат. Единственный вывод: мы молодцы и хорошо описываем наши возможности :)

Вайбкодинг. Итоги.

Методика ВУ и НДВ – 2026 (пост №1 из 3)

Событие, которое РБПО-сообщество ожидало уже несколько месяцев. 12 мая 2026 года ФСТЭК была утверждена "Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении" (далее — Методика). Методика приведена в соответствие с ГОСТ Р 56939—2024.

Из информационного сообщения В. Лютикова от 28 мая № 240/24/3693:

Методика ориентирована на проведение исследований, выполняемых испытательными лабораториями и разработчиками в рамках сертификационных испытаний программных, программно-аппаратных средств защиты информации и защищённых программных, программно-технических средств, а также в рамках внесения изменений в ранее сертифицированные средства. Разработчикам программного обеспечения средств защиты информации рекомендуется использовать положения настоящей Методики для организации внутренних процессов жизненного цикла программного обеспечения в соответствии с ГОСТ Р 56939—2024 "Защита информации. Разработка безопасного программного обеспечения. Общие требования".

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

Соответственно, с выходом новой Методики старая более не применяется:

В связи с утверждением настоящей Методики положения методического документа "Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении", утверждённого ФСТЭК России 25 декабря 2020 г., не применяются.

С рассуждением о вопросе "Как быть с уже идущими работами по старой методике?" можно познакомиться в здесь (Информационный канал сообщества ФСТЭК России и ИСП РАН).

Примечательно, что впервые выложена выписка из Методики (для 6-4 уровней доверия).

Теперь затрону некоторые моменты, которые так или иначе касаются близкой нам темы — статического анализа кода.

В выписке говорится (п.2.3.л), что при проведении исследования объектов оценки (далее — ОО) используются методики статического анализа заимствованных компонентов с открытым исходным кодом, опубликованные на сайте Центра исследований в разделе "Методика проведения статического анализа". Как я понимаю, имеются в виду следующие методические материалы:

• Методика проведения статического анализа ядра Linux
• Инструкция по импорту результатов разметки предупреждений SVACE
• Инструкция по проведению разметки результатов статического анализа ядра Linux

Здесь речь идёт исключительно про работу с ядром Linux с помощью конкретно анализатора Svace. Однако суть этих материалов может быть легко перенесена на другие открытые библиотеки и анализаторы кода.

Примечание. Для разметки (выставления вердиктов, обмена комментариями и т. д.) в экосистеме PVS-Studio появился инструмент ATLAS в двух редакциях:

• Atlas Viewer — десктопное приложение для работы с одним отчётом анализатора PVS-Studio.
• Atlas Server — серверное решение для работы с отчётами статических анализаторов кода в многопользовательском режиме.

Методика ВУ и НДВ – 2026 (пост №2 из 3)

Статический анализ исходного кода объекта оценки требуется начиная с 5 уровня контроля (таблица 3 в разделе 4.2 выписки). Но для 5 уровня нет требований к анализаторам кода. Эти требования появляются начиная с 4 уровня доверия.

Задачей исследования является выявление недостатков безопасности кода методами и инструментами статического анализа кода в соответствии с ГОСТ 56939—2024. В стандарте этому посвящён раздел 5.10 — Статический анализ исходного кода.

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

Статический анализ выполняется разработчиком для всех высокоуровневых языков программирования, которые встречаются в исходном коде модулей. Здесь уместно напомнить, что согласно ГОСТ Р 71207—2024 (п. 5.2) необходимо выбрать один или несколько статических анализаторов. Не ставится задача выбрать только один инструмент сразу для всех языков.

Используемые статические анализаторы должны реализовывать автоматизированный анализ исходного кода на уровне синтаксического дерева. Это базовое с точки зрения технологий анализа требование служит для того, чтобы отсечь совсем простые инструменты (линтеры), где детекторы реализуются только с помощью регулярных выражений. Почему построение полноценного анализа возможно только на базе синтаксического дерева, см. в статье "Статический анализ и регулярные выражения".

Методика ВУ и НДВ – 2026 (пост №3 из 3)

Должна быть выполнена ручная разметка всех предупреждений о критических ошибках, выданных анализаторами. Обратите внимание, что речь идёт о фокусе на ошибках критического типа.

Анализаторы выдают разнообразнейшие предупреждения, многие из которые могут иметь стилистический характер: способ именования переменных, запрет приведения типов в стиле языка C, запрет на использование оператора goto и т. д. Попытка отрефакторить все места кода, где выданы подобные предупреждения, или разметить все предупреждения крайне трудоёмка и на практике слабо повлияет на безопасность. Возникает вопрос, какие предупреждения анализаторов обязательны к разбору, а какие нет?

Ответ на него даёт ГОСТ 71207—2024 "Статический анализ программного обеспечения", где введено понятие критическая ошибка. Именно предупреждения, указывающие на потенциальное наличие критической ошибки, и должны быть разобраны/размечены в обязательном порядке.

Анализатор PVS-Studio выявляет все типы критических ошибок и помечает их специальным маркёром. Подробнее про разметку критических ошибок и работу с ними можно прочитать в статье "Фильтрация предупреждений PVS-Studio, выявляющих критические ошибки (согласно классификации ГОСТ Р 71207—2024)".

Разработчиками выполняется разметка всех предупреждений, предусмотренных планом поддержки безопасности заимствованных компонентов (в случае внесения изменения в сертификационный ОО).

Дополнительные требования к статическому анализатору начинаются с 4 уровня доверия. Испытательной лабораторией проверяется, что используемый статический анализатор отвечает требованиям ГОСТ 71207—2024 "Статический анализ программного обеспечения".

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

Примером анализатора, совместимого с ГОСТ 71207—2024, является PVS-Studio:
1. Статический анализатор кода PVS-Studio в 2026: ГОСТ Р 71207, ГОСТ Р 56939, приказ ФСТЭК №117
2. Кратко об итогах испытаний статических анализаторов исходного кода в 2025 году

Основные характеристики PVS-Studio:
• поддерживает: C, C++, C#, Java, (скоро Go, JavaScript, TypeScript);
• совместим с ГОСТ Р 71207—2024 (Статический анализ кода);
• может применяться для РБПО согласно ГОСТ Р 56939—2024;
• соответствует требованиям Методики от 12 мая 2026 года;
• включён в Реестр российского ПО: запись № 9837;
• имеет сертификат технической совместимости с Astra Linux — №31190/2025;
• запросить демонстрацию PVS-Studio.

Статический анализ и сквозное влияние изменений
В последнее время мне в различных статьях встретилась мысль, что статический анализ ограничен областью правок кода и не учитывает сквозное влияние изменений. Вчера в очередной раз прочитал это здесь – ИИ-ревью кода в 2026 году: как оно работает и как внедрять.

В этих статьях рассматривается статический анализ в разрезе pull request, где его возможности ограничены способом использования. Однако написано так, что создаётся впечатление, что технология статического анализа в целом имеет эту слабость.

Несколько гипотез, почему так пишут:

• Авторы имеют опыт работы с простыми инструментами статического анализа (линтерами), которые действительно не используют контекст за пределами функции/файла. Авторы же транслируют свой опыт на все инструменты.

• Команды сами себя загонят в узкий сценарий запуска анализатора, но описывают это как единственный способ запуска анализатора.

• Стоит задача во чтобы то не стало написать, как похорошела жизнь с ИИ. Остальные инструменты/технологии рассматриваются с уменьшением их возможностей на фоне ИИ :)

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

Естественно, заставляя инструмент анализировать изменения в конкретном файле (инкрементальный анализ) обрубается/усложняется возможность заметить, как эти изменения влияют на другие части проекта. Но и проблемы как таковой нет. Достаточно время от времени выполнять полную проверку проекта, когда включен межмодульный анализ.

Более того ГОСТ Р 71207—2024 (Статический анализ программного обеспечения) явно предписывает выполнять оба вида анализа (см. п. 5.6.).

Статический анализ добавленных или измененных частей ПО следует выполнять после каждого внесенного изменения.

Статический анализ всего разрабатываемого ПО следует выполнять не реже одного раза в 10 рабочих дней, если за данный период времени исходный код был изменен.

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

Для тех кому-то не понятна суть обсуждаемого вопроса, приведу совсем простой пример из мира C++, где нельзя просто проверить изменения в h-файле. Вернее, можно, но от это мало пользы. Нужно сразу проверять зависящие от него cpp файлы. Я тут даже не про межмодульный анализ говорю, а про препроцессирование.

Допустим, кто-то взял и решил добавить в definesTypes.h такой макрос:

#define sprintf std::printf

Анализирую эти изменения в файле definesTypes.h нельзя сказать, внесена ли какая-то ошибка. В файле definesTypes.h всё хорошо. Но ошибка использования неинициализированного буфера возникнет в другом месте, там где произойдёт подмена С-функции sprintf на функцию std::printf.

Кстати, это реальный баг найденный PVS-Studio в проекте StarEngine: Любите статический анализ кода!

Немного подзамочного контента для моих уважаемых подписчиков.

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

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

Чисто для моей аудитории, готовой, прямо скажем, на многое, выкладываю ссылки на магистерский курс этого года на русском. Предупреждаю: это очень фанатский контент. Не надо даже пробовать его потреблять, если вы привыкли к той лакированной подаче, которую я считаю нормой для своего ютуба.

Это вторая часть выкладки.

Have fun.

Лекции 1-14: https://t.me/cpp_lects_rus/333

Лекция 15. Аллокаторы, часть 1
Лекция 16. Аллокаторы, часть 2
Лекция 17. Умные указатели
Лекция 18. Полиморфизм
Лекция 19. Потоки, часть 1
Лекция 20. Потоки, часть 2
Лекция 21. Очереди
Лекция 22. Атомики, часть 1
Лекция 23. Атомики, часть 2
Лекция 24. Атомики, часть 3
Лекция 25. Корутины, часть 1
Лекция 26. Корутины, часть 2
Лекция 27. SYCL и GPGPU
Лекция 28. Execution

Да, все ссылки на rutube, я стримил туда.

#cpp_postgraduate

Минутка улыбок сеньоров, возящихся с legacy-проектами

Просьба не читать амбассадорам и энтузиастам ИИ. Мы тут своим кружком минутку похихикаем и всё.

Решил погуглить, что последний год пишут на тему "поиск ошибок в коде". Раньше находились статьи про разные инструменты, сейчас всё забито статьями с общим названием "Нейросети для поиска ошибок в коде". Заглянул внутрь, например, этой: "Исправить код с помощью нейросети: ИИ для исправления ошибок в коде на Python, JavaScript и в больших проектах".

Как же предлагают искать баг в большом проекте? В начале водянистая вода, а затем:

Поиск синтаксических ошибок. Это базовый уровень. Модель может увидеть: пропущенные скобки; ошибки отступов; неправильные кавычки; бла-бла…

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

Дальше про поиск логических ошибок, анализ производительности, поиск уязвимостей. В общем, ИИ всё может, бла-бла. Как ошибки-то искать?

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

Так-так, ну давайте уже, что сделать-то надо?

Подготовьте код и описание проблемы. Перед отправкой соберите минимум: фрагмент кода; текст ошибки; что код должен делать; …

Знать бы только, где этот код! ;)

Бугогашенька. Показываем код с багом и говорим: "Найди, где он!" Автор-капитан, спасибо! Составители таких статей принципиально не понимают суть сопровождения больших старых проектов. Исправить ошибку в нужной функции — это самое простое. Вот только бывает непонятно, откуда начать поиск той самой функции.

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

И последнее:

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

Конечно, я понимаю, что не стоит воспринимать всерьёз эту нейрослопую статью или искать в ней какие-то ответы. Она написана не для того, чтобы ты нашел баг, а чтобы рекламировать "онлайн-сервис с нейросетями на русском языке для быстрого создания и обработки контента". Ну, собственно, пример создания быстрого контента у нас перед глазами :)

Господа сеньоры, морально держитесь. Скоро работы прибавится. Сейчас мы переживаем эпоху:

Люди, которые не понимают, как устроено программирование во всей его полноте, сегодня с очень большой уверенностью рассказывают всем остальным, как нужно делать программирование.
Миша Ларченко. Хороший код больше не важен? Почему разработка катится не туда — мнение техлида

А потом всё это придётся разгребать и чинить ;) Не надо сопротивляться. Чем больше будет таких статей, вайб-кодеров и говнокода, тем быстрее начнётся отрезвление, а природа очистится :)

Коллеги подготовили обновлённую обзорную презентацию о PVS-Studio. А если хочется нырнуть глубоко, то напоминаю про этот фолиант.

Прям в продолжение :)
А вас вайб-кодеры уже достали?

Ааа, всё пропало! AI создаёт дырявый код! Что же делать?

Что-то у меня неделя ИИ. Сегодня за утренним кофе прочитал статью "70% разработчиков считают ИИ-код дырявым, при этом 30% всех опрошенных деплоят его в прод".

Кажется, это ещё одна из статей, написанных с помощью ИИ про ИИ, которые всё заполонили. Поэтому рекомендовать её к прочтению не стану. Да и приведённым там числам я что-то не очень верю.

Позабавило: "C-код оказался самым дырявым". Да, C такой :) Надо иметь прямые руки, чтобы им пользоваться — плата за скорость и экономный расход памяти.

Краткая суть статьи: постепенно начинает выясняться, что с генеративным ИИ (GenAI) не всё так волшебно. Сгенерированный код оказывается не таким уж качественным и безопасным. Дополнительная проблематика заключается в том, что вместо ужесточения контроля он, наоборот, снижается: кто-то из вайб-кодеров некомпетентен, чтобы проводить обзоры кода и грамотно выстраивать процессы разработки; кто-то может, но не чувствует свою ответственность за сгенерированный код (тем более его слишком много в силу простоты создания).

Внезапного для меня в этом нет. Я уже писал, что ожидания завышены, а к сгенерированному коду есть избыточное доверие (как и к текстам в целом).

Кстати, скоро эту тематику мы затронем в вебинаре "Что скрывает код: от поверхности атаки до производительности" в новом цикле "Качество и безопасность ПО в эпоху GenAI". Приглашаю зарегистрироваться: 24.06.2026 в 15:00 по МСК, онлайн.

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

Эээ… Так ничего не изменилось. Проблема качества кода и проектов была всегда. Уже известно всё, что надо делать. Проблематика не стоит выеденного яйца.

Нужно выстраивать процессы разработки так, как это делалось до GenAI. Если же нет сил на выстраивание процессов или команда считает, что уровень качество приемлем ("и так сойдёт" (C)), то GenAI тут ни при чём.

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

Что там у нас? Обучение сотрудников. Если хотите, чтобы вайб-кодеры умели не только наваливать код, но и уметь проводить его аудит, задумайтесь о том, как они будут расти. Кстати, вот недавно статья на эту тему была: "Поколение "Approve": почему я заставил команду переписать проект, который уже работал".

Необходимо сформировать требования к программному обеспечению. Если нет требований, то не стоит удивляться, что в итоге получилось что-то не то. GenAI позволяет быстрее приступить к делу и быстрее сесть в калошу, например, из-за того, что выбранное архитектурное решение не масштабируется.

Всегда был нужен процесс композиционного анализа. С GenAI это лишь заиграло новыми красками в связи с атаками, построенными на галлюцинациях в названиях пакетов. Про это хорошо рассказывают специалисты компании CodeScoring в докладах и статьях:

Галлюцинации систем ИИ (slopsquatting). Сегодня многие разработчики используют ИИ‑агентов в IDE. Например, просят подсказать библиотеку или показать пример кода. Но LLM "галлюцинируют" и рекомендуют несуществующие библиотеки в 20% случаях, либо воспроизводят ряд вышеописанных рисков, в основе которых лежит мимикрия проблемных решений под легитимные. Этим пользуются злоумышленники: они создают вредоносный пакет и ожидают, что кто‑то установит его, доверившись исключительно подсказке модели. Ситуацию усугубляет тот факт, что галлюцинации являются воспроизводимыми, что облегчает процесс наименования вредоносных компонентов для злоумышленников.

И так далее. Хотим качества и надёжности — просто берём и делаем хорошо :)