Cloud Exposure
Cloud Exposure is the inside view of your cloud estate: what exists, how it is configured, and which of those configurations are a problem.
It is the largest section of the CyberOptix CTEM Platform by some distance - around 180 posture checks across AWS and Azure - because cloud misconfiguration is mostly a breadth problem. Any one check is simple; the value is that all of them run on everything, continuously.
Connecting an account
The platform reads your cloud with read-only credentials and discovers from there. Nothing is deployed into your account and nothing is changed by the connection.
- AWS uses a cross-account IAM role with a read-only policy. If you use AWS Organizations, connecting at the organization level covers member accounts.
- Azure uses a service principal with reader access at the subscription or management group scope.
Connect one under Integrations. Discovery begins immediately and an initial inventory usually appears within the hour.
SCREENSHOT: the Cloud Accounts view after a connection is established.
An organization-level or management-group connection picks up accounts created later without anyone remembering to add them. Account-by-account connections drift the moment someone provisions a new one, and the account nobody connected is exactly the one worth looking at.
What is assessed
| Group | Covers |
|---|---|
| Accounts | AWS accounts and Azure subscriptions |
| Compute | Instances, serverless, containers, Kubernetes, container registries, web apps and PaaS |
| Storage | Object, file, block, and backups |
| Database | Relational, NoSQL, cache, data warehouse, and search |
| Networking | Virtual networks, load balancers, CDN, firewalls and WAF, connectivity |
| Secrets & Keys | Key management, secrets, parameters and configuration |
| APIs & Integration | API gateways, messaging, streaming |
| DevOps | Pipelines and build |
| Logging & Monitoring | Audit trails |
| Organization & Policy | Service control, tag, backup and AI opt-out policies |
| Vulnerabilities | Findings across all of the above |
Coverage differs by provider, and each section states what it actually covers rather than implying parity. AWS coverage is currently broader than Azure.
What the checks look for
Grouped by what they are actually about, rather than by service:
| Theme | Roughly | Examples |
|---|---|---|
| Encryption | 39 checks | Unencrypted storage, databases, queues; data in transit |
| Networking | 30 checks | Over-permissive security groups, public exposure |
| Configuration | 29 checks | Hardening and safe defaults |
| Identity | 25 checks | Over-privileged roles, missing MFA, stale credentials |
| Compute | 20 checks | Instance, container and serverless settings |
| Logging | 19 checks | Audit logging disabled or incomplete |
| Storage & database | 14 checks | Public buckets, backup and retention settings |
The two that produce the most immediately actionable findings are public exposure - something reachable from the internet that should not be - and identity - a role that can do far more than its job requires.
How cloud findings are scored
Cloud posture findings work differently from vulnerability findings, and it is worth knowing why.
A misconfiguration usually has no CVE, so there is no published score to inherit. Each check carries a severity assigned by whoever wrote it, reflecting how exposed that misconfiguration typically leaves you - an unencrypted bucket is scored 7.0, a publicly reachable managed database 9.0.
The consequence: a cloud finding's severity is a judgement about the class of problem, not a measurement of your specific instance of it. A public database in a sandbox and one holding customer records score identically. Use business units, zones and tags to tell them apart. See Findings, severity, and risk.
Working through it
- Public exposure first. Anything reachable from the internet that should not be.
- Identity second. Over-privileged roles and users, missing MFA, credentials that have not rotated.
- Encryption and logging third. Large in number, usually low individual risk, frequently a compliance requirement - which makes them worth fixing in bulk rather than one at a time.
- Everything else by severity, filtered to production.
Cloud estates generate a lot of findings on first connection. Filtering to production before triaging is usually the difference between a queue people work and one they close.
The same resource, more than once
An EC2 instance can appear here as a cloud resource and separately under Attack Surface as an externally discovered host. Both are correct and they carry different findings: this view knows the security group, the IAM role and whether the volume is encrypted; external discovery knows what the service actually answers with from outside. See Assets.
API
The endpoints behind this section are in the API reference.
Next
- Integrations - connecting an account
- Findings and triage - working what is found
- Assets - why one resource appears in several views