Version Drift Is the Finding: Why Knowing the Version Beats Scanning the Endpoint

1. The scan-budget tax of symptom probing

A traditional vulnerability scanner walks a target and tries to elicit a behaviour: a banner, a stack trace, a default page, a malformed-response leak. The behaviour is then mapped backwards to a known weakness. This pattern carries a fixed tax. Every endpoint probed consumes a budget: TCP connections, HTTP requests, time inside a WAF rate-limit window, attention from the customer's SOC. When the customer has 600 internet-facing services and the scanner budget is 90 minutes, the question is not can we detect this CVE, it is can we detect it before we get throttled, banned, or noisy enough to land in someone's morning triage queue.

The cheapest, highest-leverage observable on any given service is its software version. Not the inferred behaviour. Not a fingerprint cluster. The version. Once you have the version, the NVD, EPSS, and CISA KEV feeds tell you everything else for free.

We have spent the last six months rebuilding our scanning core around that observation. The result is the AI-KB Version Vulnerability Projector: a component in our pipeline whose entire job is to take a fingerprint, resolve it to a version, and project every known CVE the version inherits from its dependency graph. Most of our customer findings now come from that projector rather than from any specific symptom probe.

2. What "version" actually means in 2026

The naive definition of version, a string like nginx/1.24.0 in a Server: header, is a starting point, not the answer. A modern stack carries six version layers, and a real projector has to walk all of them:

1. Server software (nginx, Apache, IIS, Caddy, Envoy). Trivially observable. Often anonymised by the front-door config; sometimes the underlying version still leaks via error pages, redirect headers, default 404 templates, or HTTP/2 frame-size quirks.
2. Application framework (Django, Rails, Spring Boot, Next.js). Detected via cookie names, static-asset path conventions, default error pages, JS chunk hashes.
3. Application library (the npm and PyPI dependency tree). Visible in bundled JS chunks, in package-lock.json artefacts the CI pipeline accidentally publishes, in Sourcemaps the team forgot to strip, in npm pack manifests cached on a CDN.
4. Runtime (node, python, java, go). Sometimes leaked via the Server header, often inferred from response-shape quirks (e.g. Date: header precision, Connection: capitalisation).
5. Container base image (alpine, distroless, ubi9). Visible from Server header oddities, from /health endpoints that include build metadata, from X-Backend-Server style headers.
6. Underlying OS kernel (for self-managed VMs). The hardest layer to elicit remotely. Usually inferred from response timings, TCP fingerprints, or, on cloud, from the published AMI / image manifest if the customer has not rotated their build pipeline.

A scanner that has resolved all six layers can project the union of every CVE that touches any layer, weighted by exposure path. A scanner that has only resolved layer 1 misses 80 percent of the inherited exposure.

3. The projection step

Once the layered version is known, the projection is mechanical. Pseudocode:

def project_cves(fingerprint: StackFingerprint) -> list[CVEProjection]:
    projections = []
    for layer in fingerprint.layers:
        for cve in cve_index.matching(layer.component, layer.version_range):
            projections.append(
                CVEProjection(
                    cve_id=cve.id,
                    layer=layer.name,
                    component=layer.component,
                    version=layer.version,
                    cvss=cve.cvss,
                    epss=epss_index.score(cve.id),
                    in_kev=kev_index.contains(cve.id),
                    patch_available=patch_index.exists(cve.id, layer.version),
                    exploit_chain=chain_index.starts_at(cve.id),
                )
            )
    return rank(projections)

The ranking step is the part vendors rarely show. A naive sort by CVSS produces a list dominated by theoretical-only-by-CVSS-7.5 issues that nobody is exploiting. Our ranker combines four signals:

• CVSS (severity ceiling).
• EPSS (probability that exploitation will occur in the next 30 days, from the FIRST EPSS model).
• KEV membership (CISA has observed exploitation in the wild).
• Chain start (the CVE is the first node of a known chain we have weaponised in a Proof Capsule, so even a low-CVSS first node may unlock a critical end state).

A finding that scores EPSS > 0.5 or appears in CISA KEV jumps the queue regardless of its CVSS. A finding that opens a known chain inherits the chain's end-state severity.

4. The economics of projection vs probing

For the same scan budget, projection wins by an order of magnitude.

Probing for CVE-2026-3854 (the GitHub git push RCE we covered in our CVE review) requires authenticating into a clone path on a GHES instance, sending a crafted push, and observing the response. Per target this is on the order of 8-15 seconds and several authenticated requests, against a CI surface that is monitored and rate-limited.

Projecting the same CVE requires identifying that the target is GHES, resolving the version (a single HTTPS request to /api/v3/meta), and looking up the version range. Per target: one request, sub-200 milliseconds, no auth.

For a customer with 12 internal GHES instances behind a single load balancer, the probing path costs ~150 seconds of credentialled traffic against the customer's most security-sensitive surface. The projection path costs 12 requests and produces the same finding with a higher confidence score, because the version match is deterministic where the probe is heuristic.

The Proof Capsule for CVE-2026-3854 still ships a probe, projection identifies the exposure, but the customer wants to see a benign demonstration before they re-prioritise the patch. The point is that the projection is what finds the finding; the probe is what closes the loop on demand, under the customer's controlled-blast-radius rules.

5. The two failure modes we tune for

Projection fails in two directions, and both have to be measured.

False projections (the version says vulnerable, the host is not). The most common cause is an out-of-band patch the vendor shipped without bumping the public version string. Microsoft's monthly cumulative update model does this on purpose; many Linux distributions backport security fixes into their stable channel without changing the upstream version. Our defence is per-distro patch-status lookups: when the layered fingerprint shows nginx/1.24.0 on Debian 12, the projector queries the Debian security tracker for the per-distro fixed version before emitting the finding. If the distro has already shipped the fix, the projection is downgraded to "version-matches-upstream-but-distro-patched" and parked.

Missed projections (the host is vulnerable, the version did not match). The most common cause is a non-default build the customer compiled from source, where the version string is nginx/1.24.0 but the patch the version implies was never applied. We catch this by cross-checking the binary's build hash where we can reach it (via /sbin/nginx -V-style admin endpoints when authenticated) and by falling back to behaviour probes for the highest-severity inherited CVEs even when the projection says clean.

The honest metric is the agreement rate between projection and probe across the customer's installed base. We publish this quarterly to every customer. In Q1 2026 the agreement rate across our active engagements sat at 94.2 percent, meaning 5.8 percent of projections needed a probe before they shipped. We are tuning the layered fingerprint to push that number into the high 90s.

6. What the customer sees

The output is a single dashboard view per asset: the layered version stack, the projected CVE set, the EPSS-weighted top-10, and a one-click "show me the Proof Capsule" link for each. No customer has ever asked us for more, they ask us for less, and our job is to keep the noise floor low.

We keep saying it because we mean it: verifiable security. Projection beats probing because projection produces a fact (the version) that the customer can act on without our involvement. The Proof Capsule beats a scan report because the Capsule is reproducible, signed, and auditable months after the fact.

If your current scanner is still spending 80 percent of its budget on symptom elicitation, the budget is the bug. Resolve the version. Project the inherited graph. Probe only the projections that the customer's risk appetite requires you to demonstrate. The customer will see fewer, sharper, higher-confidence findings, and the SOC will stop opening a ticket every time a scan runs.

Verifiable security.