Running an Inspection¶

An inspection run scans one or more cloud accounts and/or code repositories, maps findings to compliance frameworks, scores each Well-Architected pillar, and generates reports - all automatically.

Before you start¶

Make sure you have the credentials ready for each target you want to scan:

• AWS - an IAM role in the target account → AWS setup guide
• Azure - a service principal with Reader + Security Reader roles → Azure setup guide
• GCP - a service account JSON key → GCP setup guide
• GitHub / GitLab - a read-only personal access token → Repository setup guide
• Container images - registry credentials if scanning private images → Container registry setup
• Kubernetes clusters - a kubeconfig (raw or base64-encoded) or in-cluster ServiceAccount → Kubernetes scanner

Start a new run¶

Click Runs in the sidebar, then New Inspection (or navigate to /runs/new). Work through the three wizard steps:

Step 1 - Targets¶

Tick the cloud accounts, repositories, clusters, images and web applications you want to scan.

Every target is a saved connection, listed as a row with a checkbox, the way it is listed under Settings > Connections. Ticking a cloud account also ticks everything saved under it, so the clusters and registries a discovery found are not added one at a time. Options on a row sets fields for this scan only. Add in a section opens the same form as Settings > Connections, with the same Check and Save, and what it saves is ticked and can be reused in every scan. A row that cannot be scanned is listed greyed out with the reason.

A cloud account, cluster or image carried in from an earlier run or schedule that was entered by hand is marked From an earlier run · read-only. Keep it or remove it; it is sent unchanged.

Cloud Accounts¶

The tabs list the fields of the connection form for each provider.

Repositories¶

Add source code repositories to scan for secrets, vulnerabilities, and code-level misconfigurations.

Leave the Repositories section empty if you are only scanning cloud infrastructure.

Kubernetes Clusters¶

Add Kubernetes clusters to scan for in-cluster security misconfigurations. Tick a saved cluster connection, or add one with Add. A cluster can sign in with a saved cloud account or with its own kubeconfig. A GKE cluster saved from a GCP discovery needs no kubeconfig: it is reached with its cloud account's key. One with a private endpoint is listed as Unavailable: it cannot be scanned yet and cannot be added.

Each cluster is scanned independently - one task is dispatched per cluster, running in parallel with cloud and codebase scanner tasks.

• Pod checks - privileged containers, missing resource limits, :latest image tags, secrets in plain-text env vars
• RBAC checks - ClusterAdmin bindings, default service account token mounts
• Network checks - missing NetworkPolicies per namespace
• PSS checks - Pod Security Standards baseline violations

Leave the Kubernetes Clusters section empty if you are not scanning Kubernetes clusters.

Container Images¶

Add container images to scan for CVEs, OS compliance violations, and software bill of materials (SBOM). Tick a saved registry connection, or add one with Add. A registry can sign in with a saved cloud account or with its own credential.

An Artifact Registry repository saved from a GCP discovery adds every tagged image in it, each at its newest tag, with untagged images skipped. Single images cannot be picked from it. A schedule or a repeated run keeps the image list it was built with. The wizard shows how many images were included and skipped and how old the list is, and adds the repository's cloud account to the scan, because the images are pulled with its key.

Each image is scanned independently. You can add as many images as you need.

• CVE scanning (Trivy) runs automatically for every image.
• SBOM generation (Syft, CycloneDX format) runs automatically and is downloadable after the run.
• OS compliance (OpenSCAP) is opt-in per image - enable it in the inspection config for slower but deeper OS-level checks.

Leave the Container Images section empty if you are not scanning container images.

Step 2 - Scope¶

Configure what gets analysed:

You can select multiple compliance frameworks in a single run. Each is scored independently.

Step 3 - Output¶

Select the report formats to generate:

Priority¶

The same step carries a PRIORITY selector with three options:

The console shows this note under the selector:

Higher priority runs jump ahead of queued work of the same type. Availability of High priority may depend on your plan.

Two things that follow from that:

• Priority orders admission, not speed. A High run starts sooner when runs are queued; it does not scan faster once it is running. Within a tier, runs start in the order they were submitted.
• On a hosted plan, High may not be available to your organisation. If it is not, your run is not rejected - it is submitted at Normal and still starts. The downgrade is recorded in the audit log. On self-hosted deployments High is always available.

Review the summary, then click Start Inspection.

Monitor a running inspection¶

After submitting you land on the Run Detail page (/runs/{id}). It shows:

• Status badge - queued → initializing → running → aggregating → reporting → completed
• Queue position - while the run is still queued, a Queue position: n indicator shows how many runs are ahead of it. 0 means yours starts next. It disappears once the run is admitted
• Trace ID - when your administrator has enabled distributed tracing, the run shows its trace ID with a copy button. The page middle-truncates it for display (first eight characters, an ellipsis, last eight), but the copy button puts the full 32 characters on your clipboard. If they also configured a trace-backend URL at build time, the ID is a link straight to that run's trace in Jaeger, Tempo, Grafana or whatever backend they run; otherwise it is plain copyable text you can paste into their tooling. No trace ID means tracing is not enabled
• Agent summaries - one card per agent (cloud inspector, codebase analyzer, kubernetes inspector, container scanner, compliance, WAF, reporting) with task count, finding count, and elapsed time
• Live findings - appear as agents complete; the page updates automatically during the run
• Resources tab - once the run completes, the Resources tab shows every scanned resource grouped as a catalog row. Each row displays the resource name (human-readable, e.g. my-s3-bucket extracted from an ARN or prod-us-east-1/default/my-pod from a K8s path), type, cloud provider, region, source agent, total finding count, and worst severity. Use this tab to quickly identify which specific resources carry the most risk.
• Map tab - once the run completes, the Map tab shows a service map grid grouped by resource type (Compute, IAM, Storage, Codebase, Kubernetes, etc.). Each tile displays the highest severity and total finding count for that category. Click View Findings → on any tile to jump directly to the Findings tab pre-filtered for that tile's source and cloud provider. Service map nodes also include the resource names discovered during the run.

A typical run takes 5–20 minutes depending on the number of cloud accounts and repository size.

Run statuses¶

Repeating a run¶

To re-run an inspection with exactly the same configuration, click the Repeat button (↺) on any completed or failed run in the Runs list. This creates a new run immediately - no wizard needed.

The new run:

• Inherits all targets, scope, and output format settings from the original
• Gets a new run ID and a name prefixed with Repeat of …
• Appears at the top of the Runs list as soon as it is queued

This is useful after remediating findings to confirm that issues are resolved, or to run a fresh scan of the same environment on demand.

Cancelling a run¶

Open the Run Detail page and click Cancel. Available while the run is queued, initializing, running, or aggregating.

Resuming, rescoring, and regenerating reports¶

For runs that are failed, partial, or completed, the Actions menu on the Run Detail page provides three operations that avoid re-running scanners:

Resume¶

Available for failed or partial runs. Opens a wizard showing the per-task pipeline status. Failed and not-started tasks are pre-selected for re-dispatch; completed tasks can be opted in via a "Force re-run completed tasks" toggle. Submitting the wizard re-dispatches only the selected tasks - completed tasks are skipped by default and their findings are preserved.

A plain resume (not a rescore or a task retry) also runs again a cloud, codebase, container or Kubernetes scanner type that completed with recorded coverage gaps, for every account or cluster of that type, with the configuration the run was submitted with. See Resume or start a new scan.

Re-run Compliance & Reports¶

Available for completed, failed, or partial runs. Re-runs compliance scoring against the cached findings and regenerates the reports. No scanners are re-executed. Useful when:

• A compliance framework's scoring rules have changed (e.g. CIS weight tweaks)
• A new compliance framework is added and you want to score an existing run against it
• A control mapping bug was fixed and the run needs re-scoring

You can optionally restrict the rescore to a subset of frameworks via the modal.

On the hosted service a rescore is held to the frameworks your plan includes today. A rescore that names no framework rescores the run's frameworks that the plan includes; the ones it leaves out keep their earlier scores and are named in the API's answer. It is refused only when the plan includes none of them. A rescore that names a framework outside the plan is refused. A new run or schedule follows the same rule: one that lists no framework is scored for the default frameworks your plan includes, and one that lists a framework outside the plan is refused.

Regenerate Reports¶

Available for completed, failed, or partial runs. Re-renders all report formats (PDF, HTML, JSON, CSV, SARIF) from the cached findings JSON on the reports volume. No scanners or compliance agents run. Existing report files are replaced. Useful when:

• A reporting template was updated
• A previous report failed mid-render and you want to regenerate without rescanning
• You changed the report layout / branding

Note: Regenerate Reports requires the original report findings JSON to still be present on the reports volume. Runs older than the report retention window cannot be regenerated this way - use Re-run Compliance & Reports instead, which loads findings from the database.

After the run completes¶

• View and filter findings →
• Browse the resource catalog →
• Review compliance scores →
• Review WAF pillar scores →
• Download reports →
• Download SBOMs →
• Set up a recurring schedule →