Our website uses cookies to enhance your browsing experience.
Want to make your open-source project cleaner and more secure? This post shows how to use PVS-Studio for regular code analysis, integrate it into your CI pipeline, and catch bugs before they make it into a release. And yes, we offer free licenses for open-source projects.
On our blog, we regularly post articles describing how we use PVS-Studio static analyzer to check various open-source projects.
Note. You can find a full list of projects we've checked at this link. To suggest a project for analysis, please submit it via this GitHub repository.
After each article, we notify project developers about the errors we've found. But since we only check each project once and with long intervals in between, new issues can still slip into the code.
That's why today I'll show how you can use PVS-Studio static analyzer to keep the codebase of open-source projects clean and secure.
You might be wondering, "Why should I even check an open-source project with an analyzer?"
The answer is simple: for the same reason you should check any code—because it can contain errors. Even the most popular and actively maintained project isn't immune to typos, logic bugs, or hidden vulnerabilities.
A static analyzer helps you find such issues before they make it into a release, whether it's a minor logical flaw or a serious potential vulnerability.
And if you use the analyzer regularly—for example, in CI/CD—it will also prevent these defects from reaching your users. So, you're not just fixing past failures, you're preventing future ones.
Open source is about "making things better together." Static analysis is one of the ways to contribute to that shared effort.
Open source is generally a non-commercial endeavor, so our licensing approach reflects that.
You can use PVS-Studio static analyzer for free when developing open-source projects hosted on GitHub. We provide a free one-year license to anyone who requests it.
Important. The free PVS-Studio license does not apply to commercial projects, projects developed by corporations, or mirrors and forks.
To get a license, you need to complete a few simple steps.
First, add the following snippet to your project's README.md file:
## 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.
Next, go to this page, enter your name and the email where we should send the license key, and provide the link to your project.
To renew your license later, follow the same steps.
Also, please adhere to the following rules when using the free PVS-Studio license:
If with the terms of a standard free license don't work for your project, that's perfectly fine. We're open to discussing custom specifications if you want to use our solution for code quality control. Tell us about your use case via our feedback form, and we'll work together to find the best solution.
If you have questions about how to use PVS-Studio in your open-source project—you can ask them on Stack Overflow using the tag pvs-studio.
If you encounter any issues with the analyzer, you can report them to our support team.
As I mentioned earlier, integrating static analysis into CI is a crucial step to get the most out of the tool. Indeed, running analysis regularly at early stage of the pipeline helps find errors and vulnerabilities before they reach the main branch. This not only improves overall code quality but also reduces the cost of fixes, since developers get feedback immediately after making changes.
Running analysis when opening a pull/merge request is even more effective. At this point, the code is ready for integration but hasn't yet been merged into the main branch.
We discussed this topic in more detail in one of our blog posts. Moreover, we also provided an example pipeline for GitHub Actions that analyzes pull requests. However, there's one point we didn't cover in that article: how to analyze "external" pull requests—those opened from forks?
In such cases, GitHub activates protection mechanisms for sensitive data and does not grant access to secret environment variables set in the project. This makes sense—otherwise, anyone could modify the yaml file and print those variables to the console.
So, how can you configure analysis for "external" pull requests? You only need to adjust a couple of settings.
In the repository's Environments settings, create a new environment and set the Required reviewers option, specifying the maintainers who will review incoming external changes.
Below, under Environment secrets, create a variable specifically for this environment, similar to how you would set a secret variable for the entire repository.
Then, add the created environment to your yaml file, for example:
....
jobs:
external-analysis:
environment: pr-review-required
....What does this change? Now, before running, the pipeline will wait for the approval from a maintainer to confirm that the external changes are safe. Once approved, the pipeline will run successfully with all the environment variables you specified earlier.
Note. When working in such an environment, you might encounter an issue uploading the analyzer report to CodeQL, because GitHub doesn't pass along the information that links the commit to the running workflow. To resolve this, you can move the CodeQL upload into a separate workflow, since it doesn't require any sensitive environment variables.
You can view an example workflow for GitHub Actions in this test repository.
In addition to GitHub Actions, you can also run PVS-Studio analyzer in GitLab CI/CD. For more specific cases, refer to this section in our documentation on analyzing commits and pull requests.
In this article, I answered the questions related to using PVS-Studio static analyzer for open-source projects. If you still have questions, I'll be happy to answer them in the comments below.
Clean code to you folks!
0
0
0
22
0
40
0
124
0
0