Responsible disclosure

How to report a vulnerability, what is in scope, and what to expect back.

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

Summaryone or two sentencesrequired: What an attacker can do. Lead with the impact, not the mechanism.
Affected componentstringrequired: Gateway, control plane, console, SDK, CLI, or a specific package. Include the version from GET /v1/meta/info or veefore --version.
Reproductionstepsrequired: The smallest sequence that demonstrates it. A curl command is ideal.
Impactdescriptionrequired: What is reachable that should not be: another tenant's data, an authority escalation, a credential, a bypassed refusal, an audit gap.
Mitigationoptional: Anything a deployment can do today, before a fix ships.

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 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

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

Out-of-scope product features. Veefore has no wallet, marketplace, payment processing, settlement or financial ledger. There is nothing there to find. → 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

#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.

Threat model

Attacker goals and the mechanism that refuses each.

The security model

The four guarantees and their limits.

Testing strategy

What each suite proves.

Getting help

For anything that is not a vulnerability.

Responsible disclosure

#How to report

#What to include

#What we consider high severity

#In scope

#Out of scope

#What to expect

#Please do not

#Testing the guarantees yourself

#Related