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

4. Scope

In-scope assets and out-of-scope assets are the same as the 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). 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 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.