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 one-time $10 reservation includes the first live month and does not start a recurring subscription.
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.
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
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
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
Small AWS estates that still need context
The founding plan covers one root domain and up to 100 compute instances, 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
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 reservation
- Any future connection flow must use least-privilege access and explicit consent
AWS exposure management questions
Does OpenWiz need AWS credentials today?
No. The reservation collects only a payment email, root domain, and instance range. It does not request cloud credentials.
What counts as an instance?
The founding scope counts cloud compute instances by cloud resource ID, with up to 100 included.
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.
Help decide what OpenWiz builds first.
The first successful paid reservation starts the 30-day MVP delivery window. If it is not delivered in that window, every founding reservation will be proactively refunded in full.
Reserve founding access — $10