Executive summary
Most vulnerability management programmes are built to answer one question well: when a new CVE lands, how urgently should we act on it? CVSS scores it, EPSS estimates the odds, KEV listing confirms real-world use, and a triage process routes the result into a patch calendar. That machinery is necessary and, for the specific problem it solves, generally works. It is also not the same machinery needed to answer a second, quieter question: of everything already patched or already scored as low-priority months or years ago, what's still sitting unremediated, and does anything about that picture need revisiting? A three-year-old ownCloud authentication bypass and a same-week 5.3 Artifactory path traversal flaw, both added to CISA's exploited list on 27 August, are two different failure modes of that second question going unasked. This paper sets out a framework for asking it deliberately: how to build a standing remediation backlog review, how to weight scoring by an asset's position in the trust chain rather than exploit difficulty alone, and how to avoid the trap of treating "we patched it" and "nothing is running the unpatched version anymore" as the same fact.
1. A severity score is a triage tool, not a completeness record
CVSS and EPSS both answer questions about a vulnerability at the moment of disclosure: how bad is it if exploited, and how likely is exploitation given current conditions. Neither is designed to track what happens to that vulnerability's real-world footprint afterward - whether the patch actually reached every affected instance, or whether the conditions behind a low EPSS score quietly changed once the flaw sat in production for a few years. The ownCloud case shows the first failure: a 9.8 score in 2023 should have driven fast remediation everywhere, and evidently didn't reach every internet-facing instance, including one holding research-reactor data. The JFrog case shows the second: a 5.3 score and an 18th-percentile EPSS estimate at disclosure said "not urgent," and neither number updates itself once a flaw turns out to sit in a CI/CD trust position that makes it more consequential than its inputs suggested. A programme that treats either score as a permanent verdict rather than a point-in-time estimate is one that will keep discovering both failure modes after the fact rather than before it.
2. Build a standing backlog review, separate from new-CVE triage
New-CVE triage and backlog review are different disciplines competing for the same team's time, and the first reliably wins because it has a deadline attached and the second doesn't - until an old CVE resurfaces as a live incident and suddenly does. The fix isn't more triage capacity, it's a separate, scheduled process: a quarterly pass over every internet-facing asset's actual patch level against every CVE ever scored against that asset class, cross-referenced against current KEV status rather than the KEV status at time of original scoring. This is deliberately boring, calendar-driven work rather than event-driven work, which is exactly why it tends not to happen without being designed in as its own line item with its own owner - not appended to the same team's new-CVE queue, where it will always lose.
3. Score assets by trust position, not just by CVE severity
The JFrog case is a useful corrective to scoring by CVSS alone: a moderate-severity, high-attack-complexity flaw in a system that sits between source control and production is not equivalent in practice to the same score in a system nothing else depends on. A more useful triage input than CVSS in isolation is a simple trust-position multiplier - artifact repositories, package registries, CI/CD control planes, identity providers, and anything else multiple downstream systems trust implicitly should have their effective priority raised a tier above what their raw score implies, precisely because attack complexity measures difficulty for an outsider, not the access an insider, a compromised pipeline, or a supply-chain foothold already has. This doesn't mean discarding CVSS or EPSS; it means treating them as one input to a score that also accounts for where the asset sits, not the sole determinant of patch urgency.
4. "Patched" needs a verification step, not just a changelog entry
A vendor advisory and a fixed version number tell you a fix exists. They don't tell you it reached every instance that needed it, and the gap between those two facts is where the ownCloud case actually happened - the fix was public for nearly three years before the specific instance that mattered got hit. Verification means treating "patched" as a status to be confirmed against your own asset inventory on a recurring basis, not a box ticked once when the advisory first arrived and never revisited. For self-hosted or internet-facing software in particular, where there's no vendor-managed update mechanism forcing the issue, an unverified assumption that "we patched that ages ago" is one of the more common gaps this framework exists to close.
Practical framework checklist
The following translates the four principles above into decisions a security or platform engineering team can act on now.
- Stand up a quarterly backlog review, owned separately from new-CVE triage, that re-checks patch level for every internet-facing asset against every CVE ever scored against that asset class - not just CVEs scored in the current quarter.
- Build a trust-position multiplier into vulnerability scoring for artifact repositories, package registries, CI/CD control planes and identity systems, so a moderate CVSS score in a highly-trusted position isn't triaged the same as the same score elsewhere.
- Re-run KEV catalog checks against your full historical CVE list, not just newly disclosed CVEs - a flaw can gain KEV status years after original disclosure, as CVE-2023-49105 did this week.
- Treat "patched" as a status requiring periodic re-verification against actual asset inventory, particularly for self-hosted software with no vendor-forced update mechanism.
- When a low-severity-scored flaw does turn up in an active exploitation report, use it as a trigger to review what else in that scoring band may be similarly under-weighted, rather than treating it as an isolated surprise.
- Report backlog age, not just backlog size, to whoever owns risk - a hundred low-priority items patched within a quarter is a different risk picture from ten sitting unaddressed for three years, and most dashboards don't currently distinguish the two.
Risks and how to manage them
The most common failure mode in standing up a backlog review is scope creep into re-litigating every historical severity decision, which turns a quarterly process into an open-ended one that never completes and therefore never repeats reliably. Keep the review mechanical: a defined asset scope, a defined CVE list pulled from live feeds, and a hard time-box, with anything requiring deeper investigation logged as its own follow-up rather than extending the review itself. A second failure mode is building the trust-position multiplier as a one-off manual judgement call rather than a documented, auditable classification of which asset categories qualify - without that documentation, the multiplier becomes inconsistent across reviewers and indefensible when questioned. A third, and the one most directly illustrated by this week's two cases, is assuming backlog risk is evenly distributed across an estate when in practice it concentrates in a small number of forgotten, rarely-touched, internet-facing systems that nobody currently owns clearly - the review's asset inventory needs an explicit process for surfacing exactly those systems, not just the ones already on a maintained list.
Conclusion
Neither vulnerability behind this paper failed because a fix didn't exist. CVE-2023-49105 had one for nearly three years; CVE-2026-66384's fix, whatever its exact version number, was available before CISA's listing. Both failed because the governance layer sitting between "a fix exists" and "the fix is verified everywhere it needs to be" wasn't doing the job severity scoring alone can't do. A programme that treats CVSS and EPSS as complete answers rather than one input into a broader backlog and trust-position model will keep closing the vulnerabilities that show up loudly at disclosure, and keep missing the ones that show up quietly, years later, in someone else's incident report. For a facilitated review of how your own remediation backlog and asset trust-position scoring would hold up under this framework, contact sales@halfteck.com.