Software composition analysis has a noise problem. A typical dependency tree pulls in hundreds of transitive packages, and traditional SCA tools flag a CVE the moment a vulnerable version shows up anywhere in that tree — whether your application ever calls the vulnerable function or not. Security teams end up triaging thousands of alerts a month, most of which describe code paths that can never execute in production.
Reachability analysis was built to fix that: instead of asking "is this vulnerable package present," it asks "can an attacker's input actually reach this vulnerable function." Endor Labs helped popularize this approach for open-source dependency risk, and it's a question we ask too, though we ask it as part of a broader supply chain security posture rather than as a standalone SCA product. This post lays out how the two approaches compare, and where they genuinely differ, without guessing at Endor Labs' internals or pricing.
What does "reachability-based SCA" actually mean?
Reachability analysis builds a call graph of your application — starting from your own source code, through your direct dependencies, and down into transitive dependencies — and checks whether a path exists from code you actually execute to the function containing a known vulnerability. If no such path exists, the CVE is present in your dependency tree but not exploitable in your build, and it can be deprioritized instead of treated as a page-one fire drill.
This matters because the volume difference is real. Industry data from reachability vendors and academic studies on call-graph-based triage has consistently shown that a large majority of flagged CVEs in a typical dependency tree are unreachable from application code. The exact percentage varies by language, framework, and how conservatively the call graph is built, but the direction is consistent: reachability materially shrinks the queue security and engineering teams have to work through.
The catch is that reachability analysis is only as good as the call graph underneath it. Dynamic languages, reflection, deserialization, and plugin-style architectures make static call graphs harder to build accurately, which is why vendors differ meaningfully in how conservative or aggressive their reachability verdicts are — a distinction worth probing in any proof-of-concept, from either vendor.
How does Endor Labs approach this problem?
Endor Labs is publicly positioned around function-level reachability analysis for open-source dependencies, built by a team with a research background in program analysis. Its core pitch is that it performs call-graph analysis across your dependency tree to determine which CVEs are reachable and which are not, and it extends that scoring with reputation and risk signals about the open-source packages themselves — things like maintenance activity, provenance of the package, and known malicious-package indicators.
Because Endor Labs' public materials center the product around dependency and package risk, we won't speculate here about implementation details, coverage breadth across ecosystems, or pricing structure that aren't independently documented — those are the right questions to put directly to Endor Labs or verify in a trial. What we can say with confidence is what Safeguard does differently, and where the two products' stated scope diverges.
How does Safeguard approach reachability?
Safeguard performs reachability analysis as one layer of a pipeline that also ingests build provenance, SBOM data, and CI/CD configuration for the same codebase, so a reachability verdict on a CVE is generated alongside context about how that artifact was built and where it's deployed — not as an isolated dependency-graph exercise. Concretely, Safeguard's engine:
- Builds a static call graph per service/repository and traces whether application entry points can reach the vulnerable function or module identified by the CVE.
- Correlates reachability with the SBOM Safeguard generates from the actual build, rather than from a manifest file, so the verdict reflects what was compiled and shipped, not just what's declared in a lockfile.
- Feeds reachability status into the same alert as build and provenance signals — for example, whether the vulnerable dependency arrived through a pinned, signed build step or an unpinned fetch at build time.
The practical effect is that a "reachable" verdict in Safeguard comes with more than a yes/no: it comes with the build context needed to decide whether to patch now, patch in the next release train, or accept the risk with a documented justification — useful for SOC 2 and similar audit evidence.
Where does scope diverge: dependency risk vs. full supply chain?
This is the dimension worth spending the most time on before choosing a tool, because it's a scope question, not a quality question.
Endor Labs, as publicly described, is centered on open-source dependency and package risk: reachability, package reputation, license and malicious-package detection, and related SCA workflows. That's a well-defined and valuable slice of supply chain risk.
Safeguard is built to cover a wider slice of the software supply chain in a single platform:
- SBOM generation from actual builds, not just dependency manifests, so the inventory reflects what was compiled rather than what a package.json or requirements.txt declares.
- Build provenance and attestation, tracking whether an artifact was produced by an expected, verified CI/CD pipeline (aligned with frameworks like SLSA) rather than assuming trust in whatever produced the binary.
- CI/CD pipeline configuration risk, including overly permissive tokens, unpinned actions, and self-hosted runner exposure — attack surface that lives upstream of any single dependency.
- Reachability-based CVE triage, as described above, applied to the artifacts Safeguard has already built provenance and SBOM data for.
If your primary pain is "we get too many CVE alerts from our dependency scanner and can't tell which ones matter," a focused reachability-based SCA tool like Endor Labs directly addresses that pain. If your pain is broader — you also need to answer "how was this artifact built, can we prove it, and is our CI/CD pipeline itself a soft target" — that's the gap Safeguard is built to close without requiring a second vendor and a second dashboard.
Which approach fits your team's workflow?
A few concrete questions help decide which shape of tool matches your situation, regardless of vendor:
- Where does your risk actually originate? If nearly all of your supply chain incidents to date have been CVE-driven — a vulnerable transitive dependency getting exploited — a dependency-focused reachability tool covers your highest-frequency risk. If you've also had to answer audit questions about build integrity, artifact provenance, or CI/CD misconfiguration, you need a platform that covers that ground too.
- How many tools can your team realistically operate? Consolidating SBOM, provenance, and CVE triage into one platform reduces the number of places an engineer has to check before shipping, and reduces the reconciliation work of correlating findings across two separate inventories of the same codebase.
- What does your compliance program require as evidence? SOC 2 and similar frameworks increasingly expect evidence of build provenance and pipeline controls, not just a vulnerability report. If that's on your roadmap, factor it into the evaluation now rather than adding a second tool later.
- How conservative do you need reachability verdicts to be? In any proof-of-concept — with Endor Labs, Safeguard, or another vendor — test reachability against a codebase using reflection, dynamic dispatch, or a plugin architecture you know well, and manually verify a sample of both the reachable and unreachable verdicts before trusting the tool to triage at scale.
How Safeguard Helps
Safeguard was built on the premise that reachability is necessary but not sufficient — knowing a CVE is exploitable only matters if you also know how the vulnerable artifact was built, whether that build pipeline can be trusted, and whether your SBOM reflects reality. Safeguard generates SBOMs from actual build output, attests to build provenance for each artifact, evaluates CI/CD configuration for the risks that let attackers compromise a pipeline before a dependency is even involved, and layers reachability-based CVE triage on top of all of it — so a single alert tells you not just "this is reachable" but "here's the build it came from and here's the evidence trail for your next audit."
If your evaluation criteria include reachability accuracy, breadth of coverage beyond open-source dependencies, and audit-ready provenance evidence in one platform, run Safeguard against your own repositories and CI/CD pipelines alongside any other vendor you're considering, including Endor Labs. Reachability data is only useful when you can verify it against your own code, and a real proof-of-concept against your own build pipeline — not vendor marketing on either side — is the fastest way to see which tool's scope actually matches the risk you're trying to manage.