2021 вот-вот закончится, а значит, настало время подведения итогов! Сегодня мы поговорим о том, что нового появилось в анализаторе PVS-Studio за прошедший год. Устраивайтесь поудобнее, мы начинаем.
И начнём мы с того, что немного переместимся в прошлое (неожиданно, да?). Ведь именно в этот день, целых 15 (!) лет назад в сеть была выложена первая версия анализатора – Viva64 1.00. Да, тогда ещё не было никаких PVS-Studio, никаких C# и Java анализаторов. Да что там, даже никаких диагностик общего назначения тогда ещё не было! :)
Воспользовавшись веб-архивом, можно посмотреть, как выглядел сайт тех лет:
С тех пор много воды утекло. Продукт неустанно развивался, а компания росла. Если вам интересно почитать о том, как шёл процесс становления PVS-Studio, предлагаю полистать эту страницу, а также почитать статью "Как 10 лет назад начинался проект PVS-Studio".
Примечание. Пока я не взглянул на заголовок и дату публикации упомянутой выше статьи, у меня держалось стойкое впечатление, что она была написана совсем недавно. Однако с тех пор минуло уже 5 лет… Andrey2008, кажется, скоро нужно будет писать новую. ;)
Но пора вернуться в настоящее время к нашей основной теме и рассмотреть, что же произошло с PVS-Studio в 2021 году! И начнём обзор мы с общих улучшений, которые не привязаны к конкретному языку. А вот в разделах про C, C++ и C# мы, наоборот, разберём более специфичные вещи.
Обновление сайта
Кстати, раз уж мы заговорили о сайтах. Если вы периодически заглядываете к нам на сайт, то могли заметить, что в этом году мы полностью обновили его дизайн. К тому же мы наконец переехали на домен pvs-studio.com. Много элементов было изменено с точки зрения юзабилити: у статей появились комментарии и лайки/дизлайки, в документации добавилось сквозное меню и много чего ещё. Подробнее про всё это мы писали здесь.
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):
В-третьих, на нашем сайте были обновлены таблицы соответствия диагностик PVS-Studio различным стандартам:
- CWE;
- OWASP Application Security Verification Standard;
- SEI CERT Coding Standard;
- MISRA C, MISRA C++;
- AUTOSAR C++14 Coding Guidelines.
Используя их, можно быстро оценить соответствие между правилами нужного стандарта и диагностиками 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.
Отображение лучших предупреждений анализатора
Когда пользователь впервые запускает статический анализатор, то он может столкнуться с большим количеством предупреждений. Особенно это актуально для проектов с историей (т.е. с объёмным legacy).
И здесь для человека, только знакомящегося с анализатором, есть сразу несколько ловушек, в которые он может попасть, например:
- включить все группы предупреждений всех уровней и приуныть от возможного количества срабатываний;
- пролистать десяток предупреждений, напороться преимущественно на false positives и отчаяться.
А хотелось бы, чтобы пользователь сразу увидел "самый сок" – предупреждения на такой код, когда смотришь и понимаешь: "Да, с этим кодом определённо что-то не то!". Что ж, теперь в PVS-Studio есть подобный механизм. Вы нажимаете на специальную кнопку и видите лучшие предупреждения из лога анализатора – те, которые с наибольшей вероятностью указывают на какую-то ошибку.
Пока данная функциональность доступна только в плагине для Visual Studio, но в будущем мы планируем добавить её и в плагины для других IDE.
Оповещения о предупреждениях, выданных на новый код
В состав PVS-Studio входит утилита blame-notifier, которая позволяет оповещать разработчиков и менеджеров о предупреждениях, найденных анализатором. Использование blame-notifier в CI в совокупности с регулярным анализом позволит разработчикам своевременно узнавать о предупреждениях, которые они могли пропустить, а менеджерам – контролировать общее состояние дел.
В этом году blame-notifier получил важный апдейт. Теперь инструмент даёт возможность обрабатывать только новые предупреждения, выданные на свежий код. К тому же сам отчёт теперь содержит больше информации – дату изменения кода, на который было выдано предупреждение, и номер ревизии.
Вы указываете "срок давности" кода, на который было выдано предупреждение. Если код более старый – предупреждение в рассылку не попадёт.
Почему такой апдейт важен? Это позволяет делать акцент именно на новых предупреждениях анализатора и иметь такой легковесный аналог SonarQube в плане подхода "Clean as You Code". Если вам не хочется / нет смысла настраивать SonarQube, но хочется иметь подобную функциональность – теперь возможность есть. Более подробно про сам режим, историю его появления и идеологию можно почитать здесь.
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 был реализован, хотя без подводных камней при разработке не обошлось.
Улучшение поддержки 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++ с учётом всех отклонений и рекатегоризаций. Что ж, теперь такая возможность также присутствует. Более подробно почитать про это можно здесь.
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, когда и были проделаны основные работы по оптимизации.
Более подробно о том, что, как и зачем мы оптимизировали, можно прочитать в этих статьях:
- "Слава баг-репортам, или как мы сократили время анализа проекта пользователя с 80 до 4 часов"
- "Оптимизация .NET приложений: большой результат маленьких правок"
Поддержка проектов на .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)
mn3m0n1c_3n3m1
01.01.2022 02:33Очень бы хотелось увидеть возможность автоматического исправления найденных PVS-Studio ошибок. Конечно это не всегда можно реализовать, но есть целый класс ошибок, о которых можно не только оповещать, но и смело править. Как это делает один из инструментов похожего толка, только для JavaScript.
15 лет, это сильно, желаю вам, что бы задор не утихал, а разгорался с новой мощью, и нас продолжали радовать новые приключения статического анализатора.
Andrey2008
01.01.2022 14:22+1Спасибо за интерес к нашему продукту и пожеланиям.
По поводу автоматических правок. Таких планов нет. Автоматическими изменениями кода занимаются инструменты, осуществляющие рефакторинг или форматирование кода. Мы не развиваем инструмент в этом направлении. Мы сосредоточены именно на поиске потенциальных ошибок и потенциальных уязвимостей.
Говоря о правке ошибок, это возможно только для очень простых случаев. В результате, эта функциональность будет столь ограничена, что лучше вообще её не делать. Тем более всё равно слишком велик риск неправильного изменения кода и человек обязан участвовать в этом процессе.
Подробнее эта тема раскрыта в статье "Почему PVS-Studio не предлагает автоматические правки кода".
mn3m0n1c_3n3m1
03.01.2022 04:11Благодарю за развёрнутый ответ.
Автоматическими изменениями кода занимаются инструменты, осуществляющие рефакторинг или форматирование кода.
Рефакторинг - это плановое изменения кода по обозначенному маршруту в рамках конкретного проекта.
Форматирование - это визуальное оформление кода: отступы и точки с запятыми.
Я же говорю об автоматическом исправлении проблемных мест в соответствии с лучшими правилами построения качественного кода.
Пример из статьи очень не плохой кандидат для автоматизации:
Говоря о правке ошибок, это возможно только для очень простых случаев. В результате, эта функциональность будет столь ограничена, что лучше вообще её не делать. Тем более всё равно слишком велик риск неправильного изменения кода и человек обязан участвовать в этом процессе.
Тут я с вами не соглашусь абсолютно. И вот почему, давайте разбираться.
Говоря о правке ошибок, это возможно только для очень простых случаев.
Какие случаи вы считаете простыми? Наверняка те, с которыми научились работать, и те которые начали автоматизировать. Начало в любом случае будет простым. Но из этого простого решения, постепенно начнут складыватся более сложные. К примеру в ????Putout есть возможность перевода CommonJS в ESM и наоборот.
В результате, эта функциональность будет столь ограничена, что лучше вообще её не делать.
Тут вы делаете вывод из собственного утверждения. А ведь простой функционал - это быстрый MVP и прямая польза.
Тем более всё равно слишком велик риск неправильного изменения кода
Риск есть всегда, однако есть и риск успешного приминения трансформаций кода, и тогда ошибки можно будет не только найти но и применить исправление. А неправильные изменения кода должны ловить тесты и компилятор.
> и человек обязан участвовать в этом процессе.
В этом я с вами не буду спорить, конечно за человеком остаётся решение. Но чем больше щепетильной монотонной работы передаётся машине, тем больше времени человек может посвящать творчеству и архитектурным решениям. Да, неплохо присматривать за результатом, но одно дело проверять результат, и совсем другое его выдавать.
Andrey2008
03.01.2022 10:06Мне кажется мы друг друга не понимаем. Например, я не понимаю, почему Вы назвали пример из статьи «не плохой кандидат для автоматизации». Даже я сам не уверен, как должна выглядеть правка. Какая уж тут автоматизация. Возможно, Вы поспешили и не углубились в повествование: изменение на картинке не является правильным исправлением.
qw1
03.01.2022 13:07Проблема в том, что пока предупреждение висит, мы знаем, что потенциально в коде есть проблема. Если исправить автоматически, да ещё неправильно, проблема будет «заметена под ковёр» и мы с ней столкнёмся, когда программа неправильно отработает, или хакеры научятся через этот баг ломать сервис.
PVS — инструмент, продаваемый бизнесу, а не одиночкам.
Если какому-нибудь стажёру дадут задание «разберись тут с предупреждениями», и он не сможет понять суть проблемы (а спрашивать у старших товарищей постесняется), и примет предлагаемое «исправление», негатив останется от инструмента, а не от стажёра.
EvgeniyRyzhkov
15 лет... Ничего себе...
foto_shooter Автор
Я работаю поменьше, но тоже не перестаю удивляться, как время летит. :)