Skip to main content

Cloud Security Posture Management (CSPM)

The platform's third module. Where EASM looks from the outside and DAST actively tests web apps, CSPM scans inside a customer's cloud accounts for misconfigurations and compliance gaps — agentless, read-only.

:::info Status AWS, Azure, and GCP are all built and deployed to production. AWS was validated end-to-end on a real AWS Organization (connect → validate → scan → findings → compliance). Azure and GCP shipped 2026-07-10 — same engine and same findings/compliance model, with provider-specific authentication (see below and the per-provider connecting guides). Their first live customer scan is the remaining validation step. :::

How it works​

CSPM runs an industry CSPM engine against each connected account and normalizes the results into the platform's Assets → Checks → Findings → Tasks — so cloud findings get the same triage, lifecycle, and reconciliation as every other module (module = "aws").

Connect a read-only role (once)  →  Validate access  →  Run scan (per account)
   →  Findings (fails) + full pass/fail posture  →  Filter by compliance framework
  • Scan once, report against any framework. Every result carries its full compliance mappings (CIS, ISO 27001, SOC 2, NIST CSF, PCI DSS, HIPAA, GDPR, and ~50 AWS frameworks). The customer picks the framework as a view — no per-framework re-scan. A compliance report gives the overall score plus a control-by-control pass/fail (e.g. "CIS 3.0: 247/300, 82% passing").
  • Pass and fail are kept. Compliance reporting shows what's passing, not just the failures.
  • Findings group by issue. One problem across many resources shows as a single grouped finding with the affected assets listed and a "5 of 20 remaining" rollup; a finding that persists across scans is flagged recurring.

Connecting an account (read-only, one time)​

Whatever the cloud, the customer grants a read-only identity and nothing more — no write access, no data reads. How that identity is provided differs per provider, and so does how we hold it:

ProviderRead-only identity the customer createsHow we hold access
AWSAn IAM role (CloudFormation / StackSet), gated by a per-customer External IDNo secret stored — cross-account assume-role gives a ~1h session per scan
AzureAn app registration + service principal with the Reader roleThe client secret is stored encrypted (dedicated KMS key); an isolated credential broker mints a ~1h read-only token per scan
GCPA service account with Viewer + Security ReviewerThe key JSON is stored encrypted; the same broker mints a ~1h read-only token per scan

For Azure/GCP the stored credential is write-only on our side (accepted, never read back or shown again) and the durable key never reaches a scanner — only the broker can decrypt it, and workers only ever receive short-lived tokens. On connect we run a live access check so the customer knows immediately whether access works — before any scan.

Step-by-step setup: Connecting AWS · Connecting Azure · Connecting GCP.

Finding lifecycle (same as the rest of the platform)​

Cloud findings are tracked per resource and follow the shared lifecycle:

  • Triage: mark a finding In Progress, Resolved, Accepted Risk, or False Positive.
  • Resolution is verified by re-scan, not a manual flag:
    • mark Resolved → the next scan confirms it's gone (1 scan);
    • fix it without triaging → it auto-closes after 2 consecutive clean scans.
  • Partial remediation is exact: fix 15 of 20 affected resources and those 15 close on their own; the other 5 remain open.

White-labeling​

The underlying engine is never exposed — not in the findings (its name, links, and internal identifiers are scrubbed) and not in the customer's own cloud audit log (AWS CloudTrail, Azure Activity Log, GCP audit logs), where the scanner is attributed to our product — the user-agent/session name (AWS) or the service-principal / service-account identity (Azure/GCP).

Known gaps (planned)​

  • UI — the platform is API-only today; triage actions exist as API calls, the clickable interface is pending.
  • Two-hop assumer isolation (AWS) — the production hardening that places the customer-access role in a separate locked-down account (coded; account pending).
  • First live Azure/GCP customer scan — the modules are deployed; the in-cloud scan of a real Azure/GCP tenant is the last end-to-end confirmation.

(Single-account and whole-Organization StackSet onboarding are now documented — see Connecting AWS — step by step.)

(Grouped finding view, the recurring marker, and the compliance report are now built — see the API Reference.)

See also the EASM Architecture page for the shared finding lifecycle, and the API Reference for endpoint detail.