skip to content

A vulnerability scan of a hardened Linux fleet reports dozens of critical findings the owners insist are already patched — how did the scanner most likely reach them, and how do you confirm it?

level: seniorimportance: must knowfreq 40%

answer

  1. what string did the check compare
  2. long-term-support distributions patch differently
  3. upstream version versus package release
  4. changelog and distribution advisory

basics

~20 s

Most likely by banner inference: distributions that backport security fixes patch the code without raising the upstream version, so the service still advertises an affected version. Confirm by reading the installed package release and changelog against the distribution's advisory.

solid answer

~50 s

Distributions with long-term support usually *backport* security fixes: they apply the upstream patch to the version they ship and raise only the package's own release number, so the service keeps advertising the old upstream version. An unauthenticated check that compares that banner with the upstream affected range reports a flaw that is no longer there — the classic false positive. To confirm, I first look at the evidence each finding cites: a banner string means remote inference, an installed package version means a local check. Then on a representative host I read the installed package's full version and release, search its changelog for the CVE, and compare with the fixed release in the distribution's own advisory. If the fix is there, a credentialed scan, which compares package releases with the distribution's advisory, should stop reporting it. If it does not, the finding may be real.

code

pseudocode · 14 lines
pseudocode
# Remote check: only the upstream version is visible
banner_version = parse_version(service_banner)          # "2.4.6"
if version("2.4.0") <= banner_version < version("2.4.10"):
    report("vulnerable", evidence=service_banner)      # backported hosts land here too

# Local check: the package record carries the distribution release
installed = local_package_version("web-server")        # "2.4.6-41"
fixed = distro_advisory_fixed_release("web-server", cve)  # "2.4.6-40"
if fixed is none:
    report("vulnerable, no fix released", evidence=installed)
else if compare_package_versions(installed, fixed) < 0:
    report("vulnerable", evidence=installed)
else:
    report("not affected", evidence=installed + " >= " + fixed)

go deeper

for a junior

Recall that a distribution can fix a flaw without changing the version number the software advertises, which fools checks that read only that number.

for a middle

Explain the chain from banner to finding: the advertised upstream version is matched against the upstream affected range, while the distribution release that carries the fix is invisible from the network.

for a senior

Demonstrate the confirmation path on one host: the evidence the finding cites, the package release and changelog against the advisory, restarts, and the second-copy cases where the finding is real.

for a principal

Argue for changing the evidence rather than arguing findings: credentialed local checks against distribution advisories remove the whole class, while per-finding debate scales with the fleet.

## What a backport is A software project fixes a security flaw in a new upstream release — say the bug affects versions `2.4.0` up to, but not including, `2.4.10`, and `2.4.10` fixes it. A distribution that promises long-term stability does not want to jump its customers to a new upstream version mid-lifecycle, because that drags in features and behaviour changes. So it **backports** the fix: it takes the patch, applies it to the `2.4.6` it already ships, and publishes a new package whose **upstream version stays `2.4.6`** while its **distribution release number goes up** (for example from `2.4.6-40` to `2.4.6-41`). The code is fixed; the version string the software reports about itself is not. Appliance and embedded-system vendors often do the same, shipping their own patched builds of open-source components under the original upstream version. ## How a banner check turns a backport into a finding The chain is mechanical: 1. The service starts and advertises the version it was built as: `2.4.6`. 2. An unauthenticated check reads that banner — the only evidence it has. 3. The check compares `2.4.6` with the upstream affected range `2.4.0 <= v < 2.4.10`. 4. The comparison matches, so the scanner reports the flaw at the severity the check carries. 5. Multiply by every host and every flaw the distribution backported since `2.4.6`, and a well-maintained fleet produces dozens of "critical" findings. Nothing in this chain is a scanner bug. The check did exactly what it was written to do; its evidence simply cannot carry the fact that matters. ## Confirming the cause, host by host The owners' certainty is a claim, not evidence. Confirm it on a representative host before the findings are treated either way: 1. **Read the evidence the finding cites.** Most reports show what was observed: a banner or response string points to remote inference; an installed package version points to a local check. 2. **Read the installed package's full version and release**, not the version the service prints. 3. **Search the package changelog for the CVE identifier.** Distributions usually record the backported fix there. 4. **Compare with the distribution's own advisory** for that release, which names the first fixed package release. 5. **Check the running process** — a fix on disk only protects a service that has been restarted since the update. If the installed release is at or above the advisory's fixed release, the finding is a backport false positive. Do this on one host per distribution release and per role, not on all of them: if the representative host is fixed, the same package release elsewhere is fixed too, and what remains is making sure every host actually runs that release. ## When the finding is real after all A disputed finding is not automatically false. It stays credible when: - **A second copy exists** — the same software built from source, shipped inside an application, or bundled as a library, which the package manager does not track and the distribution never patched. - **The distribution has not shipped a fix** for that release yet, or has decided not to. - **The process predates the update** — the package is fixed on disk, but the long-running service still runs the old code. - **The check already used local evidence** — a credentialed finding that names an unpatched package release is evidence, not inference. ## Evidence and what it proves | Evidence | What it proves | |---|---| | Service banner shows an affected upstream version | Only what the service advertises | | Package version and release at or above the advisory's fixed release | The fix is installed on disk | | Changelog entry naming the CVE | The distribution applied that fix | | Service restarted after the update | The running code includes the fix | | A credentialed check comparing release with the advisory | A durable answer the next scan repeats | ## What to take away Backport false positives are the price of deciding from a version string that was never meant to describe patch level. The durable remedy is to change the evidence, not to argue each finding: a credentialed scan compares the installed package release with the distribution's advisory, so a fleet that is genuinely patched stops producing them, and a host that is genuinely behind keeps reporting for the right reason.

  • The scan was credentialed and still reports the CVE on a host whose distribution package is fixed. What do you look at?
    Which copy the finding names. A second, separately installed build of the same software — compiled from source, shipped inside an application, or bundled as a library — is outside the package manager and may genuinely be vulnerable. Also check whether that check compares against the distribution's advisory at all, or only knows upstream versions.
  • The package is fixed on every host, yet the flaw is still exploitable. How can that be?
    A fix on disk does not change code already loaded in memory. A long-running service keeps running the old binary until it is restarted, and every process that loaded an old shared library keeps that copy; a kernel fix needs a reboot. A check that reads the package record calls the host fixed either way, so confirm restarts before calling it remediated.

saying these in an interview costs you the question

  • If the banner shows an affected version, the host is vulnerable.
  • The owners say the hosts are patched, so the findings are false.
  • A backported fix always raises the upstream version number.
  • Once a scan is credentialed, a backport false positive is impossible.
  • Only upgrading to the newest upstream release truly fixes the flaw.