Cloud security posture, done the Umbra way: proof, paths, and the fix
Most cloud security tools have the same problem as most vulnerability scanners: they’re very good at generating a list, and not very good at telling you what’s actually exploitable or what to do about it. You connect an account and get 400 “misconfigurations,” sorted by a severity that was assigned to the rule, not to your account. Somewhere in there is the bucket that’s actually public. Good luck.
We built cloud posture the other way. It’s live now across AWS, Google Cloud, and Azure (read-only, in the same workspace as the rest of your attack surface) and it’s built on three ideas that we think a cloud scanner should have been built on from the start.
1. Prove it. Don’t infer it.
Most scanners flag a public bucket by reading its policy and reasoning about it. Policies are complicated; the reasoning is often wrong in both directions.
Umbra doesn’t guess. When it thinks a bucket is public, it makes an unauthenticated request for an object (with no credentials) and checks for a 200. That’s the exact thing an attacker would do. If a byte comes back, the exposure is real, and the finding records the confirmed object so a triager can reproduce it in one command. This works for S3, GCS, and Azure blob containers.
”Public bucket (anonymously confirmed)” is a different sentence than “public bucket (per policy analysis).” One you act on. The other you argue about.
2. A path to your data beats a list of problems
A single misconfiguration is rarely the story. The story is the path: how an internet-reachable foothold becomes access to real data.
So Umbra correlates findings into data-terminating attack paths:
- On AWS: an internet-facing EC2 instance that still allows IMDSv1 → an SSRF mints its role token → the named S3 buckets and secrets that role can read.
- On GCP: a public VM → its service account → the specific Cloud Storage buckets, Secret Manager secrets, and BigQuery datasets it can read.
- On Azure: an internet-reachable VM → its managed identity → the storage, Key Vault, and Cosmos its RBAC grants.
Each path names the terminal data. Not “this role is over-privileged”:
“this path reads customer-pii.” That’s the difference between a finding an
engineer deprioritizes and one they fix today.
And because the dangerous failure mode of any scanner is confident silence (a collector that quietly parses nothing, draws no edges, and reports a clean cloud full of paths) we guard against it: reachability we can’t determine is attested, not assumed safe, and every technique family reports whether it ran, found nothing, or couldn’t be evaluated. A clean result is never confused with a blind spot.
3. Every finding ships with the fix
Finding a problem is half the job. The half that stalls in every security program is the handoff: “here’s a critical finding” → someone has to research what to actually run.
So every Umbra cloud finding (across every detectable type, on all three
clouds) ships with the concrete change that removes it. Not “apply least
privilege.” The exact aws / gcloud / az command, built from the
finding’s own evidence (its real ARN, resource id, member, CIDR), with a
guardrail telling you what to check before you apply it. For an attack path,
you get the command for each breakable link, so you can pick the cheapest cut.
It’s generated as output, read-only, never applied. Umbra doesn’t touch your cloud. And where a finding’s evidence genuinely can’t produce a precise, copy-pasteable command, we say so and give the next step, never a plausible-looking but wrong command, because a wrong fix is a false all-clear someone will act on.
The unglamorous part: being right
Privilege-escalation findings are where most tools produce a wall of false Criticals, because they flatten IAM to action patterns and ignore the things that actually constrain it. Umbra’s effective-permission analysis honours SCPs, permission boundaries, resource scope, and conditions. An IAM path that a restrictive SCP already blocks doesn’t fire a Critical. Fewer findings, but the ones you get are real. We’d rather ship 10 correct findings than 30 that train you to ignore the dashboard.
And you can hand it to someone
Any scan exports to a branded PDF posture report (the same report engine as our internal-pentest and web-audit exports) with the risk summary, the methodology, and every finding with its remediation inline. The engineer who owns the misconfigured bucket usually isn’t watching your dashboard; a PDF that proves the exposure and includes the one command to fix it is a handoff they can act on without logging in.
Try it
Connect a cloud account read-only (the docs walk through the least-privilege role), click Scan, and open a finding. You’ll see the proof, the path to the data, and the copy-ready fix.
If you’re a team that’s been priced out of Wiz / Orca / Prowler-plus-a-team, this is the same bet as the rest of Umbra: not more checks than everyone else: better evidence, real attack paths, and the fix in the box.
The Umbra team