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
Section titled “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:
- 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.
- 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
Section titled “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.
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
Section titled “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
Section titled “Handling and Hardening References”- 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.
Security Practices
Section titled “Security Practices”Development
Section titled “Development”- Memory-safe language: All backend services in Rust;
unsafeblocks 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)
Dependencies
Section titled “Dependencies”- License allowlist: Apache-2.0-compatible licenses only; AGPL/SSPL/BUSL forbidden
- Vulnerability scanning:
cargo denychecks 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
Code Review
Section titled “Code Review”- 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
Release Process
Section titled “Release Process”- 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.jsonandreport.pdf
Runtime Security
Section titled “Runtime Security”- 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
Compliance
Section titled “Compliance”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 Updates
Section titled “Security Updates”Notification
Section titled “Notification”Security advisories are published through:
- GitLab Security Advisories
- Release notes with CVE references
- Deployment upgrade guides
Patch Distribution
Section titled “Patch Distribution”- Source: Tagged releases on GitLab
- Images: Updated container images with vulnerability fixes
- Verification: New signatures and SBOMs with each patched release
Responsible Disclosure
Section titled “Responsible Disclosure”Nexus follows coordinated disclosure:
- Private report received
- Acknowledge within 48 hours
- Investigate and develop fix
- Patch prepared and tested
- Coordinate public disclosure with reporter (typically 90 days)
- Release patch with security advisory
- Credit reporter in advisory (if desired)
Security Review Triggers
Section titled “Security Review Triggers”The following changes require security team review:
- New
unsafeblocks 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
Contact
Section titled “Contact”- Security email: Documented in
SECURITY.mdin GitLab repository - PGP key: Available on request
- Response time: 48 hours for acknowledgment, 5 business days for initial assessment
More Information
Section titled “More Information”- Security Overview - Security architecture and threat model
- Compliance Map - NIST SP 800-53 control mappings
- CI/CD Pipeline - Release and security scanning process
- Apache 2.0 license policy and third-party license allowlist - Dependency policy
