0905_PVS-Studio_2021_ru/image1.png


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


И начнём мы с того, что немного переместимся в прошлое (неожиданно, да?). Ведь именно в этот день, целых 15 (!) лет назад в сеть была выложена первая версия анализатора – Viva64 1.00. Да, тогда ещё не было никаких PVS-Studio, никаких C# и Java анализаторов. Да что там, даже никаких диагностик общего назначения тогда ещё не было! :)


Воспользовавшись веб-архивом, можно посмотреть, как выглядел сайт тех лет:


0905_PVS-Studio_2021_ru/image3.png


С тех пор много воды утекло. Продукт неустанно развивался, а компания росла. Если вам интересно почитать о том, как шёл процесс становления PVS-Studio, предлагаю полистать эту страницу, а также почитать статью "Как 10 лет назад начинался проект PVS-Studio".


Примечание. Пока я не взглянул на заголовок и дату публикации упомянутой выше статьи, у меня держалось стойкое впечатление, что она была написана совсем недавно. Однако с тех пор минуло уже 5 лет… Andrey2008, кажется, скоро нужно будет писать новую. ;)


Но пора вернуться в настоящее время к нашей основной теме и рассмотреть, что же произошло с PVS-Studio в 2021 году! И начнём обзор мы с общих улучшений, которые не привязаны к конкретному языку. А вот в разделах про C, C++ и C# мы, наоборот, разберём более специфичные вещи.


Обновление сайта


Кстати, раз уж мы заговорили о сайтах. Если вы периодически заглядываете к нам на сайт, то могли заметить, что в этом году мы полностью обновили его дизайн. К тому же мы наконец переехали на домен pvs-studio.com. Много элементов было изменено с точки зрения юзабилити: у статей появились комментарии и лайки/дизлайки, в документации добавилось сквозное меню и много чего ещё. Подробнее про всё это мы писали здесь.


0905_PVS-Studio_2021_ru/image4.png


Safety and security


Мы продолжаем развивать PVS-Studio как SAST-решение (Static Application Security Testing) и в 2021 году уделили этому направлению много сил.


Во-первых, появились новые группы диагностик, соответствующие OWASP ASVS (C++, C#, Java) и AUTOSAR. С полным списком диагностических возможностей PVS-Studio можно ознакомиться здесь.


Во-вторых, в отчёты анализатора была добавлена дополнительная информация про "security-идентификаторы". Если раньше можно было посмотреть идентификаторы CWE и MISRA, то теперь к ним добавились OWASP ASVS, SEI CERT и AUTOSAR. Данная информация доступна в плагинах для IDE, при использовании утилит конвертации (PlogConverter), в SonarQube на уровне тегов.


В плагине для Visual Studio это может выглядеть так (на примере CWE и OWASP ASVS):


0905_PVS-Studio_2021_ru/image5.png


В-третьих, на нашем сайте были обновлены таблицы соответствия диагностик PVS-Studio различным стандартам:



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


Кроме того, были добавлены соответствия для OWASP Top 10 и CWE Top 25:



Более подробно о том, что было сделано по safety/security направлениям для каждого из языков, будет рассказано в соответствующих разделах.


Поддержка Visual Studio 2022


В начале 2021 года Microsoft анонсировала Visual Studio 2022. Обещали много интересных фишек, главная из которых заключается в том, что сама IDE теперь будет 64-битной.


В принципе, вопроса о необходимости поддержки Visual Studio 2022 даже не стояло – конечно, мы собирались её поддержать. Но дополнительно нашу уверенность подкрепляло то, что чем ближе был релиз VS2022, тем больше людей спрашивало, а есть ли у нас плагин для этой IDE.


Что ж, в итоге мы поддержали Visual Studio 2022 в декабрьском релизе PVS-Studio – ближайшем к релизу самой IDE.


0905_PVS-Studio_2021_ru/image7.png


Отображение лучших предупреждений анализатора


Когда пользователь впервые запускает статический анализатор, то он может столкнуться с большим количеством предупреждений. Особенно это актуально для проектов с историей (т.е. с объёмным legacy).


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


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

А хотелось бы, чтобы пользователь сразу увидел "самый сок" – предупреждения на такой код, когда смотришь и понимаешь: "Да, с этим кодом определённо что-то не то!". Что ж, теперь в PVS-Studio есть подобный механизм. Вы нажимаете на специальную кнопку и видите лучшие предупреждения из лога анализатора – те, которые с наибольшей вероятностью указывают на какую-то ошибку.


0905_PVS-Studio_2021_ru/image9.png


Пока данная функциональность доступна только в плагине для Visual Studio, но в будущем мы планируем добавить её и в плагины для других IDE.


Оповещения о предупреждениях, выданных на новый код


В состав PVS-Studio входит утилита blame-notifier, которая позволяет оповещать разработчиков и менеджеров о предупреждениях, найденных анализатором. Использование blame-notifier в CI в совокупности с регулярным анализом позволит разработчикам своевременно узнавать о предупреждениях, которые они могли пропустить, а менеджерам – контролировать общее состояние дел.


В этом году blame-notifier получил важный апдейт. Теперь инструмент даёт возможность обрабатывать только новые предупреждения, выданные на свежий код. К тому же сам отчёт теперь содержит больше информации – дату изменения кода, на который было выдано предупреждение, и номер ревизии.


Вы указываете "срок давности" кода, на который было выдано предупреждение. Если код более старый – предупреждение в рассылку не попадёт.


Почему такой апдейт важен? Это позволяет делать акцент именно на новых предупреждениях анализатора и иметь такой легковесный аналог SonarQube в плане подхода "Clean as You Code". Если вам не хочется / нет смысла настраивать SonarQube, но хочется иметь подобную функциональность – теперь возможность есть. Более подробно про сам режим, историю его появления и идеологию можно почитать здесь.


0905_PVS-Studio_2021_ru/image11.png


Java


К сожалению, по Java-анализатору нет обновлений, кроме упомянутых выше (SAST-идентификаторы, несколько диагностик из OWASP ASVS). :(


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


Тем не менее, мы продолжаем поддержку Java-анализатора и исправление возможных багов.


C, C++


Поддержка межмодульного анализа


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


Межмодульный анализ позволяет получить информацию о полной структуре проекта, делая анализ более точным и качественным. Это очень схоже с задачей оптимизации на этапе компоновки (Link Time Optimization, LTO). Таким образом, анализатор может узнать поведение той или иной внешней функции из другого файла проекта и выдать предупреждение, к примеру, на разыменование нулевого указателя, переданного как аргумент внешней функции.


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


Плагин для CLion


В PVS-Studio уже были плагины для различных IDE от JetBrains: Rider, IntelliJ IDEA. Другую известную IDE – CLion – мы как-то долго обходили стороной, хоть и не забывали про неё. Но пользователи всё чаще и чаще спрашивали про её поддержку. Более того, плагин PVS-Studio для CLion как кроссплатформенной IDE дал бы возможность удобной работы с C++ анализатором независимо от того, в каком окружении работает разработчик: на Windows, Linux или macOS.


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


0905_PVS-Studio_2021_ru/image13.png


Улучшение поддержки Unreal Engine


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


В C++ анализаторе PVS-Studio были дополнительно проаннотированы функции из игрового движка Unreal Engine. Аннотации помогают не только выявить новые ошибки, но и исключить некоторые ложные срабатывания. В качестве полигона для испытаний выступил свободный проект CARLA. Подробнее про всё это можно почитать в отдельной статье.


Другим важным улучшением в работе с Unreal Engine проектами стала возможность отключения предупреждений на существующем коде (baseline разметка). Это позволит разработчикам работать только с новыми предупреждениями, не отвлекаясь на те, что выдаются на legacy-код. Подробнее про это можно почитать здесь.


MISRA


Собрав обратную связь от наших пользователей и увидев интерес к анализу кода проектов в соответствии с MISRA C 2012, мы стали развивать это направление до конкурентоспособного уровня, выставив себе цель повысить покрытие стандарта нашими диагностиками до 80% к концу года. В результате усердной работы за 2021 год мы реализовали 57 новых MISRA диагностик. Теперь поддержка стандарта обеспечения надёжности MISRA C 2012 в PVS-Studio, как мы и планировали, достигла 80%.


Другой важной целью было добавление возможности генерировать отчёт MISRA Compliance. Он необходим для того, чтобы понять, соответствует ли ваш проект стандартам MISRA C или MISRA C++ с учётом всех отклонений и рекатегоризаций. Что ж, теперь такая возможность также присутствует. Более подробно почитать про это можно здесь.


0905_PVS-Studio_2021_ru/image14.png


C#


Taint-анализ, OWASP


В 2021 году в C# анализаторе появился taint-анализ. Если в двух словах – это технология анализа, позволяющая отслеживать попадание и распространение по приложению 'заражённых' данных. Потенциально заражёнными они являются по той причине, что поступают из внешнего источника и, как следствие, могут быть скомпрометированы злоумышленником. Если такие данные попадут в те точки приложения, куда им попадать не следовало бы (например, в сырой SQL-запрос), это может привести к появлению потенциальной уязвимости. Более подробно taint-анализ описан в этой статье.


На основе taint-анализа были разработаны диагностики для поиска ряда потенциальных уязвимостей: SQLI, XSS, path traversal, XXE, XEE и т.п.


Кстати, к разговорам про безопасность и XEE. Если вдруг вы пропустили, вам может быть интересно, как и почему Visual Studio 2022 Preview при работе могла потреблять кучу памяти (например, 100Гб) на машине. Почитать про это можно тут.


Performance


Много времени мы уделили оптимизациям C# анализатора и написали несколько статей на эту тему. Ниже приводится график того, как менялось время анализа некоторых проектов на нашей тестовой базе между релизами PVS-Studio 7.11 – PVS-Studio 7.14, когда и были проделаны основные работы по оптимизации.


0905_PVS-Studio_2021_ru/image15.png


Более подробно о том, что, как и зачем мы оптимизировали, можно прочитать в этих статьях:



Поддержка проектов на .NET 5 и .NET 6


В этом году мы немного запоздало научили C# анализатор работать с проектами на .NET 5. Чуть позже – уже своевременно – с .NET 6. Вместе с тем анализатор научился разбирать код C# 10.


К слову, сам PVS-Studio C# под Linux и macOS теперь также работает на .NET 6.


Заключение


Конечно, в этой статье описано не всё, что появилось в анализаторе в этом году. Вместе с тем продолжается разработка диагностик общей направленности, правка false positives и прочие улучшения. Например, поддержка новых компиляторов, возможности более тонкой настройки анализа с помощью .pvsconfig-файлов и т.п. Более подробно с изменениями, которые входили в каждый релиз PVS-Studio, можно ознакомиться здесь.


Кстати, если хотите не только читать, но и смотреть – за новостями теперь можно следить и на нашем YouTube-канале.


В качестве завершения хочу закинуть удочку на будущее и спросить – а что бы вы хотели видеть в PVS-Studio в 2022 году?


И, конечно, с наступающими праздниками! ;)


Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Sergey Vasiliev, Maxim Stefanov, Oleg Lisiy. What's new in PVS-Studio in 2021?

Комментарии (8)


  1. EvgeniyRyzhkov
    31.12.2021 15:33
    +4

    15 лет... Ничего себе...


    1. foto_shooter Автор
      31.12.2021 15:38
      +1

      Я работаю поменьше, но тоже не перестаю удивляться, как время летит. :)


  1. mn3m0n1c_3n3m1
    01.01.2022 02:33

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

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


    1. qw1
      01.01.2022 13:46

      Получится клон R#/ReSharper for C++ :)


    1. Andrey2008
      01.01.2022 14:22
      +1

      Спасибо за интерес к нашему продукту и пожеланиям.

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

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

      Подробнее эта тема раскрыта в статье "Почему PVS-Studio не предлагает автоматические правки кода".


  1. mn3m0n1c_3n3m1
    03.01.2022 04:11

    Благодарю за развёрнутый ответ.

    Автоматическими изменениями кода занимаются инструменты, осуществляющие рефакторинг или форматирование кода.

    Рефакторинг - это плановое изменения кода по обозначенному маршруту в рамках конкретного проекта.

    Форматирование - это визуальное оформление кода: отступы и точки с запятыми.

    Я же говорю об автоматическом исправлении проблемных мест в соответствии с лучшими правилами построения качественного кода.

    Пример из статьи очень не плохой кандидат для автоматизации:

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

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

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

    Какие случаи вы считаете простыми? Наверняка те, с которыми научились работать, и те которые начали автоматизировать. Начало в любом случае будет простым. Но из этого простого решения, постепенно начнут складыватся более сложные. К примеру в ????Putout есть возможность перевода CommonJS в ESM и наоборот.

    В результате, эта функциональность будет столь ограничена, что лучше вообще её не делать.

    Тут вы делаете вывод из собственного утверждения. А ведь простой функционал - это быстрый MVP и прямая польза.

    Тем более всё равно слишком велик риск неправильного изменения кода

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

    > и человек обязан участвовать в этом процессе.

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


    1. Andrey2008
      03.01.2022 10:06

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


    1. qw1
      03.01.2022 13:07

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

      PVS — инструмент, продаваемый бизнесу, а не одиночкам.
      Если какому-нибудь стажёру дадут задание «разберись тут с предупреждениями», и он не сможет понять суть проблемы (а спрашивать у старших товарищей постесняется), и примет предлагаемое «исправление», негатив останется от инструмента, а не от стажёра.