Shopify Overexposed Scans GKE Ingresses and Cloud Run for Exposure

Shopify has developed and deployed Overexposed, an internal security scanner engineered to find exposed Google Kubernetes Engine Ingress resources and Google Cloud Run services accessible from the public internet without authentication. The system replaces an earlier static infrastructure analysis tool that parsed repository code and produced excessive false positives and blind spots across company deployments. According to details shared in InfoQ's report, Shopify overhauled the tool by combining Google Cloud Platform Cloud Asset Inventory data with an automated, anonymous HTTP probing pipeline. In just a few weeks of tuning the new architecture, the engineering team reduced inconclusive Ingress verdicts by approximately 80 percent, converting an unreliable alert generator into an actionable detection platform.

This breakdown details how Overexposed audits public endpoints, handles complex Google Cloud access rules, mitigates server-side request forgery risks, and reconciles repository intent against live cluster enforcement. It is designed for cloud security engineers, site reliability teams, and platform architects operating containerized workloads on Kubernetes and serverless infrastructure who need reliable visibility into unintended public exposure.

Shopify Overexposed Scans GKE Ingresses: what actually changed

Shopify abandoned its original repository-based exposure scanner after discovering fundamental structural flaws in analyzing declarative configuration files. The initial tool checked Git repositories for Ingress resources specifying public hostnames without explicit authentication settings, then dispatched external network probes to test accessibility. This configuration-centric strategy failed in three distinct ways. First, service teams that configured proxy authentication annotations directly on resources triggered persistent false positives. Second, admission controllers that mutate or rewrite settings during cluster admission did not run consistently across all clusters, meaning that a configuration that looked correct in a pull request often had no actual effect in the running environment. Finally, platform tooling and other pipelines generated Ingresses outside the main infrastructure repository, leaving entire workloads completely unmonitored.

The authors concluded that Git repositories indicate operational intent, whereas the live cluster reveals what is actually enforced. To bridge this gap, Shopify rebuilt Overexposed around Google Cloud Platform Cloud Asset Inventory queries on an automated schedule. The managed asset inventory captures all Ingress resources accepted by GKE after admission controllers execute, alongside Cloud Run services and external load balancers. A secondary inventory lookup extracts access control policies without requiring the scanner to hold cluster-level credentials. This transition immediately discovered active Cloud Run services running in projects that the previous repository-bound scanner had never evaluated, establishing complete visibility across production projects.

Shopify Overexposed Scans GKE Ingresses: how it works

Once Cloud Asset Inventory gathers candidate endpoints, Overexposed executes a disciplined probing workflow to assess exposure. The scanner dispatches a single anonymous network request to each candidate target, attempting an HTTP HEAD request first and falling back to a standard GET request when necessary. Overexposed follows up to three redirects, evaluating the response headers and payload state at every step. It also tests case-sensitive path variations, such as uppercase admin paths, to ensure path routing rules cannot be bypassed. The probing engine maps all findings to six defined verdicts: exposed, expected, protected, not found, unreachable, and inconclusive.

An expected verdict applies when an endpoint is deliberately open to the internet and matches a reviewed entry in an in-code allowlist by exact hostname and path. Overexposed continues to probe allowlisted endpoints during every scheduled run, automatically flagging any allowlist entry as stale if the target becomes protected or disappears entirely. The scanner treats HTTP status codes within their specific deployment context rather than assuming generic meanings. While a 404 code behind a GKE Ingress signifies that the proxy answered and the requested path does not exist, Google Cloud Run frontends can emit a 404 before the backend application even starts, prompting Overexposed to record the result as inconclusive rather than protected.

Shopify Overexposed Scans GKE Ingresses: why it matters now

The architecture behind Overexposed highlights a major split in how modern engineering organizations approach exposure scanning. Static rule-based scanners, such as Trend Micro rules for Cloud Run that look for allUsers identity bindings, are cheap and integrate cleanly into continuous integration pipelines. However, those linters inspect intent rather than enforcement, consistently missing cloud resources created outside the primary repository as well as configurations altered by dynamic cluster admission webhooks. Inventory-based frameworks like Cartography improve upon this by reading running infrastructure state, but tools like Cartography derive exposure flags from raw configuration values without validating whether an external internet client can actually reach the underlying application.

Overexposed addresses this blind spot by coupling authoritative cloud asset inventories with external anonymous probes and an auditable allowlist. The system refuses to treat uncertain evidence or standard 403 responses as proof of security, classifying ambiguous states as inconclusive. On Cloud Run, the scanner isolates network ingress configurations from Cloud IAM settings, recognizing that a service is genuinely public only when allUsers holds the invoker role or when invoker authorization checks are explicitly disabled. For services deployed behind Google Cloud external load balancers, the scanner parses URL maps to identify which backend services service specific paths and verify where identity protections like Identity-Aware Proxy are strictly enforced.

Shopify Overexposed Scans GKE Ingresses: who is affected

This technical overhaul directly impacts Shopify infrastructure teams, product developers managing public endpoints, and external operators running similar multi-cluster cloud environments. During early testing runs, Overexposed produced high ambiguity, with roughly three out of every four scan results categorized as inconclusive in one July run. To stabilize the scanner, the team grouped ambiguous outcomes by root cause, defined new explicit verdicts only when concrete diagnostic evidence supported them, and replayed rule changes against historical scan archives before rolling updates into production. This discipline kept false reassurances low by preventing uncertain results from defaulting to a safe status.

For security and compliance reasons, Overexposed stores scan verdicts, detailed decision reasons, and team ownership metadata, while strictly excluding HTTP response bodies and authorization credentials from storage. Because the scanning engine sends automated outbound network traffic to arbitrary, dynamically discovered hostnames, Shopify implemented stringent defenses against server-side request forgery attacks. The scanner validates every IP address resolved through DNS, immediately rejects loopback and private internal network addresses, establishes connections directly to the verified IP to block DNS rebinding attempts, and repeats these validations on every HTTP redirect. Shopify also restricts network egress from the scanner instance, blocking access to internal cloud metadata endpoints.

Shopify Overexposed Scans GKE Ingresses: what to watch

As teams adopt similar runtime verification architectures, the construction and testing of security tools will increasingly rely on automated testing guards. Shopify built Overexposed with AI coding agents and automated AI code review systems. To ensure that test suites do not pass while evaluating faulty assumptions, the development team integrated mutation testing into the scanner codebase to stress security guards and established dedicated canary targets for each of the six classification verdicts. These canaries provide constant baseline verification, ensuring that scanner logic changes do not drift or misclassify live traffic.

For engineering teams seeking to replicate this security posture, Shopify recommends using live cloud inventory as the primary source of operational truth while retaining repository configuration analysis as a fast, preliminary signal in pull request checks. Network probing should be introduced selectively when inventory data alone cannot definitively prove whether edge access controls are functioning. Organizations managing large-scale Google Cloud deployments should monitor how their admission controllers, load balancer URL maps, and Identity-Aware Proxy rules interact, ensuring runtime auditing tools verify actual boundary enforcement rather than declarative repository intent.