Scope is one of the most important elements in a crowdsourced security program. As described here, the Bugcrowd team works closely with program owners to craft a detailed and clear brief that describes the desired plan of attack for testers on appropriate targets, whether the task at hand is a penetration test, private bug bounty, or something else. In that brief, specific targets will be described as “in-scope” or “out-of-scope”.
But if you’re a tester working on the program, what does “in-scope” mean? Why does it exist? What happens if you go “out-of-scope”? You’ll find answers to these questions and more below, plus helpful hunting tips that will result in better payouts.
What does it mean to be “in-scope”?
When an organization sets up a crowdsourced security program , one of the most important aspects of that program is defining what can and can’t be tested. An organization can be very specific about what assets are “in-scope”, or they can choose a more broad approach. Whichever way they go, it will be clearly outlined under the program brief.
Your work is considered “in-scope” when it’s against assets that have been clearly defined by the program as allowable to test against. Being “out-of-scope” is the opposite: that is, testing against assets that are not explicitly defined as in scope, or are explicitly listed as out-of-scope.
*Anything not listed explicitly as “in-scope” is out of scope.
Why does remaining “in-scope” matter?
Issues will arise as a result of performing work where it wasn’t asked for or sanctioned. Here are a few ways testing out-of-scope can hurt:
- It can have significant repercussions on organizations and the people that run the program
- It can open the tester up to legal action (safe harbor on programs only protects testing “in-scope”)
- It can create an escalation that may result in the tester getting temporarily or permanently banned, depending on the severity of the situation
- It is unlikely to lead to any reward
*It’s important to clarify that there is a difference between responsibly disclosing an issue that you happened to notice, and performing active testing against an asset. Always reach out to Bugcrowd Support if you have questions.
What is the program owner’s process for designing scope?
Organizations often have specific goals for running a given program. For instance, they may be looking to test just one asset at this time, resulting in a narrow scope. This isn’t to say they don’t care about all other assets; they just have a specific priority for their program at this time.
In most cases, the priorities for program owners gradually grow and change over time – adding scope along the way. It’d be ideal if every program had all assets in-scope, but that’s not reasonable for the majority of organizations.
How going out of scope can lead to an escalation
As our Code of Conduct states, “Bugcrowd strives to create a safe, inclusive and positive environment for the mutual benefit of Researchers and Customers alike, allowing for collaborative engagement in the pursuit of a safer Internet”.
Going out-of-scope can result in reward rejection, an escalation, or even getting temporarily or permanently banned. This is because of the harm it can potentially cause the organization and the strain it puts on the Bugcrowd team.
Can a researcher push for a change on a program?
If there’s a valid reason why something should be in-scope, we encourage testers to respectfully reach out and request an update. We don’t guarantee that the request will be granted, but it doesn’t hurt to ask.
What role does triage play in determining scope?
None. The scope is defined by the program owner with the help of their account team (Solutions Architect, etc) when building the program brief.
How can you find success while staying in-scope?
There is a tremendous amount of success in testing in-scope. Tens of millions of dollars are paid out every year on the Bugcrowd Platform and 99% of those dollars are for in-scope findings. There is plenty of money and vulnerabilities to be found inside of the defined scopes for programs.
We recommend focusing on wide recon efforts and deep, nuanced vulnerabilities. This will lead to a greater path of success than going out-of-scope. The real money and vulnerabilities are in the deep work. Here are a few wide recon tactics you can try:
- Scope company domains
- Scope target company acquisitions
- Search ASN Enumeration
- Reverse WHOIS lookups
- Subdomain Enumeration
- Port analysis
- Ad/analytics trackers
- Use Shodan as a search engine
- Google copyrights, terms of service and privacy policies
- Seek education and resources to keep learning
The effort you put into discovery will pay off. That’s payout, after payout. Situations like that are only found by putting in the work that others won’t. That’s how you stay in-scope AND find the valuable, high severity, non-duplicate issues that get you paid
Conclusion
Overall, it’s important to be respectful of an organization’s scope. There’s always space for feedback, but ultimately focusing on deeply understanding and doing recon on in-scope assets is your best bet for finding high-value vulnerabilities. Happy hunting! Join our Bugcrowd Twitter, Instagram and Discord community to connect with thousands of other hackers just like you.
