How Orvanta secures itself
A security product has to hold itself to a higher standard than the code it reviews. Here's how we do that.
Your code
Source you scan is analyzed to produce findings and is stored so you can revisit a scan. It is never used to train models and never shared across organizations. Analysis runs in an isolated server context with no outbound access to your other systems. You can delete a project and its scans at any time.
Isolation & sandboxing
Uploaded code is treated as untrusted data, never executed. The static analysis engine reads files as text and runs deterministic rules — it does not import, evaluate, or run your code. Dependency analysis compares manifest versions against an advisory database offline.
Authentication
Passwords are hashed with scrypt and a per-user salt; we never store or log plaintext. Sessions use signed, HttpOnly, SameSite cookies scoped to Orvanta. Every API route re-verifies the session and scopes each query to the authenticated user — there is no cross-tenant read path.
API keys & secrets
Provider credentials (such as the OpenAI key that powers reasoning) live only in server-side environment variables and are never sent to the browser. Secrets we detect in your code are shown to you truncated and are never transmitted anywhere else.
Platform hardening
- Strict security headers (nosniff, frame-deny, referrer, permissions policy) on every response.
- Zod-validated inputs on all mutating endpoints; size and file-count caps on ingestion.
- Rate limiting and per-plan quotas on scan and AI endpoints.
- Encrypted transport (TLS) and encryption at rest through our database provider.
Responsible disclosure
Found something? Email security@orvanta.dev. We acknowledge reports within one business day and credit researchers who report in good faith.