This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Reachability analysis

Learn how Endor Labs helps you identify which vulnerabilities are exploitable, potentially exploitable, and false positives.

Table of Contents

This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Learn how Endor Labs helps you identify which vulnerabilities are exploitable, potentially exploitable, and false positives.

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.

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.

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.

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.

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.

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.

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

Analysis Type Requirements Coverage Use Case
Function-level Successful project build and client call graph generation Direct and transitive dependencies Precise vulnerability assessment for production applications
Dependency-level Dependency resolution and import analysis only Direct and transitive dependencies Quick dependency prioritization and cleanup
Pre-computed Dependency metadata without compilation or call graphs Transitive dependencies only Pragmatic analysis as a fallback when builds fail, and when you want reachability analysis without build requirements

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.

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.

Pre-computed Reachability analysis

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.

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#.

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:

Scan type Reachability analysis type Reachability Coverage Call graph generated
Quick scan None None ✗
Quick scan with pre-computed flag Pre-computed Transitive dependencies ✗
Full scan Full dependency-level and function-level Direct and transitive dependencies ✓
Full scan with pre-computed flag Dependency-level and function-level. If the code build fails, it falls back to pre-computed reachability Direct and transitive dependencies ✗

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.

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.

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.

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.

Pre-computed reachability serves two distinct purposes:

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.

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.

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.

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.