Хотите, чтобы ваш open source проект был чище и безопаснее? Рассказываем, как использовать PVS-Studio для регулярного анализа кода, внедрить его в CI и находить баги до их попадания в релиз. И да, лицензия для открытых проектов у нас бесплатная.

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

Примечание. Полный список проверенных проектов можно найти по этой ссылке, а предложить свой проект для проверки можно в этом GitHub репозитории.

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

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

Зачем?

Важный вопрос, который может возникнуть: "А зачем мне вообще проверять open source проект анализатором?"

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

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

А если использовать анализатор регулярно — например, в CI/CD — он ещё и не даст этим дефектам проникнуть в руки пользователям. То есть вы не просто чините упавшее в прошлом, а предотвращаете падения в будущем.

Open source — это про "вместе делаем лучше". И статический анализ — один из способов внести свой вклад в эту общую работу.

Сколько?

Open source, как правило, история некоммерческая, поэтому и мы с точки зрения лицензирования продукта подходим к вопросу соответствующе.

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

Важно. Бесплатная лицензия PVS-Studio не распространяется на коммерческие или развиваемые корпорациями проекты, а также на зеркала и форки.

Чтобы получить лицензию, нужно выполнить несколько несложных шагов.

Сначала нужно добавить следующий фрагмент в README.md проекта:

## SAST Tools 
 
[PVS-Studio](https://pvs-studio.com/pvs-studio/?utm_source=website&utm_medium=github&utm_campaign=open_source) - static analyzer for C, C++, C#, and Java code.

Далее нужно перейти на эту страницу нашего сайта, ввести имя и e-mail, на который будет прислан лицензионный ключ, и ввести ссылку на проект.

Для дальнейшего продления лицензии нужно воспользоваться этим же алгоритмом.

Также важно соблюдать следующие правила использования бесплатной лицензии PVS-Studio:

1. Использовать одну лицензию только на одном проекте;

2. Упоминать PVS-Studio в коммитах и Pull Request'ах, которые касаются исправления предупреждений PVS-Studio, например, "Fixed issues found by PVS-Studio";

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

Если при использовании PVS-Studio в своём открытом проекте у вас возникли вопросы из разряда "как сделать...", их можно задать на Stack Overflow, добавив к вопросу тег pvs-studio.

Если вы столкнулись с какой-то неполадкой в работе анализатора, то о ней можно сообщить в поддержку.

Регулярно?

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

Особенно эффективно запускать анализ при открытии Pull/Merge Request. В этот момент код уже готов к интеграции, но ещё не попал в основную ветку.

Подробнее об этой теме мы говорили в одной из публикаций в нашем блоге. Более того, там же мы разбирали и пример пайплайна для GitHub Actions, в котором рассматривали анализ Pull Request'ов. Но один момент в той публикации мы всё же упустили: как анализировать "внешние" Pull Request'ы, т.е. запросы на слияние, открытые из fork'ов?

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

Но как же тогда настроить анализ "внешних" Pull Request'ов? Нужно добавить всего пару настроек.

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

Ниже в пункте Environment secrets, по аналогии с секретной переменной для всего репозитория, нужно создать переменную конкретно для этого окружения.

После этого в yaml-файле нужно добавить созданное окружение, например:

....
jobs:
  external-analysis:
    environment: pr-review-required
....

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

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

Посмотреть на пример workflow для GitHub Actions можно в этом тестовом репозитории.

Помимо работы с GitHub Actions анализатор PVS-Studio также можно запустить в GitLab CI/CD. Для более специфичных случаев можно воспользоваться разделом нашей документации о том, как анализировать коммиты и Pull Request'ы.

Конец?

В этой статье я постарался ответить на вопросы, связанные с использованием статического анализатора PVS-Studio для анализа open source проектов. Если же какие-то вопросы остались незатронутыми, то я с радостью отвечу на них в комментариях под этим текстом.

Чистого вам кода, друзья!

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Valerii Filatov. Use PVS-Studio to analyze open-source projects.