Endor Labs has developed a systematic approach to conduct call graph analysis. Here is a structured overview:

• Scope Expansion: Traditional methods of static analysis typically analyze a single project at a time. Endor Labs, however, expands its scope to include not only the client projects but also their dependencies, often comprising over 100 packages.

• Enhanced Dependency Analysis: Endor Labs employs static call graphs to conduct detailed dependency analysis, enabling a comprehensive understanding of how different external components interact within client projects. By leveraging these call graphs, Endor Labs aims to minimize false positives and more accurately identify the specific locations of problems in dependencies.

• Multiple Data Sources: Endor Labs uses both source code and binary artifacts to enrich the analysis. This approach ensures swift results without a heavy reliance on test coverage.

• Benchmarking for Continuous Improvement: Endor Labs maintains accuracy and relevance by using dynamic call graphs internally to benchmark and refine static call graphs, thereby actively identifying and addressing gaps.

• Scalability: Endor Labs addresses the challenge of scalability and generates call graphs not only for each project release but also for all its dependencies. This approach effectively manages large projects with multiple versions, ensuring that the analysis remains both relevant and applicable across the entire spectrum of client dependency sets.

For more information, see Visualizing the impact of call graphs on open source security.

Endor Labs uses static call graphs to perform dependency analysis at a fine-grained level. It is minimally intrusive to the developer workflow and provides results during development.

The Endor Labs user interface provides visualizations of call graphs that annotate vulnerability data and simplify it into informative call paths. This empowers developers to identify and address problematic invocations of vulnerable methods efficiently.

Endor Labs supports call paths for Java, Python, Rust, JavaScript, Golang, .NET (C#), Kotlin, and Scala.

View call paths

View call paths in Endor Labs to see the sequences of functions that your program invokes during execution.

1. Select Projects from the left sidebar.

2. Select the project for which you want to view the call path.

3. Select FINDINGS and select the finding from the list view.

4. Expand a specific finding to view more details.

   

5. In the details section, select CALL PATHS.

   

   A finding may have multiple call paths.

Modern software relies on complex code, external libraries, and open-source components (OSS). Managing risks requires understanding where issues come from, such as internal code, OSS, or other external dependencies.

Projects contain two types of dependencies, direct and transitive. Developers explicitly add direct dependencies, such as when they include a specific library in a project. Transitive dependencies enter the project indirectly through other libraries. While direct dependencies are easier to track and manage, transitive dependencies can introduce complexity, as they may not be immediately visible in the project’s configuration files.

Categorizing code as reachable, potentially reachable, or unreachable is another important step. Reachable code is actively invoked during normal execution. Unreachable code, on the other hand, is not used and can accumulate over time, leading to unnecessary complexity and potential issues. Identifying and managing these categories ensures that the codebase remains efficient and maintainable.

Types of Reachability Analysis

Endor Labs offers multiple types of reachability analysis to help you accurately assess vulnerability exposure in your applications. Each type provides different levels of granularity and accuracy depending on your specific use case and available analysis context.

• Function-level reachability and Dependency-level reachability: These analyses run during a full scan, when the project builds successfully and Endor Labs generates complete call graphs. They use actual code paths and dependency metadata to provide the most precise vulnerability assessment.
• Pre-computed reachability: A pragmatic, manifest-based analysis technique that enables you to assess whether vulnerabilities in transitive dependencies could be reachable from your direct dependencies—all without requiring code compilation, builds, or full call graph generation. With approximately 95% of vulnerabilities existing in transitive dependencies according to Endor Labs’ State of Dependency Management report, pre-computed reachability helps you deprioritize security issues that can’t be called by your application by filtering out vulnerabilities that affect functions in transitive dependencies that are not used by your direct dependencies. This approach works by analyzing how your direct dependencies interact with their transitive dependencies, providing valuable reachability insights as a fallback for full scans when builds fail, or as an optional enhancement for quick scans when you want reachability analysis without build requirements. Learn more about pre-computed reachability.

Function-level reachability

To help developers and security teams make informed decisions for SCA results, Endor Labs uses a static analysis technique called program analysis to perform function-level reachability analysis on direct and transitive dependencies. This is the most accurate way to determine exploitability in the context of your application, which is critical for determining which risks you should remediate.

Function-level reachability labels

The different function reachability labels include:

• Reachable Function: Endor Labs has determined that there is a path from the developer-written code to a vulnerable function, indicating that the finding is exploitable in your environment. 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 conclusion by demonstrating the absence of such a path.

• Potentially Reachable Function: Endor Labs 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. This means that the function in question may be executable in the context of the dependent project, but the analysis cannot definitively determine if it is reachable or not.

Dependency-level reachability

Endor Labs supports dependency-level reachability by default for all supported languages. This type of reachability analysis is more coarse-grained than function-level reachability. It indicates that the application uses the imported package somewhere but does not determine whether the source code calls the vulnerable package.

Dependency-level reachability serves as a good indicator for prioritization. If you’re not actually using the dependency at all, consider removing that dependency. Determining whether your code calls or uses a dependency provides another layer of prioritization you can add to your remediation process.

Dependency reachability labels

The different dependency reachability labels include:

• Reachable Dependency: Endor Labs established that an imported package is being used somewhere in the application.

• Unreachable Dependency: Endor Labs determined that the imported dependency is not being used. The customer can use this information to remove the dependency, which is helpful for technical debt reduction initiatives.

• Potentially Reachable Dependency: Endor Labs cannot definitively determine whether the application uses a dependency, generally because Endor Labs does not support the given language or package manager.

Comparison of reachability analysis types

The following table compares the three types of reachability analysis available in Endor Labs:

Phantom dependencies

Phantom dependencies are packages that your codebase uses but does not explicitly declare in your project’s manifest files, for example, package.json, or requirements.txt. These undeclared dependencies can pose significant security and operational risks, as they may contain vulnerabilities that standard dependency analysis does not track or assess. Identifying and managing phantom dependencies is crucial for accurate reachability analysis and comprehensive risk assessment.

Detection of phantom dependencies

Endor Labs’ reachability analysis conducts thorough scans of your codebase to identify functions and methods that both declared and undeclared dependencies invoke. By analyzing the actual usage of packages in your source code, the system identifies phantom dependencies—those that your code uses but does not explicitly declare. This detection ensures that all utilized code paths are assessed for potential vulnerabilities, providing a more accurate and comprehensive security evaluation.

Introduction

Modern applications rely on open-source dependencies, with the vast majority of vulnerabilities (approximately 95% according to Endor Labs’ State of Dependency Management report) existing in transitive (indirect) dependencies rather than direct ones. This means most security risks come from packages you didn’t explicitly add to your project, making it challenging to assess which vulnerabilities actually pose a threat to your application.

Pre-computed reachability is a pragmatic analysis technique that enables you to assess whether vulnerabilities in transitive dependencies could be reachable from your direct dependencies, all without requiring code compilation or builds. It serves two primary purposes: as a fallback mechanism for full scans when builds fail, and as an optional enhancement for quick scans when you want reachability analysis without build requirements. This analysis technique filters out vulnerabilities that affect functions never called within your dependency chain, helping you focus your team’s time and attention on the security issues that truly matter.

The benefits of pre-computed reachability include:

• Pragmatic and easy: Results are pre-computed and cached, making it a practical approach to reachability analysis. It works solely from your manifest files (for example, package.json, go.mod, pom.xml, build.gradle, and others), requiring no access to your application’s built artifacts.
• Excellent noise reduction: By analyzing how your direct dependencies interact with transitive dependencies, pre-computed reachability can filter out a significant portion of irrelevant vulnerabilities, enabling you to focus your team’s time on the security issues that truly matter.
• Build-independent: Works without requiring builds or compilation, making it a pragmatic option when you want reachability analysis without build setup.
• Reliable fallback for full scans: When builds fail or call graph generation isn’t possible, pre-computed reachability ensures you still get actionable security insights rather than missing out on reachability analysis entirely.

Getting Started

To enable pre-computed reachability analysis, use the ENDOR_SCAN_ENABLE_PRECOMPUTED_CALLGRAPHS flag:

export ENDOR_SCAN_ENABLE_PRECOMPUTED_CALLGRAPHS=true

Once enabled, pre-computed reachability analysis is used in the following scenarios:

• Quick Scan: When you run endorctl scan --quick-scan, you can enable pre-computed reachability analysis to get reachability insights without requiring builds. This provides actionable reachability results based solely on your manifest files.

• Full Scan: When you run endorctl scan, the system attempts to generate a full call graph first for maximum precision. If the build fails or call graph generation isn’t possible, it automatically falls back to pre-computed reachability, ensuring you still get valuable reachability insights rather than missing out on analysis entirely.

Endor Labs supports pre-computed reachability for the following languages: java, javascript, typescript, kotlin, python, scala, and C#.

Scan modes and pre-computed reachability

Endor Labs supports multiple scan modes that can utilize pre-computed reachability analysis. The analysis type depends on whether a call graph is generated and whether pre-computed reachability is available as a fallback.

The following table summarizes how pre-computed reachability is used across different scan modes:

How Pre-computed Reachability Works

Pre-computed reachability analysis evaluates transitive dependencies using a simple but effective approach: it assumes that everything in your direct dependencies is reachable, then uses that assumption to assess whether vulnerabilities in transitive dependencies could be called.

From Manifest to Dependency Graph

The analysis begins with your manifest files (package.json, go.mod, Gemfile, pom.xml, build.gradle, and others). Endor Labs resolves your dependencies to build a complete list of direct and transitive dependencies—along with the dependency graph that connects them. Dependency resolution is required to identify all transitive dependencies, but no build or compilation is necessary.

Computing Vulnerability Reachability

For every detected CVE in a transitive dependency, the analysis works as follows:

1. Assume direct dependencies are fully reachable: Pre-computed reachability assumes that all functions and code in your direct dependencies are reachable. This includes both open-source dependencies and private, non-open source first-party libraries. This conservative assumption ensures comprehensive coverage without needing to analyze your application’s source code.

2. Assess transitive dependency reachability: Using pre-computed call graph information from open-source dependencies, the system analyzes how your direct dependencies interact with their transitive dependencies. If a direct dependency can call a vulnerable function in a transitive dependency, that vulnerability is marked as reachable.

3. Filter unreachable vulnerabilities: If a vulnerable function in a transitive dependency cannot be reached through any of your direct dependencies (based on the pre-computed call graph information), the CVE is marked as unreachable and can be deprioritized.

The key insight is that pre-computed reachability leverages the fact that Endor Labs has already analyzed how open-source packages interact with their dependencies. By assuming your direct dependencies are fully reachable and using this pre-computed information, the analysis can determine which transitive dependency vulnerabilities could be reachable without needing to build your application or analyze your source code.

Reachable vs Unreachable CVEs

Based on the analysis:

• Unreachable CVEs: If a vulnerable function in a transitive dependency cannot be reached through any of your direct dependencies (based on pre-computed call graph information), the CVE is marked as unreachable. These can be deprioritized, as the vulnerable code cannot be invoked through your dependency chain.

• Reachable CVEs: If a vulnerable function in a transitive dependency can be reached through one or more of your direct dependencies, the vulnerability is flagged as reachable. For reachable CVEs, Endor Labs shows the list of function calls in your dependencies that may trigger the vulnerability.

Pre-computed reachability assumes all direct dependencies are reachable, so if a direct dependency can call a vulnerable function in a transitive dependency, that vulnerability is marked as reachable. Pre-computed reachability focuses on analyzing dependency relationships rather than your application’s source code usage. For the most precise assessment when builds are successful, function-level reachability analysis analyzes your application’s source code directly through full call graph generation to determine actual usage.

When Pre-computed Reachability is Used

Pre-computed reachability serves two distinct purposes:

As a Fallback for Full Scans

For full scans, pre-computed reachability automatically serves as a fallback when:

• Builds fail: If your project build fails or encounters errors, pre-computed reachability ensures you still get reachability analysis rather than missing out entirely.
• Call graph generation isn’t possible: In cases where full call graph generation isn’t available, pre-computed reachability provides valuable reachability insights.

As an Option for Quick Scans

For quick scans, you can proactively enable pre-computed reachability when you want reachability analysis without build requirements. This pragmatic approach provides vulnerability assessment based on manifest files alone, making it ideal for:

• Build-free analysis: When you want reachability insights without setting up build environments or waiting for compilation.
• CI/CD pipelines: In environments where you want reachability analysis without build dependencies.
• Large-scale scanning: When scanning multiple repositories or projects, where build setup isn’t practical.

The philosophy behind pre-computed reachability is simple: don’t let perfect get in the way of better. When full call graph analysis isn’t possible or when you want a pragmatic approach without build requirements, pre-computed reachability ensures you still get actionable security insights rather than no analysis at all.

Comparison with Other Reachability Analysis Types

Pre-computed reachability complements Endor Labs’ other reachability analysis capabilities:

• Function-level reachability: The most precise analysis that examines your application’s source code directly through full call graph generation. This is the primary and preferred method when builds succeed, providing the highest accuracy for production applications.
• Pre-computed reachability (this page): A pragmatic, manifest-based analysis that works without builds or source code access. Serves as an automatic fallback for full scans when builds fail, and can be enabled for quick scans when you want reachability analysis without build requirements. Focuses on transitive dependencies.

Endor Labs automatically uses the best available analysis method for your situation. When full call graph generation is possible, it’s used for maximum precision. When it’s not, pre-computed reachability steps in as a reliable fallback, ensuring you always get actionable security insights.

Limitations

Direct Dependency Vulnerabilities

Pre-computed reachability analysis is optimized for vulnerabilities in transitive/indirect dependencies, where it can leverage the analysis of how your direct dependencies interact with their dependencies. When full call graph generation is possible, function-level reachability analysis provides more precise results by analyzing your application’s source code directly.

Endor Labs collects and analyzes a large amount of information about open-source packages and uses it to compute scores.

• Every open-source package is scored across different dimensions that capture both security and operation aspects of a risk.

• Every AI model is scored on a multidimensional scoring system grouped into four main categories: security, activity, popularity, and operational integrity.

Each category’s Endor score represents the average of all contributing factors within that category. See View scorecards for more information on checking Endor scores.

See Package scores for more information on package scores.

Scores provide a high-level, easy-to-understand metric of how well a package does based on factors such as security, activity, popularity, and code quality.

Endor Labs scores are categorized into:

• Security: Indicates the number of security-related issues a package may have such as known vulnerabilities, following security best practices when developing code, and the results of static code analysis. Packages with lower security scores can be expected to have many security-related issues when compared with packages with higher scores. See the factors affecting the security score for more details.
• Activity: Indicates the level of development activity for a package as observed through the source code management system. Packages with higher activity scores will be more active and presumably better maintained when compared to packages with a lower activity score. See the factors affecting the activity score for more details.
• Popularity: Indicates how widely a package is used in its ecosystem by tracking both source code management system metrics (for example, the number of stars in GitHub), as well as counting how many other packages import it. A package with a high popularity score indicates that it is used widely. See the factors affecting the popularity score for more details.
• Code Quality: Indicates how well the package complies with best practices for code development and includes the results of static code analysis of that package’s source code. A package with a higher quality score has fewer code issues. See the factors affecting the code quality score for more details.

Input data for score calculation

For calculating scores of vulnerabilities, Endor Labs performs score computation for various entities such as:

• Repository score - A repository has a score that captures overall repository activity and properties that span multiple versions of the code.
• Repository version score - A repository version has a score that captures details that are specific to a version of the code.
• Package version score - A package version that captures the details that are specific to a package version.

The scoring algorithm considers the following input parameters while calculating the scores:

• Data from a version control system such as Git that provides information about files, versions, and their contents.
• Data from a source code management system such as GitHub that provides information about the development activities on a project like issues, pull requests, and more.
• Data from Package managers that provide information about the properties of a package, for example, license, releases, and metadata like the number of stars.
• Data from Vulnerabilities that provide information about known security issues in a package.
• Data from Static code analysis tools that provide information about specific issues in the source code of the package.

Score range

The scores for each category range between 0 and 10. For example, a score of 5 indicates inconclusive analysis and the package is neutral. A score higher than 5 indicates that the package mostly has positive factors while a score lower than 5 indicates negative factors. A score of 10 indicates that the package meets all the positive conditions, while a score of 0 indicates that a package meets all negative conditions.

Endor Labs detects malware in dependencies by scanning the packages used in the project and recognizing known malicious patterns.

Monitoring for known malicious packages: Endor Labs scans dependencies to identify malware by cross-referencing findings with the Open Source Vulnerability (OSV) database and data from the proprietary malware feed.

Suspicious code behavior: Endor Labs uses malware detection rules and SAST rules to scan open source package dependencies for suspicious code patterns and behaviors. These rules analyze code structures, detect anomalies, and identify potential threats.

Detect malware findings

Endor Labs provides a set of malware policies designed to identify and manage malicious or suspicious code in your project, ensuring that Endor Labs detects potential security risks early.

• The OSS finding policy detects malicious code and findings in your project. You can edit the policy to change the severity and template parameters.

• Configure malware action policy to specify how detected malware findings should be handled automatically, including notifications, blocking actions, and workflow triggers.

• Configure malware exception policy to exclude malware findings under defined conditions. This filters out false positives and keeps the focus on critical risks.

View malware findings

You can view the malware findings, prioritize them, and take corrective action.

1. Sign in to Endor Labs and select Projects from the left sidebar.

2. Select the project for which you want to view the malware.

3. Select Malware under Code Dependencies to view malware findings.

   

4. Select a finding to view detailed information of the malware in the right sidebar.

   The right sidebar contains the following information:

• Project: The name of the project where Endor Labs finds the malware, finding policy, categories, and attributes of the project.

• Risk Details:

  • Explanation of the finding.
  • Reasoning explains why Endor Labs classifies the package as malware.
  • Recommended remediation.

• Metadata: Contains details such as the vulnerability IDs, ecosystem, package release date, and advisory publication date.

  

5. Click View Details, then select Dependency Path to view the dependency path.

   

Check for malicious package versions

You can check whether specific package versions are flagged as malicious by querying the Endor Labs malware database. Run the following command to make an API query. The namespace must be oss, and you can pass one or more package versions in the names list.

endorctl api create -r QueryMalware -n oss -d '{"spec":{"package_version_names":{"names":["<ecosystem>://<package>@<version>"]}}}'

For example, run the following command to check whether the MailBee@12.3.3 package version is malicious.

endorctl api create -r QueryMalware -n oss -d '{"spec":{"package_version_names":{"names":["nuget://MailBee@12.3.3"]}}}'

The command returns a json response with details about the package version and the reasons for marking it as malicious.

{
  "meta": {
    "create_time": "2025-09-02T04:40:29.773434484Z",
    "kind": "QueryMalware",
    "name": "malware for ",
    "update_time": "2025-09-02T04:40:29.773434744Z",
    "version": "v1"
  },
  "responses": {
    "values": {
      "nuget://MailBee@12.3.3": {
        "list": {
          "objects": [
            {
              "meta": {
                "create_time": "2025-06-27T07:39:08.576Z",
                "index_data": {
                  "data": [
                    "@ancestor=oss"
                  ],
                  "tenant": "oss"
                },
                "kind": "Malware",
                "name": "Malicious code in MailBee (nuget)",
                "update_time": "2025-09-02T01:41:51.930710821Z",
                "upsert_time": "2025-09-02T01:41:51.930710821Z",
                "version": "v1"
              },
              "spec": {
                "additional_notes": [
                  "\n---\n_-= Per source details. Do not edit below this line.=-_\n"
                ],
                "advisory_last_updated": "2024-06-25T13:30:02Z",
                "advisory_published": "2024-06-25T13:30:02Z",
                "aliases": [
                  "MAL-2024-4540"
                ],
                "cwe_id": "CWE-506",
                "ecosystem": "ECOSYSTEM_NUGET",
                "malware_detected_on": "2024-06-25T13:30:02Z",
                "package_name": "MailBee",
                "purl": "pkg:nuget/MailBee",
                "source": "MALWARE_SOURCE_OSV",
                "status": "MALWARE",
                "summary": "Malicious code in MailBee (nuget)",
                "version": {
                  "osv_id": "MAL-2024-4540",
                  "version": "12.3.3"
                }
              },
              "tenant_meta": {
                "namespace": "oss"
              },
              "uuid": "685e4a9c9787b3b77c7ac0c0"
            }
          ],
          "response": {
            "next_page_id": "685e4a9c9787b3b77c7ac0c0",
            "next_page_token": 1
          }
        }
      }
    }
  },
  "spec": {
    "package_version_names": {
      "names": [
        "nuget://MailBee@12.3.3"
      ]
    }
  },
  "tenant_meta": {
    "namespace": "oss"
  },
  "uuid": "68b6753d19d009449113d065"
}