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 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)
Confirm budget envelope (per finding cap and quarterly cap)
Confirm internal IR-team capacity (triage SLA listed in vulnerability-disclosure.md 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 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)

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 or §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
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)

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) 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>

7.5 KiB Raw Blame History Unescape Escape