Scopes: Where Bigger is Better

Today, we’re going to be talking about scopes, and more specifically, how and why having an open scope is quite possibly the single most effective thing your organization can do to help secure your external attack surface. But before we get there, let’s start by covering some basics.

 What is a scope?

A scope is the defined set of targets listed by an organization as assets to be tested as part of a particular engagement. Things that are listed as “in scope” are eligible for testing, and things that are “out of scope” are to not to be tested. Scopes can apply to pen tests, bug bounties, and just about any type of active security engagement. However, for the purpose of this guide, we’re going to focus exclusively on scopes as they relate to bug bounty programs. Within the context of a bug bounty, what’s in scope is what researchers are incentivized to report (and are rewarded for), and what’s out of scope is off limits, and no compensation is given for findings in those targets.

Let’s define the three main types of scope:

1. Limited scope. A limited scope on a bug bounty program is one that only includes single or specific targets. For instance, listing “example.com” as the only in-scope domain is considered a limited scope. Furthermore, even if “accounts.example.com” was added to the scope, as well as “api.example.com,” this is considered a larger scope but still limited. Any time the scope is made up of precisely specific targets, it’s generally considered a limited scope.
2. Wide scope. A wide-scope bounty program is one that includes a wildcard to the in-scope targets, such as “*.example.com.” This signifies that any subdomain of example.com is in scope. For instance, part of that wildcard could include previously unmentioned or unexplored attack surfaces such as “staging-2019.example.com” or “admin.example.com,” both of which could have rich opportunities for identifying vulnerabilities. Researchers are particularly adept at finding and exploiting assets that have been forgotten about or hidden by the sands of time. By including the wildcard, your organization increases the probability of identifying security risks across a much broader swath of your attack surface.
3. Open scope. An open-scope bounty program is one that has no limitations on what researchers can or cannot test, so long as the target/asset belongs to your organization. Open scopes generally look something like “any externally facing asset belonging to Example Org,” where nothing is excluded, so long as it belongs to the organization. Researchers are highly effective at identifying assets here—some may find and exploit an old marketing page for an event from a decade ago; they may find keys or sensitive information stored on GitHub or Pastebin; there may be remnants from mergers, acquisitions, and any other artifacts that live in a litany of different places on the web. Running an open scope leverages the power of the whole Crowd to find and identify any exposures your organization may have online, and most of the time, there’s a lot more out there than you realize.

Most organizations and bounty programs tend to follow a general and systematic progression as they grow their security posture over time, starting with a basic, limited scope (example.com) to adopting a more expansive, limited scope (accounts.example.com, api.example.com) to including a wildcard (*.example.com) and finally to establishing an open scope (“anything belonging to Example org”). Some organizations make this progression in a matter of months, while others take years to get there, but the important thing is that they’re always evolving forward. Very few (if any) organizations have an attack surface that stays the same year over year or even month over month—there’s always new code or new assets, and with each comes the possibility of more vulnerabilities.

To be clear, there’s nothing wrong with running a bounty program with a limited scope—it’s a whole lot better than not running a bounty against that scope. But just like any exercise is most certainly better than no exercise at all, doing a little is still no replacement for doing more, and as we all know all too well, there’s almost always an opportunity to do more and do better.

So, why is expanding your scope important when it comes to securing your organization? And more importantly, why is having an open scope so valuable and critical to identifying flaws before they’re exploited in the wild?

Here are a few high-level reasons that speak to each:

• Bad actors in the wild don’t have to play by any set scope or rules. Unlike the participants on a bounty program, a nefarious party isn’t limited to testing just one area of an organization’s attack surface. Bad actors go wherever to find the path of least resistance, which is most commonly through those assets that receive the least testing. They are far more likely to be via an obscure or less-tested asset. If the goal of a bug bounty is to harden and secure your assets by finding issues before the bad actors, then both sides need to be operating from the same perspective and playing field. If one team can color outside the lines and the other can’t, who do you think will win in the end? To give your organization a shot at defending against attackers, it’s critical to give the good guys as much opportunity to find the issues before the bad actors do. Otherwise, it’s a lopsided race out the gate.
• There’s more than one way in. The reality is that while you may have a bank vault for a front door, you may also have an unsecured doggy door out back (or a wide-open window), and attackers will find that path of least resistance and exploit it. One needs to only look at how attackers are exploiting supply chain vulnerabilities to see that attackers are resourceful. And most of the time, it’s far easier to find a way around via a less secure vector than attacking things head on where defenses are the strongest. Every military and army in history has understood this, and rest assured that bad actors know it as well. Whether it’s a flanking maneuver to attack from the rear or finding a forgotten shadow IT asset that provides a foothold into the network, the concept is the same: attackers aren’t going to only come in through your front door; they’re going to come in wherever they can find holes. And the reality is that most of the time, that’s where they do come in from…
  • JP Morgan Chase was breached via a single server that hadn’t received the appropriate update to MFA, compromising 83 million accounts (even when 99% of things are updated, hackers and researchers are particularly adept at finding that one percent that wasn’t).
  • Verifications.io had over 700 million records breached through a publicly exposed MongoDB server with no password.

• In 2021, Bonobos suffered a breach of 12.3 million records due to a backup server that got compromised.
• Equifax’s exposure via Apache Struts was repeatedly not identified via internal tools and processes until it was exploited in the wild by nefarious parties (researchers are good at finding things as soon as 0 days hit).
• MedEvolve lost 200,000 records containing PHI data due to an unsecured, publicly accessible FTP server.
• And there are countless other cases where the details of such attacks are unknown. The moral of the story: Attackers have to enter somewhere, and more often than not, that somewhere is via an internet-facing asset (especially in a cloud-based, remote-working world).

Long story short, bad actors aren’t asking for (and don’t need) permission to test everywhere. And by limiting where the good actors can test, we only further disadvantage ourselves in the battle for securing assets, data, and ourselves. To combat this, an open-scope program is not only useful but necessary to help secure your organization and assets and beat the bad actors to it.

While we’ve gone through the most compelling and important reasons to run an open-scope program, it’s worth highlighting some important data:

• On average, programs with wider scopes (at least a wildcard) get nearly 250% more findings than programs with limited scopes. This includes nearly 250% more P1s, where each and every P1 identified represents a breach that could have happened but didn’t. The breach was prevented by leveraging the Crowd to help identify the vulnerabilities and risks before the bad actors have had a chance to exploit them. It simply makes sense that a larger scope would have more vulnerabilities, but it’s also extremely telling that all one has to do to find more vulnerabilities (including critical ones) is to open up their scope. There are no extreme hoops to jump through to find them—the vulnerabilities are already there and probably have been for some time. Like the bugs under a rock, whether you can see them or not, they very much exist—and when you flip it over, that becomes exceedingly obvious. The same holds with scopes and bounties; the bugs and risks are there. All that needs to be done is to expose them to inspection.
• What also plays into the larger numbers of findings on more broadly scoped programs is that those with wider scopes often see longer and more substantial researcher engagement, with testers submitting more findings over a longer period of time. If there’s enough scope around an organization, testers will often go deeper to learn more and more about what/who they’re testing against. And once they get so deep, they’re (A) more likely to find more nuanced and contextual findings and (B) are more likely to stay there, meaning that they’ll find more, even against the primary assets, than they would have otherwise simply because they’re testing all the assets over a longer timeline. 
• Additionally, on programs with larger scopes, the number of researchers who engage on average is double compared to limited-scope programs. More researchers finding more issues over a longer period of time—that’s a win/win/win when it comes to securing one’s assets.
• Finally, independent researchers (and also bad actors) are extremely good at finding and identifying things many organizations weren’t or aren’t already aware of. Often, when organizations move to wide or open scopes, they learn about a significant number of assets that were simply forgotten or lost, whether they are unmaintained relics of M&As, shadow IT, or threat scenarios they simply hadn’t entertained before, all due to the intelligence and diversity of approaches brought to bear by the Crowd. There are very few things that are more effective in helping secure the totality of your organization’s external footprint than running a completely open scope for all internet-facing assets. Simply put, nothing else even comes close.

For as valuable as going open scope is for your organization, we’re also acutely aware that it’s not as easy as snapping one’s fingers. That said, to make things easier, here are some of the frequently asked questions on the topic, as well as Bugcrowd’s guidance on how to handle issues internally or externally. If you have any questions beyond these, feel free to reach out to your Technical Customer Success Manager (TCSM) or Account Manager (AM), and we’ll be more than happy to assist however we can.

FAQs

“But I don’t want hackers to hack everything…”

This is the most common concern, but the reality is that bad actors don’t need permission to hack anything/everything. Said differently, the bad guys are doing it anyways, whether or not you want them to. The least we can do in this regard is to level the playing field so that good actors (responsible researchers) are able to help secure these assets before they’re exploited in the wild. It’s a simple but powerful way to reframe the conversation from that of fear to opportunity.

“But if I put all my assets in scope, nobody will test the tough ones that I care about most.”

This is a reasonable concern; however, the simple answer is to make it more valuable to test on/against the things you really care about by tiering out the reward structure. If it pays many times more (say, five times) to find bugs on the main app, testers will still probe around the rest of the attack surface, but they also know that the big money is where you put it. In this way, you can work to secure all of your assets but also emphasize the ones you care the most about. An example of this would look something like the following :

• All assets: $100 (P4) to $1500 (P1)
• Secondary assets: $250 (P4) to $2500 (P1)
• Primary assets: $500 (P4) to $5000 (P1)

Of course, your specific situation may vary. If your current rewards for your primary assets are only up to $2500, then secondary assets could be up to $1500, and all other assets could max out at $750. Additionally, it doesn’t need to be linear. You can offer significantly disproportionate rewards on the most important assets while offering smaller, but still meaningful, rewards on everything else. Even if you’re just offering $25 for a P4 and $500 for a P1 on all non-primary/secondary assets, that will encourage researchers to do high-level testing for common vulnerabilities, so you’re not left out in the open with an unpatched 0 day or obviously exposed asset/server.

“I like the idea of having an open scope but don’t have the money to spend on the findings (which could/will be many).”

This is also a reasonable concern. But given the options to pay $X to know about a critical vulnerability against a system that’s not on your radar or to deal with a multi-million-dollar breach, wouldn’t you prefer the former? Keep in mind that with a bug bounty, you only pay for valid vulnerabilities. Meaning, if there’s nothing out there, then there’s nothing to reward, and if there is something, your rewards are set up in a way so that they’re commensurate with the value that’s being derived from the finding (e.g., by tiering out rewards, you won’t be stuck paying a disproportionate reward for a low priority finding). In short, there are many upsides and limited downsides.

“This sounds interesting but doesn’t really apply to me because I don’t have that large of an attack surface. Mine is a small company.”

Regardless of its size, it can still be valuable for any organization to run an open-scope program. If there’s not much out there, then there’s not really any downside to running an open scope, so why not level the playing field and do it anyways?

Additionally, as you’re likely well aware, in today’s cloud-based, remote work environment, an organization’s attack surface is extremely complex and always evolving. There’s a reason attack surface management (ASM) has exploded in the last few years and tools like Expanse get purchased for hundreds of millions of dollars. There’s a lot of exposure out there, for a litany of reasons. And in this regard (and many others), the Crowd is the best weapon when it comes to helping organizations secure the totality of their footprint.

“Alright, I’m sold. How do I start moving toward an open scope?”

The best place to start is by talking to your Bugcrowd Success Team. Your TCSM will provide guidance, recommendations, and support to get you going. All you really need to get started is an appetite for doing so—we’ll help with the rest. Note that when opening up your scope, it can be helpful to provide a list of assets you already know to be in scope. This gives researchers a starting point and saves them from having to do some early legwork. (It also allows them to focus on what really matters.) Generally speaking, the more information you can provide, the better.

Bugcrowd is happy to help champion an open scope internally for you as well. If you need data, quotes, references, or anything else to help sell an open scope internally, we’re happy to help however we can. We’re here to help you secure your organization, and we truly believe that going to an open scope is a critical part of that security journey.