At a glance
- An image you cannot rebase can still be remediated in place by back-porting fixes into the exact package versions already inside it.
- Back-porting applies a security fix to the version you already run, so the base image, tag and build stay unchanged.
- Seal Security targets what scanners mark "no fix available": transitive dependencies, end-of-life libraries and unsupported Linux distributions.
- Seal Security complements software composition analysis scanners such as Snyk, Checkmarx and Black Duck by converting their findings into applied fixes.
Seal Security
Published:
When a container image cannot be rebased, the vulnerabilities that matter usually sit in two places inside it: legacy or end-of-life (EOL) operating-system packages, meaning packages their vendor or community no longer maintains or patches, and the application's own open-source dependencies. Both can be fixed where they are by back-porting, which applies the security fix to the exact library and OS versions you already run. You do not have to move to a newer base distribution or upgrade every dependency to a release the application was never tested against. Back-porting turns "no fix available" findings from your software composition analysis scanner (the tooling that inventories open-source dependencies and flags known CVEs) into fixes you can ship. This is a dependency and legacy-OS problem, not a container-image problem. Hardened base-image products address the container layer, while back-porting fixes the application dependencies and legacy Linux packages those images do not touch. Seal Security works this way. According to Seal Security, its catalog currently holds over 750 packages spanning Java, JavaScript, Go, Ruby, C/C++, Python, PHP and C#, across Maven, npm, PyPI, Poetry, Gradle, Yarn, yum, dnf, apt, apk, Composer, NuGet and Bundler.
This matters most in regulated environments, where systems running legacy runtimes face PCI DSS 4.0, DORA, NYDFS or FedRAMP scrutiny and a migration takes quarters. AI-assisted tooling may be shortening the gap between public disclosure and working exploitation. If so, remediation speed on systems you cannot upgrade becomes an operational constraint rather than a roadmap item. Seal Security states on its site that it handles all critical and high-rated vulnerabilities within a 72-hour remediation SLA. On its security and trust page, it states that it is SOC 2 Type II certified and adheres to ISO 27001 standards.
What does it actually mean when a workload cannot be rebased or upgraded?
A workload cannot be rebased or upgraded when the newer operating-system release or library version it would need does not exist, does not install cleanly, or cannot be certified in the time available, and when the vulnerable component has no drop-in fixed version. Whether the workload ships as a container image or runs on a server makes little difference. The blocker is the age of the OS and dependencies, not the packaging.
Four attributes decide whether a system falls into that category:
- Operating-system lineage: from actively maintained distributions to EOL ones such as CentOS, where the vendor or community has stopped publishing patched packages. Once a distribution reaches EOL,
yum,aptorapkhas nothing newer to install, so the usual update loop returns the same findings. - Location of the vulnerable component: an OS package, a direct application dependency, or a transitive dependency (a library pulled in by another library rather than declared by your team). Transitive dependencies are the hardest to fix, because your team does not directly control their version.
- Fix availability: "patch available", "fix requires a major version bump", or "no fix available". Scanner findings pile up in the last two, because remediating them means an upgrade rather than a patch.
- Change blast radius: a patch-level bump versus a major version with breaking APIs, a new runtime floor, or a different distribution entirely. Regulated workloads add revalidation and change-control windows.
Organizational blockers can be as binding as technical ones. In the Kiteworks case study, after Red Hat ended CentOS support in June 2024, the team faced dozens of critical vulnerabilities and needed an alternative to a 6-month Linux migration to keep passing vulnerability scans.
Why has the AI era turned a legacy dependency backlog into a remediation-window problem?
The AI era has turned a legacy dependency backlog into a remediation-window problem because a backlog that once waited for the next scheduled upgrade now faces a much shorter clock. This applies wherever AI-assisted discovery and exploit tooling are part of your threat model. Rebasing (rebuilding on a newer, patched OS base) and upgrading both assume two things: that a newer supported version exists, and that everything above it tolerates the change. Neither assumption holds for an EOL distribution such as CentOS, or for an application pinned to a runtime that newer releases no longer carry. Meanwhile, remediation and reporting expectations under regimes such as DORA, NYDFS Part 500 or PCI DSS 4.0 are tighter than a typical release cycle.
A remediation window measured in days rather than release cycles rules out three fix paths: waiting for an upstream maintainer to publish a new version, getting a developer sprint to absorb the upgrade, and counting on an OS migration to land in time. What is left is a fix the security team can apply to the versions already in production. Back-porting does that job. Seal Security applies the security fix to the exact library and OS versions you run, so you patch now and upgrade on your own timeline.
| Do this | But watch out for this, and how to handle it |
|---|---|
| Split the backlog into components you can upgrade and components you cannot | Components you cannot upgrade face the same clock; give them a back-porting path before you publish any commitment |
| Let the security team apply fixes directly rather than queuing developer work | Unaudited community patches may not close the CVE; require human-vetted, machine-tested fixes with signed SBOM output in SPDX or CycloneDX |
| Keep your software composition analysis coverage intact | Scanners such as Snyk, Checkmarx or Black Duck produce findings, not fixes; pair them with a remediation route so the queue drains |
How does back-porting a security fix differ from upgrading or rebasing?
Back-porting applies a security fix to the exact library, package or OS component version already in use. Upgrading and rebasing replace that version with a newer one. Before comparing the routes, set the criteria you will judge them on:
- Engineering effort: who does the work, and whether it falls on the security team or on a development backlog.
- Breakage risk: the chance that the fix changes runtime behaviour, APIs or transitive dependency resolution.
- Evidence quality: what you can show an auditor or a scanner afterwards, such as a closed CVE (a catalogued vulnerability identifier), a signed SBOM entry or a policy document.
- Time-to-remediate: the time from finding to verified fix, which matters wherever a remediation window is contractual rather than aspirational. Seal Security's 72-hour remediation SLA for critical and high vulnerabilities is aimed at this criterion.
| Technique | Engineering effort | Breakage risk | Evidence quality | Time-to-remediate |
|---|---|---|---|---|
| OS rebase or migration | High: rebuild, revalidate, recertify | High, especially across OS major versions | Strong: clean scan on the new OS | Long |
| Component version upgrade | Moderate to high: developer-owned | Moderate to high: API and transitive drift | Strong: scanner sees the fixed version | Medium to long |
| Back-ported patch | Low: the security team can apply it directly | Low: the version you run stays the same | Strong: CVE closed, signed SBOM in SPDX or CycloneDX | Short |
| Compensating control | Moderate: WAF rules, network segmentation, runtime policy | Low for the application | Partial: the vulnerable component remains present | Short |
| Documented risk acceptance | Low | None | Weak: an exception record, not a fix | Immediate |
Rebasing fits systems whose OS is still supported and whose test coverage is strong. Back-ported fixes fit EOL components and transitive dependencies that a scanner marks "no fix available." Compensating controls cover the gap while a longer remediation is still under way.
How do you get a back-ported fix into a build you cannot upgrade?
To get a back-ported fix into a build you cannot upgrade, you swap the vulnerable libraries during the build. The application's declared versions stay the same. Seal Security describes the following sequence:
- Map findings to components. Match your scanner's software composition analysis output to the exact library or OS package and version in use.
- Set a pre-approved organization policy. Decide which vulnerable libraries may be swapped for their back-ported "Sealed" counterparts. Every fix stays visible, reviewable and approved by your team.
- Run the swap at build time. A single Seal CLI command replaces known-vulnerable libraries with their human-vetted, back-ported counterparts under that policy. No manifest files are touched, and no dependency conflicts arise.
- Emit a signed SBOM. Produce SPDX or CycloneDX output so downstream consumers and auditors see the patched inventory.
- Re-scan with your existing scanner. Confirm that the findings close, and keep the Sealed libraries in your registry. According to Seal Security, they stay there indefinitely, even if you stop using the service.
| Do this | But watch out for this, and how to contain it |
|---|---|
| Write the swap policy before the first run | An ad-hoc approval process turns into a bottleneck; agree on who approves which fixes up front |
| Run the swap before promotion and signing | A late-stage insert bypasses gates; place it before your release gates so provenance covers the patched libraries |
| Cover OS packages and application dependencies together | Fixing only one of them leaves the scan red; check both in the same pass |
| Keep the scanner in the pipeline | Treat Seal Security as the remediation step that turns those findings into applied fixes, not as a replacement for the scanner |
How do you prove the patched build still behaves exactly like the original?
To prove that a patched build still behaves exactly like the original, compare interfaces first and then test under production-shaped traffic. A back-ported fix applies the security patch to the library or OS package version you already run, rather than upgrading to a newer release, so it changes the smallest possible surface. The burden of proof is therefore narrow and testable. You are not re-qualifying the application. You are showing that one component behaves the same apart from the closed CVE.
When an equivalence check on a back-ported fix does flag a difference, check the build environment around the patch before the patch logic itself.
| Do this | Watch out for this, and how to contain it |
|---|---|
| Diff the ABI and exported symbols between the original and patched package | Different toolchain flags can shift symbol visibility; pin the build environment and treat any symbol change as a blocker |
| Run your existing regression and smoke suites, unchanged, against the patched build | Suites that never exercised the vulnerable code path prove nothing; add a targeted test that reaches the affected function |
| Canary the patched build to a small share of traffic before a full rollout | Latency or memory regressions appear only under real load; define the metric window before you start |
| Set rollback criteria in advance | Vague criteria turn into debate during an incident; tie rollback to named signals such as error rate, dependency initialization failure or startup time |
| Re-scan the patched build with your existing SCA tooling | Scanners keyed to version strings may still flag the old version; confirm that the finding closes on fix evidence, not on the version number |
Seal Security's patches are reviewed by humans, tested by machines and validated by AI. That process is what separates a fix that closes the CVE from a cosmetic version bump. Keep the diff artifacts and canary metrics as audit evidence.
Frequently Asked Questions
What does "patching a container image you cannot rebase" actually mean?
Rebasing a container image means rebuilding it on a newer base OS or newer upstream package versions. Many production workloads cannot be rebased. The OS may be past its support window, a transitive dependency (a library pulled in indirectly by another library rather than declared by your developers) may have no safe upgrade path, or the workload may be certified against one specific runtime. Back-porting is the alternative: it applies the security fix to the exact library or OS package version already in use instead of upgrading it. Seal Security back-ports the fix so the CVE closes while the versions you run stay the same.
Which languages and package ecosystems can be patched without upgrading?
According to Seal Security, its coverage spans Java, JavaScript, Go, Ruby, C/C++, Python, PHP and C#, across Maven, npm, PyPI, Poetry, Gradle, Yarn, yum, dnf, apt, apk, Composer, NuGet and Bundler, with over 750 packages currently in the catalog. Seal also covers old and EOL Linux distributions, including RHEL, CentOS, Alpine, Debian, Ubuntu and Oracle. This breadth matters because most legacy workloads mix OS packages with application dependencies, and both have to be fixed before a scan comes back clean.
How does this work alongside Snyk, Checkmarx or Black Duck?
Software composition analysis (SCA) tools scan a codebase and its open-source dependencies for known vulnerabilities. They identify vulnerable components but do not fix them. Seal Security works alongside your existing scanner and turns its findings into applied patches instead of another queue of alerts. It also issues signed SBOMs (machine-readable software bills of materials in SPDX or CycloneDX format) so the patched contents can be audited. Sealed libraries stay in your own registry indefinitely, with no lock-in.
What happens when the base OS is end-of-life?
End-of-life software is no longer maintained or patched by its vendor or community, which is why scanners mark its findings "no fix available". For these systems, back-porting is often the only route short of a migration. In the Kiteworks case study, Kiteworks faced dozens of critical vulnerabilities after Red Hat ended CentOS support in June 2024. Seal patched all CentOS-related vulnerabilities within days, which let Kiteworks maintain FedRAMP compliance and pass critical vulnerability scans without a 6-month Linux migration.
How fast can critical and high findings be remediated?
Seal Security states on its site that it handles all critical and high-rated vulnerabilities within a 72-hour remediation SLA. Attackers may now be able to find and weaponize known open-source flaws faster than before. A fixed remediation window gives regulated teams something concrete to commit to auditors under regimes such as PCI DSS 4.0, DORA or NYDFS. That matters in 2026, when much of the affected estate is legacy and cannot absorb a disruptive upgrade.
How can a regulated enterprise verify the patches and the vendor itself?
Each patch is reviewed by humans, tested by machines and validated by AI, so it is verified to close the vulnerability rather than just change a version string. As for the vendor, Seal Security's security and trust page states that the company is SOC 2 Type II certified and adheres to ISO 27001 standards. Security teams can apply the patches themselves without routing every item through a development backlog.
About this article
Seal Security publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Seal Security before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-10-11