Skip to content

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.

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.

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

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.

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.

  • Threat model: Available in GitLab repository at docs/security/threat-model.md
  • Compliance map
  • Telemetry privacy tiering: Available in GitLab repository at docs/security/telemetry-tiering.md

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

  • Memory-safe language: All backend services in Rust; unsafe blocks require security review
  • Pre-commit hooks: Gitleaks for secret scanning, format/lint checks
  • CI security gates:
    • Gitleaks (secrets)
    • Checkov (infrastructure-as-code)
    • Semgrep (console TypeScript/Next.js)
    • Cargo deny (license/advisory/source policy)
    • Grype (image/SBOM scanning)
  • License allowlist: Apache-2.0-compatible licenses only; AGPL/SSPL/BUSL forbidden
  • Vulnerability scanning: cargo deny checks RustSec advisories; Grype scans images and SBOMs
  • Update policy: High/Critical vulnerabilities trigger immediate review
  • SBOM: CycloneDX SBOMs generated for all release images with cargo-auditable builds
  • Required reviewers: Security-sensitive paths (gateway, auth, policy, audit, crypto, classification, redaction, escrow) require 2 reviewers including a security reviewer
  • CODEOWNERS: Enforced for security-sensitive directories
  • ADR requirement: Architectural changes affecting security must include or reference an ADR
  • Image signing: Release images signed with cosign; public key checked in at deploy/pipeline/signing/cosign.pub
  • Provenance: SLSA-style provenance attestations link images to source commit and CI job
  • Verification: Consumer verification commands published with release notes
  • Evidence: Release job produces dist/pipeline/release/evidence.json and report.pdf
  • FIPS mode: Optional FIPS 140-3 build with mandatory boot self-check
  • TLS: rustls with aws-lc-rs provider (no OpenSSL in standard builds)
  • Audit integrity: Tamper-evident Merkle chains with ed25519 signatures anchored to WORM storage
  • Secrets: Never logged; provider keys encrypted at rest; API keys stored as argon2 hashes
  • Tenant isolation: Every query scoped by tenant/org/project; cross-tenant lookups fail as not-found

Nexus is designed for regulated environments:

  • NIST SP 800-53: Compliance Map documents control implementations
  • FIPS 140-3: Optional build feature for validated crypto module
  • Audit requirements: Cryptographically verifiable audit trail with offline verification
  • Air-gap deployment: Full functionality without internet access; offline verification tools

Security advisories are published through:

  • GitLab Security Advisories
  • Release notes with CVE references
  • Deployment upgrade guides
  • Source: Tagged releases on GitLab
  • Images: Updated container images with vulnerability fixes
  • Verification: New signatures and SBOMs with each patched release

Nexus follows coordinated disclosure:

  1. Private report received
  2. Acknowledge within 48 hours
  3. Investigate and develop fix
  4. Patch prepared and tested
  5. Coordinate public disclosure with reporter (typically 90 days)
  6. Release patch with security advisory
  7. Credit reporter in advisory (if desired)

The following changes require security team review:

  • New unsafe blocks in Rust
  • Changes to authentication/authorization logic
  • Policy engine modifications
  • Audit event schema changes
  • Cryptographic primitive changes
  • Cross-tenant data access paths
  • New external dependencies in runtime artifacts
  • License allowlist modifications
  • TLS/crypto provider changes
  • Security email: Documented in SECURITY.md in GitLab repository
  • PGP key: Available on request
  • Response time: 48 hours for acknowledgment, 5 business days for initial assessment