Scope is one of the most important elements of 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 are described as “in scope” or “out of scope.”
But if you’re a tester working on a program, what does “in scope” mean? Why do these terms and boundaries 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 to establish 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 broader approach. Whichever way they go, it should be clearly outlined by the program brief.
Work is considered in scope when it’s against assets that have been clearly defined by the program as allowed for testing. Any assets marked as out of scope are the opposite; that is, these assets 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 when hackers perform work where it wasn’t requested 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 tests conducted 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 when deciding on 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 that they don’t care about all the other assets; rather, they just have a specific priority for their program at this time.
In most cases, the priorities for program owners gradually grow and change, and they broaden the scope along the way. It’d be ideal if every program had all assets marked as 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 considered 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 that comes from 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 the defined scopes.
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
- Using Shodan as a search engine
- Googling copyrights, terms of service, and privacy policies
- Seeking education and resources to keep learning.
The effort you put into discovery will pay off; it’ll lead to payout after payout. Situations that pay are only found by putting in the work that others won’t. Effort is 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! Follow us on Twitter and Instagram and join our Discord community to connect with thousands of other hackers just like you.
