Shopify has built a new internal security scanner called Overexposed to find Kubernetes Ingresses on GKE and Cloud Run services that are reachable from the internet without authentication. The company says the first version, which relied on repository configuration files, produced too many false positives and missed real exposures, so it rebuilt the tool around Google Cloud Asset Inventory and anonymous HTTP probing.
Why Shopify changed approach
The original scanner started in the infrastructure repository, looking for public hostnames and missing authentication settings before probing those endpoints. Shopify found that approach broke down in several ways. Proxy authentication annotations could trigger false alarms, admission controllers could rewrite settings after code review, and resources created outside the repository were invisible to the scanner.
Shopify’s summary of the problem is blunt: the repository shows intent, while the cluster shows what is actually enforced. That distinction became the basis for Overexposed’s second design.
How Overexposed scans GKE Ingresses and Cloud Run
The current scanner runs on a schedule and pulls data from Cloud Asset Inventory. That inventory includes GKE Ingresses accepted after admission, Cloud Run services, and load balancers. It also provides access-policy data without requiring cluster credentials, which broadens coverage beyond what the original repository-based scan could see.
From there, Overexposed sends a single anonymous request to each candidate endpoint. It starts with HEAD, falls back to GET if needed, follows up to three redirects, and checks each redirect target. The tool also tests path variations such as /ADMIN, since path matching can be case-sensitive.
- HEAD first, then GET if needed
- Up to three redirects are followed and checked
- Path variants are tested to catch case-sensitive routing
- Anonymous probing is used to reflect what an external visitor can see
Verdicts rather than a simple yes or no
Overexposed does not collapse results into a single exposure flag. Instead, it uses six verdicts: exposed, expected, protected, not found, unreachable, and inconclusive. “Expected” is reserved for endpoints that are intentionally open and match a reviewed in-code allowlist entry by exact host and path.
Even allowlisted endpoints are probed on every run. If one is later found to be protected or missing, the tool treats that allowlist entry as stale and flags it for review.
Cloud Run, GKE, and the limits of status codes
Shopify stresses that HTTP status codes mean different things depending on the platform. On a GKE Ingress, a 404 usually means the proxy responded and the requested path is missing. On Cloud Run, however, Google’s front end can return a 404 before the application ever runs, so Overexposed treats that case as inconclusive.
The scanner also avoids assuming that a 403 proves protection. For Cloud Run, it distinguishes between ingress settings and IAM permissions. A service is considered public only if allUsers has the invoker role or the invoker check is disabled.
For services behind a load balancer, Overexposed uses the URL map to determine which backend handles each path and whether authentication mechanisms such as Identity-Aware Proxy are required.
Reducing false alarms without hiding uncertainty
In early runs, the team saw a high rate of inconclusive results. Shopify says one July run had roughly three in four findings marked inconclusive. Rather than forcing those cases into a “protected” bucket, the team grouped results by reason, added new verdicts where the evidence supported them, and replayed rule changes against saved scan data before shipping updates.
That design choice is important to the tool’s philosophy: uncertain evidence stays inconclusive. The scanner stores verdicts, reasons, and team ownership, but not response bodies or credentials.
Security hardening against SSRF
Because Overexposed makes outbound requests to arbitrary hostnames, Shopify hardened it against server-side request forgery risks. The scanner validates every IP returned by DNS, rejects private and loopback addresses, connects directly to the resolved IP to prevent DNS rebinding, and repeats checks on every redirect.
The authors also recommend restricting the scanner’s network egress, including access to cloud metadata endpoints, to further reduce abuse potential.
AI tools helped build the scanner
Shopify says it built Overexposed with AI coding agents and AI-assisted code review. To reduce the risk of tests passing while checking the wrong thing, the team used mutation testing for security guards and kept one canary target for each verdict.
That combination of automation and validation reflects the same theme running through the project: use automation aggressively, but verify the result against real behavior instead of assuming configuration is correct.
What the project suggests for cloud security teams
Shopify’s experience offers a practical split for exposure scanning. Configuration-based checks, such as rules that look for allUsers bindings, are cheap and fit naturally into CI, but they only report intent. They can miss resources created elsewhere or settings rewritten later by platform automation.
Inventory-based approaches start from what is actually deployed. That closes blind spots, and adding an anonymous probe can reveal whether access control really works from the outside. Shopify’s recommendation is to use inventory as the main source of truth, keep configuration analysis as an early warning signal, and add probing only when inventory cannot answer the question.
- Use cloud inventory as the primary reference
- Keep config scanning in CI for early feedback
- Probe externally only when enforcement needs confirmation
- Treat uncertainty as inconclusive rather than assuming safety
For teams running GKE, Cloud Run, or similar managed platforms, the lesson is straightforward: exposure is best measured from the outside, but it must still be tied back to the cloud resources that actually exist.
Source: Original report
Was this helpful?
Explore more: Application Audit & Review More Cloud & DevOps Tech News
Last Modified: November 2, 2026 at 10:34 pm
2 views
