117 lines
7.5 KiB
Markdown
117 lines
7.5 KiB
Markdown
# Bug-Bounty Program (Foundation)
|
||
|
||
This document is the operator-side foundation for a future bug-bounty program. It defines the scope, severity table, exclusions, and payout-mechanism so that the program can be turned on with a single operator decision, without rewriting the policy at that time.
|
||
|
||
> **Status:** **planned — not yet active.**
|
||
>
|
||
> Until the program is activated, vulnerability reports remain eligible for the [coordinated-disclosure hall of fame](./vulnerability-disclosure.md#9-hall-of-fame) and thank-you swag at the operator's discretion. We do not commit to monetary rewards prior to activation.
|
||
|
||
## 1. Activation criteria
|
||
|
||
Before the program can be marked **active** the operator must:
|
||
|
||
- [ ] Confirm legal review of this document with counsel (jurisdiction, tax, anti-fraud, contract-with-researcher template)
|
||
- [ ] Confirm payout-mechanism (SEPA, PayPal, optional cryptocurrency) and KYC requirements (see [§6](#6-payout-and-kyc))
|
||
- [ ] Confirm budget envelope (per finding cap and quarterly cap)
|
||
- [ ] Confirm internal IR-team capacity (triage SLA listed in [`vulnerability-disclosure.md`](./vulnerability-disclosure.md#6-response-sla) is sustainable)
|
||
- [ ] Replace the "planned — not yet active" banner above with the activation date
|
||
- [ ] Update `.well-known/security.txt` `Policy` field to reference this document
|
||
- [ ] Publish an announcement on the operator's public security page
|
||
|
||
## 2. Scope
|
||
|
||
Scope is identical to the [`pen-test-scope.md`](./pen-test-scope.md) in-scope / out-of-scope list. The reporter is responsible for confirming an asset is in scope before testing.
|
||
|
||
**Out-of-scope vulnerability classes** (in addition to the asset-level out-of-scope list):
|
||
|
||
- Self-XSS that requires the victim to paste attacker-controlled JavaScript into their own browser
|
||
- Social engineering, phishing, vishing, smishing
|
||
- Physical-security findings
|
||
- Findings against unsupported / end-of-life software versions
|
||
- Volumetric DoS, slow-loris, or any test that requires sustained traffic
|
||
- Missing security headers without a concrete exploit path
|
||
- "Missing best-practice" findings without a demonstrated impact (e.g. "you don't use HSTS-preload")
|
||
- SPF / DKIM / DMARC misconfigurations that don't produce a deliverable spoof PoC
|
||
- Username / email enumeration on documented public-discovery surfaces (e.g. password reset, signup)
|
||
- Rate-limit thresholds (unless the threshold is so high that it enables a meaningful attack)
|
||
- Vulnerabilities in third-party providers we use (Stripe, Mailjet, etc.) — please report directly to the provider
|
||
- CSRF on logout or other low-impact GET-tolerant routes
|
||
- Use of a known-vulnerable library version where the vulnerable function is not invoked by our codepath (SBOM is published — see [`sbom.md`](./sbom.md))
|
||
|
||
## 3. Severity table and reward tiers
|
||
|
||
Severity is determined by the operator using CVSS 3.1 and the operator severity bucket. Reward tiers are **examples**; final amounts are set per finding by the operator and are bounded by the activation budget envelope.
|
||
|
||
| Severity (operator bucket) | CVSS 3.1 | Example impact | Example reward |
|
||
| --- | --- | --- | --- |
|
||
| **P0 / Critical** | 9.0–10.0 | Remote code execution, cross-tenant write at scale, mass PII exfiltration, key compromise | up to €5,000 |
|
||
| **P1 / High** | 7.0–8.9 | Cross-tenant read of sensitive fields, authentication bypass, server-side request forgery to internal metadata | up to €2,000 |
|
||
| **P2 / Medium** | 4.0–6.9 | Privilege escalation within a tenant, IDOR returning non-sensitive fields, stored-XSS with limited persistence | up to €500 |
|
||
| **P3 / Low** | 0.1–3.9 | Low-impact information disclosure, minor authorisation gaps, CSP-bypass without exploit path | up to €100 |
|
||
| **Informational** | 0.0 | Hardening suggestion, documentation gap | Hall-of-fame credit (no monetary reward) |
|
||
|
||
**Modifiers**:
|
||
|
||
- **Chain bonus**: if a chain of findings demonstrably escalates severity, the operator may award the highest tier in the chain rather than the sum of tiers.
|
||
- **Quality bonus**: high-quality reports with deterministic PoC, working patch suggestion, and tests may receive a quality bonus of up to 50 % of the tier.
|
||
- **First-reporter only**: only the first reporter of a unique vulnerability is eligible for a reward. Duplicates receive hall-of-fame credit if quality-reported.
|
||
- **No-reward conditions**: findings that violate [§2 out-of-scope](#2-scope) or [§5 exclusions](#5-exclusions) receive no monetary reward.
|
||
|
||
## 4. Eligibility
|
||
|
||
A reporter is eligible if **all** of the following are true:
|
||
|
||
- The reporter is not employed by the operator and is not a contractor with access to the affected system at the time of the finding
|
||
- The reporter is not on a sanctions list (OFAC, EU, UN, UK)
|
||
- The reporter is at least 18 years old (or has a guardian's signed consent on file)
|
||
- The reporter has not breached the safe-harbor terms of [`vulnerability-disclosure.md`](./vulnerability-disclosure.md#5-safe-harbor)
|
||
- The reporter agrees to the operator's reporter agreement (provided at activation)
|
||
- The reporter is willing to complete the KYC step before payout (see [§6](#6-payout-and-kyc))
|
||
|
||
## 5. Exclusions
|
||
|
||
The program does **not** apply to:
|
||
|
||
- Findings produced by automated scanners without a reproducible PoC
|
||
- Findings derived from access obtained through a non-public method (e.g. leaked credentials, insider information)
|
||
- Findings that the reporter has previously disclosed publicly without an embargo
|
||
- Findings against pre-release branches, feature-flag-gated unreleased features, or local development environments
|
||
|
||
## 6. Payout and KYC
|
||
|
||
At activation the operator will offer **at least one** of the following payout mechanisms:
|
||
|
||
- SEPA bank transfer (EUR)
|
||
- PayPal (EUR, USD)
|
||
- Optionally: cryptocurrency (USDC on a major chain — operator-selected at activation)
|
||
|
||
KYC requirements (regardless of payout mechanism):
|
||
|
||
- Government-issued ID (passport or national ID card)
|
||
- Address proof (utility bill or bank statement, ≤ 3 months old)
|
||
- Sanctions screening (handled by the operator)
|
||
- Tax form completion as required by the reporter's jurisdiction (W-8BEN / W-9 / equivalent)
|
||
|
||
KYC artifacts are processed by the operator's finance partner under a data-processing agreement (DPA) and are retained for the period required by the operator's tax jurisdiction. Reporters may request deletion of KYC artifacts after the retention period.
|
||
|
||
## 7. Anti-abuse
|
||
|
||
- The operator may refuse a reward to any reporter who has previously made bad-faith reports, repeated duplicates, or extortion attempts.
|
||
- The operator may pause or cancel the program at any time. Findings in flight at the time of pause are still eligible for the reward tier in force at submission.
|
||
- The operator may exclude classes of findings (e.g. flood of similar low-severity findings) for a defined period after an announcement.
|
||
- The operator reserves the right to **not** reward findings that demonstrably caused harm beyond what was required to demonstrate impact.
|
||
|
||
## 8. Public credit
|
||
|
||
Researchers may opt in to public credit on the operator's hall-of-fame page (see [`vulnerability-disclosure.md`](./vulnerability-disclosure.md#9-hall-of-fame)) regardless of whether they receive a monetary reward. Credit is reversible — reporters can ask to be removed.
|
||
|
||
## 9. Program revision
|
||
|
||
When the program is activated, this section must be filled in with:
|
||
|
||
- **Activated:** `<YYYY-MM-DD>`
|
||
- **Activated by:** `<operator-role>`
|
||
- **Initial reward envelope:** `<EUR per quarter>`
|
||
- **Reporter agreement version:** `<semver or date>`
|
||
- **Public announcement URL:** `<url>`
|