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.
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.
Common questions
Rate your own cloud security first
See what attackers and insurers see. Free for your own organisation.