Open a fresh software composition analysis report and the same number stares back: thousands of vulnerabilities, most of which will never run in production. The trick being that the scanner doesn't tell you which ones are least consequential. It's within that gap in knowledge that SCA remediation turns a wall of numbers into a springboard for action.
SCA remediation is the process of fixing the vulnerabilities that software composition analysis finds in your open-source dependencies. Done well, it ranks findings by real risk first. Then it closes each issue with a safe upgrade, a targeted patch, or a replacement. This helps the team fix what matters most. It also keeps them from chasing every CVE.
This guide covers why SCA remediation breaks at scale, how effective remediation works, how to identify vulnerable codes in production, and what the workflow looks like in practice.
Why SCA Remediation Is Broken at Scale
The math works against every AppSec team. Open source makes up about 80 percent of the code in a modern app. Most of that code comes through dependencies no developer chose. When a scanner reports every CVE in each dependency, teams end up with a backlog in the tens of thousands, and they never fix most of it.
The transitive dependency problem is the core of it. According to Endor Labs' State of Dependency Management report, about 95 percent of vulnerabilities sit in transitive dependencies, the indirect packages your direct dependencies pull in. A developer never selected them and cannot easily judge whether they matter, so the findings pile up unowned.
Traditional prioritization makes the pile worse. CVSS rates severity in isolation.
A high CVSS score does not mean high risk, because the score does not know whether the vulnerable function runs in your application. Teams that sort by CVSS alone spend their time on findings that were never exploitable, while the reachable risks wait in the same queue. That gap between what a scan reports and what a team can fix is vulnerability debt, and it grows every sprint the noise stays high.
How Effective SCA Remediation Works
Effective remediation flips the model from find everything to fix what matters. Instead of triaging a wall of findings, the team narrows the list to what is exploitable, then closes each item through the safest available path. Three steps carry the work.
Prioritize Vulnerabilities With Reachability, Not Just CVSS
Reachability analysis traces the call graph from your code into its dependencies and checks whether your application runs the vulnerable function. A vulnerability that is present in a package is not the same as a vulnerability an attacker can reach. When most flagged CVEs sit in code the application never calls, reachability moves them off the priority list and leaves the exploitable few.
Consider two findings. A CVSS 10 vulnerability sits in a dependency function your code never calls. A CVSS 5 vulnerability sits in the library that handles your authentication. The severity score ranks the first one higher. Reachability ranks the second one higher, because that is the one an attacker can hit. Layer EPSS, which scores the probability of exploitation in the wild, and the CISA KEV catalog, which names vulnerabilities under active attack, and you get a priority list built on exploitability instead of theory. See reachability analysis for how this works at the function level.
Identify Safe Upgrade Paths That Won't Break Your Code
Once you know what to fix, the next question is how to fix it without breaking the build. Semantic versioning promises that a minor bump is safe, but the promise holds only as far as the maintainer kept it, and a version bump can change an API your code calls or drag a transitive dependency to a conflicting release. This is why "update everything to latest" fails: it treats every upgrade as free when some upgrades break production.
Upgrade impact analysis closes that gap. It checks API compatibility between the current and target versions, maps the cascading effect on transitive dependencies, and flags the breaking changes before you merge. The output tells you which upgrade closes the CVE with the smallest blast radius, so you pick the safe path with evidence instead of guessing.
Apply Patches When Upgrades Are Not an Option
Sometimes no clean upgrade exists. A legacy system pins an old version, a complex dependency tree blocks the bump, or a release freeze rules out a major change. A security patch backports the fix to your current version, so you close the vulnerability without the full upgrade. This is a maintained, tested fix, not a monkey-patch bolted on at runtime, and it goes through the same verification as any change: run the regression suite, confirm the patch closes the CVE, and confirm it introduces no new failure. Endor Patches generates these fixes, and Mythos extends patch generation to scale, gated by reachability.
How to Evaluate an SCA Remediation Platform
When you compare platforms, judge them on the metrics that move remediation velocity and risk down, not on scan counts. Two areas matter most.
Time-to-Fix SLAs for Direct and Transitive Vulnerabilities
Set realistic SLA targets by severity and reachability, then track mean time to remediate against them. A reachable critical earns a tight clock. An unreachable low does not need one. Separate your SLAs for direct dependencies, which you control and can upgrade, from transitive ones, where you wait on an upstream maintainer or reach for a patch. Benchmark against real requirements: FedRAMP expects high-severity findings closed within 30 days, and tracking remediation velocity over time shows whether the program is gaining ground or losing it. For the full metric, see mean time to remediate.
CI/CD Integration and Developer Workflow Fit
A remediation tool only reduces risk if developers adopt it, and developers adopt tools that fit their workflow. Look for IDE plugins that surface fixes before a pull request exists, PR automation that proposes fixes without flooding the queue, and pipeline controls that let you gate on real risk while warning on the rest. An API-first design lets you wire remediation into custom workflows. Friction tests the tool: if it blocks deploys or drowns developers in noise, developers turn it off.
What Reachability-Based SCA Remediation Looks Like in Practice
Here is the workflow end to end:
- A scan of a mid-sized application returns 5,000 findings.
- The reachability filter marks the vulnerabilities in code the application never calls as "unreachable" and leaves a few hundred that sit on live paths.
- Layer EPSS and a production-code filter, and the list narrows to a few dozen critical fixes that carry real risk.
Now the team faces a short, ranked queue instead of a wall of 5,000.
From there, each fix runs the decision tree. If a safe upgrade exists, take it.
If the upgrade breaks too much, apply a patch. If the vulnerability is unreachable, defer it and spend the effort elsewhere. The numbers above are illustrative, but the pattern is the point: reachability turns an unworkable backlog into a list a team can clear in a sprint.
The real-world proof shows the same shape. Zebra Technologies cut its SCA noise by 97 percent with Endor Labs, which let its product security team spend more time building and less time chasing false positives (Endor Labs, Zebra Technologies customer story).
SCA Remediation Starts With Fixing the Right Vulnerabilities First
Effective remediation is a matter of precision, not volume. Three pillars carry it: reachability-based prioritization that cuts the noise, safe upgrade paths that ship fixes without breaking the build, and targeted patches for the cases where no upgrade fits. Together they shrink the backlog, cut mean time to remediate, and reduce the production incidents that come from both unfixed risk and broken upgrades.
The need for precision only grows from here. AI coding agents generate dependencies at a pace no manual review can match, and Endor Labs' 2025 research found that a large share of AI-recommended dependencies carry known vulnerabilities. As machines write more of the code, remediation has to get more exact, not less, which is the case the agentic remediation guide lays out.
What's Next?
- Book a demo to see reachability-based remediation in action on your codebase.
- Try AURI for Developers (free) to scan your code locally and see which findings are reachable.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help:
