HiveGrid-Wireframes/hivegrid-cloud/docs/security/vulnerability-disclosure.md

# Vulnerability Disclosure Policy

This is the canonical public vulnerability disclosure policy for the platform. The same content is referenced from [`SECURITY.md`](../../SECURITY.md), the public `.well-known/security.txt` and any operator-hosted "Security" page.

> **Status:** active. Reports are accepted at `security@<your-domain>` (PGP key in `.well-known/pgp-key.txt`).

## 1. Promise

We take security seriously. We invest in the architecture, the controls, and the runbooks that defend customer data — and we recognise that even with that investment, well-meaning security researchers will sometimes find issues we have missed. This policy describes how to report those issues to us, what to expect in response, and the safe-harbor commitment that protects researchers acting in good faith.

## 2. Reporting channels

| Channel | Use when |
| --- | --- |
| `security@<your-domain>` (PGP, see [`.well-known/pgp-key.txt`](../../apps/web/public/.well-known/pgp-key.txt)) | Default — any suspected vulnerability |
| Coordinated-disclosure form (link published on the public security page once available) | Researchers who prefer a web form |
| `dpo@<your-domain>` | If the report involves a suspected data-protection breach affecting a specific data subject |
| `oncall@<your-domain>` | Only if the issue is being actively exploited and the operator must page on-call immediately |

Please **do not** open a public issue on the source repository, post on social media, file a chargeback, or contact customer support for a security issue. Those channels are not monitored for security reports and will delay the response.

## 3. What to include

A high-quality report typically contains:

1. **Concise title** (≤ 80 chars)
2. **Affected surface** — generic route class, endpoint shape, worker job, or documentation page. Do not include a customer-specific URL
3. **Reproduction steps** — using fixtures or synthetic values only; do not include real secrets, customer data, tenant identifiers, or production tokens
4. **Observed impact** — what happened
5. **Expected behavior** — what should have happened
6. **Severity estimate** — your best guess (CVSS 3.1 vector + score is welcome)
7. **References** — CWE / OWASP / related advisories
8. **Researcher contact** — preferred email + PGP fingerprint
9. **Hall-of-fame preference** — whether you want credit (and the name to use) or prefer to stay anonymous

Where to find safe values for examples: see "Safe evidence" in [`SECURITY.md`](../../SECURITY.md).

## 4. Scope

In-scope assets and out-of-scope assets are the same as the [`pen-test-scope.md`](./pen-test-scope.md) definition. Researchers should review §2 and §3 of that document before testing.

**Quick reference**:

- **In scope**: `app.<env>.<your-domain>`, `admin.<env>.<your-domain>`, `api.<env>.<your-domain>`, `realtime.<env>.<your-domain>`, public widget bootstraps (`widget.js`, `marketing.js`), embed routes, lead-capture endpoint, public documentation
- **Out of scope**: production tenants, third-party provider consoles, marketing site, customer-configured destinations, social engineering, DoS / load testing, destructive activity, real-user data exfiltration, public CDN edge-cache attacks

## 5. Safe harbor

We will not pursue legal action against, will request stand-down from any third party we control on behalf of, and will publicly thank (on request) any researcher who:

- limits activity to the in-scope assets,
- avoids the out-of-scope activities,
- respects an operator stop request,
- reports findings exclusively through `security@<your-domain>` (or another listed channel) until disclosure is mutually agreed,
- does not modify, destroy, or exfiltrate data beyond the minimum required to demonstrate impact,
- gives us a reasonable opportunity to remediate before publishing.

If you are unsure whether an activity is in scope, ask first at `security@<your-domain>`. We will respond within one business day.

Safe harbor does **not** cover:

- Activity that violates applicable law (e.g. unauthorised access to systems beyond the in-scope list)
- Activity that breaches a contract with another customer
- Sustained denial-of-service or destructive activity
- Extortion ("pay me and I'll tell you the bug")

## 6. Response SLA

| Step | Target |
| --- | --- |
| Acknowledgement of receipt | ≤ 48 hours (business days) |
| Triage and severity assignment | ≤ 5 business days |
| Status update cadence during fix | every 7 calendar days |
| Fix for **P0 / Critical** | ≤ 7 calendar days |
| Fix for **P1 / High** | ≤ 30 calendar days |
| Fix for **P2 / Medium** | ≤ 60 calendar days |
| Fix for **P3 / Low** | ≤ 90 calendar days |
| Public advisory | at fix deployment, or 90 days from report, whichever is first |

Severity is determined by the operator using CVSS 3.1 and the operator severity bucket (P0–P3, see [`incident-response.md`](./incident-response.md)). Reporters may dispute the severity assignment in writing; the operator records the dispute and the final decision.

## 7. Coordinated disclosure

We work with reporters to find a disclosure date that gives customers time to upgrade or apply mitigations. By default:

- We publish an advisory on the operator's public security page when the fix ships.
- We credit the reporter (by their chosen name) in the advisory and in the hall of fame, unless they have asked to stay anonymous.
- We disclose 90 days after the original report at the latest, even if a fix has not shipped, unless the reporter agrees to a longer embargo.

If a vulnerability is being actively exploited, we may publish a partial advisory immediately, with full technical detail following the fix.

## 8. Bug bounty

A formal bug-bounty program is **planned but not yet active**. See [`bug-bounty.md`](./bug-bounty.md) for the program skeleton and current activation status. Until the program is active, reports remain eligible for the coordinated-disclosure hall of fame and for thank-you swag at the operator's discretion. We do not commit to monetary rewards until the bounty program is formally activated.

## 9. Hall of fame

We maintain a list of researchers who have responsibly disclosed vulnerabilities to us, with their consent, on the operator's public security page (`https://app.<your-domain>/security/hall-of-fame`, indexed by `.well-known/security.txt` via the `Acknowledgments` field). Inclusion is opt-in and reversible — researchers can ask to be removed at any time.

## 10. What we will not do

- We will not threaten or pursue legal action against a researcher who follows this policy.
- We will not require a non-disclosure agreement as a precondition to triage.
- We will not require the researcher to forfeit credit as a precondition to acceptance.
- We will not share researcher identity or contact information with any third party without consent, except where required by law.

## 11. Updates to this policy

This policy is versioned with the repository. Material updates are announced via the operator's public security page and via a new entry in the operator's changelog. The current revision is the file `docs/security/vulnerability-disclosure.md` at the tip of the `main` branch.