Cloud security posture

What it is

Connect a cloud account read-only and Umbra scans it for the exposure a network scan can’t see. Instead of probing ports, it reads the provider’s control plane (object storage, IAM and role bindings, compute and networking, serverless, managed databases, secret stores) and reasons about what an attacker could actually reach: world-readable data, identities that can escalate to administrator, secrets sitting in configuration, and services open to the whole internet. Then it chains those into attack paths that terminate at specific data.

It runs across AWS, Google Cloud, and Azure from a single workspace, with ~75 checks over 37 enumerators, and it is strictly read-only: Umbra never creates, modifies, or deletes anything in your cloud.

What it detects

• Public data: proven, not inferred. A public S3 bucket, GCS bucket, or Azure blob container isn’t flagged from a policy guess. Umbra confirms it by fetching an object with no credentials (anonymous read-proof). A triager can copy-paste the request and see the exposure.
• Privilege escalation to admin. 30+ AWS IAM privesc techniques (PassRole→compute, policy-attach, trust-policy rewrite, resource-policy self-grant, role chaining), plus GCP project/org IAM escalation and Azure RBAC (Owner / User Access Administrator). Effective permissions honour SCPs, permission boundaries, resource scope, and conditions, so the finding is right in the enterprise accounts that matter, not a false Critical.
• Secrets in configuration: Lambda environment variables, EC2 user-data, ECS task definitions.
• Internet-open services: security groups / firewalls / NSGs open to 0.0.0.0/0 on datastore and management ports, public RDS / Cloud SQL / Azure SQL, and public Kubernetes control planes (EKS / GKE / AKS).
• Identity hygiene: root without MFA, long-lived access keys, user-managed service-account keys, GitHub Actions OIDC trust with a missing or wildcarded sub.
• Attack paths: an internet-reachable workload → the identity it runs as → the specific data that identity can read.

Evidence-grade, and honest about coverage

Two things make the output trustworthy:

• Read-proof. Public storage is proven by reading a byte anonymously, the same way an attacker would, not by inferring from a property.
• Coverage attestation. Every technique family reports whether it ran, found nothing, or couldn’t be evaluated. A disabled service API or a missing read permission is surfaced as its own state, never silently skipped. A clean result is never confused with a blind spot.

Every finding ships with its fix

This is the difference from a generic CSPM: every finding carries its concrete, resource-specific remediation: the exact aws / gcloud / az command that removes the exposure, built from the finding’s real ARN / resource-id / member, with a guardrail to review before you apply it. “Path to customer data” arrives with “here is the one command that breaks it.”

Export it

Any scan exports to a branded PDF posture report (cover page, posture summary, per-finding detail with the remediation inline, and a sign-off), the same report template as the internal-pentest and web-audit exports.

Why it matters

For a cloud-native business the network perimeter isn’t the attack surface. The control plane is. A bucket made public to share one CSV gets forgotten. An over-broad role a developer granted “to unblock a deploy” becomes a path to every secret in the account. A port scan sees none of it, because none of it opens a port. Umbra reads the layer where the breach actually happens, proves the exposure, shows the path to the data, and hands you the fix.

Why it’s valuable

• Three clouds, one workspace. Same findings list, same reports. No separate cloud console per provider.
• Read-only + least-privilege. A read-only role (AWS SecurityAudit, GCP roles/viewer + iam.securityReviewer, Azure Reader); credentials are encrypted at rest and verified at connect time.
• Correctness over check-count. Effective-permission analysis (SCPs, boundaries, resource scope, conditions) means fewer, right findings, not a wall of false Criticals.
• Proven, not guessed. The anonymous read-proof and the data-terminating attack graph are evidence, not inference.

How to use it

1. Cloud in the left nav → Connect account → pick AWS / Google Cloud / Azure.
2. Paste a read-only credential (an AWS access key, a GCP service-account JSON key, or an Azure service principal). Umbra verifies it before saving.
3. Click Scan: assets, findings, coverage, and attack paths stream in.
4. Open any finding for the proof, the impact, and the copy-ready fix; open a scan and Export PDF to hand the report to the owning team.