Security — MPP Registry

Responsible Disclosure

If you discover a security vulnerability in the MPP Registry or any Q2X-published package, please report it to us at support@quantum2x.com.

Please include:

A description of the vulnerability and its potential impact
Steps to reproduce (proof of concept if possible)
Your contact details for follow-up

We will acknowledge receipt within 2 business days and aim to provide an initial assessment within 5 business days. We ask that you do not publicly disclose the vulnerability until we have had a reasonable opportunity to investigate and address it (typically 90 days).

We do not currently operate a formal bug bounty programme, but we will acknowledge responsible disclosures in our changelog (if you wish) and may offer recognition at our discretion.

Please do not attempt to access data belonging to other users, perform denial-of-service attacks, or test security controls in production without written permission.

Infrastructure Security

Encryption

In transit: TLS 1.2+ for all connections. TLS 1.0 and 1.1 are disabled.
At rest: AES-256 encryption for all data at the storage layer (Supabase / AWS).
Package signing: Ed25519 (local) / ECDSA SHA-256 (AWS KMS) for all published packages. Signing keys for production are stored in AWS KMS — the private key material never exists outside the HSM.

Access Control

Production system access is limited to named Q2X engineers with MFA enabled.
Database access uses row-level security (RLS) to enforce tenant isolation at the query level, independent of application code.
API tokens are hashed before storage. We cannot recover a lost token — you must regenerate it.
Service accounts use the principle of least privilege.

Multi-Tenant Isolation

All customer data (packages, audit logs, usage records) is tagged with a \`tenant_id\`. Postgres RLS policies enforce that queries can only access data belonging to the authenticated tenant. This isolation operates at the database level, independent of application-layer filtering.

Application Security

Package Integrity

Every published package version has an immutable SHA-256 content hash stored in the registry.
The hash is signed with the publisher's key at publication time.
The runtime recomputes the hash on every load and rejects the package if it does not match.
Registry records are append-only — a Postgres trigger prevents UPDATE and DELETE on package version records.

Audit Log Integrity

Audit log entries are append-only at the database level (Postgres trigger).
Application code cannot modify or delete audit log entries.
Entries are periodically checkpointed with a Merkle hash to detect tampering.

WASM Sandbox

Tools run inside a Wasmtime WASM sandbox with WASI 0.2 (Component Model).
The sandbox intercepts and enforces the capability manifest at the system call boundary.
On Linux, the sandbox runs under a seccomp filter for an additional isolation layer.
Sandbox violations terminate the process immediately and are logged with outcome \`blocked\`.

HTTP Security Headers

All responses from the MPP Registry include:

Content-Security-Policy — restrictive policy allowing only necessary sources
X-Frame-Options: DENY — clickjacking protection
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy — disables camera, microphone, geolocation
X-Content-Type-Options: nosniff

Incident Response

In the event of a security incident affecting customer data, we will notify affected customers without undue delay (and within 72 hours of confirming a personal data breach, as required by UK GDPR). Notifications will include: the nature of the incident, data affected, actions taken, and recommended next steps for customers.

Dependency Management

We perform automated dependency audits using \`npm audit\` and Dependabot alerts. Critical and high severity vulnerabilities in dependencies are addressed within 14 days of disclosure. We pin major versions of all direct dependencies.

Contact

Security: support@quantum2x.com
General enquiries: support@quantum2x.com