Что нового появилось в PVS-Studio в 2025 году

• Общие изменения
  • Плагины для IDE
  • Новые интеграции в ASOC-системы
  • Сборочные системы
  • Используем анализатор по ГОСТ Р 71207-2024
  • Пользовательские аннотации кода в формате JSON
  • Улучшения документации
• C и C++
  • Новый парсер C и C++ кода
  • Улучшения анализа и разбора конструкций языка и стандартной библиотеки
  • Улучшения поддержки стандартов MISRA
  • Новый функционал в файлах конфигурации анализа
  • Новые диагностические правила
  • Выпущенные статьи
• C#
  • Поддержка .NET 10
  • Улучшения анализа
  • Новые диагностические правила
  • Выпущенные статьи
• Java
  • OWASP Top 10 2021
  • Новые диагностические правила
  • Выпущенные статьи
• Заключение

Уже наступил новый 2026 год, а это значит, пришло время вспомнить, что же интересного сделала команда PVS-Studio за 2025 год. Усаживайтесь поудобнее, мы начинаем наш вечер воспоминаний.

Общие изменения

Плагины для IDE

Visual Studio 2026

В прошлом году вышла новая версия интегрированной среды разработки от Microsoft — Visual Studio 2026. Так же, как и для предыдущих версий IDE, для новинки появился плагин PVS-Studio, позволяющий анализировать С, C++ и C# проекты на основе сборочной системы MSBuild.

Подробнее о том, как использовать PVS-Studio в Visual Studio, можно прочитать в нашей документации.

Qt Creator

За прошедший год плагин PVS-Studio для Qt Creator стало возможно использовать аж в четырёх свежих версиях среды разработки. Поддержана работа плагина с Qt Creator 15, 16, 17 и 18.

Однако не обошлось и без версий, которые перестали поддерживаться. Мы стараемся обеспечивать обратную совместимость по поддержке последних версий плагинов для всех версий Qt Creator за два года с момента каждого релиза, поэтому в 2025 году была прекращена поддержка Qt Creator 9, 10, 11 и 12.

Также в 2025 году плагин PVS-Studio для Qt Creator был портирован на комплект разработчика для операционной системы "Нейтрино" на Windows. Из него поддержана работа с Qt Creator 6 (Qt 5.14.2).

Подробнее о работе плагина PVS-Studio для Qt Creator можно прочитать в нашей документации.

OpenIDE

В 2025 году плагин PVS-Studio стал доступен в интегрированной среде разработки OpenIDE. С его помощью можно анализировать проекты, написанные на Java.

Вместе с коллегами из OpenIDE мы также написали статью с проверкой исходного кода среды, а ещё выпустили целый подкаст, в котором обсудили, что за зверь такой этот OpenIDE:

Об использовании плагина PVS-Studio для OpenIDE можно прочитать в нашей документации.

Мониторинг компиляции в плагине для Visual Studio Code

В плагине PVS-Studio для среды разработки Visual Studio Code в 2025 году появилась возможность проводить анализ проектов на основе мониторинга компиляции.

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

Сейчас подобный функционал доступен только на Windows, но мы планируем добавить его и на Linux.

Новые интеграции в ASOC-системы

В 2025 году мы заключили технологическое партнёрство с самыми различными ASOC-инструментами, чтобы анализатор PVS-Studio можно было легко внедрять в конвейер разработки, используя те же инструменты, что и ранее.

В итоге результаты анализа PVS-Studio стало возможным интегрировать в:

• AppSecHub
• Hexway
• Securitm
• CyberCodeReview
• TRON.ASOC

Сборочные системы

В прошлом году была улучшена работа PVS-Studio с различными сборочными системами.

Появилась возможность использовать синтаксис Kotlin DSL при написании скриптов сборки для сборочной системы Gradle, использующих плагин PVS-Studio. Соответствующая инструкция появилась в документации.

Для сборочной системы MSBuild появилась возможность анализировать проекты на основе файлов решений в формате .slnf и .slnx. О том, чем .slnx отличается от .sln, мы писали в нашем блоге.

Используем анализатор по ГОСТ Р 71207-2024

В 2024 году в плагинах PVS-Studio для Visual Studio и Visual Studio Code появилась возможность включить отображение специальных SAST-идентификаторов, отображающих принадлежность срабатывания к категориям критических ошибок из ГОСТ Р 71207-2024.

В 2025 году подобный функционал появился в плагине для SonarQube и в файлах конфигурации анализа .pvsconfig.

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

Если вы интересуетесь темой безопасной разработки, в прошлом году мы начали большой цикл из 25 вебинаров, посвящённых стандарту ГОСТ Р 56939-2024. Подробнее можно узнать на этой странице.

Пользовательские аннотации кода в формате JSON

В 2024 году мы добавили возможность добавления пользовательских аннотаций кода в формате JSON для C и C++ анализатора. Эти аннотации дают анализатору дополнительный контекст об использовании различных сущностей, позволяя улучшить качество анализа.

В 2025 году подобная возможность появилась в Java и C# анализаторах PVS-Studio.

Улучшения документации

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

Например, в 2025 году раздел документации об использовании анализатора для анализа Unreal Engine проектов дополнился разделом про анализ с использованием системы распределённой сборки Unreal Build Accelerator.

Помимо дополнения документации нововведениями, мы не забываем и про старые разделы. Например, в прошедшем году была полностью переработана документация об использовании плагина PVS-Studio для интегрированной среды разработки Visual Studio Code.

C и C++

Теперь поговорим об изменениях, которые произошли в C и C++ анализаторе PVS-Studio.

2025 год ознаменован улучшением технологий, используемых в C и C++ анализаторе: мы подготовили фундамент для поддержки новых стандартов языков и развития data flow и taint-анализа.

Олег Лысый,

руководитель отдела разработки C и C++ анализатора

Новый парсер C и C++ кода

В 2025 году мы наконец-то выпустили новый парсер для C и C++ кода, который разрабатывался нашей командой больше года. Это большое обновление, пусть и незаметное для большинства пользователей, служит фундаментом для дальнейших усовершенствований анализатора.

В ходе расширенного периода тестирования (EAP), прошедшего весной, у нас получилось достигнуть стабильной работы нового парсера на большом количестве реальных проектов, однако для обеспечения обратной совместимости была сохранена возможность переключения на предыдущую версию.

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

Благодаря обращениям пользователей мы уже произвели множество различных доработок. Например, исправили критические падения при анализе проектов на Unreal Engine, а также улучшили работу нового парсера при работе с шаблонами.

Улучшения анализа и разбора конструкций языка и стандартной библиотеки

Помимо улучшений, связанных с новым парсером, были и другие.

Например, в C и C++ анализаторе механизм анализа помеченных данных был распространён на диагностические правила поиска других типов ошибок: деления на ноль, побитового сдвига на недостоверное значение, выхода за границу буфера, знакового переполнения и передачи аргументом недостоверного значения.

Также в механизме анализа помеченных данных были и другие изменения, например, отслеживание заражённости при операторе % стало корректным, а также была улучшена обработка taint-статусов в ветвлениях.

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

Также была улучшена поддержка различных стандартов языка:

• C11: квалификаторы restrict и _Atomic, спецификаторы _Atomic(T) и _Thread_local;
• C23: спецификатор thread_local, ключевые слова constexpr и alignas.

Помимо этого, мы активно работаем с фидбеком от пользователей и исправляем недочёты в работе анализатора. Так, например, по наводкам от пользователей мы поправили внутренние аннотации функций std::min, std::max, std::unique_ptr<T[]>::reset и std::unique_ptr<T[]>::release.

Улучшения поддержки стандартов MISRA

В прошедшем году мы начали работы по улучшению покрытия стандарта MISRA C 2023 диагностическими правилами C и C++ анализатора.

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

В 2025 году была поддержана генерация отчёта MISRA Compliance с учётом новых поддерживаемых версий стандарта. Подробнее об этом можно прочитать в нашей документации.

К февральскому релизу PVS-Studio 7.41 стандарт MISRA C 2023 будет покрыт на 80-85%.

Новый функционал в файлах конфигурации анализа

Изменения в прошедшем году коснулись и файлов конфигурации анализа .pvsconfig.

В кроссплатформенную утилиту для проверки C и C++ проектов pvs-studio-analyzer был добавлен новый флаг ‑‑apply-pvs-configs. С помощью него включается режим автоматического поиска и применения файлов конфигурации анализа .pvsconfig для проверяемых исходных файлов. Сами файлы конфигурации правил ищутся в каталоге исходного файла и во всех родительских каталогах вплоть до корневой папки проекта, которая указывается с помощью нового флага ‑‑project-root.

Был добавлен механизм перезаписи более приоритетных настроек с помощью опции //V_OVERRIDE ON. Эта опция позволяет поддерживать сложные сценарии, где для каких-то частей проекта нужны другие значения настроек, указанных в файлах .pvsconfig с более высоким приоритетом.

Подробнее о файлах конфигурации анализа .pvsconfig можно прочитать в нашей документации.

Новые диагностические правила

Общего назначения

• V1118. Excessive file permissions can lead to vulnerabilities. Consider restricting file permissions.

Стандарт MISRA

• V2626. MISRA. The 'sizeof' operator should not have an operand which is a function parameter declared as 'array of type'.
• V2627. MISRA. Function type should not be type qualified.
• V2628. MISRA. The pointer arguments to the Standard Library functions memcpy, memmove and memcmp should be pointers to qualified or unqualified versions of compatible types.
• V2629. MISRA. Pointer arguments to the 'memcmp' function should point to an appropriate type.
• V2630. MISRA. Bit field should not be declared as a member of a union.
• V2631. MISRA. Pointers to variably-modified array types should not be used.
• V2632. MISRA. Object with temporary lifetime should not undergo array-to-pointer conversion.
• V2633. MISRA. Identifiers should be distinct from macro names.
• V2634. MISRA. Features from <fenv.h> should not be used.
• V2635. MISRA. The function with the 'system' name should not be used.
• V2636. MISRA. The functions with the 'rand' and 'srand' name of <stdlib.h> should not be used.
• V2637. MISRA. A 'noreturn' function should have 'void' return type.
• V2638. MISRA. Generic association should list an appropriate type.
• V2639. MISRA. Default association should appear as either the first or the last association of a generic selection.
• V2640. MISRA. Thread objects, thread synchronization objects and thread-specific storage pointers should have appropriate storage duration.
• V2641. MISRA. Types should be explicitly specified.
• V2642. MISRA. The '_Atomic' specifier should not be applied to the incomplete type 'void'.
• V2643. MISRA. All memory synchronization operation should be executed in sequentially consistent order.
• V2644. MISRA. Controlling expression of generic selection must not have side effects.
• V2645. MISRA. The language features specified in Annex K should not be used.
• V2646. MISRA. All arguments of any multi-argument type-generic macros from <tgmath.h> should have the same type.
• V2647. MISRA. Structure and union members of atomic objects should not be directly accessed.
• V2648. MISRA. Null pointer constant must be derived by expansion of the NULL macro provided by the implementation.
• V2649. MISRA. All arguments of any type-generic macros from <tgmath.h> should have an appropriate essential type.
• V2650. MISRA. Controlling expression of generic selection must have essential type that matches its standard type
• V2651. MISRA. Initializer using chained designators should not contain initializers without designators.
• V2652. MISRA. Argument of an integer constant macro should have an appropriate form.
• V2653. MISRA. The small integer variants of the minimum-width integer constant macros should not be used.
• V2654. MISRA. Initializer list should not contain persistent side effects.
• V2655. MISRA. The right operand of a logical '&&' or '||' operator should not contain persistent side effects.
• V2656. MISRA. The Standard Library function memcmp should not be used to compare null terminated strings.
• V2657. MISRA. Obsolescent language features should not be used.
• V2658. MISRA. Dead code should not be used in a project.
• V2659. MISRA. Switch statements should be well-formed.
• V2660. MISRA. A function declared with a _Noreturn specifier should not return to its caller.
• V2661. MISRA. A 'for' loop should be well-formed.
• V2662. MISRA. Any value passed to a function from <ctype.h> should be representable as an unsigned character or be the value EOF.
• V2663. MISRA. The macro EOF should only be compared with the unmodified return value of any Standard Library function capable of returning EOF.
• V2664. MISRA. Use of the string handling functions from <string.h> should not result in accesses beyond the bounds of the objects referenced by their pointer parameters.
• V2665. MISRA. The size argument passed to function from <string.h> should have an appropriate value.
• V2666. MISRA. All declarations of an object with an explicit alignment specification should specify the same alignment.

По запросам пользователей

• V2023. Absence of the 'override' specifier when overriding a virtual function may cause a mismatch of signatures.

Выпущенные статьи

В 2025 году в нашем блоге вышло 37 статей, посвящённых C и C++. Вот подборка некоторых из них:

• std::array в С++ быстрее массива в С. Иногда
• Безопасная работа с массивами? Нет, не слышали
• CMake: герой, который споткнулся о 12 багов
• Что нам недодали в C++
• Стоматологические услуги для компиляторов на примере LLVM 21

C#

Теперь перейдём к изменениям в C# анализаторе PVS-Studio!

В 2025 году мы уделили время созданию специализированных диагностических правил для работы с проектами на основе Unity. На данный момент в C# анализаторе более 20 специализированных диагностик для выявления проблем оптимизации и ошибок общего назначения.

Также в этом году была проведена работа по улучшению части диагностических правил C# анализатора, входящих в первую сотню. И, конечно же, был поддержан .NET 10 и C# 11.

Артём Ровенский,

руководитель отдела разработки C# анализатора

Поддержка .NET 10

В последнем релизе прошлого года уже по традиции мы поддержали анализ проектов на свежей версии .NET 10.

В 2024 году в ходе поддержки проектов на .NET 9 мы изменяли системные требования анализатора на всех платформах (после версии 7.34 стало необходимо наличие .NET 9 SDK в системе).

В 2025 же году изменение системных требований коснулось только Linux и macOS: с версии PVS-Studio 7.40 для анализа C# проектов потребуется .NET 10 SDK.

Улучшения анализа

В прошлом году мы также занимались и улучшением качества анализа для C# проектов.

Например, вернулись к самым первым диагностическим правилам C# анализатора и доработали их. В этих правилах были поддержаны новые конструкции языка, а также улучшены механизмы PVS-Studio по выявлению проблем в коде.

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

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

Также в C# анализаторе был добавлен учёт помеченных данных при выходе за границу массива, определении переполнения и потенциального деления на 0.

Новые диагностические правила

Общего назначения

• V3211. Unity Engine. The operators '?.', '??' and '??=' do not correctly handle destroyed objects derived from 'UnityEngine.Object'.
• V3212. Unity Engine. Pattern matching does not correctly handle destroyed objects derived from 'UnityEngine.Object'.
• V3213. Unity Engine. The 'GetComponent' method must be instantiated with a type that inherits from 'UnityEngine.Component'.
• V3214. Unity Engine. Using Unity API in the background thread may result in an error.
• V3215. Unity Engine. Passing a method name as a string literal into the 'StartCoroutine' is unreliable.
• V3216. Unity Engine. Checking a field with a specific Unity Engine type for null may not work correctly due to implicit field initialization by the engine.
• V3217. Possible overflow as a result of an arithmetic operation.
• V3218. Cycle condition may be incorrect due to an off-by-one error.
• V3219. The variable was changed after it was captured in a LINQ method with deferred execution. The original value will not be used when the method is executed.
• V3220. The result of the LINQ method with deferred execution is never used. The method will not be executed.
• V3221. Modifying a collection during its enumeration will lead to an exception.
• V3222. Potential resource leak. An inner IDisposable object might remain non-disposed if the constructor of the outer object throws an exception.
• V3223. Inconsistent use of a potentially shared variable with and without a lock can lead to a data race.
• V3224. Consider using an overload with 'IEqualityComparer', as it is present in similar cases for the same collection element type.
• V3225. A data reading method returns the number of bytes that were read and cannot return the value of -1.
• V3226. Potential resource leak. The disposing method will not be called if an exception occurs in the 'try' block. Consider calling it in the 'finally' block.
• V3227. The precedence of the arithmetic operator is higher than that of the shift operator. Consider using parentheses in the expression.
• V3228. It is possible that an assigned variable should be used in the next condition. Consider checking for misprints.
• V3229. The 'GetHashCode' method may return different hash codes for equal objects. It uses an object reference to generate a hash for a variable. Check the implementation of the 'Equals' method.

Микрооптимизации

• V4008. Unity Engine. Avoid using memory allocation Physics APIs in performance-sensitive context.

OWASP

• V5629. OWASP. Code contains invisible characters that may alter its logic. Consider enabling the display of invisible characters in the code editor.
• V5630. Possible cookie injection. Potentially tainted data is used to create a cookie.
• V5631. OWASP. Use of externally-controlled format string. Potentially tainted data is used as a format string.

Выпущенные статьи

За год C# команда выпустила более 20 статей. Вот подборка самых интересных из них:

• Ошибки и подозрительные места в исходниках .NET 9
• На защите GameDev'a: статический анализ и Unity
• Файловый менеджер Files: ошибки по папочкам
• Обзор нововведений в C# 14
• Что нового в .NET 10?

Java

Ну и, наконец, дошла очередь до Java анализатора!

В Java анализаторе был реализован taint-механизм, что позволило сделать много диагностических правил, направленных на защищённость. Сейчас мы покрываем 9 из 10 категорий OWASP, а к следующему (февральскому) релизу в Java анализаторе будет 40 security-диагностик.

Константин Волоховский,

руководитель отдела разработки Java анализатора

OWASP Top 10 2021

В 2024 году в Java анализаторе появился механизм taint-анализа. Тогда же вышло и первое диагностическое правило V5309, в рамках которого происходит поиск потенциальных SQL-инъекций.

В 2025 же году пришло время использовать этот механизм по полной!

Мы провели большие работы по покрытию Java анализатором категорий дефектов безопасности из OWASP Top 10 2021, для чего было выпущено множество новых диагностических правил, целью которых является поиск потенциальных уязвимостей. Сейчас диагностики Java анализатора покрывают 9 из 10 категорий.

Подробнее о классификации диагностических правил PVS-Studio согласно OWASP Top 10 можно узнать на этой странице.

Новые диагностические правила

Общего назначения

• V6126. Native synchronization used on high-level concurrency class.
• V6127. Closeable object is not closed. This may lead to a resource leak.
• V6128. Using a Closable object after it was closed can lead to an exception.
• V6129. Possible deadlock due to incorrect synchronization order between locks.
• V6130. Integer overflow in arithmetic expression.
• V6131. Casting to a type with a smaller range will result in an overflow.
• V6132. It is possible that 'else' block was forgotten or commented out, thus altering the program's operation logics.

OWASP

• V5310. OWASP. Possible command injection. Potentially tainted data is used to create OS command.
• V5311. OWASP. Possible argument injection. Potentially tainted data is used to create OS command.
• V5312. OWASP. Possible XPath injection. Potentially tainted data is used to create XPath expression.
• V5313. OWASP. Do not use the old versions of SSL/TLS protocols as it may cause security issues.
• V5314. OWASP. Use of an outdated hash algorithm is not recommended.
• V5315. OWASP. Use of an outdated cryptographic algorithm is not recommended.
• V5316. OWASP. Do not use the 'HttpServletRequest.getRequestedSessionId' method because it uses a session ID provided by a client.
• V5317. OWASP. Implementing a cryptographic algorithm is not advised because an attacker might break it.
• V5318. OWASP. Setting POSIX file permissions to 'all' or 'others' groups can lead to unintended access to files or directories.
• V5319. OWASP. Possible log injection. Potentially tainted data is written into logs.
• V5320. OWASP. Use of potentially tainted data in configuration may lead to security issues.
• V5321. OWASP. Possible LDAP injection. Potentially tainted data is used in a search filter.
• V5322. OWASP. Possible reflection injection. Potentially tainted data is used to select class or method.
• V5323. OWASP. Potentially tainted data is used to define 'Access-Control-Allow-Origin' header.
• V5324. OWASP. Possible open redirect vulnerability. Potentially tainted data is used in the URL.
• V5325. OWASP. Setting the value of the 'Access-Control-Allow-Origin' header to '*' is potentially insecure.
• V5326. OWASP. OWASP. A password for a database connection should not be empty.
• V5327. OWASP. Possible regex injection. Potentially tainted data is used to create regular expression.
• V5328. OWASP. Using weak authorization checks could lead to security violations.
• V5329. OWASP. Using unsafe methods of file creation is not recommended because an attacker might access the files.
• V5330. OWASP. Possible XSS injection. Potentially tainted data might be used to execute a malicious script.
• V5331. OWASP. Hardcoded IP addresses are not secure.
• V5332. OWASP. Possible path traversal vulnerability. Potentially tainted data might be used to access files or folders outside a target directory.
• V5333. OWASP. Possible insecure deserialization vulnerability. Potentially tainted data is used to create an object during deserialization.
• V5334. OWASP. Possible server-side request forgery. Potentially tainted data is used in the URL.
• V5335. OWASP. Potential XXE vulnerability. Insecure XML parser is used to process potentially tainted data.
• V5336. OWASP. Potential XEE vulnerability. Insecure XML parser is used to process potentially tainted data.
• V5337. OWASP. Possible NoSQL injection. Potentially tainted data is used to create query.
• V5338. OWASP. Possible Zip Slip vulnerability. Potentially tainted data is used in the path to extract the file.

Выпущенные статьи

В 2025 году в нашем блоге вышло 37 статей, посвящённых Java. Вот подборка некоторых из них:

• Как уронить Minecraft своим модом
• Поиск потенциальных уязвимостей в коде, часть 2: практика
• Инъекция блокнотом или история о том, как мы новые диагностики делали
• Method Handles быстрее рефлексии (иногда)
• Цепочка гаджетов в Java и как небезопасная десериализация приводит к RCE?

Заключение

Мы постарались рассказать обо всех важных нововведениях в анализаторе за 2025 год, но даже так мы охватили лишь часть. Полный список изменений можно найти на странице истории релизов.

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

В 2026 нас ждёт ещё больше всего интересного, следите за новостями!