Bug Bounty and Vulnerability Disclosure Guide

Outsiders find vulnerabilities in your systems whether or not you invite them, and without a published way to report them, those findings end up ignored, sold, posted publicly or never sent. A vulnerability disclosure programme (VDP) gives finders a safe, clear route to you; a bug bounty adds payment to attract more and better testing. Both are now written into regulation: US federal agencies must run a VDP, UK connectable product makers must publish a reporting contact, and the EU Cyber Resilience Act brings vulnerability handling duties for products with digital elements. This guide covers VDP versus bug bounty, policy scope and safe harbour, security.txt, triage, rewards, disclosure timelines, CVE assignment and metrics. It is for security leaders, product security (PSIRT) teams and anyone deciding whether and how to open their systems to outside researchers.

Key takeaways

• A VDP comes before a bug bounty. You need a policy, a monitored channel and a working triage process before money attracts volume; a bounty without them produces backlog and frustrated researchers.
• Safe harbour is the core of the policy. CISA's BOD 20-01 requires agencies to commit "to not recommend or pursue legal action against anyone for security research activities" carried out in good faith; private organisations should make an equivalent, explicit promise.
• security.txt is cheap and expiring. RFC 9116 makes Contact and Expires mandatory, recommends an expiry less than a year ahead, and warns that stale data can be worse than no file.
• Triage is the programme. Most cost and reputation risk sits in acknowledgement, validation, deduplication and fixing, not in the policy page; set and measure target timelines from day one.
• Credential findings need incident handling. Exposed API keys, tokens and over-privileged test accounts are common report types, and they need revoke-and-rotate handling, not just a ticket.

VDP, bug bounty and penetration testing compared

A VDP is a standing invitation to report; it does not promise payment. A bug bounty is a VDP with rewards, usually limited to a defined scope and often open first to invited researchers (private) before the public. ISO/IEC 29147:2018 covers the outward side, receiving reports and "disclosing vulnerability remediation information", and ISO/IEC 30111:2019 covers what happens in between, "how to process and remediate reported potential vulnerabilities".

A penetration test gives documented coverage, a bounty gives continuous attention on exposed assets, and a VDP catches everything else. Reported vulnerabilities join the main remediation queue. See the Vulnerability Management Guide.

Legal and regulatory drivers

Prosecutorial policy is not a licence and does not reach civil claims or other countries, so your own written authorisation still matters. See the Global Cybersecurity Regulatory Map.

Writing the policy: scope, rules of engagement and safe harbour

The NCSC Vulnerability Disclosure Toolkit says a basic policy should cover how you want to be contacted, secure communication options, what to include in a report, what the finder should expect, and what is in and out of scope. BOD 20-01 adds a useful federal benchmark: allowed and prohibited testing, a statement that anonymous reports are accepted, acknowledgement expectations and an issuance date.

Scope

• List assets explicitly: domains, wildcard domains you actually own, mobile app identifiers, API base URLs, product versions and open source repositories. Say what is out of scope (third-party SaaS you do not control, acquired companies not yet integrated, staging that shares production data).
• Name excluded finding types: typical exclusions are volumetric denial of service, social engineering of staff, physical attacks and findings that need a rooted device or an outdated browser.
• Cover AI features: if a product includes LLM features, say whether prompt injection, jailbreaks, model output issues and data leakage through retrieval are in scope, and how they are rated. See the Prompt Injection Guide.

Rules of engagement

• Data handling: stop at proof of access; do not download, modify or retain personal data, and delete anything accessed by accident. BOD 20-01 requires agencies to prohibit disclosing discovered personal data to third parties.
• Accounts, rates and automation: test only with your own or programme-supplied accounts, state a request rate ceiling and whether scanners are allowed, and ask researchers to tag their traffic.
• Disclosure: ask for a reasonable period to fix before publication rather than a gag. BOD 20-01 prohibits policies that "restrict the reporter's ability to disclose discovered vulnerabilities to others" beyond a reasonably time-limited response period, and the NCSC toolkit advises avoiding NDAs.
• No conditions on reporting: a VDP should not require personal information, citizenship or registration to submit; BOD 20-01 bars agencies from limiting testing to vetted parties or US citizens. A bounty can ask for identity details at payout, not at report.

Safe harbour

Safe harbour language states that research conducted in line with the policy is authorised, that you will not pursue civil or criminal action for it, and that you will make that clear if a third party complains. It typically also waives anti-circumvention and terms-of-service claims for compliant research. The disclose.io project publishes open, standardised policy and safe harbour terms, which it describes as letting "people acting in good faith, as the recipient defines it, report security issues without fear of legal repercussions", plus a generator for policies and security.txt. Have counsel review the wording for each jurisdiction you operate in, and make sure it cannot be read as authorising testing of systems you do not own.

security.txt done properly

RFC 9116 defines a machine-readable file that tells researchers where to report. It is served at /.well-known/security.txt over HTTPS as text/plain in UTF-8, and it applies only to the exact host it is served from, not subdomains or parent domains.

Contact: mailto:[email protected]
Contact: https://example.com/security/report
Expires: 2027-09-30T23:00:00.000Z
Encryption: https://example.com/.well-known/pgp-key.txt
Policy: https://example.com/vulnerability-disclosure-policy
Acknowledgments: https://example.com/security/hall-of-fame
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

• Mandatory fields: Contact "MUST always be present"; Expires "MUST always be present and MUST NOT appear more than once", and should be less than a year ahead.
• Signing: an OpenPGP cleartext signature is recommended, with Canonical fields so the signature also authenticates the location. Encryption points to a key; it must not embed one.
• Every host: publish on each domain in scope, and in multi-tenant hosting reserve the path so a tenant cannot publish a fake file.
• Not a permission slip: the RFC is explicit that publishing the file does not grant permission to test; that belongs in the Policy document.
• Expiry monitoring: add the Expires date to certificate-style expiry monitoring. The RFC warns that stale information can be worse than having no file.

Triage and vulnerability handling

ISO/IEC 30111 handling is where programmes succeed or fail. Run it as a defined workflow with a named owner, usually a product security incident response team (PSIRT) for vendors or the security operations or application security team for service operators.

1. Receive: through a protected web form or platform rather than a shared inbox, as the NCSC recommends protecting vulnerability information.
2. Acknowledge: automatically and then by a person. CISA recommends "no more than 3 business days" for acknowledgement in BOD 20-01.
3. Validate and deduplicate: reproduce the issue, check whether it is already known, and decide in or out of scope. First valid report wins for duplicates; say so in the policy.
4. Rate severity: use CVSS v4.0 plus your own impact context, and record the rating rationale so researchers can challenge it.
5. Assess impact: check logs for prior exploitation. BOD 20-01 requires agencies to treat confirmed past impact as an incident; if the report shows a live credential or exploitation, hand over to incident response. See the Incident Response Guide.
6. Remediate: route to the owning team with a remediation SLA by severity, and keep the researcher updated periodically.
7. Verify and close: invite the researcher to confirm the fix, pay any reward, publish an advisory where users must act, and credit the finder.

CVE assignment: if you ship software, users need a CVE ID to track the fix. CVE Numbering Authorities (CNAs) assign IDs within an agreed scope; software vendors of any size can apply to become one, which lets you assign IDs for your own products on your own timeline instead of waiting for a third party. Open source projects can use their hosting platform's private vulnerability reporting and advisory features where available. See the Open Source Security Guide.

Coordinated disclosure timelines

Coordinated vulnerability disclosure (CVD) means the finder and the vendor agree when details go public, normally after a fix is available. A 90-day window is a widely used default. Google Project Zero's policy gives vendors "90 days after Project Zero notifies them" to ship a patch, publishes details 30 days after the patch if it lands inside 90 days, allows a grace period if a patch will arrive within 104 days (publication at day 120), and switches to a 7-day deadline when it finds in-the-wild exploitation. CISA's own coordination process for multi-vendor and unresponsive cases is covered in the Zero-Day and Exploited Vulnerabilities Guide.

• Publish a default: state your target fix window and that you will agree publication dates with finders, rather than leaving it to negotiation per case.
• Plan for disagreements: if a fix needs longer, explain why early and propose a date; silence pushes finders to publish unilaterally.
• Advisories: publish affected versions, fixed versions, CVE IDs, severity and workarounds, and credit the finder with consent.

Rewards, platforms and running costs

• Reward table: publish ranges by severity tier and asset criticality, with the top tier reserved for issues such as remote code execution, authentication bypass or exposure of customer data at scale. Paying more for critical assets steers researchers to what matters.
• Rules researchers check first: duplicates, third-party component issues, chained findings and severity disputes.
• Payout controls: collect identity and tax details only at payment, screen against sanctions lists, and keep bounty payments within the security budget with dual approval. A bounty payment must never be used to buy silence about a breach.
• Non-cash recognition: an acknowledgements page, CVE credit and private programme invitations.

Choosing the model for your organisation

• Small organisations: publish a VDP, security.txt and a monitored form; do not pay until you can fix a critical issue within days. A private, invite-only bounty on one or two key applications is the next step.
• Software vendors and device makers: PSTI and the CRA make a published reporting route and a handling process a legal duty, not an option. Build ISO/IEC 30111 handling, become a CNA if you ship often, and plan for 24-hour CRA reporting of exploited vulnerabilities.
• Large enterprises: run a VDP for everything, a private bounty for crown-jewel applications, and move to public only when median time to remediate high-severity reports is under your published window.
• Public sector: BOD 20-01 sets the floor for US federal agencies, including growing scope on a schedule until everything internet-facing is covered; bounties can sit on top for specific systems.

Where identity fits

Many serious external reports concern credentials rather than code: API keys in mobile apps and JavaScript bundles, tokens in public repositories, CI logs exposing secrets, and admin panels reachable with default or test accounts. In the Homebrew GitHub token exposure, a researcher found a token on a public Jenkins page that gave push access to core repositories.

• Treat secret reports as incidents: revoke and rotate first, then investigate use of the credential from its creation date, then fix the leak path. See the Leaked Credential Response Playbook.
• Provision researcher accounts as managed identities: bounty test accounts should be tagged, isolated from real customer data, rate limited, expiring and monitored, and removed when the programme or researcher leaves.
• Secure the programme's own integrations: API tokens that sync reports from a platform into ticketing or chat are non-human identities with access to unfixed vulnerability details; scope, vault and rotate them. See the API Key Management Guide.

Implementation roadmap

1. Readiness (weeks 1 to 4): name the owner, define the triage workflow and SLAs, agree escalation to incident response and legal, and inventory internet-facing assets for scope.
2. Publish the VDP (weeks 4 to 8): policy with scope, rules and safe harbour, a protected submission form, and security.txt on primary domains with expiry monitoring.
3. Pilot and measure (months 2 to 6): run the VDP, track acknowledgement and remediation times, and fix process gaps. Test the workflow with an internal or friendly-researcher report before launch.
4. Private bounty (from month 6): invite a small group onto a narrow, well-understood scope with a published reward table.
5. Expand: add assets on a schedule, widen invitations, then consider going public.
6. Rollback: if volume outruns triage, pause new invitations, narrow scope or move back from public to private, and tell researchers why. Never withdraw safe harbour retroactively.

Detection and measurement

Track BOD 20-01's federal metrics, which work for any programme: report counts, valid vulnerabilities, age of open items, and median times to validate, remediate and first respond. Useful KPIs:

• Median time to first response against the published target.
• Median time to remediate valid reports by severity.
• Signal ratio: valid, unique reports as a share of all submissions.
• Repeat findings: valid reports in a vulnerability class already reported, which shows root causes are not being fixed.
• Scope coverage: share of internet-facing assets inside the policy, and security.txt files within expiry.
• Researcher disputes: severity or payout disagreements, and any unilateral public disclosures.

Framework mapping

Common failure patterns

• Bounty as a cover-up: in the Uber 2016 breach, the company's former security chief "arranged to pay the hackers $100,000 under the guise of a bug bounty program" with NDAs, and was later convicted of obstruction and concealing a felony. Extortion is a breach, not a bounty.
• Launching public before triage works: hundreds of reports arrive, acknowledgements slip and researchers publish.
• Safe harbour with loopholes: vague "we may take action" wording, NDAs as a condition of reporting, or legal threats against good-faith finders.
• Stale contacts: security.txt pointing to a departed employee's mailbox or past its Expires date.
• Fixing the report, not the class: each injection bug is patched alone and the same flaw returns next quarter.
• Secrets closed as tickets: a leaked key is marked fixed when removed from code, but is never revoked.

Practitioner checklist

• Publish a VDP with explicit scope, rules of engagement, safe harbour and expected response times.
• Serve signed security.txt on every relevant host and monitor its Expires date.
• Accept anonymous reports and never require NDAs or personal data to report.
• Define a triage workflow with owners, CVSS-based severity and links to incident response.
• Set acknowledgement, assessment and remediation targets and report against them.
• Revoke and rotate any reported credential before closing the report.
• Start any bounty private, on a narrow scope, with a published reward table.
• Become a CNA or use a coordinator so shipped fixes get CVE IDs.
• Map PSTI and CRA obligations if you make connectable or digital products.

Standards and references

• IETF: RFC 9116, A File Format to Aid in Security Vulnerability Disclosure
• CISA: Binding Operational Directive 20-01, Develop and Publish a Vulnerability Disclosure Policy
• ISO: ISO/IEC 29147:2018, Vulnerability disclosure
• ISO: ISO/IEC 30111:2019, Vulnerability handling processes
• UK legislation: The PSTI (Security Requirements for Relevant Connectable Products) Regulations 2023, Schedule 1
• European Commission: Cyber Resilience Act reporting obligations
• NCSC: Vulnerability Disclosure Toolkit
• US Department of Justice: New policy for charging cases under the Computer Fraud and Abuse Act

Related NHI Mgmt Group resources: Vulnerability Management Guide · Zero-Day and Exploited Vulnerabilities Guide · Open Source Security Guide · Leaked Credential Response Playbook