Merge gates
Automated architectural and security checks run on every change — tenant isolation, input validation, secret handling, accessibility and more. No bypass flags.
Built secure.
Operated closed.
The principles we enforce in code, gate on every change and hold to in production. Written for the security team that will review us.
SSO
Short-lived sessions
Signed, short-lived access tokens with key rotation; MFA and your IdP.
Every
Query tenant-scoped
Every query is scoped to your tenant, with automated isolation checks.
0
Platform credentials in a scanner
Scanners never hold platform secrets or data access.
Signed
Software supply chain
Rootless builds, signed images, verified before they run.
Security of the product
How is the product secured?
The controls below are enforced by code and automated gates. The principles are on the architecture page; detailed design is available under NDA.
Scanner isolation
Scanners are treated as hostile. Each runs isolated and short-lived, reaches only the target it was given, and can return results only through an authenticated, signed channel.
Tenant isolation
Every request is bound to the authenticated organisation before it touches data, and every query is scoped to that tenant, with automated isolation checks. The tenant is never taken from a value a caller can set.
Governance writes
False-positive and accepted-risk dispositions require an authorised person and a reason. AI cannot make those decisions. Separate lifecycle automation can update eligible findings after a successful re-scan while preserving human-held decisions.
Input validation
Every request body is strictly validated — unknown fields rejected, lengths capped. Imported files are sanitised before use.
Cryptography
Industry-standard algorithms throughout: signed sessions, encrypted stored credentials, signed control decisions, a hash-chained audit log, signed and replay-protected webhooks and signed images. Data is encrypted in transit with TLS, both over public networks and between our internal services.
Frontend
Strict content-security policy, safe rendering of user content, and validated sign-in redirects.
AI
AI triage and natural-language filters run on models hosted in our own infrastructure, are advisory and are audited. Model output is strictly validated and rejected on any failure; customer content is never sent to a third-party AI provider.
How we operate
How do we build and run it?
01
02
Tests in containers
Unit, property, integration and end-to-end suites run in isolated containers against the production build; schema proofs run on fresh and upgraded databases.
03
Self-scan
Our own code 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, signed images, a private mirror for upstream images, and pinned dependencies with automated updates through the same gates.
05
Secrets
Platform secrets live in a managed secrets store; customer credentials are encrypted at rest and rotatable. Automated checks reject hard-coded secrets.
06
Observability
Structured logs, metrics and traces across the platform, with alerting on security anomalies and policy-evaluation failures.
Where it runs
Where does it run?
Location
Launching in India and operated by SecurityVault Systems Private Limited. US and EU regions are planned in response to customer demand and are not yet available. Third parties are limited to those listed on our subprocessors page.
Network
Least-privilege network policy between components; TLS and a web application firewall at the edge.
Data
Data is encrypted in transit with TLS, both over public networks and between our internal services, and encrypted at rest; replicated, with point-in-time recovery. Backups are tested by restore, not by existence.
Your environment
Run the whole platform self-hosted, on request — same images, same boundaries. Scanning in your own cluster with our hosted platform is in development. Discuss rollout with our team.
Vulnerability disclosure
How do you report a vulnerability?
Contact
security@securityvault.io. Our security.txt is published.
Policy
Scope, good-faith research terms and what to include are in the disclosure policy. We acknowledge reports 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
What do security reviewers ask?
- Can you answer our security questionnaire?
- Yes. We answer CAIQ, SIG and custom questionnaires on request, and share detailed architecture under NDA.
- Do you store our source code?
- Scanners clone the repository in an isolated environment for the duration of the scan, which is destroyed afterwards. The platform stores findings, typed evidence such as code spans and dataflow paths, SBOM components and hashes — not the repository. If code must never leave your network, run the whole platform self-hosted, on request.
- What happens if a scanner is compromised?
- It reaches the target it was given and nothing else. It cannot reach platform data, platform secrets or another tenant, and its result is still verified before it is parsed.
- Do you hold SOC 2 or ISO 27001 certification?
- Not today; independent audits are planned. We answer questionnaires from evidence and share our detailed architecture under NDA. See the trust centre.
- How will we hear about an incident?
- Customers are notified directly. Personal-data breaches are notified without undue delay and within 72 hours of confirmation, as set out in the DPA. Live service health is on the status page.
- Which third parties process our data?
- Two: one at the network edge and one for transactional email. Both are named, with purpose and region, on the subprocessor list.
Ask us anything
Talk to a SecurityVault engineer.
Discuss your security requirements, review the published architecture and request supporting evidence under NDA.