Статический анализ — это не только запуск проверки. Как обрабатывать отчёты, рассылать предупреждения разработчикам и визуализировать результаты? Рассказываем, как с помощью утилит и интеграций PVS-Studio превратить сырые данные анализатора в эффективный процесс улучшения кода.

В предыдущих статьях нашего блога мы рассказывали о важности регулярного статического анализа кода и о том, как его можно интегрировать в процесс разработки — в том числе через анализ Pull Request'ов и автоматизацию в CI/CD.

Но запуск анализа — это только начало. Также важно уметь работать с тем, что анализатор выдаёт. Ведь результаты нужно не просто получить, а обработать, доставить нужным людям и визуализировать, чтобы в итоге отчёт анализатора привёл к конкретным изменениям.

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

Использование плагинов для IDE

Один из эффективных способов улучшить опыт работы со статическим анализатором на этапе разработки — это интеграция его в среду разработки (IDE) с помощью специальных плагинов. Такие плагины позволяют запускать анализ прямо из интерфейса IDE, не покидая рабочего пространства, а также удобно просматривать результаты: отображать предупреждения в режиме реального времени, переходить к месту проблемы одним кликом и даже применять автоматические исправления. Это существенно снижает когнитивную нагрузку разработчика и ускоряет выявление и устранение ошибок на ранних стадиях.

Рассмотрим, например, плагин PVS-Studio для IntelliJ IDEA и OpenIDE.

В отдельном окне IDE отображается таблица, содержащая результаты работы анализатора. Здесь же мы можем удобным образом фильтровать срабатывания по уровням достоверности диагностических правил (кнопки High, Medium, Low), категориям диагностических правил (кнопки General, OWASP).

В плагинах PVS-Studio для IntelliJ IDEA, CLion, Rider и Visual Studio также есть специальная кнопка Best Warnings, позволяющая отобразить 10 самых интересных, по мнению анализатора, срабатываний:

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

Примечание. Попробовать статический анализатор PVS-Studio на своём проекте можно с помощью бесплатного пробного ключа, который можно получить по ссылке.

Также, дважды кликнув по срабатыванию, мы окажемся в том фрагменте кода, на который было выдано данное срабатывание анализатора, а трасса срабатывания будет подсвечена в коде:

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

Примечание. Подробнее о настройках плагина PVS-Studio для IntelliJ IDEA и OpenIDE можно прочитать по ссылке.

Помимо плагина для IntelliJ IDEA и OpenIDE также есть плагины PVS-Studio для других сред разработки: Visual Studio, CLion и Rider, Visual Studio Code, Qt Creator.

Конвертация отчёта

После проведения анализа мы получаем отчёт анализатора, который может быть в самых разных форматах. Например, PVS-Studio может выдавать его в .plog, .log и .json в зависимости от используемого анализатора и платформы.

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

В PVS-Studio мы для решения таких задач разрабатываем отдельный компонент нашего анализатора — утилиту конвертации отчётов Plog Converter.

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

Команда для Windows:

PlogConverter.exe -t sarif -o ./report.sarif report.json

Команда для Linux:

plog-converter -t sarif -o ./ -n report -a ALL report.json

В данной команде мы указываем с помощью флага -t, в какой формат мы хотим конвертировать отчёт; с помощью флага -o задаём место, где будет сохранён отчёт анализатора. Для Linux с помощью флага -a мы дополнительно указали, что нужно оставить все срабатывания, которые содержал исходный отчёт, , а также добавили имя отчёта с помощью флага -n (в Windows-реализации название файла можно написать прямо в пути до преобразованного отчёта).

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

Например, чтобы оставить только срабатывания группы General Analysis 1 и 2 уровня достоверности, мы бы написали в команде -a "GA:1,2".

Также с помощью Plog Converter можно отфильтровать все срабатывания в отчёте, которые относятся к категориям критических ошибок по ГОСТ Р 71207-2024. Для этого нужно использовать флаг --filterSecurityRelatedIssues.

Для того, чтобы отфильтровать критические ошибки, анализ предварительно нужно запускать с флагом для добавления к срабатываниям специальных SAST идентификаторов. Флаг для проектов на C++ можно посмотреть в этом разделе нашей документации.

Примечание. Подробнее о работе Plog Converter можно прочитать в посвящённом утилите разделе нашей документации.

Рассылка результатов

После получения отчёта анализатора важно вовремя отреагировать на выданные им предупреждения. Более того, важно также понять, кто будет ответственным за исправление того или иного найденного анализатором бага. Здесь на помощь пользователям PVS-Studio может прийти утилита Blame Notifier.

Она автоматически связывает предупреждения анализатора с разработчиками, чей код был изменён, используя blame из системы контроля версий. На основе этого формируются персонализированные HTML-отчёты, которые рассылаются непосредственно тем, кто вносил изменения в проблемные участки кода. Это устраняет неопределённость, ускоряет реакцию и формирует культуру персональной ответственности за качество.

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

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

Примечание. Подробнее о работе утилиты Blame Notifier можно прочитать в нашей документации.

Использование веб-интерфейсов

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

Попытка использовать систему контроля версий для синхронизации отчётов, например, через общий файл, быстро сталкивается с практическими трудностями: формат отчёта не предназначен для слияния изменений, а попытки синхронизации в Git или других VCS приводят к конфликтам и потере актуального состояния.

Решение этой проблемы — переход к специализированным инструментам для управления результатами статического анализа. Отчёты PVS-Studio, например, можно интегрировать в такие платформы, как SonarQube, DefectDojo, CodeChecker, AppSecHub, Securitm и другие. Они предоставляют веб-интерфейс для удобного просмотра, фильтрации и анализа срабатываний, что делает процесс обработки отчёта прозрачным и доступным для всей команды.

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

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

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

Исправление срабатываний

После того, как мы узнали о наличии срабатываний, нужно же их исправить, верно?

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

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

Завершение

В данной статье мы чуть расширили тему использования статического анализатора, погрузившись в вопрос, а что делать после? Что делать, когда мы уже получили отчёт?

Данные советы помогут улучшить как опыт от использования инструмента, так и результативность его применения.

Если вы всё ещё не используете статический анализатор в своём проекте, то попробовать проверить его с помощью PVS-Studio можно с помощью бесплатной пробной лицензии по ссылке.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Valerii Filatov. How to manage static analysis results.

Управление результатами статического анализа