Clear scope in your vulnerability disclosure policy determines what researchers should test. Get it wrong and you'll discourage valid research or deal with unwanted testing.
The scope section of your vulnerability disclosure policy determines what researchers should test and what they should avoid. Get it wrong and you'll either discourage valid research or deal with unwanted testing that doesn't improve your security.
Without clear scope, researchers don't know what's acceptable to test. Some will test everything, including systems you don't own or can't fix. Others will avoid testing anything because they're unsure what's allowed. Neither outcome serves security.
Clear scope encourages researchers to focus on systems where their findings will be acted upon. It protects third-party services you integrate with but don't control. It manages researcher expectations about what you consider valid vulnerabilities.
The simplest approach is to list specific domains, IP ranges, or applications that researchers can test. This works well for organizations with a small number of web properties.
The problem with enumerating systems is that it requires maintenance. Launch a new product and you need to update your scope. Acquire another company and their systems aren't automatically covered. Researchers might discover interesting vulnerabilities in systems you forgot to list.
Broader scope definitions avoid this problem but create ambiguity. Saying "all systems owned and operated by Example Corp" is technically comprehensive, but researchers can't know what that includes. They see your corporate website, but do you also operate infrastructure they can't easily identify?
A hybrid approach works better. List your primary properties explicitly, then add a catch-all for other owned systems. This gives researchers clear primary targets while allowing reports on systems you didn't explicitly mention.
Most organizations integrate third-party services. Your website might use Cloudflare for CDN, AWS for hosting, Stripe for payments, and Auth0 for authentication. Vulnerabilities in these services aren't yours to fix.
Explicitly excluding third-party services from scope prevents wasted effort. A researcher who spends days finding a vulnerability in your payment provider's checkout flow can't expect a response when you don't control that code.
But the boundary isn't always clear. If you misconfigure Cloudflare in a way that exposes origin servers, is that in scope? You're responsible for the configuration even though Cloudflare provides the service. Same for improperly configured AWS S3 buckets or overly permissive Auth0 rules.
The distinction is whether the vulnerability is in your configuration and usage of the third-party service, or in the service itself. The former is in scope because you can fix it. The latter isn't because you can't.
Scope isn't just about what systems researchers can test, but how they can test them. Certain testing methods are universally problematic and should be explicitly prohibited.
Social engineering against your employees isn't useful security testing for most organizations. A researcher who calls your helpdesk pretending to be an executive demonstrates social engineering works, which you already knew. Unless you're specifically trying to test social engineering defenses, exclude it from scope.
Physical security testing requires even more explicit authorization. A researcher showing up at your office to test badge readers or door locks isn't helpful without prior coordination. The risk of involving law enforcement is too high.
Denial of service testing is tricky. Legitimate security testing sometimes causes service disruption accidentally. That's different from intentionally testing DoS vulnerabilities by taking down production services. Your scope should prohibit intentional DoS but acknowledge that accidental disruption during authorized testing isn't a violation.
Some organizations exclude certain vulnerability types from scope. Common exclusions include SPF/DMARC issues, missing security headers without demonstrated impact, descriptive error messages, or self-XSS.
These exclusions are controversial. Some researchers argue that organizations use them to ignore valid security issues. Organizations counter that they address known limitations and don't want duplicate reports of issues they've accepted.
The middle ground is explaining why you exclude certain findings rather than just listing them. If you've decided that missing CSP headers aren't a priority given your threat model, explaining that helps researchers understand the decision. If you exclude "SPF records" without context, researchers don't know if you're aware of the issue and have chosen not to fix it, or if you don't understand SPF.
Researchers sometimes encounter data during testing that they shouldn't access. Real user data, financial information, healthcare records, or data about minors requires special handling.
Your scope should specify that researchers must minimize access to real user data. If they need to demonstrate a vulnerability, creating test accounts is preferable to accessing real user data. If they must access real user data to demonstrate the issue, they should access the minimum necessary and should not exfiltrate or retain it.
This is as much about protecting researchers as protecting users. A researcher who accesses extensive real user data during testing has potential legal exposure under various data protection laws. Clearly stating that they should minimize such access provides guidance that protects everyone.
Many organizations operate legacy systems they know are insecure but can't immediately fix or decommission. These systems create scope challenges.
Excluding them from scope prevents researchers from reporting known issues, but also signals that security testing on these systems isn't welcome. Including them means receiving reports about problems you already know about and can't quickly fix.
One approach is to list legacy systems as in-scope but with caveats. Acknowledge that you're aware of security limitations and are working on migration, but are interested in unexpected issues that researchers might discover. This manages expectations while still allowing valuable research.
Scope evolves as your infrastructure changes. Launching new products, acquiring companies, or migrating to new architectures all affect scope.
When adding systems to scope, announce it. Researchers monitoring your program will notice and might investigate new targets. When removing systems from scope, explain why. If you're decommissioning a service, researchers should know not to spend time on it.
Don't silently remove systems from scope without explanation, especially if researchers have been testing them. A researcher who finds a vulnerability in a system that was in scope last month deserves a response even if you've since decided to exclude it.
Organizations sometimes run multiple disclosure channels with different scope. An internal VDP might have broad scope covering all systems. A public bug bounty might have narrow scope limited to specific high-priority applications.
This works, but communicate it clearly. Researchers should know which channel to use for which findings. A vulnerability in an out-of-scope system for your bug bounty might still be in scope for your VDP, just without payment.
Whether researchers should test production systems depends on your risk tolerance and the nature of your service. For many web applications, careful testing of production systems is acceptable. For financial services or healthcare systems, it might not be.
If you provide staging or testing environments, specify whether researchers should use them instead of production. If you don't provide such environments, researchers will test production systems by default.
The challenge with staging environments is that they often don't match production. Security issues in production might not exist in staging, or vice versa. Researchers generally prefer testing production because it reflects actual security posture.
Some organizations limit scope geographically. They might exclude systems hosted in certain countries, or restrict testing to researchers in certain jurisdictions.
Geographic restrictions are rare in vulnerability disclosure, but they exist. An organization subject to specific export controls might restrict who can receive technical details about their systems. An organization operating primarily in one country might scope only those systems.
These restrictions create enforcement challenges. How do you verify where a researcher is located? How do you prevent researchers from outside your geographic scope from testing systems they can access? Geographic scope makes sense only when you have strong technical or legal reasons for it.
However you define scope, document it clearly in your vulnerability disclosure policy. Use specific examples rather than just general principles. Instead of "don't test third-party services," list the specific third-party services you integrate with that are out of scope.
Provide context for your scope decisions when helpful. If you exclude certain systems because they're being decommissioned, say so. If you limit scope to specific applications because they handle sensitive data, explain that.
Clear scope reduces friction with researchers and helps them focus their efforts where you'll benefit most from their findings.
A technical comparison of vulnerability disclosure approaches from security.txt to full bug bounty platforms. Understanding the security trade-offs at each maturity level.
GDPR creates obligations around data breaches that intersect with vulnerability management. Understanding this intersection prevents compliance problems.
CVSS provides numerical vulnerability severity ratings, but it's frequently misunderstood. Learn what CVSS actually measures and where it falls short.
Get the latest security research insights and vulnerability disclosure best practices delivered to your inbox.