The NOVA security team takes the safety, integrity, and operational resilience of our distributed inference infrastructure seriously. We appreciate the responsible disclosure of security vulnerabilities by security researchers, operators, and community members.

Only the current major release branch receives proactive security patches, audit reviews, and dependency vulnerability updates.

If you discover a security vulnerability within NOVA V2, please do NOT open a public issue, discussion, or pull request.

Instead, submit your report confidentially:

1. GitHub Private Security Advisory (Recommended): Navigate to the NOVA V2 Security Advisories page and click "Report a vulnerability".
2. Security Email: Send an encrypted report to security@cardsorting.org.

To facilitate swift triage and resolution:

• A descriptive summary of the vulnerability and its operational impact.
• Step-by-step reproduction instructions, curl commands, or a minimal test case.
• The specific module affected (e.g., src/pipeline.rs, src/balance.rs, src/gateway.rs).
• Any observed memory safety, token starvation, or unauthorized header exposure anomalies.

• Initial Acknowledgment: Within 24 to 48 hours.
• Triage & Severity Assessment: Within 3 business days.
• Coordinated Disclosure: We kindly request that you maintain confidentiality until a patched binary or release tag has been published.

NOVA V2 is built in pure, memory-safe Rust (#![forbid(unsafe_code)] across all core routing paths) and implements several architectural defenses:

All client incoming Bearer tokens are validated using constant-time comparison algorithms to eliminate side-channel and timing attacks against the inference gateway.

Public API callers (/v1/*) are strictly separated from upstream cluster topologies:

• Internal shard identifiers, pool configurations, and private upstream endpoints are completely stripped before returning responses.
• Upstream socket errors and stack traces are normalized to clean RFC 7807 / OpenAI error JSON structures.

• Bounded TTL Retention: Job records and SSE event streams are strictly pruned after a configurable retention window (default 3,600s), preventing memory exhaustion attacks via abandoned client streams.
• Continuous Token-Bucket Governor: Hardware-grade rate limiting guarantees no single tenant or shard exhausts upstream quotas.
• Atomic Shard Leasing: Shards cannot be double-allocated or starved under concurrent Tokio tasks.