Bug Bounty Program

Owner: Security. Review cadence: annual or on material change. Approver: CEO.

This is the program structure behind MeterBox's paid security-researcher channel. The public researcher-facing terms — what's in scope, safe harbor, response SLAs — live in the vulnerability disclosure policy; this doc covers what MeterBox commits internally — reward tiers, program lifecycle, eligibility, duplicate handling, hall-of-fame format, budget owner.

Until the managed program is live (see § 8), the canonical channel is the email address in the VDP and reports are handled as coordinated disclosure (no payout). This document then becomes the SOW for standing the program up.

1 — Program lifecycle

The program graduates through three phases. The Security lead decides when to graduate each phase based on signal quality + remediation throughput.

Graduation criterion at each step: at least one quarter at the prior phase with no Critical findings missed by internal CI, and remediation SLA met on at least 90% of received reports.

2 — Reward tiers

Rewards are paid in USD via the bounty platform (HackerOne or equivalent). Amounts are guidelines — the Security lead may adjust ± 50% based on report quality (clarity of reproduction, novelty of attack chain, severity of customer impact).

Bonuses:

• +25% for a working proof-of-concept exploit beyond the description.
• +25% for a suggested fix that's accepted and shipped.
• +50% for a chain that combines two or more findings into a higher- impact attack (paid against the chained severity).

No reward for:

• Findings out of scope per the VDP.
• Duplicates of an already-reported issue (§ 5).
• Issues already known internally (recorded in a private tracker).
• Theoretical issues without a demonstrated exploit path.

3 — Scope refinements specific to the bounty

The VDP scope is the floor. The bounty program adds:

• In scope, bountied: the surfaces listed in VDP Scope — /cp/*, /v1/*, the SPA, the Helm chart, the container images, plus the customer-portal endpoints (/v1/customer-portal/*).
• In scope, coordinated disclosure only (no payout): the marketing site, documentation surfaces (/docs, /trust, /security), open-source SDKs (sdks/), Helm-chart documentation under deploy/helm/. We still want these reported; just not bountied.
• Out of scope, no acknowledgement: anything on the VDP Out-of-scope list, plus issues against the MeterBox Advisor LLM egress (third-party model behavior is the vendor's responsibility once the brief has been sent).

4 — Researcher eligibility

A researcher is eligible to receive a reward if all the following hold:

• They are not a current employee, contractor, board member, or vendor of MeterBox, nor an immediate family member of one.
• They are not in a jurisdiction MeterBox is prohibited from making payments to under applicable sanctions law (OFAC SDN list + the bounty-platform's sanctions screening).
• They report through the program's managed channel (HackerOne or the VDP email until the program is live).
• They are ≥ 18 years old or have explicit written consent from a parent or legal guardian.
• They have complied with the safe-harbor terms in VDP § Safe harbor on the report.

An ineligible researcher who submits a valid report is acknowledged, credited (with consent), and given the remediation update; no payout.

5 — Duplicate handling

• Earlier report wins — the first researcher whose report contains enough information to reproduce the issue receives the payout. Later reports of the same issue are marked duplicate, acknowledged, and given the remediation update.
• Independently-discovered chains — if a later report adds material novelty to a known issue (e.g. a different attack vector chained to it), the Security lead may issue a partial payout against the chained severity at their discretion.
• Disputes — researcher may request a re-review by the Security lead; CEO decision is final.

6 — Disclosure timeline

• Day 0 — report received; acknowledged per VDP SLA (2 business days).
• Triage — severity assigned per § 2; remediation SLA from SECURITY.md kicks in (Critical 24h / High 1 week / Medium 1 month / Low 3 months).
• Remediation + retest — fix is shipped; reporter confirms the issue is no longer reproducible.
• Public disclosure window — 90 days from initial report. Reporter may publish a write-up after remediation OR after the 90-day window, whichever is sooner. MeterBox may publish a CHANGELOG entry crediting the reporter (with consent) at the same time.
• Embargo extensions — granted when remediation is genuinely blocked on a third-party (e.g. an upstream library fix). Maximum extension is 90 additional days; the reporter is informed.

7 — Hall of fame

Researchers credited (with consent) for valid reports are listed in the public hall of fame at /security#hall-of-fame (rendered from SECURITY.md). Format:

- @<handle>  —  <one-line attribution>  —  <YYYY>

A researcher may request anonymity or removal at any time. Removal is honored within 5 business days.

8 — Standing up the program (the human steps)

The doc cannot stand up the platform — these are the org actions:

1. Pick the platform. HackerOne private invite-only is the default per the VDP; Bugcrowd is the documented alternative. Selection is on the same criteria as the pentest vendor: SaaS experience, methodology, MSA + NDA, payment-rail coverage for sanctioned-juris screening.
2. Fund the bounty pool. Initial quarterly budget set by the CEO based on phase 1 expected volume + the § 2 ranges. Pool replenished monthly.
3. Paste this doc as the program brief. The VDP is the public policy; this doc — minus § 8 — is the private program brief.
4. Update /.well-known/security.txt to point at the program URL once it exists.
5. Wire reports into the triage workflow. Same workflow as CI / Dependabot / pentest findings.

9 — Annual program review

Each fiscal year, Security lead reviews:

• Were the SLAs met? (Report acknowledgement, severity assignment, remediation per SECURITY.md.)
• What was the report volume + valid-rate by phase? Decide on graduation (§ 1).
• Were reward tiers competitive? Benchmark against published programs of comparable SaaS scope.
• Were there any incidents that the program could plausibly have surfaced? (If yes, scope or tier adjustment.)

Review notes filed with the year's pentest review (annual program review checkpoint in penetration-testing.md).

10 — Review + version control

This document is reviewed annually or on material change (platform switch, tier restructure, phase graduation, regulator requirement). Material changes go through PR review + Security lead + CEO sign-off + a CHANGELOG entry.

Last reviewed: 2026-06-04

Related docs

• Vulnerability disclosure policy — public researcher-facing terms.
• Penetration testing — paid firm engagement, rules of engagement.
• SECURITY.md — remediation SLA, hall-of-fame rendering.
• InfoSec policy § 7 — vulnerability management commitment.
• Risk register R-003 — supply-chain risk that the bounty + pentest programs are part of the mitigation for.