How Secorvia handles access to your cloud, and what it keeps

How the read-only connection works

Secorvia never asks for write access to your infrastructure. You create a read-only, least-privilege credential in your own cloud account and give Secorvia its details. Secorvia uses it to read configuration and metadata, and a read-only credential cannot change your environment.

The credential type depends on the provider. On AWS you can let Secorvia assume an IAM role, which is the recommended route and uses an external ID that you control in the role's trust relationship, or you can supply an IAM access key. Azure uses a service principal. Google Cloud uses a service account key. DigitalOcean uses an API token. Cloud posture scanning is agentless, so nothing is installed in your accounts. Collectors exist only for the deeper workload features: one for Kubernetes cluster posture and a host agent for runtime security. You can leave both out and still run the rest.

Because you create the credential in your own account, you can also narrow it, rotate it or remove it whenever you like.

How access is scoped

The permissions are the ones needed to read configuration and metadata so the security graph can be built, and no more. Secorvia does not ask for the ability to create, change or delete anything.

Two things are worth knowing. First, you are the one who writes the policy or role, so what Secorvia can see is bounded by what you grant. A narrower grant means fewer resources appear and some findings cannot be produced. The guides say so directly, for example that a scan which cannot read resources should be checked against the service account's permissions, and that identity analysis needs a connection with permissions sufficient for identity inventory. Second, the connection guides describe the fields and the checks, and they do not hand you a fixed policy to paste. If your security team wants the exact permission list for a provider before approving a connection, email [email protected].

What is stored

• Configuration and metadata about the resources, identities and relationships your read-only credential can see. This is the data the security graph is built from.
• Your connection secrets, encrypted before they are stored. The form never shows a secret again after you save it. Webhook signing secrets and API keys are shown once, and Secorvia cannot reveal them afterward.
• Findings and their history, including who changed a finding's state, who commented and when. Audit log retention depends on the plan: 30 days on Free, 90 days on Starter and a year on Growth. Enterprise has no fixed limit.
• Account details you submit, such as your name, work email, company name and size, and the cloud providers you use. The free plan does not ask for a credit card.
• Standard technical information, meaning IP address, browser type and pages visited, used for rate limiting, abuse prevention and basic analytics.
• Package lists for container images. When a self-managed host scans its own images, the agent uploads the package list and the image stays on the host.

Data is encrypted in transit with TLS and at rest. Access to customer data is limited to the people who need it to run or support the service, and access to customer environments is audit logged.

What is not stored

Secorvia does not access the contents of your databases, your object storage or your application data. It reads how things are configured and connected, not what is inside them. It does not hold write credentials for your environment, because it never asks for them.

It also does not sell your personal information, and it does not use customer data to train unrelated models or for anything outside providing the service. Those commitments are written into the privacy policy and the data processing addendum, which also covers sub-processors, data subject requests and international transfers. A countersigned DPA is available to Enterprise customers.

Who can see what inside Secorvia

Every organization is isolated from the others. Inside an organization, members have one of four roles: Owner, Admin, Analyst or Read-Only. Invitations let people set their own password through a link. Changes made through an API key are attributed to the service identity that key belongs to, so the activity trail shows which integration acted.

Reporting a vulnerability

If you find a security problem in the product or on this site, please report it privately to [email protected] instead of through a public issue or a social media post. Our security.txt has the same contact and an expiry date.

Our open source tool frontdoor is separate from the platform. It is a read-only command line program that needs no account, and its source is on GitHub under the Apache 2.0 licence.