How we secure and test the platform
How customers are kept apart, the security tests that run every week and after every deploy, how builds are signed and checked before they run, and the service objectives we monitor.
This page is about Sovaria's side of security: what we do so that one customer can never reach another's data, and how we check that it keeps holding. Your side — who may read and change what in your project — is How access is decided.
#How customers are kept apart
- Each project's data lives in its own Postgres database.
- Which organization and project a request acts on comes from its session or key, checked on the server. Naming another project in a header, path or body is refused.
- Functions run in a gVisor sandbox with no route to Sovaria's internal network; outbound calls go only where you allow them.
- Secrets are encrypted at rest (AES-GCM); storage can use your own key (Your own encryption key (BYOK)).
- Each Sovaria service has its own database login and only the permissions it needs.
#What we test, and how often
| Test | When | What it proves |
|---|---|---|
| Cross-tenant isolation matrix | Weekly, and a read-only part after every deploy | One account's session is refused on another account's SQL, documents, storage, functions, realtime and knowledge bases, whichever way it names them. Each check first confirms both accounts can use their own data, so a refusal really is isolation. |
| Penetration-test suite | Weekly | Transport security (TLS 1.2+, HSTS), forged and expired tokens, injection, path traversal, SSRF, rate limits, prompt injection, database escape attempts, malformed input, and that error messages never reveal internals. |
| OWASP ZAP baseline | Weekly | A passive scan of the console, the docs and the API for common web weaknesses. |
| Dependency and image scanning | Every build | No known fixable high or critical vulnerability in the code we ship or its container images. |
| Function sandbox checks | Every deploy of the function runtime | Functions can't open raw sockets, reach cloud metadata or start processes they shouldn't. |
All of these are non-destructive and run against production with test accounts. Results go to the Sovaria team by email; any failure is handled as an incident.
#Signed builds
- Production images are built by CI from reviewed code on our main branch, never on a developer machine.
- Each image is scanned, ships with a software bill of materials (SBOM) and build provenance, and is signed with Sigstore (cosign, keyless).
- Before a new version starts, the server checks the signature came from our build workflow and runs exactly the signed image. An image that fails the check is not deployed.
#Monitoring and service objectives
| Objective | Target |
|---|---|
| Response time | 99 % of API requests answered within 1 second |
| Errors | Fewer than 0.1 % of API requests fail with a server error |
Latency per route, error rates, and CPU and memory per service are watched continuously. If the slowest 1 % of requests take longer than a second for ten minutes, the team is alerted. Current availability and past incidents are on the status page.
#Found something?
Please tell us: Reporting a vulnerability.