To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at

If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

An Easy Way to Make Money on Bug Bounty

An Easy Way to Make Money on Bug Bounty

Aug 21 2019

Surely you've heard the expression "bug hunting" many times. I dare to assume, you won't mind earning one or two hundred (or even thousand) dollars by finding a potential vulnerability in someone's program. In this article, I'll tell you about a trick that will help analyzing open source projects in order to find such vulnerabilities.


Bug Bounties on Free and Open Source Software - what is it?

Bug Bounty is a common name for various programs, where website and software developers offer cash rewards for finding bugs and vulnerabilities. In addition to well-known Bug Bounty programs from such large corporations, as Apple or Microsoft, there are also programs for searching vulnerabilities in open source projects.

Many of them can be found on HackerOne, but perhaps the largest is FOSSA - Free and Open Source Software Audit. It's a program on searching vulnerabilities in various open source projects, sponsored by the European Union. The total prize fund is an impressive sum - as much as 850,000 euros!

How to take part?

First, you need to register on HackerOne. We'll need only open source projects. There is a whole list on HackerOne.

If you'd like to take part in Bug Bounty from the European Union, the list of projects, participating in this program, can be found here. For most projects, it will be enough to be registered on HackerOne, but many of listed programs are also on the website.

To participate, you have to choose an appropriate project for yourself and then carefully read the terms of participation. If you agree with them, go to a practical part.

To find a vulnerability and get your money, you'll just need to download a project (or clone it from GitHub) and thoughtfully analyze each code line, examining each expression for potential errors. If you find something, that can affect program security - make a report and send to developers. If they rate your finding as worthy to be rewarded - you have your money in your pocket :).

But where is the simplicity?

The simple part is that you don't have to analyze the code only manually. There are tools that let you search for errors in code automatically. For example - static code analyzers. I prefer using our tool - PVS-Studio. PVS-Studio analyzer is able to find errors in code, written in C++, C# and Java, as well as has a user-friendly interface. In addition, there are several options of its free usage. Anyway, there are other various code analyzers.

Of course, static analyzers can reveal not all errors. Never mind! After all, we have a purpose to find errors quickly and easily, and not to find them all.

Once the project is downloaded and built, it will take only a couple of clicks to start the analysis. The result will be a report with some (usually considerable) number of warnings generated by the analyzer. In PVS-Studio, they are classified into three levels of certainty. You should start with the first level of warnings, so the orange and yellow levels can be weeded out from the analysis result.


An example of filtering the results of the analysis. You can click on the picture to enlarge.

Thus, you'll only need to look though the rest warnings and choose the places that may pose the greatest danger. It is worth checking whether it is possible to reproduce any of them directly when running the program. If you manage to do it - it will not only increase the chances that developers will accept the report, but also certainly increase the amount of payment. In this case, visibility is your best friend.

It's also worth considering whether the bug you found affects the security of the program. After all, in this case, the amount paid to you will be several times more :)

The screenshot shows the Visual Studio interface. However, don't let it mislead you. The analyzer can be used not only as a plugin for Visual Studio, but also on its own, including the Linux and macOS environments.

Pros of this Approach

First, using a static analyzer is one of the easiest ways to find bugs. You don't have to have any special knowledge to use code analyzers: you just need to understand the language in which the code is written.

Secondly, analyzers are attentive. They don't get tired and don't lose their vigilance, unlike a human being. Therefore, they can be used to analyze as large code bases as you like with almost minimal cost.

Third, analyzers often have more knowledge than humans. What does it mean? Let me explain my thoughts with the example from the Android kernel code:

static void FwdLockGlue_InitializeRoundKeys() {
  unsigned char keyEncryptionKey[KEY_SIZE];
  memset(keyEncryptionKey, 0, KEY_SIZE); // Zero out key data.

It would seem, where's an error here?

It turns out, that a compiler, seeing that an array isn't used anywhere else, can optimize the code and remove the call of the memset function from it. And it'll do it only when building the release configuration. Everything would be fine, but only the encription key will remain in the RAM uncleared for some time, this way it can be obtained by an intruder. That's a real breach is safety!

In addition, it can be hardly found by yourself: in the debugging mode the call of memset works fine. Tests also won't be of help... The only thing that remains is to be aware and remember about this feature yourself.

What if the project developers don't know about this feature? What if you don't know about this feature when you search for bugs? As for the analyzer, it has the V597 diagnostic, so you'll definitely find out about this feature when viewing the report.

Finally, the fourth point. One of the most useful advantages of using static analysis when chasing for Bug Bounty is speed. It's true that you can check two, three, four project in one evening - but that's not all.

The main thing is that you can be the first. While the award is offered for finding bugs in any project, the project continues to be refined and developed. Developers ship new releases and new features along with new code and new space for errors. When using the approach I've described, you'll be able to targetedly consider new errors and potential vulnerabilities in the very first day they're released.


Potential Vulnerabilities

An attentive reader may be puzzled:

Wait, wait! On the one hand, you're saying about searching for errors in code in programs, on the other hand - you're mentioning potential vulnerabilities. Vulnerabilities are more interesting in terms of Bug Bounty. Please, clarify what you mean!

The fact of the matter is that errors and potential vulnerabilities are basically the same thing. Sure, only a few errors/potential vulnerabilities prove to be real vulnerabilities in further research. However, a harmless blunder and crucial vulnerability might look exactly the same in code. The article "How Can PVS-Studio Help in the Detection of Vulnerabilities?" gives several seemingly common bugs that are now known to be vulnerabilities.

By the way, according to the report by National Institute of Standards and Technology (NIST), about 64% of vulnerabilities in applications relate to software errors, not issues directly related to security.

So grasp the nettle, get PVS-Studio and start searching for errors and safety flaws! Classification according to the CWE will be of great help here.


Hopefully, I helped a reader in his searching for that very bugs that will bring him honoring and monetary reward. I'm sure that static analysis will help in this! Remember that developers usually don't have time to analyze bugs in detail, so you'll have to prove that your finding can actually affect the program. The best way is to visually reproduce it. And remember: the more the bug destructs security - the more you'll get paid for it.

Well, that's it. Good luck in searching for a reward!

Popular related articles
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
Free PVS-Studio for those who develops open source projects

Date: Dec 22 2018

Author: Andrey Karpov

On the New 2019 year's eve, a PVS-Studio team decided to make a nice gift for all contributors of open-source projects hosted on GitHub, GitLab or Bitbucket. They are given free usage of PVS-Studio s…
PVS-Studio ROI

Date: Jan 30 2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →