cm-bot scans every region of your AWS account for public entry points: open ports, public databases, APIs without authorization. It ranks them by risk, explains what an attacker would see, and closes them in one click, with undo.
One scan walks every enabled region and looks for resources an outsider can reach, then checks which ports and paths are open to them.
| Resource | What cm-bot checks |
|---|---|
| EC2 instances | Running instances with a public IPv4 or IPv6 address, and every security group rule open to 0.0.0.0/0 or ::/0. |
| Load balancers | Internet-facing ALBs and NLBs, HTTP listeners without a redirect to HTTPS, and NLBs with no security group. |
| RDS databases | Databases marked publicly accessible, and rules that reach the database port from anywhere. |
| API Gateway | REST APIs that aren't private, HTTP and WebSocket APIs with the default endpoint on, and routes with no authorization. |
| CloudFront | Enabled distributions serving plain HTTP, allowing old TLS versions, or running without WAF. |
You watch the scan as it runs; a reload picks it up where it is. Not analysed yet: network ACLs, prefix lists, Classic Load Balancers and S3 buckets.
Each entry point gets a risk level from its open rules and findings, and the map lists the riskiest first. cm-bot then writes "What an attacker sees": a short summary of the shortest paths in, and what to close first.
Examples of each level.
An attacker scanning your IP ranges would find a Windows server, jump-1, answering RDP from anywhere, and a production database, orders-db, reachable from the internet. Together they are the shortest path to your customer data.
Close RDP on jump-1 or restrict it to your office IP, then make orders-db private. The HTTP listener on app-alb comes next: it sends logins unencrypted.
Example summary.
Every finding comes with the fix that fits it. Try the buttons below.
| Entry point | What's exposed | Risk | |
|---|---|---|---|
| jump-1EC2 · eu-west-1 | RDP 3389 open to 0.0.0.0/0 | critical | |
| orders-dbRDS · us-east-1 | Database publicly accessible | critical | |
| web-1EC2 · eu-west-1 | SSH 22 open to the internet | high | |
| orders-apiHTTP API · us-east-1 | Default endpoint on, route without authorization | high | |
| old-cdnCloudFront · global | Unused distribution serving plain HTTP | medium |
Remove the open rule, or keep the port and allow it only from an address range. "Use my IP" fills in yours.
Make a database private, disable a CloudFront distribution, or turn off an HTTP API's public endpoint. REST APIs need a redeploy, so you get step-by-step advice instead.
A security group can protect several resources. Before a rule fix, the map lists every other entry point using that group, and you confirm on the spot.
A report describes how to attack your account, so we don't keep it. Every scan saves a PDF and the raw results to a private bucket in your account; we keep only the file names and counts.
| Scan | Entry points | Critical |
|---|---|---|
| 13 Nov 2026, 09:12 | 64 | 3 |
| 6 Nov 2026, 09:05 | 61 | 5 |
| 30 Oct 2026, 08:58 | 58 | 7 |
Open a report to read it in the browser or download the PDF. Example data.
A role you create with one CloudFormation stack and an External ID. Delete the stack and access is gone.
Set AllowFixes to false and the role can only scan. The map and reports still work.
A fix acts on what the scan found, never on values sent from a browser, apart from the address range you type.
Every scan, fix and undo is in History, with who did it. Undo works even after a plan ends.
No. It reads configuration: instances, security groups, load balancers, database settings, APIs and distributions. It never reads what's stored in them.
No. It uses the AWS APIs to read settings. Nothing is probed or port-scanned.
A rule fix changes the whole security group, so the map shows every other resource using it before you confirm. If something breaks, Undo puts the old rule back.
AWS today. The Scheduler already covers Google Cloud and Azure VMs.
