Open source patch management for versions past end of life

It is the practice of getting security fixes onto an open source version the upstream project no longer patches. A provider tracks new CVEs in the version you run, backports the upstream fix to that release and gives you a signed build, so a scanner finding closes because the build is patched rather than because the version number moved. OSSeva Patch does this for the lines on the supported versions list, with Critical CVEs patched within 48 hours and High within 7 days.

Check the affected range in the CVE record against your exact version. The CVE directory lists the range for each entry, the supported versions page shows the lines OSSeva covers, and the end-of-life page for your line counts the CVEs published since it ended. For a patched build, the VEX statement says per CVE whether it is fixed, not affected (with a justification) or under investigation, so an auditor does not have to take your word for it.

No. Virtual patching puts a rule in a firewall, WAF or intrusion prevention system that blocks a known exploit pattern while the vulnerable code stays in the application. Patch changes the code: the upstream fix is backported to your version and delivered as a signed build. A virtual patch can cover the gap while you roll the build out, but it only covers the exploits the rule matches.

OSSeva does not publish a ranking, and Patch is not patch management software in the endpoint sense. Operating system and endpoint patch tools deploy updates that a vendor has already released; vulnerability scanners find the components that need them. Neither can supply a fix that no one has released for an end-of-life open source version. That is the gap Patch fills, and it works alongside whatever deployment and scanning tools you already run.

There is nothing to backport, so the CVE stays open in the VEX statement with status affected, and the CVE record documents a configuration mitigation where one exists. A build is marked fixed only when it contains a fix. If upstream later ships a fix on a newer line, OSSeva backports it to the covered versions on the patch window above.

Each OSSeva CVE patch delivery includes: the patched binary build for all affected supported versions, a signed checksum file, a GPG-signed artifact for Maven or an OCI-signed container image for Docker, a CVE attestation letter documenting the vulnerability ID, CVSS score, affected versions, and fix description, and — for Assure customers — a compliance mapping to relevant audit frameworks.

OSSeva engineers actively participate in the OSS security community, monitor NIST NVD, GitHub Security Advisories, and vendor-specific mailing lists, and maintain relationships with upstream project maintainers. For technologies we support, we receive advance notice through coordinated disclosure processes and have internal tooling to detect vulnerable patterns in the codebases we maintain.

Yes. OSSeva signs all Maven artifacts with a GPG key (Key ID B7C4E831, fingerprint E8A1 3F92 D4B7 C401 8E35 F067 A293 B84C E7C4 E831) and all container images using Sigstore cosign. SHA-256 checksums are also provided for every binary release. Customers can independently verify integrity before deploying in any environment.

OSSeva patches all CVEs with a CVSS score of 4.0 or higher that affect supported runtimes. Low-severity issues (CVSS < 4.0) are evaluated case-by-case and typically bundled quarterly. All CVE decisions are documented in the customer-facing vulnerability directory with triage notes.

A backport applies the security fix from a newer upstream version to an older EOL version, without changing the runtime's public APIs, behavior, or configuration surface. This is critical for enterprises: a backport lets you close the CVE without the compatibility testing, code changes, and operational risk of a major version migration. OSSeva specializes in surgical, tested backports — not version upgrades.