SecurityVault
Book a demo
Company/Security

Built secure.
Operated closed.

What we enforce in code, what we gate in CI and what we run in production. Written for the team that will review us.

Book a demo View the platform
RS256
Session tokens
15-minute access tokens with a key id; refresh in an httpOnly cookie.
RLS
Tenant isolation
Row-level policies on every tenant table, asserted in CI.
0
Credentials in a scan pod
No database, cache, vault or storage credentials, ever.
Cosign
Signed images
Rootless builds, private registry mirror, admission webhook.
Security of the product

Built closed, then opened.

The controls below are enforced by code and CI, and each one is described in more depth on the architecture page.

Scanner isolation
Split container, split secret, authenticated callback. A scanner with remote code execution reaches the repository it was given and nothing else. The adapter refuses to start if a storage credential appears in its environment.
Tenant isolation
Every session binds app.current_org_id; single-resource reads filter on the organisation in SQL; a CI gate rejects handlers that trust a caller-supplied organisation. Platform-admin routes use a separate, never-tenant-bound session.
Governance writes
Finding status and disposition are governance fields: an ORM guard and a database trigger refuse writes without a bound human principal. AI has no principal.
Input validation
Every POST and PUT body is a strict model — unknown fields rejected, lengths capped. Path-like inputs from SARIF, Burp and Nmap imports are sanitised before use.
Cryptography
RS256 sessions, Fernet-encrypted stored credentials, Ed25519-signed control decisions, HMAC-chained audit log, HMAC-signed scanner and ticketing callbacks with replay nonces, Cosign-signed images, TLS at the edge and internal mTLS from a platform PKI.
Frontend
Strict content-security policy; Markdown rendering with HTML skipped and URL allow-lists; SSO redirects validated against an origin allow-list; rel="noopener noreferrer" enforced by a lint gate.
AI
Local-model triage and natural-language filters are advisory, one-shot and audited. Model output is validated against a strict schema and rejected on any failure; the model is never re-prompted.
How we operate

Gated on every merge.
Observed in production.

01

Merge gates

Dozens of architectural-invariant checks run on every merge request: banned patterns, tenant-parameter authority, structured-logging floor, Cilium policy shape, bundle budgets, route manifest, credential-rotation versions and accessibility on redesigned routes. No bypass flags.

02

Tests in containers

Unit, worker, property and integration suites run in Docker; Playwright end-to-end runs against the production build; schema proofs run on fresh and upgraded databases.

03

Self-scan

Our own repository and images are scanned on the production pipeline. Detector defects found that way are fixed in the detector, not suppressed.

04

Supply chain

Rootless image builds, Cosign signatures, a private registry mirror for upstream images, pinned dependencies with automated update proposals through the same gates.

05

Secrets

Platform secrets live in Vault; customer credentials are encrypted at rest with a rotation API. A CI gate rejects hard-coded key literals.

06

Observability

Structured logs, Prometheus metrics and OpenTelemetry traces across planes and workers; central log store; alerting on scanner-band anomalies, callback rejections and evaluator failures.

Where it runs

Infrastructure we operate.

Location
Kubernetes on hardware owned and operated by SecurityVault Systems Private Limited in India. Compute, databases, object storage, analytics, observability, secrets and CI are first-party; the only third parties are at the network edge (see subprocessors).
Network
Cilium network policies scoped by label; a CI gate refuses an empty selector because it would put every pod into default-deny at once. Edge TLS and WAF at the gateway.
Data
PostgreSQL with streaming replication and point-in-time recovery from WAL; Redis; ClickHouse; S3-compatible object storage. Backups are tested by restore, not by existence.
Power
Uninterruptible power for compute and network with monitored battery state and alerting.
Your environment
Run the scan band in your own cluster, or run the whole platform self-hosted. Same charts, same images, same boundaries.
Vulnerability disclosure

Found something?
We want to know.

Contact
security@securityvault.io. Our security.txt is published.
Policy
Scope, safe-harbour terms and what to include are on the disclosure page. We acknowledge within two business days.
What we ask
Do not access data that is not yours, do not degrade service, and give us reasonable time to fix before publishing.
Questions security teams ask

Straight answers.

Are you SOC 2 or ISO 27001 certified?
No, not today. We publish our architecture and answer CAIQ, SIG and custom questionnaires on request. The platform maps your controls to those frameworks; it does not attest to ours.
Do you store our source code?
Scanners clone the repository inside the scan band for the duration of the scan and the Job is garbage-collected afterwards. The platform stores findings, typed evidence such as code spans and dataflow paths, SBOM components and hashes — not the repository. Run the scan band in your own cluster if code must never leave your network.
Can your staff see our data?
Platform administration uses a separate, platform-scoped session that can never bind a tenant; access is audited. Self-hosted deployments give us no access at all.
What happens if a scanner is compromised?
It reaches the target it was given and nothing else. It cannot reach the database, the cache, Vault, object storage or another tenant. Its result is still verified by token and signature before it is parsed.
Ask us anything

Talk to a SecurityVault engineer.

Security reviews start with the architecture and the code, not a questionnaire.

Book a security review Read the architecture