Vulnerability Disclosure Policy

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

MeterBox welcomes reports from security researchers. This policy is the public-facing program description — the text to paste into a HackerOne (or similar) private program and to link from /.well-known/security.txt.

Reporting

• Email: contact@meterbox.ai (PGP key on request).
• Program: a private, invite-only HackerOne program is the intended managed channel — see Operationalization below. Until it is live, email is the canonical channel.
• Please include: affected component (control plane /cp/*, data plane /v1/*, the SPA, the Helm chart, or an image), a clear reproduction, and impact. One issue per report.

Scope

In scope:

• The MeterBox API surface — /cp/* (control plane) and /v1/* (tenant billing API).
• The dashboard SPA.
• The Helm chart + container images (docker/Dockerfile.*, deploy/helm/meterbox).

Out of scope (report to the upstream instead):

• Third-party subprocessors — Stripe, Resend. Report to them.
• Findings that require a compromised operator cluster, physical access, or a privileged insider.
• Volumetric DoS, rate-limit exhaustion without a logic flaw, and social engineering of MeterBox staff or customers.

Safe harbor

We will not pursue legal action against good-faith research that:

• respects this scope and the data-locality boundary (no exfiltration of real tenant data — use your own test org/sandbox env),
• avoids privacy violations, service degradation, and data destruction,
• gives us a reasonable window to remediate before public disclosure (coordinated disclosure; 90 days is the default).

Good-faith research conducted under this policy is authorized; we consider it neither a violation of our terms nor of anti-hacking law.

Our commitments

• Acknowledge within 2 business days.
• Triage + assign a severity (CVSS as the starting point).
• Remediate on the published SLA — Critical 24h / High 1 week / Medium 1 month / Low 3 months (see SECURITY.md → Vulnerability management). The same gate that blocks Critical dependency advisories in CI applies to reported criticals.
• Keep the reporter updated through resolution and credit them (with consent).

Operationalization (the human steps)

This document is the policy; standing up the managed program is an organizational action that can't be automated. The detailed program structure — reward tiers, eligibility, duplicate handling, phase graduation — lives in the bug bounty program doc. Summary:

1. Create the HackerOne program (private/invite-only to start), paste this policy as the program brief, paste the bug-bounty program doc (minus its § 8) as the private brief, set scope from the lists above.
2. Fund the bounty pool per bug-bounty-program.md § 2 reward tiers; CEO sets quarterly budget.
3. Point /.well-known/security.txt (served by the control plane) at the program URL once it exists — update the Policy/Contact fields.
4. Route HackerOne reports into the same triage + remediation-SLA workflow as CI/Dependabot findings.

Related docs

• Bug bounty program — internal program structure, reward tiers, eligibility, lifecycle.
• Penetration testing — paid firm engagement (a separate channel; firms and bounty hunters are not the same talent pool).
• SECURITY.md — public security overview + SLAs.