Build1 publisher3 min readPublished
Vendor backporting leaves the old version number that scanners flag as vulnerable
A dev.to write-up walks through a 37-finding scan on a still-supported enterprise Linux box and shows why only the vendor advisory for that exact package on that exact minor release can settle it.
The Engineer · Build desk
What happened
- A dev.to write-up opens on a familiar standoff: an enterprise Linux server still under vendor support, and a vulnerability scanner reporting 37 findings against it.
- Red Hat's Extended Update Support covers security updates for specific minor releases and Ubuntu's Extended Security Maintenance covers supported LTS releases, with scope varying by package and architecture.
- The post sets out a validation process that routes a finding through the vendor advisory, lifecycle status and coverage checks before anyone calls it actual exposure.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint The ticket closes on the vendor advisory for that package on that minor release, and somebody has to go and read it; a version-string comparison is not enough.
- decision Each finding on an extended-support host needs a named owner for the errata lookup before it can become a patch request or a documented risk acceptance.
- exposure Because coverage turns on repository, severity and support tier, some findings are real work that no subscription closes, and they land on the teams least able to migrate.
- cost The same four teams meet every scan cycle because the advisory data is not in the scan output.
The example finding in the post lists a package, an installed version and an upstream fixed version, and the obvious reading is that installed is lower than fixed, so patch it [9]. That reading is a statement about the upstream project's release history. Red Hat documents taking a security fix from a newer upstream version and applying it to the older version of the package it distributes [10]. In the write-up's illustration, upstream fixes the CVE at 3.2 while the enterprise package stays at 3.0 with the fix backported in, and the CVE is addressed [11].
For a version compare to settle the question, the scanner would have to be reading the vendor's advisory for that package on that minor release. Comparing an installed package version against an upstream version can produce misleading conclusions, the post says [12]. In my view this is a data-plumbing problem before it is a risk problem: two teams quote numbers at each other from different version namespaces.
The support side covers several separate claims too. Red Hat's Extended Update Support provides security updates and bug fixes for specific minor releases, and Ubuntu's Extended Security Maintenance covers supported LTS releases. Exact scope depends on the product, release, package, architecture and support offering [8]. Ubuntu's ESM documentation distinguishes different package coverage areas and support streams [20]. Coverage can also turn on repository, severity, subscription or support tier, and technical feasibility [13]. So the post replaces "Is this OS under ELS?" with a narrower question: "Is this specific vulnerability covered for this specific package on this specific release?" [14]
In the post's version of the standoff, the application team says "The OS is supported. Why are you asking us to patch it?" and the vulnerability team says "The scanner says it's vulnerable." [2][3] Both sentences can be true at once. The lifecycle it sketches runs new release, standard or full support, maintenance support, extended support, end of life, and "supported" does not always mean everything receives the same level of updates [6][7].
The proposed validation chain starts at the scanner finding, identifies OS and package, checks the vendor advisory, checks lifecycle and support status, checks extended-support coverage, then checks for a vendor fix or backport before determining actual exposure. Exploitability and business criticality come after that [15]. Five checks stand between the finding and the exposure call, and two more between the exposure call and the priority call [16].
The post does not give a rate for how often an extended-support finding is already covered by a backport. Asked who is right, it answers "It depends." [5] It is firmer on direction. As a system ages, application dependency, migration difficulty and business dependency rise while upgrade options, supported package scope and change tolerance fall, and scanner findings rise [17]. Extended support is designed to extend the useful and supported life of systems that cannot immediately move to newer platforms. It does not mean every vulnerability discovered anywhere in the software ecosystem will automatically be fixed for that system [18]. The post calls the combination the ELS vulnerability paradox [17].
What to watch
- Whether anyone publishes incidence data on how many extended-support findings a vendor advisory already covers.
- Whether scanners start keying findings to distribution errata for a given minor release instead of upstream fixed versions.
- Changes to Ubuntu ESM package coverage areas or to the minor-release scope of Red Hat EUS.