Zuul Fingerprints Need Tenant and OIDC Boundaries Before a CI/CD Exposure Claim
Zuul is an open-source CI/CD system that runs jobs across nodes and presents a web interface. A ZoomEye count-only probe on November 15, 2026 returned 7,062 app="Zuul" matches, 955 title="Zuul" matches, and 26,632 http.body="Zuul" matches. The queries used sub_type=all, page 1, and page size 1.
The application count is large enough to invite a misleading headline. It is an index observation, not a count of exposed production CI systems. Product fingerprints can include services, test deployments, and versions with different authentication. Title and body matches can include documentation and unrelated references to the name.
Authentication is not tenant authorization
Zuul's authenticated-access documentation describes OpenID Connect authenticators and access rules for tenants. The configuration can use a remote identity provider, token issuers, and a JWKS key set. A successful login establishes an identity. Tenant policy decides what that identity may do.
Review the OIDC issuer, audience, signing keys, and tenant rules together. A token for the wrong audience should not be accepted. A valid user from another tenant should not inherit administration because the issuer is trusted. Do not collapse those checks into a single "logged in" flag.
The web interface may expose job status, logs, tenant configuration, and actions that affect pipeline execution. Separate read access to build results from permission to enqueue, cancel, or reconfigure jobs. A public status page can be useful without exposing the administrative API.
CI is an execution boundary
A CI system can run code, access source repositories, and hold credentials for deployment targets. Inventory the executor model, allowed secrets, job isolation, and network reachability. A compromised Zuul controller or executor can be more significant than an exposed read-only web page.
Restrict which repositories can define jobs and which tenants can use privileged nodes. Review secret scopes and job inheritance. If a job can reach a production deploy key, that key should be released only to the job and tenant that need it.
Check whether the web process and the scheduler share credentials or run in the same trust zone. Confirm that an authenticated user cannot use a web action to submit arbitrary code outside the normal project and pipeline policy.
Investigate with context
Start with application fingerprints that return a Zuul web interface. Record the final URL, tenant name if it is intentionally visible, authentication method, OIDC issuer, and whether the status page is public. Do not attempt to log in or submit a job.
For a confirmed instance, ask the owner whether it is production CI, a lab, or a public demo. Review tenant access rules and the relationship between the identity provider and the projects that can run jobs. Check the composition of the 7,062 application matches for unrelated software before treating the whole number as a Zuul fleet.
Monitor changes in application fingerprint and title around known CI domains. New instances can be created for a migration or a test. A count change does not prove that the new host is configured like the old one.
Keep the measurement honest
The 955 title and 26,632 body matches are broader than the application signal. Keep all three categories separate and preserve the exact query timestamps. A host may appear in more than one category, and a body match may be documentation.
Zuul is a strong candidate for asset discovery because a reachable CI interface can expose a large operational boundary. The finding is not complete until the tenant model, OIDC policy, job execution authority, and secret scope are verified.
