Jenkins at 3 and Kubernetes at 1: When a Small Count Means a Missing Signature

A vulnerability report that cites "only three exposed Jenkins servers" would be treated as good news. In reality it is usually a report about fingerprint coverage, and the difference matters when that number is used to justify deprioritizing a platform.

The measurements

On 20 October 2026, between 22:33 and 22:37 UTC, ZoomEye queries with sub_type="all" and a page size of one record returned:

Query	Matched assets
`app="Jenkins"`	3
`app="Grafana"`	22
`app="Kubernetes"`	1
`app="SonarQube"`	12,022
`app="Apache Tomcat"`	585,251
`app="GitLab"`	1,397,539

Jenkins, Grafana and Kubernetes are all widely deployed platforms with substantial internet-facing populations. SonarQube, a far less ubiquitous tool, returns four orders of magnitude more matches.

Why the numbers invert

A product fingerprint requires a distinctive, stable, safely observable response. SonarQube emits a recognizable web interface with identifiable markers on a predictable path. That makes a reliable signature easy to write.

Jenkins also has a distinctive interface, but it is frequently deployed behind reverse proxies that rewrite headers, customised with themes, or restricted to internal networks. Its detection may depend on a path or marker that is often absent.

Kubernetes is not a single application. An API server, a dashboard, an ingress controller and kubelets are separate components with separate exposure profiles. A signature labelled for the platform may correspond to an extremely narrow detection condition, which produces a count that describes the condition rather than the deployment.

Grafana's 22 is likely to reflect a specific authentication redirect or version marker that most deployments do not present to an unauthenticated scanner.

What this means for prioritization

If an exposure count is used to rank platforms by risk, a missing signature silently removes an entire product class from consideration. That is the failure mode to guard against.

A practical check before trusting a low count: query a neighbouring form of the same product. If app="Jenkins" returns 3, try a title query, a header query, or a path-specific marker. A large difference between related queries is evidence of a signature gap rather than a small population.

A second check: compare against your own deployment reality. If your organization operates forty Jenkins instances, a global count of three is obviously not a measurement of the global population.

The platforms that do yield stable counts

SonarQube at 12,022 and Tomcat at 585,251 are useful precisely because their signatures are stable. Jenkins and Kubernetes are not, and no amount of repeated querying changes that.

The methodological consequence: build exposure arguments on products whose fingerprints are reliable, and use internal inventory for the rest. A scan can support the first case and cannot support the second.

For a defender operating Jenkins, the useful external question is not "how many are exposed globally" but "is any instance of ours answering from a public address." That question is answered by scanning your own address space, and the answer is binary.

The CI/CD consequence

This matters more than for a typical web application because CI/CD servers hold deployment credentials. A Jenkins instance with build credentials can modify production artifacts, which is a supply-chain position rather than a hosting position.

For that reason, the appropriate default is that no CI/CD server answers from the public internet. Where a build agent must be reachable, it should be the agent, not the controller.

An organization relying on an external count of "three exposed Jenkins servers globally" to conclude that its own instance is safe would be making an inference the data cannot support.

A note on the honesty of measurement

Publishing a count of 3 for Jenkins without stating that signatures are incomplete would be technically accurate and practically misleading. The same applies to a count of 1 for Kubernetes.

This series reports counts with their queries and treats implausible values as evidence about the tool rather than about the world. That discipline is not pedantry; it is the difference between a measurement and a number.