Scan your account
CBX Guard inventories your connected AWS account through the read-only role — resources and the network graph — to fill Landscape and Context and resolve reachability. This is what makes the account-aware review sharp.
Scan your account
Coming soon. CBX Guard is not yet generally available. This page describes the account-scan model so you know exactly what CBX Guard reads and how it uses it.
Connecting a cloud account grants CBX Guard the ability to read it. The scan is what actually reads it: a read-only sweep that inventories your account's resources and network graph, then resolves reachability from that graph. The result populates two views in the Console — Landscape (what you have) and Context (what's reachable, and your blast radius) — and, crucially, it's the captured state the account-aware review resolves each change against.
Everything on this page is read-only. The scan calls Describe*, Get*, and List* APIs
through the cross-account role you launched in Connect an AWS account.
It never creates, modifies, or deletes anything.
What the scan captures
CBX Guard assumes your read-only role and sweeps the account's live resources and how they connect:
- Resources — EC2 and security groups, RDS databases, load balancers, S3 buckets, VPCs and subnets, IAM roles and their trust relationships.
- The network graph — subnets and their routes, internet gateways, security-group references, and the IAM trust edges — the inputs reachability is computed from.
Per-service read failures never fabricate coverage. If one layer can't be read (a denied permission, a throttled API), the scan comes back partial with a note about exactly what it couldn't read, rather than silently assuming that layer is empty.
Reachability: the tri-state
From the captured network graph, CBX Guard resolves whether each resource is actually reachable from the internet. It reports this as an honest tri-state — and never guesses:
| State | Meaning | How it's derived |
|---|---|---|
| Reachable (internet-facing) | There is a resolved path from the internet to this resource. | e.g. a public subnet with a route to an internet gateway and a world-open security group; an internet-facing load balancer; an RDS instance flagged publicly-accessible and fronted by a world-open SG. |
| Contained | There is no resolved internet path — the resource is private. | e.g. a database in a private subnet with a source-restricted security group; the crown jewel with "no resolved internet path". |
| Unreadable | CBX Guard couldn't determine reachability from what it could read. | The network layer needed to decide wasn't readable, or the state is genuinely ambiguous. Never silently treated as "contained." |
The discipline is the same one that governs verdicts: unknown is never silently cleared. An
unreadable resource is surfaced for review (it routes to Watch), not passed as if it were safe.
A resource is only marked contained when the graph actually proves there's no internet path — not
merely because CBX Guard failed to find one.
Reachability before a scan — and how a scan resolves it
Before you scan an account, CBX Guard has no captured graph to reason over, so reachability is simply
not yet resolved — every resource sits in the unreadable state, and the account-aware review
falls back to the same offline reasoning the CI gate uses (which is why a
fresh internet exposure resolves only to Watch offline — reachability can't be confirmed from a
plan alone).
Running a scan is what resolves that unknown. Once the graph is captured, CBX Guard can say — with facts from your account — that the database in the diff is publicly accessible and production, and the "internal" source group is itself world-open. That's the difference between a Watch ("we can't tell") and a High ("we resolved it, and it's exposed"). See the worked example in Two lanes.
Rescan to stay current. The captured landscape reflects your account as of the last scan (the Console shows when — "captured Nh ago"). Rescan after significant infrastructure changes so the account-aware review resolves against current state. Re-scanning upserts what still exists and prunes what's gone; it only ever touches the account it scanned.
What a scan does and does not do
It does: assume your read-only role per session via AWS STS, call read-only Describe* / Get* /
List* APIs, and build the resource + network graph that Landscape and Context read from.
It does not: create, modify, or delete any resource; store long-lived credentials in your account; or hold any write permission — there is none in the role's template. Delete the CloudFormation stack and the next scan simply fails to assume the role: access is gone.