I'm an amateur web application security enthusiast with what I would say is an intermediate level of knowledge at this point. I'm interested in finding full time work as a web app pen tester.

Up until now I've been working mainly on vulnerable web apps hosted on VMs locally.

I'd like to start doing actual vulnerability research and try and get some CVE listed bugs to my name. I feel that lacking a degree or directly relevant work experience this basically serves as a portfolio and demonstrates proficiency.

My question is where should I start looking?

Should I aim for the high-profile sites offering bounties like the ones listed on Bugcrowd?

Or would a better approach be to audit smaller, open source projects and submit my findings to their teams?

My thought process is that bigger high profile sites will be much more heavily scrutinized so less chance of a finding interesting issues when you're not as experienced. But finding a bug there is a bigger deal.

Whereas smaller projects may not be putting much work into security to begin with so bugs may be plentiful to find but do they mean anything in terms of demonstrating proficiency & in terms of a portfolio to show to employers? (Aside from the value brought to the project by making their code more secure assuming they are receptive to your efforts).

Where did you start? Any tips on how to proceed?

1 Answer 1


The choice between projects with big bounty offerings and small projects with no budget at all is getting less and less important. Projects like Google's Patch Reward program mean that even bugs in GCC can earn you money if you write a patch to fix the bug.

You can earn recognition for projects without bug reward programs. As an example, a couple of Googlers started using their fuzzing framework to look for bugs in ffmpeg and now, two years later, they have had over 1,000 security bugs patched. They chose ffmpeg because it had a history of security bugs, was easy to test and it was used by lots of people. It also shows that you can spend a long, long time on a single project.

But in order to receive the right kind of recognition, the quality of your reports must be high. Some people submit lots of reports and get lots of CVEs but vulnerability database maintainers hate seeing a new report come through because it's so much work to extract the truth from the report.

The best advice I can give for getting started is to find a project that you enjoy working on and know well that's written in a language you know well or has a class of bugs you know well (such as XSS or memory corruption). That way all of your focus can be on learning the new tools and learning the vulnerability database process rather than learning a new project and programming language.

Finding a project with a history of security bugs is a good idea if you can manage it. The theory is that although it has had a lot of bugs fixed already, there are many more left undiscovered because the developers are not good at secure coding practices. Projects where the developers are good at secure coding just don't have as many security bugs to find.

Later, once you are well grounded in all of those new things might be a good time to expand into new languages and new projects.

I did just think of an interesting class of apps that fit several of the criteria above. A new-ish phone app with an infinite number of inputs, an exponential growth curve and a history of security flaws that has just been purchased for exorbitant amounts of money by a large company with an existing bug bounty program. Yep, WhatsApp. Although any ridiculously popular phone app that performs network access would be a good candidate for fuzzing so Candy Crush Saga, Flappy Wings, Splashy Fish, Telegram, Threema, etc. are all good candidates.

Not the answer you're looking for? Browse other questions tagged or ask your own question.