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 that have been listed by an organization as assets that are 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 pentests, 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 scopes:

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 a more expansive, limited scope (accounts.example.com, api.example.com), to a wildcard (*.example.com), and finally to 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 it’s 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 the organization’s attack surface. Bad actors go wherever to find the path of least resistance – which is most commonly not through those assets which receive the most testing, but is 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 out in the end? In order 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, versus 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.
  • Bonobos in 2021 had a breach of 12.3 million records, due to a backup server that got compromised.
  • Equifax’s exposure via Apache Struts – the vulnerability 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 200k records containing PHI data due to an unsecured, publicly accessible FTP server.
  • And there are countless others 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 calling out 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. This 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. 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 scope 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 larger scoped programs is that those with wider scopes often have 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 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 can be 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 and can be for your organization, we’re also acutely aware that it’s not as easy as snapping one’s fingers to make it so. 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 them 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 the most about…”

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, 5x) 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 your assets, but also emphasize the ones you care the most about. An example of this would look something like this:

• 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 is only up to $2500, then secondary assets could be up to $1500, and all other assets 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 0day 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 option 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 in the aftermath, 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 setup 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). All upside, limited downside.

“This sounds interesting, but doesn’t really apply to me, because I don’t have that large of an attack surface, I’m just a small company…”

Regardless of 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 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 the 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 kept secret weapon when it comes to helping organizations secure the totality of their footprint.

“Alright, I’m sold; how do I start moving towards an open scope?”

The best place to start is by talking to your Bugcrowd Success Team – your TCSM will help provide guidance, recommendations, and support for whatever you need to get going. All you really need to get started is an appetite for doing so – we’ll help with the rest. As a note when opening up 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 it 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, and want to help however we can.