If you've run a security or vulnerability scan against your server recently, there's a decent chance that it flagged one or more packages as outdated or potentially vulnerable. OpenSSH is probably the most common culprit, but the same thing can happen with curl, OpenSSL, Nginx, and plenty of others. It's a reasonable thing to investigate. But in most cases it's also a false alarm.
It's a bit like checking whether a car is roadworthy by looking at its model year, rather than its service history.
This comes down to a type of patching known as “backporting”, which is invisible to these scanners. Here's what's actually going on.
How Linux distributions package software
Enterprise Linux distributions, like Ubuntu (which we use for Cloud Containers), AlmaLinux or Debian, don't simply pull the latest upstream version of every package the moment it's released. Instead, each distribution takes a snapshot of a package at a particular version, and then maintains that version for the life of the release.
As an example, Ubuntu 24.04 LTS (Noble Numbat) is the most recent long-term support version of that distro. It’s packaged with OpenSSH version 9.6p1 and standard support will continue through to April 2029. Its predecessor, 22.04 (Jammy Jellyfish) is also still in support (to April 2027), and is packaged with OpenSSH 8.9p1.
Those are the versions of OpenSSH that Noble and Jammy were released with, and which they will keep for their entire lifespans. So, what happens when a vulnerability is discovered in OpenSSH?
When a security vulnerability is discovered in a package (which might be OpenSSH, curl, OpenSSL, or anything else), the distribution's security team reviews it, develops a fix, and backports that patch into the version they ship. To carry on our example, the Ubuntu team would backport any OpenSSH patches to the versions that they still support, including 9.6p1 (for Noble Numbat) and 8.9p1 (for Jammy Jellyfish).
The version number on the package doesn't change. OpenSSH 9.6p1 is still 9.6p1. The fix is still in there—it just isn't advertised in the version string.
Backporting is standard practice across every major Linux distribution. It's actually a sign of a well-run distribution, not a neglected one.
Why scanners get it wrong
Most vulnerability scanners, including popular tools used for compliance audits, check a package's reported version number against the upstream project's release history. In the case of OpenSSH, that history now includes version 9.9p2.
So if your virtual server is running Ubuntu Jammy, which is still in support for another year, then a scanner will see that you’re running OpenSSH 8.9p1, and report it as outdated and potentially vulnerable to everything that’s been fixed up to 9.9p2. The scanner doesn’t see any of the backported fixes that Ubuntu have made over the same timespan.
The problem: the scanner is making the wrong comparison for systems running distribution-managed packages. It ought to check the distribution's own security advisories—Ubuntu's, AlmaLinux's, Debian's—not the upstream project's changelog. And this problem applies to other upstream projects like curl, OpenSSL, Nginx, and others.
A server running Ubuntu 24 or AlmaLinux 9 will have received all the relevant security backports for its package versions. The version number is lower, but the security posture is not.
It's a bit like checking whether a car is roadworthy by looking at its model year, rather than its service history. A well-maintained older model can be perfectly safe even if a newer one exists.
Image by lynnemthompson from Pixabay.
Can't you just tell vulnerability scanners what’s gone on?
There’s no easy or surefire way to solve this problem. The most obvious method would be for our servers to somehow advertise a package version number that isn’t literally true, but does tell scanners how up-to-date our patching is. For example, perhaps our fully backported instances of OpenSSH 8.9p1 could start calling themselves 9.9p2.
This is technically possible, but not a good idea. In the case of OpenSSH it isn't possible without recompiling the package from source, and that's something we're not willing to do for any package. Using each distribution's official packages means we stay in lockstep with their security teams and update processes. Compiling our own binaries would mean taking on responsibility that rightly sits with Canonical for Ubuntu, the AlmaLinux OS Foundation for AlmaLinux, or the Debian Security Team. This is clearly the wrong trade-off.
Backporting is standard practice across every major Linux distribution. It's actually a sign of a well-run distribution, not a neglected one.
So package versions will always appear a generation or two behind the upstream releases. That's by design, not by accident.
What we patch, and when
For anything rated critical or high severity, we move quickly. If a genuine vulnerability emerges in any package on your server and it isn't covered by an existing backport, we'll push an update as a priority. That’s equally true for any package: OpenSSH, OpenSSL, curl, Nginx, etc.
For lower-severity issues, the reality is that patching takes time. Across Cloud Containers, images need to be tested, staged, and rolled out carefully. On managed servers, updates need to be scheduled to avoid disrupting running workloads. We work through lower-priority updates over time, typically within a few months. This is standard practice across the hosting industry, and consistent with how the distributions themselves handle their support cycles.
Critical CVEs get fast-tracked. We don’t let urgent issues sit.
This work has gotten more complex as the number of published CVEs has exploded in recent years. It’s now completely normal for well over a hundred new CVEs to be published daily, and for 40% of those to be rated as critical or high severity. Our routines have adapted to fit this new reality.
If you're running scans for compliance
This is where the conversation gets more nuanced. There are two main reasons that customers run vulnerability scans:
The one-off scan. Maybe a client asked for it, or you're doing due diligence before a launch. If packages like OpenSSH come up as findings, you can note them in your report with the context in this article. Simply, the packages picked up in your scan include security backports that are not reflected in the version string. Most auditors familiar with Linux distributions will accept this explanation.
Ongoing compliance requirements. If you're running regular scans as part of a PCI DSS, ISO 27001, or similar compliance programme, you need more than a one-time explanation. You need documentation, a remediation schedule, and evidence that vulnerabilities are being tracked and addressed in a timely way.
If that sounds like your situation, we should talk.
Can we shoulder your compliance burden?
If you have ongoing compliance requirements, our Premium Server Management is designed for exactly this kind of work. We can work with you to set up a regular scanning schedule, review the findings with the appropriate context (like the backport model used by Ubuntu, AlmaLinux, or Debian), and plan remediation for anything that genuinely needs attention. Where a finding is a false positive, we can help you document that. Where it's real, we'll fix it.
The goal is to take the compliance burden off your plate and give your auditors the evidence trail they need.
If you're on a Cloud Container or a managed server and want to talk through your security scanning requirements, get in touch. We're happy to work out what makes sense for your situation.
Photo by Moheb Iskander on Unsplash