--- title: Responsible disclosure description: How to report a vulnerability, what is in scope, and what to expect back. label: Responsible disclosure --- :::danger Do not open a public issue for a security vulnerability A public report is a public exploit until every deployment has upgraded. Report it privately first. ::: ## How to report Email `security@veefore.com` with the detail below. If you need encryption, request a key in a first message with no technical detail in it. ## What to include :::params :::param Summary | one or two sentences | required What an attacker can do. Lead with the impact, not the mechanism. ::: :::param Affected component | string | required Gateway, control plane, console, SDK, CLI, or a specific package. Include the version from `GET /v1/meta/info` or `veefore --version`. ::: :::param Reproduction | steps | required The smallest sequence that demonstrates it. A `curl` command is ideal. ::: :::param Impact | description | required What is reachable that should not be: another tenant's data, an authority escalation, a credential, a bypassed refusal, an audit gap. ::: :::param Mitigation | optional Anything a deployment can do today, before a fix ships. ::: ::: :::danger Never include a real secret in a report Not a private key, not credential material, not a session token. Redact them. If you believe you have obtained a real credential, say so without including it and we will treat it as compromised and rotate. ::: ## What we consider high severity In rough order: | | | | --- | --- | | Cross-tenant data access | Reaching another organization's resources through any surface | | Authority escalation | Acting beyond a delegation's bounds, or a child exceeding its parent | | Enforcement bypass | A protected action executing without passing the pipeline | | Fail-open | Any path where a dependency failure results in an allow | | Credential exposure | Material readable through any API, log, audit record or error message | | Agent impersonation | Authenticating as an agent without its private key | | Audit tampering | Altering or removing events without the chain detecting it | | Step-up bypass | Performing a step-up-gated operation without a fresh re-authentication | Each of those corresponds to a guarantee on [the security model](/secure) page. A report that breaks one of those guarantees is a serious report. ## In scope - The gateway and control plane HTTP surfaces - The policy evaluator — determinism, totality, precedence - Delegation resolution and bounds - The credential broker and lease lifecycle - The audit hash chain - Tenant isolation in both layers - Agent assertion verification — signature, nonce, timestamp, audience, generation - The JS and Python SDKs - The CLI, including local secret handling - The console, for anything that is a server-side authorization failure rather than a rendering choice ## Out of scope **Navigation hiding in the console.** Hiding an item you cannot use is a courtesy. The control plane re-authorizes every request, and a hidden item you can still reach by typing the URL is not a vulnerability — the request will be refused. A *request* that succeeds without authorization is in scope. **Fail-closed behaviour reported as a denial of service.** Protected actions being refused when a dependency is unavailable is the design. It is deliberate and tested. [→ Fail closed](/secure/fail-closed) **Development keys in `.env.example`.** They exist so the stack boots and are shared with everyone who has ever cloned the repository. Documented as not secret. **Missing security headers with no demonstrated impact.** Report them with an impact and they become in scope. **Rate limiting thresholds.** Configurable. A bypass of limiting itself is in scope. **Published values.** The gateway audience and the platform public key are published deliberately. Knowing them grants nothing. [→ Sign your own assertion](/build/sign-your-own-assertion) **Out-of-scope product features.** Veefore has no wallet, marketplace, payment processing, settlement or financial ledger. There is nothing there to find. [→ Scope](/scope) **Social engineering, physical access, third-party services.** ## What to expect | | | | --- | --- | | Acknowledgement | Within 2 working days | | Initial assessment | Within 5 working days | | Fix for a high-severity issue | Prioritised above feature work | | Coordinated disclosure | Agreed with you before publication | | Credit | Offered, and declinable | Security releases may bypass the normal feature cadence, and still carry full audit and change documentation — the same step-up, reason and `CRITICAL` auditing as any other authorization change. ## Please do not - Access, modify or delete data belonging to anyone else - Degrade service for other users - Use social engineering against anyone - Attempt physical access - Publish before a coordinated date Test against your own deployment. `npm run dev` plus `npm run seed:demo` gives you a complete environment with realistic data in about three minutes. [→ Self-host Veefore](/install) ## Testing the guarantees yourself The security properties are asserted by suites you can run: ```bash npm run test:security # 49 cases from the threat model npm run test:chaos # 13 cases, fail-closed and recovery npm run smoke:gateway # replay refusal, enforcement, revocation, over real HTTP npm run scope:audit # the out-of-scope features must not exist npm run quality:audit # no auth bypass, no fail-open, no committed secret ``` A case the suites do not cover, which breaks a stated guarantee, is exactly the report we want. ## Related :::cards :::card Threat model | /secure/threat-model Attacker goals and the mechanism that refuses each. ::: :::card The security model | /secure The four guarantees and their limits. ::: :::card Testing strategy | /architecture/testing-strategy What each suite proves. ::: :::card Getting help | /support For anything that is not a vulnerability. ::: :::