Security Policy

nexus handles tenant credentials, money movement (pass-through billing), and a tamper-evident audit chain. We take security reports seriously and ask researchers to disclose responsibly.

Reporting a vulnerability

Do not open a public issue, merge request, or discussion for a suspected vulnerability.

Report privately through the repository’s private security advisory flow:

1. Open a confidential issue on the project (GitLab: New issue → check This issue is confidential). Confidential issues are visible only to reporters and project members with at least the Reporter role, and are the canonical channel for the hosted project.
2. Self-hosted deployments should publish their own monitored security address and, optionally, an encryption key, and route reports there. The hosted project does not expose a shared inbox; the confidential-issue flow above is the supported path.

Please include:

• A description of the issue and its impact.
• The affected component or route (for example services/gateway, /v1/chat/completions, the audit verifier).
• Reproduction steps or a proof of concept.
• Any known mitigations or configuration that affects exploitability.

Do not include live tenant data, real provider keys, or other secrets in a report.

Our commitment

• Acknowledgement: within 2 business days of receiving your report.
• Triage and severity assessment: within 5 business days, using CVSS-style impact reasoning.
• Status updates: at least every 7 days while a report is open.
• Fix targets (from triage): Critical within 7 days, High within 30 days, Medium/Low on a scheduled release.
• Coordinated disclosure: we will agree on a disclosure timeline with you and credit you in the advisory unless you prefer to remain anonymous.

We will not pursue legal action against researchers who follow this policy, act in good faith, avoid privacy violations and service disruption, and give us reasonable time to remediate before public disclosure.

Scope

In scope:

• The gateway edge and provider routing (services/gateway).
• Authentication, authorization, and service-to-service auth (services/auth, service tokens, developer access tokens).
• The policy decision point and classification/redaction handling (services/policy).
• The tamper-evident audit pipeline and verifier (services/audit, the audit CLI).
• Credential storage and KMS wrapping (provider keys, platform keys).
• Pass-through billing, the workspace wallet, and escrow accounting.
• Any cryptography, TLS, classification, redaction, or escrow code path.

Out of scope:

• Findings that require a malicious operator who already controls the deployment.
• Vulnerabilities in third-party providers or upstream model APIs.
• Denial of service from unrealistic traffic volumes against a local dev stack.
• Reports generated solely by automated scanners without a demonstrated, reproducible impact.

Supported versions

nexus is pre-1.0 (0.y.z). Security fixes target the latest tagged release on main. Older 0.y tags do not receive backports while we are pre-1.0; upgrade to the latest release to receive fixes.

Handling and hardening references

• Threat model: docs/security/threat-model.md
• Compliance map: docs/security/compliance-map.md
• Telemetry privacy tiering: docs/security/telemetry-tiering.md

Security-sensitive paths declare the required domain and security reviewers in .gitlab/CODEOWNERS and CONTRIBUTING.md. Protected-branch settings should require code-owner approval so those declarations block merges without the right reviewers.