Backporting and CVE related findings

What is Backporting?

Backporting is the process of applying a fix, feature, or security patch from a newer version of software to an older version. This is commonly done in enterprise Linux distributions to ensure security and stability without upgrading to a newer major version, which might introduce breaking changes.

Why is it necessary?

Security Without Disruption:
- Organizations often run older, stable software versions. Backporting ensures they get security patches without upgrading to potentially unstable or incompatible newer versions.
Enterprise Stability:
- Production environments demand stability. Backporting avoids the risks of full upgrades.
Long-Term Support:
- Many Linux distributions guarantee support for older releases (e.g., RHEL 7), and backporting helps fulfil that promise.

How does it work?

When a new vulnerability (such as a CVE) is disclosed, the fix is first developed in the current upstream version of the software. The distribution's package maintainers then review that fix and apply it to the older, stable version they ship. If the fix is compatible with the older version, it is tested and released as a security update; if it is not, the maintainers apply an alternative fix. In either case, the vulnerability is resolved in the older release while the version number it reports usually stays the same.

Why backported software can appear vulnerable on your scorecard

SecurityScorecard identifies patching-cadence findings from the version a service advertises externally, then matches that version against published CVEs. When a distribution backports a fix but leaves the version string unchanged, the service still advertises the older version, so the finding is raised even though the vulnerability may already be patched. See examples below.

How to confirm whether a fix has been backported

Check the installed package on the affected host, or the vendor's security tracker:

RHEL, CentOS, Alma, or Rocky: run rpm -q --changelog <package> | grep CVE, or check the Red Hat CVE/RHSA tracker.
Debian or Ubuntu: run apt changelog <package> | grep CVE, or check the Debian or Ubuntu security tracker.

If the changelog or tracker shows the CVE has been addressed in your installed package release, the fix has been backported.

Examples

Apache httpd:

{
  "name": "http",
  "product": "Apache httpd",
  "version": "2.4.37",
  "extra_info": "(Oracle Linux Server) OpenSSL/1.1.1k"
}

Breakdown:

Apache httpd version shown: 2.4.37
OS vendor: Oracle Linux
Version of OpenSSL that Apache was compiled against: OpenSSL 1.1.1k

Checking this information against CVE-2021-44790 for example:

Is vulnerable based on version?
- Yes, if using <= 2.4.51, Fixed in Upstream: 2.4.52
Is vulnerable in an Oracle Linux 8 context?
- Fixed in ELSA-2022-0258 version httpd 2.4.37-43.1
- The displayed version remains 2.4.37.

Conclusion:

There isn't enough information on the version to ensure that it is using a package that contains the backport. We would need validation against the changelogs of the running version.

OpenSSH:

{
  "product": "OpenSSH",
  "version": "8.4p1",
  "banner": "SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u3"
}

Breakdown:

Product: OpenSSH
Upstream version: 8.4p1
Banner: It is an initial text message sent by a server to a client immediately after a connection is established, before any authentication happens. Here "SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u3", it indicates here Protocol Version "SSH-2.0", Product & Upstream Version "OpenSSH_8.4p1", OS Distribution "Debian" and Package Revision "-5+deb11u3".

Checking this information against CVE-2021-41617 for example:

Is vulnerable based on version?
- Affects: OpenSSH 6.2 through 8.x before 8.8
Is vulnerable in a Debian "Bullseye" context?
- Fix in 1:8.4p1-5+deb11u3
- See https://security-tracker.debian.org/tracker/CVE-2021-41617 ,
  https://security-tracker.debian.org/tracker/source-package/openssh

Conclusion:

There isn't enough information on the version (8.4p1) to ensure that it is using a package that contains the backport. However, the banner contains package information that is an indication of the version of the package installed and running. We would need validation against the changelogs of the running version.

How to resolve the finding

If you have confirmed the fix is backported, submit the finding as a compensating control:

Select the finding(s).
Select Other resolutions.
Select "I have compensating controls."
Provide supporting evidence (for example, the package changelog entry showing the CVE fix).
Click Submit.