Running a scan

Cloud testing

Two different things: the infrastructure committed to your repository, and a read-only posture scan of a live account.

How to run each half

Committed configuration needs nothing but a repository scan. The live posture scan needs read-only credentials, which you create at the provider.

  1. For committed configuration: scan a repository that contains your Terraform, Kubernetes manifests or Dockerfiles. Open Cloud in the sidebar to see those findings collected across the portfolio.
  2. For a live account: open Cloud and choose your provider. The page lists exactly which credential values it needs and where each one comes from in that provider's console.
  3. Create the read-only identity it describes — an IAM user with the generated read-only policy on AWS, and the equivalent role on Azure or GCP. Grant nothing beyond what the page lists.
  4. The live scan reads those values from the server environment, which only the service owner can set — so a live account scan is arranged with us rather than switched on from the page. The values are never returned, logged, or included in a result.
  5. Run the scan with the CLI. It exits non-zero if any check fails, so it can gate a pipeline.

Note

The permissions listed on the Cloud page come from the same allow-list the client enforces in code, not from a hand-written document. What the credential can never do is enforced, not merely described.

The distinction that matters

The Cloud section covers two sources of truth, and confusing them produces false confidence. Committed configuration is what your repository says the infrastructure should be. A posture scan is what a live account actually reports.

A resource somebody created by hand in a console appears in the second and is invisible to the first.

Committed configuration

Terraform, Kubernetes manifests and Dockerfiles are analysed on every repository scan, and the Cloud page collects those findings across the portfolio rather than leaving them buried one scan at a time.

No cloud API is called for this. Nothing is reconciled against a live account.

What this does not do

Committed configuration cannot tell you about drift. If the deployed state no longer matches what is in the repository, only a posture scan will show it.

Live posture scan

AWS, Azure and GCP can each be connected with read-only credentials to assess the account itself — root account MFA, root access keys, password policy, and the rest of the provider's baseline.

The access is read-only and enforced by an allow-list in the code, not by a policy document somebody pasted into a wiki. Credentials are read from the environment and are never returned, logged, or included in a result. The account identifier appears in the result because it is something you already know, not a secret.

# Assess a connected account
node webcuris.cjs cloud aws
node webcuris.cjs cloud azure
node webcuris.cjs cloud gcp

# Machine-readable, exits non-zero if any check fails
node webcuris.cjs cloud aws --json

Container images

An image can be scanned for known vulnerabilities in its layers with image, which is the same dependency analysis applied to what was actually built rather than to what the manifest asked for.

node webcuris.cjs image registry.example.com/app:1.4.2