The Vulnerable-Dependency Triage: Fix Now, Schedule, or Accept

An SCA scan just returned hundreds of vulnerable dependencies and you cannot fix all of them this quarter. This guide is for the AppSec engineer, engineering manager, or owning developer who has to decide which flagged findings to fix now, which to schedule, and which to accept, and defend that call to an auditor later. It gives you a graded rubric built from named public inputs so two engineers scoring the same finding reach the same tier.

Software composition analysis, or SCA, is the scan that inventories your open source dependencies and matches them against known vulnerabilities. Most guides tell you whether to adopt or update a whole library. This one does something narrower and more useful under fire: it scores a single already-flagged vulnerability, often buried deep in the transitive tree, and resolves it to one of four remediation tiers.

Why sorting by CVSS alone fails

CVSS severity is the wrong sort key because it does not know whether the vulnerable code runs in your application. A high CVSS score describes the vulnerability in the abstract; it says nothing about whether the vulnerable function is callable in your build, whether the affected service is exposed, or whether anyone has ever exploited the flaw in the wild.

The scale of the mismatch is the whole reason triage exists. Only about 6% of all published CVEs have ever been observed exploited in the wild. CISA's Known Exploited Vulnerabilities catalog, the authoritative list of flaws with reliable evidence of exploitation, holds roughly 1,300 entries against 355,000+ published CVEs, under 0.4%. Sort by CVSS and you spend your week on findings that were never exploitable while a genuinely reachable, exploited risk waits in the same queue behind them.

The rubric that follows inverts the naive order. It applies threat-based filtering first, using KEV membership and the EPSS threshold, then reachability and exposure, and only then uses severity to break ties or justify deprioritization.

The dimensions that decide the tier

Score every finding on the same six dimensions, in this order. Each dimension proves something specific, and each has a failure mode where the signal lies to you. Say what the signal proves, and know what it looks like when it is wrong.

Two of these dimensions carry more weight than the rest, and it helps to understand why.

KEV is an override, EPSS is a filter

KEV and EPSS operate at very different scales, which is exactly why the order matters. KEV covers under 0.4% of all CVEs, so treat it as an absolute override: any open KEV finding is Fix-Now before you look at anything else. The published EPSS v3 remediation threshold of 0.088 flags a much larger slice, about 7.3% of CVEs, so treat it as a volume filter for everything KEV did not already catch.

The payoff of that ordering is measurable. At the 0.088 threshold, EPSS v3 reaches about 82% coverage for 7.3% of the effort, versus the 58.1% of CVEs you would have to remediate to hit the same coverage by chasing volume without a threshold. Restated per thousand, the 0.088 gate flags 73 of every 1,000 vulnerabilities, at an efficiency of 45.5%.

Reachability is the highest-yield cut you have

Reachability is the single most powerful filter in this rubric, because most dependency code never runs. Commercial SCA products report that 70 to 80% of dependencies are never referenced in application code at all. Reachability analysis answers the exact question CVSS cannot: not whether a vulnerable library is present, but whether the vulnerable function is actually callable, analyzed at function level across direct and transitive dependencies.

The reduction is dramatic and documented. Function-level reachability cut SCA findings by 92% in one Endor Labs use case. A conservative automated check on 12 Go projects gave a 74.4% false-positive reduction, confirming 31 of 121 reported findings. That is a bigger cut than any severity threshold delivers.

One caution that belongs on the dimension itself: dependency-level reachability is not function-level reachability. Dependency-level analysis tells you the package is present; it cannot tell you the vulnerable code is used. Confirm your tool resolves to the function, or the filter is worth far less than the numbers above.

Most of your findings are transitive, and that sets your effort

Nearly all flagged vulnerabilities live in dependencies you never chose directly, which changes what a fix costs but not how urgent it is. The share depends on whose data you read, and that range matters because it silently sets your effort expectation.

A rubric that quotes the 95% figure but assumes every fix is a simple version bump understates the work badly. Patching transitive dependencies is documented as complicated, and few fixes are clean upgrades. This is why upgrade distance is a scored dimension: a finding in a direct dependency with a published patch is a Fix-Now you can close in an hour, while the same severity in a package four hops deep may force a version override that breaks the build.

A precise, published upgrade-distance metric, meaning the exact number of hops to a fixed version, is not established publicly as a single figure. So score it qualitatively: direct bump, forced transitive override, or no fix available. Do not push a blind transitive patch onto a developer without verifying a real fixed version and a path to it first.

The four tiers and what lands in each

Every finding resolves to one of four tiers. The tier is a function of the six dimensions, and the written justification names the inputs so the verdict survives an audit. This borrows its logic from CISA's SSVC model, whose four outcomes are Act, Attend, Track*, and Track, but keeps the language plain for a dependency queue.

• Fix-Now. Open KEV finding, or EPSS at or above 0.088, and reachable or undetermined on an internet-facing or business-critical asset. Remediate ahead of the rest of the queue.
• Schedule. High exploitation signal but not currently reachable, or reachable on a low-exposure asset. Assign a fix window rather than dropping everything.
• Accept-with-monitoring. Reachable but low exploitation likelihood today, or a KEV item whose exposure and reachability are marginal. Accept for now, but book a dated re-review.
• Accept. Low EPSS, not on KEV, not reachable, low exposure. Document the rationale and close it.

Remember that exploited is not exploited at you. Fewer than 5% of exploited CVEs ever hit more than 1 in 10 organizations, so a KEV item on an unreachable, unexposed component is a legitimate Accept-with-monitoring, not an automatic fire drill. Pair the KEV flag with reachability and exposure before you escalate.

The triage procedure

Run these eight steps in order for each scan. The first three are cheap and fast; the expensive analysis comes only after threat-based filtering has already shrunk the queue.

Note one open disagreement in the sources so you can settle it for your own shop. A published two-stage decision-tree model runs KEV and EPSS before CVSS. A pure SSVC implementation starts from the Exploitation decision point instead. The two approaches disagree on whether severity or exploitation status is evaluated first; both agree severity is never the leading key. Pick one and apply it consistently, so your tiers are reproducible.

Finding: <package>@<version> - <CVE ID>
Placement: direct | transitive (hops: <n>)
KEV: yes/no (checked <date>)
EPSS: <value> (pulled <date>) - pass/fail vs 0.088
Reachability: reachable | unreachable | undetermined (tool: <name>, function-level: yes/no)
Exposure: internet-facing? <y/n>  business-critical? <y/n>
Fix: version <x> available? <y/n>  upgrade distance: direct bump | transitive override | none
Tier: Fix-Now | Schedule | Accept-with-monitoring | Accept
Justification: <one paragraph citing the five inputs above>
Re-review due: <date>

How this goes wrong

The rubric fails in predictable ways, and every one of them produces a defensible-looking verdict that is actually wrong. This is the section to read twice, because a standard that misfires quietly is worse than no standard.

• EPSS treated as static. EPSS is a 30-day forecast, not a fixed label. An Accept item can cross 0.088 next week. Check by re-pulling EPSS on a cadence, not once at scan time.
• KEV checked only at scan time. The catalog is additive, so a finding accepted before its CVE was listed goes stale silently. Check by re-running all open findings against the current catalog, not just new additions.
• Reachability false negatives. When an application loads or invokes code dynamically, in Java, JavaScript, or Python, or uses dependency injection like Spring or .NET, reachability often cannot resolve call paths. An "unreachable" verdict on dynamically-invoked code is a false clear. Check by treating undetermined as reachable for internet-facing assets.
• CVSS used as the sort key. Teams that sort by CVSS alone chase findings that were never exploitable while reachable risks wait. Check by confirming KEV, EPSS, and reachability were applied before CVSS.
• Confusing exploited with exploited everywhere. Exploits hitting more than 1 in 10 organizations are rare, under 5%. Over-escalating a KEV item with no bearing on your stack burns the same hours a real Fix-Now needs. Check by pairing KEV status with reachability and exposure.
• Blind transitive fixes. Forcing a transitive override without a verified fixed version breaks builds. Check by confirming a real fixed version and upgrade path before assigning Fix-Now.
• Citing revoked deadlines. The flat 15-day internet-facing and 25-day other rule under BOD 22-01 was revoked on June 10, 2026, when CISA issued BOD 26-04, a four-criteria risk-scored model that can be as fast as three days. Reference BOD 26-04 for any federal-facing timeline claim.
• Dependency-level reachability sold as function-level. Dependency-level analysis cannot tell you whether the vulnerable code is actually used. Check that your tool resolves to the function, not the package.

Reported SCA false-positive rates run from 71 to 88% across tools, so most of what your scanner hands you is noise. The failure modes above are precisely the ways that noise sneaks past your rubric wearing a verdict.

Who runs this well, and why they are hard to find

The judgement this rubric teaches is a specialized skill, and the talent to run it is both scarce and unevenly distributed. Generic vulnerability-management experience is common; the specific competence in software composition analysis and reachability is rare.

In Refolk's index of professional profiles, 42,962 US profiles list Vulnerability Management as a skill but only 42 list Software Composition Analysis, a gap of more than 1,000x. The dedicated AppSec and product security pool is thin too: 1,119 engineers in the US against 49 in Germany. If you are hiring for the person who owns this triage, generic security titles will flood your pipeline while the specific skill stays invisible, so you have to search on the capability itself rather than the job title.

number: 42
label: US profiles listing "Software Composition Analysis" as a skill
note: Against 42,962 who list generic "Vulnerability Management" - the specific skill is roughly 1,000x rarer.