# Статический анализ в open source проектах с помощью PVS\-Studio

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

![1283_sa_in_opensource_ru/image1.png](https://import.viva64.com/docx/blog/1283_sa_in_opensource_ru/image1.png)

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


> \*\*Примечание\\\.\*\* Полный список проверенных проектов можно найти по \[этой ссылке\]\(https://pvs\-studio\.ru/ru/blog/inspections/\), а предложить свой проект для проверки можно в \[этом GitHub репозитории\]\(https://github\.com/viva64/pvs\-studio\-check\-list\)\\\.

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

Поэтому сегодня расскажу про то, как можно использовать статический анализатор 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\\\.

Далее нужно перейти на [эту страницу](https://pvs-studio.ru/ru/order/open-source-license/) нашего сайта, ввести имя и e\-mail, на который будет прислан лицензионный ключ, и ввести ссылку на проект\.

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

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

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

Базовые условия бесплатной лицензии могут не подойти вашему проекту, и это нормально\. Мы готовы обсудить индивидуальные условия, если вы хотите использовать наше решение для контроля качества кода\. Расскажите нам о своём кейсе через [форму обратной связи](https://pvs-studio.ru/ru/about-feedback/), и мы найдём удобное решение вместе\.

Если при использовании PVS\-Studio в своём открытом проекте у вас возникли вопросы из разряда "как сделать\.\.\.", их можно задать на Stack Overflow, добавив к вопросу тег [pvs\-studio](https://stackoverflow.com/questions/tagged/pvs-studio)\. 

Если вы столкнулись с какой\-то неполадкой в работе анализатора, то о ней можно сообщить [в поддержку](https://pvs-studio.ru/ru/about-feedback/)\.

## Регулярно?

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

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

Подробнее об этой теме мы говорили в [одной из публикаций](https://pvs-studio.ru/ru/blog/posts/1264/) в нашем блоге\. Более того, там же мы разбирали и пример пайплайна для GitHub Actions, в котором рассматривали анализ Pull Request'ов\. Но один момент в той публикации мы всё же упустили: как анализировать "внешние" Pull Request'ы, т\.е\. запросы на слияние, открытые из fork'ов?

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

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

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

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

![1283_sa_in_opensource_ru/image2.png](https://import.viva64.com/docx/blog/1283_sa_in_opensource_ru/image2.png)

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

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

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


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

Посмотреть на пример workflow для GitHub Actions можно в [этом тестовом репозитории](https://github.com/feeelin/sast-in-ci-example)\.

Помимо работы с GitHub Actions анализатор PVS\-Studio также можно запустить в [GitLab CI/CD](https://pvs-studio.ru/ru/docs/manual/0056/)\. Для более специфичных случаев можно воспользоваться [разделом нашей документации](https://pvs-studio.ru/ru/docs/manual/0055/) о том, как анализировать коммиты и Pull Request'ы\.

## Конец?

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

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