How CVERiskPilot is built and protected
This page describes the platform as it runs today: where it is hosted, which AI models see your findings and where they run, how data is protected in transit and at rest, who can access what, how the audit trail is signed, and which third parties process customer data. It is written for security reviewers, enterprise buyers and investors, and every statement on it is meant to be verifiable.CVERiskPilot is a controlled alpha. A signed DPA, subprocessor list and security measures exhibit are available for enterprise contracts.
Where the platform runs
Everything runs inside one Google Cloud project in the United States.
- Application
- A Next.js 15 application and a separate worker service run on Google Cloud Run in us-central1. The worker processes background jobs and accepts no external traffic.
- Database
- PostgreSQL 16 on Cloud SQL, reached over private IP only. There is no public database endpoint.
- Cache
- Redis on Cloud Memorystore, inside the same VPC.
- Object storage
- Scan artifacts, exports and backups are stored in Google Cloud Storage.
- Background jobs
- Cloud Tasks queues drive scan processing and other asynchronous work.
- Delivery
- Deployments go through Cloud Build with an approval gate before production. Every change runs lint, type-check, tests, Semgrep, Gitleaks, a production dependency audit and our own scanner in CI. Database migrations are applied on every rollout.
- Hosting location
- United States (Google Cloud, us-central1).
Which models see your findings
Four model tiers, listed by where they run and what leaves the project.
| Tier | Where it runs | Data path | Role |
|---|---|---|---|
| Corvus v2.1 | Our private triage model, hosted as a private Cloud Run service inside the same Google Cloud project. Only the platform's own services can invoke it. | Finding data never leaves the project for this tier. | Private model tier |
| Gemini | Google Vertex AI, in the same Google Cloud project and region. | Processed by Vertex AI within the project. | Hosted model tier |
| Anthropic Claude | Anthropic API (United States). | Request context is sent over TLS for the duration of the request. | Escalation tier for high-severity cases |
| NVIDIA-hosted models | NVIDIA-hosted inference (United States). | Request context is sent over TLS for the duration of the request. | Escalation tier for high-severity cases |
Rules that apply to every tier
- Customer data is not used to train models.
- A provider refusal is never retried and never re-sent to another provider.
- A provider outage fails closed with a clear error rather than falling back silently.
- A daily spend ceiling applies to external AI providers.
The published triage benchmark, with reproducible code, is at /trust/ai-quality.
How data is protected
- In transit
- TLS everywhere, with HTTP Strict Transport Security and a content security policy on every response.
- At rest
- Integration credentials and other secrets are encrypted with AES-256-GCM. Customer-managed keys in Cloud KMS are available on Enterprise.
- Platform secrets
- Held in Google Secret Manager and bound to services at deploy time; never stored in the repository.
- Tenant isolation
- Every query is scoped to the organization. Static isolation tests run in CI and fail the build if a page or route drops the scope. MSSP workspaces add client-level scoping on top.
Who can reach what
- Sign-in
- Google, GitHub and Microsoft. SAML and OIDC single sign-on on Enterprise.
- Multi-factor
- TOTP authenticator apps and passkeys.
- Network and sessions
- Per-organization IP allowlists. Sessions can be revoked by the user or an administrator.
- Roles
- Eleven roles, including a read-only Auditor role and client-scoped roles for MSSP workspaces. API keys carry explicit scopes and can be revoked at any time.
A signed record of every action
- Vault Protocol
- Every audit record is linked into an Ed25519-signed hash chain. New records are signed every ten minutes and the full chain is verified daily.
- For auditors
- The audit log is exportable with its signatures so an auditor can verify it independently.
- Review status
- The implementation is unit-tested and has not yet had an external cryptographic review.
Backups, alerting and status
- Backups
- Daily automated database backups with seven days of point-in-time recovery.
- Monitoring
- Error tracking, uptime checks, and alerting on error rate, latency, health-check failures and AI provider outages.
- Status page
- Public status pagePlanned
What the product maps to, and where we stand ourselves
Frameworks the product maps findings to
Thirteen frameworks. Every finding shows which controls it threatens and every remediation shows how posture improves.
CVERiskPilot's own posture
- SOC 2
- Audit not yet started. Readiness is tracked with our own SOC 2 readiness tool.Not started
- Penetration test
- Third-party test scheduled after the controlled alpha.Planned
- Vulnerability disclosure
- Published at /security-policy, with security.txt per RFC 9116.
Third parties that process customer data
This list is maintained on this page. Changes are announced in the changelog.
| Subprocessor | Purpose | Location |
|---|---|---|
| Google Cloud Platform | Hosting, storage, Vertex AI | United States |
| Anthropic PBC | AI inference (escalation tier) | United States |
| NVIDIA | AI inference (escalation tier) | United States |
| Stripe | Billing | United States |
| Resend | Transactional email | United States |
| Sentry | Error monitoring | United States |
| WorkOS | Enterprise SSO | United States |
| Cloudflare | DNS | United States |
Changes are recorded in the changelog.
Report a security concern
Send security concerns to security@cveriskpilot.com. Our disclosure policy, response commitments and safe-harbor terms are at /security-policy.
