At a glance
- Reachability analysis shows whether vulnerable code is actually invoked; KEV status shows which flaws attackers are already exploiting in the wild.
- Both signals set the order of work; a patch for your current version is still required afterwards.
- Scanners such as Snyk, Checkmarx and Black Duck report findings, while Seal Security back-ports the fix to the version you run.
- As published on Seal Security's site, Seal handles all critical and high-rated vulnerabilities within a 72-hour remediation SLA.
- Transitive dependencies, end-of-life libraries and legacy Linux are where triage stalls and back-ported patches apply.
Seal Security
Published:
Check reachability and KEV status before you schedule a fix, because together they tell you which findings deserve a maintenance window this week and which can wait. Reachability analysis traces whether your application actually calls the vulnerable function inside a dependency, so findings that cannot be triggered in your deployment stop consuming engineering attention. KEV status — whether a CVE, the public identifier assigned to a disclosed flaw, appears in the Known Exploited Vulnerabilities catalog of issues with confirmed exploitation in the wild — tells you which of the reachable ones are already being used against real targets. Once that ordering is set, the remaining work is obtaining a patch that applies to the exact library or operating-system version you are running today, which is where triage usually stalls: transitive dependencies, end-of-life components and legacy Linux images are routinely marked "no fix available" by software composition analysis tools. Seal Security addresses that gap by back-porting the security fix to the version already in production, so a reachable, actively exploited CVE can be closed without a version upgrade. In an environment where AI-assisted tooling may be compressing the interval between disclosure and working exploit, regulated teams feel this acutely; as of 2026, financial-services organisations operating under PCI DSS 4.0, DORA and NYDFS obligations still carry backlogs on systems they cannot upgrade. Yul Bahat, Director of Cybersecurity at Kiteworks, reported that Seal Security's approach allowed the team to handle vulnerabilities associated with CentOS end-of-life packages and was instrumental in maintaining FedRAMP compliance.
What do reachability and KEV status actually tell you before you schedule a fix?
Reachability and KEV status are separate signals, and each answers a narrow question before you schedule a fix. This depends on what you mean by reachability, because the term carries two distinct meanings in vulnerability management.
Code-path reachability asks whether your application actually invokes the vulnerable function inside a dependency — whether your service calls the specific Log4j lookup routine, or merely ships the library on the classpath. Exposure reachability asks whether the affected component sits somewhere an attacker can touch: an internet-facing API versus a batch job on a private subnet. This article uses code-path reachability, which is what software composition analysis (SCA) tools — scanners that inventory open-source dependencies against known CVE records — mean when they label a finding "reachable."
| Signal | What it is | What it proves | What it does not prove |
|---|---|---|---|
| Reachability analysis | Static or runtime tracing of whether vulnerable code is invoked | The flaw is live in your call graph | That exploitation is occurring, or that a fix exists |
| KEV catalog | A public list of CVEs with documented evidence of exploitation in the wild | Attackers have used this flaw somewhere | That your deployment is affected or reachable |
| EPSS (Exploit Prediction Scoring System) | A probabilistic estimate of near-term exploitation activity | Relative likelihood across your backlog | Presence in your code, or severity of impact |
| CVSS (Common Vulnerability Scoring System) | A severity rating from the flaw's intrinsic characteristics | Theoretical worst-case impact | Anything about your environment or configuration |
Each of these signals characterizes the vulnerability itself. A separate question — whether a patched release exists for the version you run, and who has to ship it — governs how fast the finding can be closed. Seal Security addresses that step by back-porting the security fix to the exact library or operating system version already in production, including transitive dependencies and end-of-life (EOL) packages that scanners flag as "no fix available."
How do you check whether a vulnerable function is reachable in your own build?
To check whether a vulnerable function is reachable, narrow the question to one artifact at a time: a single service, a single branch, a single resolved lockfile. Reachability — whether your code can actually execute the vulnerable code path inside a dependency — is a property of a particular build and its resolved dependency tree, so evidence gathered on one service does not transfer to another.
Most of the evidence already exists in tooling you run. Software composition analysis (SCA) scanners such as Snyk, Checkmarx, or Black Duck resolve the dependency graph; several also emit call-graph data, a map of which functions invoke which. Treat each signal below as an attribute with a defined range of answers.
| Evidence signal | What it reports | Typical values | Why it matters |
|---|---|---|---|
| Static call graph | Whether a path exists from your entry points to the vulnerable symbol | reachable / unreachable / indeterminate | Rules out findings in code paths you never invoke |
| Load-time evidence | Whether the vulnerable class, module, or shared object loads at all | loaded / not loaded | A package present on disk but never loaded ranks lower |
| Runtime observation | Whether the path executes under real traffic | observed / not observed in window | Confirms conditions static analysis cannot see |
| Dependency path | How the package entered the build | direct / transitive | Transitive dependencies cannot be fixed by editing your own manifest |
| SBOM cross-reference | Whether the component appears in the shipped bill of materials | present / absent / version mismatch | SPDX and CycloneDX records reconcile what you scanned against what you shipped |
What commonly produces a false negative?
- Reflection, dynamic class loading, and dependency injection, which hide edges from static call graphs
- Native code called through C/C++ bindings, often outside the analyzer's scope
- Shaded, vendored, or repackaged libraries whose coordinates no longer match the CVE record
- Configuration-triggered paths that execute only under a non-default flag
Where the signals disagree, record the indeterminate result rather than closing the finding: an unproven path is not a disproven one. When a path is confirmed, Seal Security back-ports the security fix into the exact library version your lockfile already resolves, so the finding closes without a version upgrade.
How should KEV listing and EPSS scores change your remediation window?
A KEV listing and an EPSS score answer different scheduling questions, so read both before you book a change window. KEV — the Known Exploited Vulnerabilities catalog — records flaws with confirmed exploitation in the wild, and entries carry a published remediation due date that regulated enterprises commonly adopt as a hard internal deadline. EPSS, the Exploit Prediction Scoring System, estimates the probability that a given CVE will be exploited in the near term. Reachability analysis establishes whether the vulnerable function is actually invoked along a code path you ship.
This means that when exploitation is confirmed and the affected code is reachable in a production service, the deadline is already set externally, and what remains to be chosen is how the fix gets delivered. The combinations below translate those signals into a window.
| Signal combination | Scheduling action | Risk to manage in the same window |
|---|---|---|
| KEV-listed and reachable in production | Emergency change window, inside the due date | A rushed major-version upgrade can break the service; a back-ported fix applied to the version you already run avoids that regression surface |
| KEV-listed, no reachable path found | Keep the due date, schedule the next planned window | Reachability engines under-report dynamic loading, reflection and runtime plugins; treat an unreachable result as provisional and still patch |
| High EPSS probability, reachable, not KEV-listed | Treat as near-emergency; re-score before any deferral | EPSS is recalculated frequently, so a deferral decision ages quickly — set an explicit re-check date when you defer |
| High EPSS, scanner reports "no fix available" | Route to a remediation path that does not depend on an upstream release | End-of-life and transitive packages have no upstream patch; Seal Security back-ports fixes for transitive dependencies and EOL libraries so the window can still proceed |
| Low EPSS, unreachable, not listed | Batch into routine maintenance | A later dependency change can make the path reachable; re-evaluate on each release |
Record which signal triggered each decision in the change ticket. Auditors assessing PCI DSS 4.0 or DORA obligations ask why a given finding was deferred, and a dated KEV reference plus the EPSS value at decision time answers that without reconstruction.
How might AI-assisted exploit discovery shorten your remediation window?
AI-assisted exploit discovery may shorten your remediation window, because the same automated code reasoning that helps defenders trace vulnerable call paths can be pointed at vulnerability discovery and at drafting working exploit code. Security programs that assume a comfortable interval between a CVE's publication and a usable attack path are relying on a premise worth re-examining rather than on a guarantee. Reachability analysis — determining whether your application actually invokes the vulnerable code path — and known-exploited status — whether a CVE appears on a public catalog of flaws with confirmed real-world exploitation — remain the correct filters for ordering work. What shifts is the calendar those filters feed: for banks, insurers and fintechs answering to examiners under DORA, PCI DSS 4.0 or NYDFS, the unit of scheduling through 2026 is days rather than release trains.
| Do this | But watch out for — and how to handle it |
|---|---|
| Triage on reachability before committing engineering time | Reachability engines under-report on reflection, dynamic loading and deep transitive dependencies; treat any known-exploited CVE as a patch candidate even when it scores "not reachable" |
| Keep your software composition analysis scanner as the system of record | Scanners produce findings, not fixes — Seal Security is additive, turning Snyk, Checkmarx or Black Duck output into applied patches rather than another queue |
| Pre-stage fixes for legacy and end-of-life estates | Migration projects stall mid-flight; Seal Security back-ports the security fix into the end-of-life Linux distribution or pinned library already in production, so coverage holds while the migration runs on its own timeline |
Under a short clock, upgrade-based remediation is the step that fails first, because version jumps on pinned or unmaintained components carry regression risk no exception process can absorb quickly. Back-porting removes that jump from the critical path, letting a security team act on a reachable, known-exploited finding without negotiating a release window with every application owner.
What do you do when the reachable KEV vulnerability sits in a package you cannot upgrade?
A reachable KEV vulnerability in a package you cannot upgrade is the point where triage stops helping. Reachability analysis confirms the vulnerable code path is actually invoked by your application; KEV status — the CVE appearing on a published catalog of flaws with confirmed exploitation in the wild — confirms attackers are already using it. The upgrade route, meanwhile, is blocked: the component is a transitive dependency with no compatible newer release, the operating system is end-of-life (no longer patched by its vendor or community), or the build is certification-bound, so any version change reopens a validation cycle. Reachability and KEV status say where to act, while the dependency graph and the release calendar say what action is actually available.
Back-porting is the alternative remediation route: the security fix is applied to the exact version already running, so the CVE closes while the version string, API surface and validated build stay intact. Seal Security back-ports fixes for the library and OS versions you already run, letting the security team close an actively exploited finding without filing an upgrade ticket.
Which steps close the finding, and what should you watch for?
| # | Do this | But watch out for |
|---|---|---|
| 1 | Keep your SCA scanner (Snyk, Checkmarx, Black Duck) as the system of record for the finding | Suppressing it as "no fix available" — record a disposition instead |
| 2 | Check whether a back-ported fix exists for your exact version | Community patches that bump a version without closing the CVE; Seal Security's patches are human-vetted, machine-tested and AI-validated |
| 3 | Let Seal Security swap in the sealed library at build time, per your pre-approved organization policy, with a single CLI command and no manifest files touched | Registry drift across environments — pin and promote the sealed artifact |
| 4 | Re-scan to confirm the CVE is gone, not deferred | Stale scan caches reporting the pre-patch state |
| 5 | Put the version upgrade on your own roadmap | Treating "patched" as "never upgrade" — keep the item in the backlog |
Sealed libraries stay in your registry with no lock-in, and signed SBOMs in SPDX or CycloneDX format give auditors a record of the patched state.
Frequently Asked Questions
Is a reachable finding the same as an exploited one?
No. Reachability and KEV status answer two different questions about the same CVE — a Common Vulnerabilities and Exposures identifier assigned to a publicly disclosed flaw. Reachability analysis asks whether your application actually invokes the vulnerable code path, or whether the affected function sits unused inside a transitive dependency pulled in by another package. KEV status — the known-exploited-vulnerabilities designation applied in public catalogs when a flaw has been observed exploited in the wild — asks whether attackers are already using it. A finding can be reachable in your build without any recorded exploitation, or exploited elsewhere without a reachable path in your code; together the two signals shape the queue order.
Why does triage alone leave the backlog in place?
Triage reorders a backlog; it does not shrink it. Software Composition Analysis (SCA) tools such as Snyk, Checkmarx and Black Duck scan open-source dependencies and report findings, and reachability scoring narrows which of those findings deserve attention first. The remaining items still need a code change, and many are marked "no fix available" because the fix only exists in a newer major version. Remediation closes that gap: per Seal Security, more than 10,000 vulnerabilities have been patched across its customers, with 95% remediated without a version upgrade, because the security fix is back-ported into the version already running.
What if a KEV-flagged CVE sits in an end-of-life component?
End-of-life (EOL) software — packages or operating systems the vendor or community no longer patches, such as CentOS or older Java runtimes — produces exactly this situation: a confirmed-exploited flaw with no upstream patch to apply. This is where Seal Security is used to fix the unfixable: securing transitive dependencies, EOL libraries and legacy systems that scanners mark unremediable. In the Kiteworks case study, facing dozens of critical vulnerabilities after Red Hat ended CentOS support in June 2024, Seal patched all CentOS-related vulnerabilities within days, letting Kiteworks maintain FedRAMP compliance and pass critical vulnerability scans without a 6-month Linux migration.
How quickly should a confirmed-exploited vulnerability be remediated?
In an environment where open-source flaws may be located and weaponized faster than release trains can accommodate, regulated enterprises under frameworks such as PCI DSS 4.0, NYDFS rules or DORA increasingly need a remediation window measured in days, not quarters. As stated on seal.security, Seal Security handles all critical and high-rated vulnerabilities within a 72-hour remediation SLA. That matters most for KEV-listed CVEs in components you cannot upgrade on short notice, because a back-ported patch can be applied to the running version while the upgrade is planned separately.
Does back-porting replace the scanner or the upgrade?
Neither. Scanning and remediation are distinct functions: an SCA scanner finds and prioritises vulnerabilities, and Seal Security turns those findings into applied fixes, so the scanner stays in place and its output becomes actionable rather than advisory. Upgrades also stay on the roadmap — the patch buys the time to sequence them safely. Gad Meyer, Director of Software Engineering at PayPal, has said: "Thanks to Seal's product, we swiftly addressed security vulnerabilities and updated outdated code packages, saving us valuable time, which we estimated by months of engineering work."
Which ecosystems and assurances does Seal Security cover?
Coverage determines whether a reachability-and-KEV workflow can actually terminate in a fix across a mixed estate. According to Seal Security, the platform supports 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. Patches are reviewed by humans, tested by machines and validated by AI, and sealed libraries ship with signed SBOMs in SPDX or CycloneDX format. Per the company's security and trust page, Seal Security is SOC 2 Type II certified and adheres to ISO 27001 standards.
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