Bug Bounty Rules of Engagement: Scope, Safe Harbour and Disclosure

#What a bug bounty program is

A bug bounty program is a standing invitation from an organization to test its public systems and report security flaws, usually for a reward. The invitation has terms. Those terms, usually called the policy, say which systems you may test, how you may test them, what you must not touch, how you must report, and what the organization promises in return.

The policy is the rulebook. Trouble often starts when a researcher skipped it or read it as a formality. A lab teaches you how to find a flaw. A program policy teaches you where you are allowed to look and when to stop at the edge of the permission. This article is about that second skill.

You will not test anything here. You will read a sample policy, annotate it, and write a pre-test checklist you can reuse on real programs. The only commands you run touch files on your own computer.

#Why the rules come before the testing

Legal exposure is the first reason people usually give, and it is real. Computer misuse laws in many countries are written broadly enough that access without permission can be charged even when the intent was good. The Computer Fraud and Abuse Act (CFAA) in the United States is the example most people know. In May 2022 the U.S. Department of Justice changed how its prosecutors charge good-faith security research under that law. The revised policy directs prosecutors not to charge research that is conducted solely to test, investigate or fix a flaw, that avoids harm, and whose information is used mainly to improve security. It does not change the statute. It does not protect research aimed at extortion, It is a charging policy, not a legal right, and it does not bind state prosecutors or private parties who sue. Read the DOJ announcement for the exact wording. Do not treat it as permission to test anything you like.

The second reason is practical. A tester who wanders into a payment system, an acquired company's domain, or a partner's API has touched something the owner never offered. Even when the finding is real, the owner now has to decide whether the report is a gift or an incident. Staying inside the written scope keeps the conversation about the bug.

So the rule is simple: if the policy does not list an asset as in scope, you are not authorized to test it. Silence is not consent. A reply from a support engineer counts only when the policy says who can grant exceptions, and then only in writing.

#Reading a program policy, step by step

Work through the policy in the same order every time. Each section below is a question you must be able to answer before the first request leaves your machine.

#1. In-scope and out-of-scope assets

Scope is the list of assets the owner allows you to test. An asset can be a domain, an IP range, a mobile app, an API, a product, or an account type. A good policy names each asset exactly and says whether a wildcard such as *.example.test covers every subdomain.

Read the out-of-scope list just as carefully. It usually names third-party services the company does not own, such as hosted payment pages, email providers and content delivery networks. A policy can grant permission to test the owner's systems. It cannot grant permission to test a vendor's systems, and each vendor has its own terms.

Two habits help. First, check where each in-scope name points. If a name resolves to a host on a third-party platform, read that platform's terms before you test it. Second, write down the date you checked, because scope lists change.

#2. Allowed and forbidden techniques

Policies describe techniques as allowed, forbidden, or silent. Treat silence as forbidden. Common forbidden items are denial of service, social engineering of staff, physical access, and attacks that would copy or change other people's data. Some programs ban automated scanners outright. Others allow them with limits.

Write the list in your own words before you start: "Allowed: manual testing of the web app with a test account. Forbidden: denial of service, phishing staff, scanners." If you cannot write it, you are not ready to test.

#3. Rate limits and load

Rate limits protect the owner's systems and other users. A policy may state a request ceiling, a concurrency limit, or a rule such as "no more than one test per second." If it says nothing, keep traffic low and manual. An automated run that looks harmless on your side can slow a small service down, and the outage then becomes your incident.

Put the number in your checklist. Configure your tool to respect it, and check the setting before you start.

#4. Test accounts

Many programs ask you to register a test account, sometimes with a specific email pattern, and to use only accounts you created. Some forbid creating accounts for other people, using a real customer's login, or testing with data you did not create. Access control testing usually needs two accounts, so the policy should say which accounts you may use and what data you may create inside them.

#5. Data handling

This section decides what you may do with what you find. Typical rules say you must stop when you reach personal data, must not download more than needed to prove the issue, must not keep copies, and must delete material once the report is closed. Some policies require redaction of screenshots.

The rule to stop at personal data catches many people. If an insecure direct object reference (IDOR) gives you someone else's record, the right proof is usually the identifier and a short description, not a dump of the table. Record what you saw, and leave the rest where it is.

#6. Safe harbour language

Safe harbour is the owner's promise that it will not start legal action against researchers who act in good faith under the policy. The disclose.io project publishes safe harbour language and tools for organizations that want to write their own. Its site describes the purpose as letting people report security issues without fear of legal repercussions, and it states that the material is not legal advice.

Read the safe harbour text closely. Good language names its conditions, such as following the policy, reporting promptly, and not using the access for anything else. It also covers the program's own systems. A promise from one company does not cover a third party or unrelated conduct. If a policy has no safe harbour at all, weigh that fact before you test.

#7. Contact and disclosure terms

The contact section says where to send a report and how the owner will answer. Look for a security contact, a platform inbox, or a security.txt file under /.well-known/. Look for an acknowledgement timeline and for what happens to the finding after the fix.

Disclosure terms say when you may publish. Some policies allow publication once a fix ships. Others set a fixed window from the first report. CISA's coordinated vulnerability disclosure page says that when a vendor is unresponsive or will not commit to a reasonable timeline, CISA may disclose as early as 45 days after its initial attempt to contact the vendor. That is CISA's rule for its own role, not a universal number. Your program's policy sets your terms, and you do not publish before they allow it.

#Coordinated vulnerability disclosure

Coordinated vulnerability disclosure (CVD) is the process in which a finder reports a vulnerability to the party that can fix it, the vendor and any other affected parties prepare a fix and guidance, and the information is published when the people who need it can act. CISA says its program facilitates the timely and synchronized dissemination of vulnerability information and any available mitigations.

ISO/IEC 29147, titled "Vulnerability disclosure" in the Information technology, Security techniques series, is the international standard for the external side of that process. It covers how a vendor receives reports, communicates with the reporter, coordinates with other vendors and publishes advisories. Its companion, ISO/IEC 30111, covers how the vendor handles the vulnerability internally. The ISO catalogue lists the document as the 2018 second edition. Check iso.org for the current status before you cite it.

For a researcher, the practical meaning is that a report starts a conversation with a process. You report, you wait for acknowledgement, you share what is needed to reproduce the issue, and you respect the agreed timeline. Those steps match the standard's model even when a program never cites it.

#Why testing outside scope is unauthorized

Authorization is a permission the owner of a system grants, and it has a boundary. Scope is that boundary written down. Anything outside it is someone else's system for the purpose of your test, and access without permission can count as unauthorized access under many computer misuse laws.

Three things go wrong when people test outside scope. First, they may be wrong about who owns the asset, so the test lands on a bystander. Second, the owner may have excluded the asset for a reason you cannot see, such as a fragile legacy system. Third, even when you are right, the report becomes harder to accept, because the owner must now decide whether to reward a finding they never asked you to look for.

The honest response to a scope question is to ask the program in writing before you test, or to skip the asset. A short question costs far less than a legal dispute.

#Hands-on: annotate a sample policy and write a pre-test checklist

No lab is needed for this section. The sample program below is fictional and uses the reserved example.test domain. You will read it, mark it up, and check a checklist with a small script on your own machine. Nothing here sends a request to a real host.

#The sample policy

Save this as sample-policy.md in an empty folder.

Example Widget Co. Vulnerability Disclosure Program (fictional)

1. Scope
   In scope: *.example.test and api.example.test.
   Out of scope: payments.example.test (hosted by a payment provider),
   any third-party SaaS host, staging-old.example.test.

2. Techniques
   Allowed: manual testing with a test account you created.
   Allowed: automated scanners at no more than 2 requests per second.
   Forbidden: denial of service, phishing or contacting staff, physical access.

3. Test accounts
   Create accounts with the suffix [email protected].
   Do not use accounts that belong to customers.

4. Data
   If you reach personal data, stop and report the identifier only.
   Delete copies within 30 days of the report being closed.

5. Safe harbour
   We will not pursue legal action against good-faith research that follows
   this policy.

6. Reporting
   Send reports to [email protected]. We acknowledge within 3 business days.
   We ask for 90 days between first report and public disclosure.

#Annotation exercise

Copy the policy into a text file and tag each line with one of four labels: [SCOPE], [RULE], [ASK], or [GAP]. Use ASK when you need to clarify with the program before testing. Use GAP when the policy is silent on something you need.

Then answer these questions in writing. Quote the line that answers each one, and do not answer from memory.

1. Is api.example.test covered by the same rules as the main site, or does it need its own check?
2. Does the rate limit apply only to scanners, or to manual traffic too?
3. What is the status of payments.example.test, and what would you do if a test reached it by accident?
4. Does the safe harbour cover a finding that exposes customer data?
5. Which part of the disclosure terms is a commitment by the owner, and which is a request to you?

Question 4 has no answer in the text. Mark it GAP and write the question you would send to the program.

#The pre-test checklist

Write the checklist before each test. It should fit on one screen, with one line per item drawn from the scope, technique, account, data and contact sections of the policy. Save this as checklist.md:

# Pre-test checklist

- [ ] written scope:
- [ ] excluded assets:
- [ ] allowed techniques:
- [ ] test account rules:
- [ ] data handling:
- [ ] contact and disclosure terms:

Fill each line with the answer and, next to it, a quote from the policy. An item you cannot fill is an open question, and you should not test until it is closed.

#Check the checklist with a script

Save the script below as precheck.py in the same folder. It reads a local text file and does not connect to anything.

import re, sys

REQUIRED = [
    "written scope",
    "excluded assets",
    "allowed techniques",
    "test account rules",
    "data handling",
    "contact and disclosure terms",
]

def read_fields(path):
    fields = {}
    with open(path, encoding="utf-8") as f:
        for line in f:
            m = re.match(r"^- \[( |x)\] ([^:]+):\s*(.*)$", line.rstrip("\n"))
            if m:
                fields[m.group(2).strip().lower()] = (m.group(1) == "x", m.group(3).strip())
    return fields

fields = read_fields(sys.argv[1])
missing = 0
for name in REQUIRED:
    if name not in fields:
        print(f"MISSING LINE: {name}")
        missing += 1
        continue
    done, value = fields[name]
    if not done or not value or value.upper() in ("TBD", "?"):
        print(f"OPEN: {name}")
        missing += 1
    else:
        print(f"OK: {name}")
print(f"{len(REQUIRED) - missing} of {len(REQUIRED)} items closed")
sys.exit(1 if missing else 0)

Run it from Git Bash in the folder that holds both files:

python precheck.py checklist.md
echo "exit=$?"

The author ran this on a Windows 11 machine with Git Bash, using a checklist in which the test account line still said TBD. The output was:

OK: written scope
OK: excluded assets
OK: allowed techniques
OPEN: test account rules
OK: data handling
OK: contact and disclosure terms
5 of 6 items closed
exit=1

The checker flags the open item and exits with status 1, so a wrapper script can stop the test. It checks only that the form is complete. It cannot tell whether an entry matches the policy, which is why each entry needs the quoted line beside it.

#Common mistakes

• Treating the program name as the scope. A program called "Example Widget" may cover one product, several companies, or none of the subsidiaries you have in mind. Read the list.
• Testing a guessed or inherited asset. A subdomain you guessed, or an address from an old public record, is out of scope until the policy lists it.
• Running a scanner at full speed because the policy is silent on rates. Silence about rates is not permission to run fast.
• Keeping data after the report. Copies left on a laptop are still the owner's data, and the policy may require deleting them.
• Publishing early because the vendor replied "fixed". Read the disclosure terms and wait for them.
• Writing a report that proves more than you were allowed to collect. The identifier and one redacted field usually prove the issue as well as a dump does.
• Assuming the safe harbour covers everything. It covers what its text says, for the systems it names.

#How to go further

Practise the reading habit on public programs that publish their rules. Keep one checklist per program, and reread the policy the same day you test, because scope changes. Read the disclose.io safe harbour material and the CISA coordinated disclosure page in full. Learn the difference between a vulnerability disclosure policy, which may offer no reward, and a bug bounty program, which pays for findings. Then read how to write your first security report to see how a finding should look once you have permission and have found something.

Keep notes on what you tested, when, and from which account. If a question comes up months later, those notes are your evidence.

Build technical skill in an isolated lab, not on someone else's system. The steps are in how to create an isolated Docker network for labs. Public information has its own limits too, covered in OSINT ethics and privacy.

#Sources

• disclose.io, safe harbour and policy tools: https://disclose.io/
• ISO/IEC 29147, Information technology, Security techniques, Vulnerability disclosure: https://www.iso.org/standard/72311.html
• CISA, Coordinated Vulnerability Disclosure Process: https://www.cisa.gov/coordinated-vulnerability-disclosure-process
• U.S. Department of Justice, New Policy for Charging Cases Under the Computer Fraud and Abuse Act (May 2022): https://www.justice.gov/opa/pr/department-justice-announces-new-policy-charging-cases-under-computer-fraud-and-abuse-act