AWS exposure management

Prioritize the AWS resources attackers can actually reach.

OpenWiz plans to connect outside-in discovery with AWS context so a public service becomes an explainable exposure issue, not another disconnected cloud finding.

OpenWiz is in development. The subscription starts immediately at $9 per root domain plus $1 per cloud compute instance each month.

Outside in, then cloud deep

AWS inventory alone is not exposure context.

A resource can exist in AWS without being reachable from the internet, while an overlooked hostname can quietly lead to a production workload. Exposure management joins both views: start with the endpoint an attacker sees, identify the AWS resource that owns it, and use cloud context to decide how urgently it should be fixed.

01

Discover the public path before scoring the resource

The planned workflow begins with a root domain, follows subdomains and public services, and preserves the network evidence behind every result. This avoids treating every AWS resource as equally exposed and gives the team a concrete starting point for validation.

  • Map domains and subdomains to public endpoints
  • Record reachable services and ports
  • Distinguish external evidence from account inventory
02

Connect endpoints to EC2 and ownership context

Once a public endpoint is found, OpenWiz plans to match it to the AWS compute resource and environment behind it. Cloudflare configuration can add the missing DNS and proxy context, making it easier to see whether an endpoint is direct, proxied, expected, or forgotten.

  • Associate public endpoints with cloud resource IDs
  • Show environment and ownership context
  • Keep Cloudflare DNS and proxy state beside the AWS asset
03

Rank remediation by connected impact

The useful output is not a complete asset dump. It is a repair queue that explains why one public workload matters more than another. Reachability, production context, and high-impact relationships can be combined into a single issue with evidence the owner can verify.

  • Group related signals into one Exposure Issue
  • Explain the reason for priority
  • Keep the first MVP focused on a small actionable queue
Designed for

Small AWS estates that still need context

The founding plan scales from one root domain and one compute instance, making it intentionally suited to startups and small infrastructure teams.

  • AWS workloads are reachable through public domains
  • Cloud ownership is clear but external visibility is not
  • The team needs prioritization without a large CNAPP rollout
Planned scope

Exposure management, not every AWS security control

The first MVP stays centered on internet exposure and its cloud context.

  • No production AWS connector is available before MVP delivery
  • No claim of full AWS compliance, vulnerability, data, or runtime protection
  • No AWS credentials are collected during checkout
  • Any future connection flow must use least-privilege access and explicit consent
Questions

AWS exposure management questions

Does OpenWiz need AWS credentials today?

No. Checkout collects only a payment email, primary root domain, and selected quantities. It does not request cloud credentials.

What counts as an instance?

Cloud compute instances are counted by cloud resource ID. Each selected instance costs $1 per month.

Does OpenWiz replace AWS Security Hub?

No. The planned MVP focuses on connecting public exposure to AWS context. It is not presented as a replacement for AWS native security services.

Founding access

Help decide what OpenWiz builds first.

The first successful paid subscription starts the 30-day MVP delivery window. If it is not delivered in that window, founding subscriptions will be canceled and every charge proactively refunded in full.

Start founding subscription