Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Running a bug bounty program has a lot of difficulties. The program has a budget for the amount it's allowed to spend. The managers need to understand resourcing and time commitments to the program as well. This article has two tips on making the program better for yourself and hackers.

Three types of hackers do bug bounty: greenhats, passion players, and professionals. The green hats are in it for the money. Passion players do it for the technical intrigue. Professionals are looking to increase their reputation with a nice quote on a website or a CVE to pad their resume. Each of these types has different ways to keep them around. Although all are great things to do as a program manager, I personally appreciate #2 the most.

For the greenhat, bonus's are helpful. Even a $100 bonus for a bug gets them excited and makes them feel like that you appreciate their work. This $100 will go a long way and will likely keep them working on the program for a while. Additionally, pay consistently. If you paid $X for a bug before, don't change it.

For the passionate player, you should compliment their skills. Making them feel like a top-notch hacker will keep them around. Another mechanism to keep these technical folks around is root causing the issue with more technical details than they can see. For instance, information about the backend architecture and why this vulnerability occurred. The passionate players LOVE to understand every little detail of vulnerabilities they find.

The final one is the professional who is trying to improve their resume. For these folks, allowing them to post about the bug publicly, adding them to the hall of fame or any public items are what they want. Job offers also make their day, even if you don't really mean it.

The most important part of the program is the publicly facing policy page. This gives hackers an insight into your program and why they should hunt on it. The first tip is to keep the rules concise and broad, living off of the primacy of impact rather than semantics. The second thing is making it easy to start on. Things like async comms for an email, VPNs or anything else are a major turn off.

For vulnerabilities that are out of scope or long-lasting issues, make sure to publish these changes. It's the worst when you're hunting for something and are dupped by a ten-year-old bug or get out-of-scoped by a recent change to the program that you missed.

The final point is probably the most important: define your threat model. What impacts do you like and dislike? What are the security boundaries of your threat model? All of these things help hackers give the highest-quality reports they can.

I love this post, even though I typically only like the very technical things. Running a bug bounty program well is a skill that is often not talked about. I think this post really helps shine some light into making the program better.