Cloud security,
misconfigurations visible from the internet.
AWS, Azure and GCP exposure discovered from the outside, without API keys and without read-only roles. The same public storage buckets, open databases and forgotten instances an attacker would enumerate on a quiet afternoon.
Optional read-only scoped access. Every other module needs no access at all.
Cloud Security at a glance
What we observe
Public storage buckets, exposed databases and management endpoints, orphaned instances and unclaimed DNS pointing at cloud services.
How it's scored
Each observation maps to a published, versioned rubric. Click any score component to see the evidence behind it.
What happens next
Findings route to the cloud owner with remediation guidance. Scores update automatically once the exposure closes.
What we observe
- Cloud posture across AWS, GCP and Cloudflare
- Misconfiguration against provider baselines
- Publicly reachable storage and services
- Identity and access configuration weaknesses
- Drift between scans
What arrives on a finding
- The specific resource and setting at fault
- Severity with the evidence behind it
- Remediation in the provider’s own terms
- The compliance control affected
- A dedicated Cloud report for the platform team
Anatomy of a finding
| Finding | Storage bucket configured for public read access |
| Evidence | The resource identifier and the effective policy observed |
| Why it matters | Public read on a storage bucket is one of the most consistently exploited cloud misconfigurations |
| Who it affects | Every data subject whose records sit in that bucket |
| Remediation | Restrict the policy, then confirm with a rescan that the exposure has cleared |
Cloud findings arrive in the same alerts view as every other module, with severity, SLA and an owner
What cloud posture looks like from outside, and what needs access
Cloud security assessment splits cleanly into two halves, and being clear about which is which avoids the overclaiming this category attracts.
From outside, with no access at all, a good deal is observable: storage buckets left publicly readable, management interfaces exposed to the internet, cloud-hosted services attributable to the organisation, misconfigured DNS pointing at deprovisioned cloud resources: the subdomain takeover case, where a record still points at a resource anybody can now claim.
The other half (IAM policy, encryption at rest, logging configuration, network segmentation inside a VPC) is not externally observable and never will be. That requires read-only scoped access to an account you choose to connect, and it is the only part of the platform that asks for anything.
The hard part is knowing which cloud assets are yours
Finding an exposed storage bucket is straightforward. Establishing that it belongs to a particular organisation, with enough confidence to raise a finding against them, is the actual work, and it is where outside-in cloud assessment most often goes wrong.
Attribution comes from converging evidence: DNS records pointing at cloud resources, certificate transparency entries, naming conventions, reverse relationships from known assets. Any one of those alone is weak. Several together are strong enough to act on, and findings carry the evidence so attribution can be checked rather than trusted.
This matters more for vendor assessment than for your own estate. Raising a finding against a supplier for a bucket that is not theirs damages the conversation and the credibility of every other finding you present, which is why an assessment that cannot show its attribution evidence is not worth much.
The accounts nobody in security knows exist
Every organisation past a certain size has cloud resources outside the sanctioned accounts. A developer's proof of concept on a personal account. A marketing team's landing page infrastructure. A subsidiary that predates central IT governance. A project from an acquisition nobody has folded in.
These are the highest-risk cloud assets by a distance, because they combine internet exposure with an absence of ownership: not patched, not monitored, not logged, not in any inventory, and with no one to escalate to. They are also invisible to any assessment that starts from your list of accounts, which is exactly what most cloud security tooling does.
Outside-in discovery finds them because it does not start from your list. It starts from your domains and works outward, which is also how an attacker finds them.
Common questions
Do you need access to our cloud accounts?
Not for the external half, exposed storage, public management interfaces, subdomain takeover risk and attributable cloud assets are all observable without access. Deeper posture such as IAM policy, encryption at rest and logging configuration requires read-only scoped access to an account you choose to connect.
How do you know a cloud resource belongs to us?
Converging evidence: DNS pointing at the resource, certificate transparency entries, naming conventions and reverse relationships from assets already attributed. Each finding carries that evidence so attribution can be checked rather than taken on trust.
What is subdomain takeover?
A DNS record still pointing at a cloud resource that has been deprovisioned. Anyone can claim the resource and then serve content from your subdomain. It is common, it is easy to fix, and it is easy to miss because the DNS record looks fine in isolation.
Can you assess a vendor's cloud posture?
The external half, yes, with no cooperation required. The internal half needs access, which a vendor is unlikely to grant: this is exactly where an audit report or questionnaire remains the right instrument.
What about shadow cloud accounts?
Those are found precisely because discovery starts from your domains rather than your account list. They are usually the highest-risk cloud assets you have, because internet exposure combined with no named owner means nothing gets patched.
Which cloud providers are covered?
Assets are discovered by attribution from public infrastructure rather than by provider integration, so provider-agnostic discovery works across the major platforms. Connected read-only assessment depends on which provider the account you connect belongs to.
Where this connects
Attack surface management →
How cloud assets are discovered and attributed from the outside.
Own enterprise visibility →
Finding the shadow cloud accounts before someone else does.
Network security module →
Exposed services and ports across the whole external estate.
Rate your own cloud security first
See what attackers and insurers see. Free for your own organisation.