Vulnerability Disclosure Policy

1. Purpose and scope

Breaking Bandwidth values the work of security researchers who report vulnerabilities in good faith. This policy describes how to report a security issue and what we commit to in return.

This policy covers:

• The public website at breakingbandwidth.com and any subdomain owned by Breaking Bandwidth.
• Breaking Bandwidth product surfaces (Scanner, Acceptance, Pentest) when publicly accessible to customers, including any preview, beta, or production environment we operate.
• Source-code repositories under github.com/breaking-bandwidth that are made public.

This policy does not cover third-party services we integrate with (such as WorkOS, Stripe, Cloudflare, or Sentry); vulnerabilities in those services should be reported to the operator of the service. It also does not cover findings produced by our own product surfaces against a customer's infrastructure under a paid engagement, which follow the engagement's contractual reporting channel.

2. How to report

Send your report to security@breakingbandwidth.com. Encrypt with PGP if your report contains sensitive details (key fingerprint published on the /security page).

A useful report includes:

• A concise description of the issue and its impact.
• Steps to reproduce, including any required configuration, accounts, or payloads.
• Evidence of the vulnerability (screenshots, request/response captures, proof-of-concept code).
• The version, environment, URL, or commit hash where you observed the issue.
• Your preferred contact method and whether you wish to be credited.

We acknowledge receipt within three business days. We aim to validate or dispute the finding within fourteen calendar days of acknowledgement, and to remediate confirmed findings within a timeline proportionate to severity, communicated to the reporter as soon as feasible.

3. Coordinated disclosure

We follow a coordinated-disclosure model. The reporter agrees to give Breaking Bandwidth a reasonable opportunity to investigate and remediate before publishing details to third parties. We agree to communicate openly about progress, target remediation dates, and any constraints. Public disclosure is coordinated between Breaking Bandwidth and the reporter; we support reporters who wish to publish writeups, with reasonable agreement on timing. For severe issues affecting customer infrastructure, we may agree to extended pre-disclosure windows to permit customer remediation.

We do not operate a bug-bounty programme and we offer no monetary reward at this time. We will publicly credit researchers who choose to be credited and whose reports lead to a fix.

4. Safe harbour

If you make a good-faith effort to comply with this policy, Breaking Bandwidth will not bring or support a civil claim against you for actions consistent with this policy, will not refer the matter to law enforcement for such actions, and will work with you to understand and resolve the issue quickly.

Activities consistent with this policy are authorised by Breaking Bandwidth for the purposes of any applicable computer-misuse law, including the Dutch Wetboek van Strafrecht art. 138ab, 138b, 350a–d, and any equivalent provision in your jurisdiction.

Activities not consistent with this policy include but are not limited to:

• Accessing, exfiltrating, modifying, or destroying customer data beyond the minimum necessary to demonstrate the vulnerability.
• Sustained denial-of-service testing, distributed denial-of-service, brute-force attempts, or load testing against production.
• Social engineering of Breaking Bandwidth staff, contractors, customers, or vendors.
• Physical intrusion against Breaking Bandwidth premises or property.
• Public disclosure of the vulnerability before coordinated disclosure has concluded.
• Reporting issues for the purpose of extracting payment, threatening publication, or coercing remediation timelines.

Reporters who act outside this policy lose its protection.

5. Out-of-scope findings

We will generally not act on the following classes of report unless a concrete, demonstrable impact is shown: missing security headers without an associated exploit; missing rate limiting on non-authentication endpoints; self-XSS or reflected XSS requiring victim cooperation outside a phishing scenario; clickjacking on pages without sensitive state-changing actions; theoretical attacks based on outdated library versions without a working proof of concept against our deployment; reports generated by automated scanners without manual validation.

6. Confidentiality

We treat all reports as confidential. We do not share reporter contact details with third parties except as required by law or by a customer's contractual right to be informed of issues affecting their tenancy. Where a third party must be informed, we anonymise the reporter unless they have explicitly consented to be named.

7. Changes to this policy

This policy may be updated. Material changes are versioned (semantic versioning) with the change log published at the /security URL. The version and effective date at the head of this document are authoritative.