Konvu vs Endor Labs: Reachability vs Exploitability (2026)

Quick verdict: Keep Endor Labs for dependency scanning and call-path reachability, and add Konvu when Endor tags more findings reachable than your team can work through. Konvu proves which of those findings an attacker can use by reproducing the exploit against its own copy of your application, then ships the fix.

Endor's function-level reachability covers eight languages. Konvu also assesses PHP and Rust, which Endor's SCA language table lists without reachability. Endor alone fits teams that need its vulnerability data, SBOM and VEX export, or backported patches. Konvu adds a written reason for every dismissal. If you already run Endor, run both: Konvu reads Endor findings with their reachability tags and checks the conditions reachability does not cover.

This page covers dependency (SCA) findings, where the two products meet. Both also work on first-party code and containers. This page leaves those out, apart from one note on Endor's AI SAST.

The question each one answers

For a dependency finding, Endor Labs' reachability analysis answers: is there a path from my code to the vulnerable function? Its docs define a Reachable Function as "a path from the developer-written code to a vulnerable function, indicating that the finding is exploitable in your environment" (Endor docs, reachability analysis). Endor computes that path for direct and transitive dependencies in eight languages, and adds context such as KEV status, fix availability and upgrade risk. Its use-case page says function-level reachability is "cutting findings by 92%" (endorlabs.com). That figure is vendor-reported. The page does not publish a method.

Konvu answers: can an attacker use this finding in your application and environment, and what is the evidence? Reachability is one of four conditions Konvu checks. The others are whether the vulnerable version is installed, whether the OS, runtime and platform match, and whether attacker-controlled input reaches the vulnerable code with the configuration the exploit needs. Our reachability page puts it as "Reachability is the floor of exploitability, not the ceiling."

A call path is strong evidence that the vulnerable code runs. It does not settle whether an attacker can use it. A reachable function can still be safe when the application controls its input, the dangerous option is off, or the code calls a safe variant of the API. In one Global Fortune 500 backlog of Black Duck SCA findings, Konvu assessed 96% as false positives and 4% as exploitable (case study). That is one customer's backlog, not a benchmark.

Side by side

How Endor Labs decides a finding

Endor runs three kinds of reachability analysis (reachability analysis). Function-level analysis is the most precise. Dependency-level analysis is on by default for all supported languages and shows whether the application uses an imported package at all. Pre-computed reachability is the fallback when a build fails.

Function-level analysis uses call graphs. Endor's docs say "Endor Labs uses static call graphs to perform dependency analysis at a fine-grained level," and that Endor uses "dynamic call graphs internally to benchmark and refine static call graphs" (call graphs).

Each finding gets one of three function-level labels:

• Reachable Function: "a path from the developer-written code to a vulnerable function, indicating that the finding is exploitable in your environment." Endor adds: "This is demonstrated by a call graph that illustrates each step between the source code and the vulnerable library."
• Unreachable Function: "Endor Labs determines that no risk of exploitation exists, as no path exists from the source code to the vulnerable function." A call graph supports this result too.
• Potentially Reachable Function: Endor "is unable to determine whether a finding is reachable or unreachable, typically because call graph analysis is unsupported for a given language or package manager."

Function-level analysis needs a "Successful project build and client call graph generation" and covers direct and transitive dependencies. When a build fails, pre-computed reachability runs "without requiring code compilation, builds, or full call graph generation" and covers "Transitive dependencies only" (same page). Endor's SCA language table lists pre-computed reachability for Java, Python, JavaScript, .NET, Kotlin and Scala. Ruby call graphs arrived in August 2026 (release notes). They need no build, are on by default for automated scans, and are switched on with an environment variable for other scans (Ruby).

Findings also carry attributes. "Exploited" means the CVE "is actively exploited and appears in the Known Exploited Vulnerabilities (KEV) database." Others include Fix Available, Direct, Transitive and Phantom (findings).

Endor's AURI Agents page says the agents "validate reachability and exploitability." For dependency findings, it describes the SCA Remediation agent in terms of call graphs and upgrade impact (agentic workflows). Endor's SCA docs do not describe checks for configuration options, attacker-controlled input or other exploit preconditions (checked Oct 13, 2026). Missing from the docs does not mean missing from the product. Ask Endor how it handles these conditions for your stack.

Endor's AI SAST covers first-party code. It draws context from "deployment files such as Dockerfiles, Kubernetes manifests, and CI configurations," and each finding includes "a data flow trace from source to sink" and "an attack vector with a concrete exploit payload" (AI SAST). That applies to your own code, not to dependency findings.

How Konvu decides a finding

Konvu keeps an enriched vulnerability database built from OSV, GHSA and NVD. It analyzes advisories, package source and patch diffs to add vulnerable method signatures and a checklist of exploit conditions for each vulnerability (vulnerability enrichment). Konvu then checks four categories of preconditions in order (reading an assessment):

1. Dependency installed. "Is the vulnerable dependency actually present in your codebase?" Konvu builds its own dependency graph and does not rely only on the scanner's direct or transitive flag (dependency findings).
2. Environment. "Does your application run in an environment where the vulnerability applies?" This covers OS, runtime and platform.
3. Code reachability. "Is the vulnerable code reachable from your application?" For Endor findings, "When Endor Labs provides function-level reachability data, Konvu uses it alongside its own analysis" (Endor Labs connector).
4. Attacker controllability. "Can an attacker actually reach and exploit the vulnerable code?" Konvu checks whether user-controlled input reaches the vulnerable function, whether dangerous configuration options are enabled, whether validation or sanitization prevents exploitation, and whether the code uses a safe API variant.

The conditions form an AND chain. Each one is marked met, not met or inconclusive, with "the specific code snippets, file paths, or reasoning that support the determination." When Konvu cites your code, it shows the file path and a few surrounding lines.

Konvu's vulnerability enrichment docs give this example checklist for GHSA-xc6g-ggrc-qq4r (CVE-2017-16016), a cross-site scripting bug in sanitize-html:

1. Untrusted HTML is passed to sanitizeHtml().
2. The allowedTags configuration includes a nonTextTag.
3. Output is rendered as HTML without additional escaping.

A call graph can confirm that your code calls sanitizeHtml(). If allowedTags has no nonTextTag, condition 2 fails and the finding is a false positive.

The verdict follows from the conditions (reading an assessment):

• Exploitable: every condition is met.
• False Positive: at least one condition is not met.
• Needs input: some conditions are inconclusive, and Konvu asks your team a question, such as "Is this service internet-facing?" Your answer triggers a new assessment (answering Konvu's questions).
• Inconclusive: some conditions are inconclusive, and no question would settle them. Inconclusive runs are not billed (pricing).

Proof by reproduction. Konvu also attacks the finding. It builds and deploys its own copy of your application in an isolated lab, runs the exploit from a separate host, and records the requests, the responses and the observed impact. A reproduced finding carries that proof, which a call graph cannot give. When the attack disproves the finding, its verdict changes to False Positive, with the evidence. If the lab cannot build what the exploit needs, Konvu records why, and the verdict from the checklist stands (How reproduction works).

For exploitable findings, Konvu automates the remediation. It prepares a remediation plan with the target version, the API changes between versions and the lines in your code they affect. Accepting the plan opens a fix pull request. Konvu runs your tests, fixes what the upgrade breaks, and keeps the PR in draft until CI passes. You can also hand the plan to a coding agent (product). After the fix, Konvu re-runs the same exploit against the fix branch to confirm it no longer fires.

Where Endor Labs is stronger

• It is a scanner. Endor finds direct, transitive and phantom dependencies by scanning source code (use case) and maintains its own vulnerability database. Its Package Firewall can "Block malicious and unapproved packages at install" (licenses). Konvu needs findings from somewhere.
• Function-level reachability at scale. Eight languages, direct and transitive dependencies, a call graph as evidence for reachable and unreachable results, and a no-build fallback for transitive dependencies (reachability analysis).
• Upgrade impact analysis. Endor assigns each recommended upgrade a High, Medium or Low remediation risk based on breaking changes and version conflicts (upgrade impact).
• Backported patches. Endor Patches applies upstream fixes to older versions when an upgrade is not an option (Endor Patches).
• Container reachability. Runtime profiling "monitors which OS-level files and dependencies the application accesses during execution" (container reachability).
• SBOM and VEX export. Endor exports "SBOM and VEX documents that meet FedRAMP, PCI DSS, and other compliance requirements" (use case). If an auditor asks for VEX, Endor produces it and Konvu does not.
• Cloud Bitbucket and Azure DevOps. Endor connects to both (SCM integrations). Konvu connects to GitHub and GitLab, and Enterprise adds GitHub Enterprise Server, GitLab self-managed, Bitbucket Data Center and Azure DevOps Server (pricing).
• Named customers and analyst standing. Endor's customers page shows OpenAI, Cursor, Atlassian, Robinhood, Dropbox, Rubrik and Citi. Gartner named Endor a Sample Vendor for Reachability Analysis and for Software Supply Chain Security in its 2026 Hype Cycle for Secure Software Engineering (Endor announcement). Konvu runs in production at Fortune 500 and Nasdaq-listed companies, and Sage is one we can name.
• A free tier. The Developer tier runs AURI locally with "no account required" (pricing).

Konvu's limits

• Not a scanner. Konvu's docs say it "does not find vulnerable dependencies itself" (dependency findings). It works on findings your scanners produce.
• SCA findings only from Endor. Konvu imports Endor's SCA findings, not its SAST or secrets findings (Endor Labs connector).
• API, CLI and self-hosting are Enterprise. The Business plan does not include them (pricing).
• No published accuracy benchmark. Konvu has not published accuracy or false-negative rates. Each verdict shows its evidence for your team to check, and a reproduced finding carries the exploit.

Running both

Konvu has a read-only Endor Labs integration (Endor integration).

1. Create an Endor Labs API key and secret with read access to Projects and Findings, and pick the namespace to import. One connection covers one namespace.
2. Konvu reads Endor SCA findings once a day and on demand. It imports the CVE or GHSA, package, version, ecosystem, manifest location, direct or transitive status, finding state, and Endor's function-level and dependency-level reachability status when available.
3. Konvu reads your code through your GitHub or GitLab connection, builds its own dependency graph, uses Endor's reachability data alongside its own analysis, checks environment and attacker controllability, then reproduces the exploit. New organizations assess Critical and High findings by default, and the scope is configurable (dependency findings).
4. Exploitable findings get a fix pull request that runs your tests, or a plan for your coding agent, and Konvu checks that the exploit no longer fires. They can also go to Slack, or to Jira on Enterprise.
5. Konvu writes nothing to Endor. Your team records the exception or the fix in Endor and can cite Konvu's evidence.

Endor stays the system of record for detection, finding state, policies, SBOM and VEX. Konvu holds the verdict and the evidence behind it. This fits teams with a backlog of findings Endor tags reachable and no time to read each call path by hand. It also fits teams that need a written reason for every dismissal. At one Fortune 500 retailer, Konvu cut the SCA triage queue by 93% (case study).

Pricing models

Endor Labs prices by seat. Its pricing page says "Pricing is seat-based and varies slightly depending on the SKU," and counts a contributor as a developer who made a commit "within the last 90 days." The page shows no list prices. The free Developer tier runs locally, and "There is no UI, policies, or scan history" (pricing).

Konvu prices by delivered work. Business is $2,000 a month and includes 400 confident verdicts. You pay for confident verdicts and successful fix PRs. Inconclusive runs and failed PRs are free. Over 400, you choose a cap or billed overage. Enterprise is custom and adds self-hosted analysis, API and CLI access, and Jira push. Konvu has a free trial at app.konvu.com, not a free tier (pricing).

Running both means two bills with different units. Endor's grows with the number of contributing developers. Konvu's grows with the number of findings that get a confident verdict or a fix PR each month.

Sources checked

All sources checked on October 13, 2026.

• Endor Labs: Reachability analysis, Call graphs, SCA language support, Ruby support, August 2026 release notes, Findings, Vulnerability database, Container reachability, AI SAST, Upgrade impact analysis, Automated pull requests, Endor Patches, Importing SBOMs, Exporting SBOMs and VEX, Third-party integrations, Data exporters, Jira integration, SCM integrations, Outpost, Licenses, SCA with reachability, Agentic workflows, Pricing, Customers, 2026 Gartner Hype Cycle
• Third parties: GHSA-xc6g-ggrc-qq4r
• Konvu: Product, Pricing, Security, Endor Labs integration, Reachability analysis, What is Konvu, How assessments work, Reading an assessment, Answering Konvu's questions, Dependency findings, Vulnerability enrichment, Endor Labs connector, Remediation plans, Fix pull requests, Dismissing false positives, Data forwarding

Related comparisons

• SCA vs SAST: What dependency scanning and code scanning each catch, including how reachability tools differ.
• Checkmarx vs Black Duck: Two enterprise platforms, and why teams pair Black Duck with a reachability tool such as Endor Labs.
• Snyk vs Semgrep: Two scanners compared on SAST, SCA reachability and pricing.
• Reachability vs exploitability: CVEs that static analysis marks unreachable but an attacker can still exploit.