Shopify launches Overexposed scanner to detect exposed GKE and Cloud Run services
The new tool uses Google Cloud Asset Inventory and anonymous probes to move beyond configuration-only checks that miss real-world enforcement.
Shopify has introduced an internal security tool called Overexposed designed to find Kubernetes Ingresses on Google Kubernetes Engine (GKE) and Cloud Run services accessible from the internet without authentication. The scanner was rebuilt after its first version produced too many false alarms and missed resources because it relied solely on configuration files in repositories.
Moving from Intent to Enforcement
The original scanner checked infrastructure repository config files for public hostnames lacking authentication settings before probing them. Shopify identified three critical failures with this approach: proxy authentication annotations triggered false positives, admission controllers that rewrite settings at creation time were ignored if they didn't run in every cluster, and Ingresses created by other repositories or platform tooling remained unseen.
The team concluded that "the repository shows intent; the cluster shows what is enforced." To solve this, Overexposed now queries Google Cloud Asset Inventory to retrieve accepted GKE Ingresses, along with Cloud Run services and load balancers. A secondary search retrieves access policies without requiring cluster credentials, allowing the tool to surface Cloud Run services in projects previously missed by repository-based scanning.
How Probing and Verdicts Work
Each candidate resource receives a single anonymous request using a HEAD method first, falling back to GET if needed, while following at most three redirects. The scanner also tests path variations like /ADMIN since rules can be case-sensitive, mapping results to six specific verdicts: exposed, expected, protected, not found, unreachable, and inconclusive.
An "expected" verdict applies when an open endpoint matches a reviewed allowlist entry by exact host and path. Allowlisted endpoints are probed on every run, and any entry that turns out to be protected or gone is flagged as stale. Shopify emphasizes that status codes depend on context; for example, a 404 behind an Ingress means the proxy answered but the path was missing, while a 403 does not prove protection.
Handling Uncertainty and Security
In early testing, roughly three in four results were inconclusive during one July run. The team grouped findings by reason, added verdicts where evidence supported them, and replayed rule changes against saved scan results before shipping updates. Uncertain evidence remains marked as inconclusive rather than defaulting to protected status.
Because the scanner makes outbound requests to arbitrary hostnames, Shopify hardened it against Server-Side Request Forgery (SSRF). The tool validates every IP returned by DNS, rejects private and loopback addresses, connects directly to the checked IP to prevent DNS rebinding, and repeats checks on each redirect. The authors recommend also restricting the scanner's network egress, including cloud metadata endpoints.
Lessons for Security Teams
Shopify built Overexposed using AI coding agents and AI code review, applying mutation testing to security guards and keeping one canary target per verdict. Their experience highlights a split between rule-based checks like Trend Micro’s Cloud Run rule, which look for allUsers bindings but report intent rather than enforcement, and inventory-based approaches like Cartography that start from what the cloud actually runs.
Inventory-based methods close blind spots regarding resources created outside repositories or settings rewritten by admission controllers. Overexposed combines this inventory data with an anonymous probe, an allowlist, and evidence-backed verdicts to confirm whether access control works in practice.
