How Secorvia works, from first connection to first fix

1. Connect an account

Sign in at app.secorvia.com, open Cloud Accounts and choose Add Cloud Account. Give it a name your team will recognise, such as Production, and pick the authentication method for the provider. AWS takes an assumed role or an access key, Azure a service principal, Google Cloud a service account key and DigitalOcean an API token.

The credential you hand over is read-only and least-privilege, and you decide its scope. Save the form and the account detail page shows its connection status and when it was last validated. If the connection fails, the error on the form is the quickest way to tell whether the problem is the credential, an identifier or a missing permission. The connection guide has a page for each provider, and each one is a two minute read. Skim the one for your provider before you create the credential, so you know which values to have ready.

2. Wait for the first scan

Connecting an account starts the first scan by itself. Open Scan History to see whether it is pending, running, completed, failed or cancelled. Treat those states as different things: a connected account is not a finished assessment, and an empty findings list while a scan is still running does not mean the account is clean.

When the scan completes, the account page links to its inventory and findings, already filtered to that account. The dashboard also shows how many accounts are connected, how old the last scan is, how many resources were monitored and whether any scans recently failed. Read those before you read the finding counts. They tell you how much of the environment the numbers describe. See checking scan history.

3. How findings are ranked

A list of findings sorted by severity is easy to produce and hard to act on. Secorvia adds the part that list leaves out, which is whether anything can reach the resource.

After a scan, the collected resources, identities and relationships are built into a security graph. That build is its own step, separate from the scan. Running an analysis on the graph produces ranked attack paths. Each one shows its severity, score, target, stage, the number of steps and a breakpoint when one is shown. Beside it you can read CVSS, EPSS and CISA KEV signals for the same resource, and run a blast radius analysis to see what else could be reached if that resource were compromised.

Two cautions. A path models what is possible and is not evidence of an attack. And a graph is a snapshot, so a resource added after the last build will not be in it until you rebuild. The graph and attack paths come with the Starter plan and above. On the Free plan you get the findings list and vulnerability intelligence, without graph ranking. The attack paths versus CVSS article explains why the two orderings differ.

4. What to fix first

Start with the dashboard. Critical Findings and High Findings are counted separately, and next to them are Internet Exposure, which counts findings on resources that can be reached from outside, and Identity Risk, which leads into the identity analysis. Reachability changes how much a severity score means, so a finding with an exposure behind it comes before one without.

Then open the finding. It carries the reason it matters, the affected resource, the evidence from the last scan, any compliance impact and the remediation steps. Assign an owner, mark it as investigating when work starts and leave a comment so the hand-off is visible on its activity timeline.

Fix it in your own environment, then scan the account again. A finding your team marks as resolved shows as awaiting verification for as long as the latest scan still detects the problem, and becomes verified only once a scan confirms it is gone. Suppressing a finding or accepting its risk changes the queue, and the finding still counts toward risk and compliance. For a path you fixed, rebuild the graph and analyse again to confirm the route is closed. The triage guide covers the whole workflow.