.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
Introducing JavaScript Reachability and Phantom Dependency Detection
Endor Labs’ JavaScript SCA capabilities cut down noise with a program analysis approach that outperforms manifest scanning SCA tools like Snyk, Veracode, and BlackDuck.
Endor Labs’ JavaScript SCA capabilities cut down noise with a program analysis approach that outperforms manifest scanning SCA tools like Snyk, Veracode, and BlackDuck.
Endor Labs’ JavaScript SCA capabilities cut down noise with a program analysis approach that outperforms manifest scanning SCA tools like Snyk, Veracode, and BlackDuck.
Endor Labs’ JavaScript SCA capabilities cut down noise with a program analysis approach that outperforms manifest scanning SCA tools like Snyk, Veracode, and BlackDuck.
Endor Labs’ JavaScript SCA capabilities cut down noise with a program analysis approach that outperforms manifest scanning SCA tools like Snyk, Veracode, and BlackDuck.
New SCA Capabilities for JavaScript, TypeScript, and NodeJS
We’re excited to announce support for reachability and phantom dependency detection for JavaScript, TypeScript, and NodeJS!
Reachability Analysis
“Reachability” in the context of software composition analysis (SCA) is the ability to determine whether the vulnerable code is being used. Vulnerability prioritization with reachability analysis across both direct and transitive dependencies is already available on Endor Labs for languages such as Java and Rust, Python, C#, and Go. And we’re excited to now extend that support to the JavaScript ecosystem! Each of these languages and ecosystems work and behave differently, but the concepts of reachability analysis are the same.
Your developers pull in open source dependencies, some of which are declared on a manifest file and some are not. Those “direct” dependencies automatically rely on more “transitive” dependencies, which can pull in even more dependencies and so on. If a risk is found anywhere along that dependency tree, you could be vulnerable. Reachability analysis helps you determine whether or not a risk can actually impact your application, and therefore needs to be prioritized.
Reachability Analysis with Endor Labs
The term “reachability analysis” gets thrown around a lot in the AppSec space, but it doesn’t always mean the same thing.
Some reachability solutions rely on runtime agents, which then require large-scale test coverage and instrumentation, while others rely on rules that can only point at direct dependencies, while 95% of vulnerabilities are in transitive dependencies.
Benefits of reachability analysis with Endor Labs:
- Direct and transitive dependency coverage— Detect and prioritize risks along your entire dependency tree, even phantom dependencies (we’re going to talk about that next).
- No runtime agents— Endor Labs uses program analysis to understand code behavior and determine reachability. Learn more in What is reachability-based dependency analysis?
- Go beyond vulnerabilities— Reachability analysis provides visibility into how your code interacts with open source dependencies. This can help you determine the impact of upgrades and prioritize work on operational risk such as unmaintained, unused, or redundant packages. Not just CVEs!
Package Manager Support: yarn, npm, and pnpm
With this release, Endor Labs supports use of the lock file of a yarn, npm, or pnpm-based package to resolve dependencies. It also considers the settings of the .npmrc file in the repository to ensure dependencies from private repositories can be resolved appropriately. And if your JavaScript frameworks and packages use workspaces, Endor Labs automatically takes the dependencies from the workspace to ensure that the package successfully builds.
Enabling these package managers for scans is easy. Using pnpm as an example, simply set ENDOR_PNPM_ENABLED to true. endorctl then scans the pnpm-managed project to discover all the direct and transitive dependencies and the dependency graphs.
Phantom Dependency Detection
A “phantom dependency” refers to a package used in your code that isn't declared in the manifest. This concept is not unique to any one language (beyond JavaScript and NodeJS, it’s also common in Python). Here is an example of how a phantom dependency can occur:
- Package A depends on Package B, which is correctly listed in A’s manifest.
- Package B also depends on Package C. The language allows Package A to require Package C even though it’s not listed in A’s manifest.
- Package C is a phantom dependency because A can access it even when it is not declared as A’s direct dependency.
Phantom dependencies are avoidable with good coding habits. However, it’s safer to assume your developers have accidentally created phantom dependencies, and use an SCA tool that can find them.
Endor Labs detects phantom dependencies and their associated security and operational risk. Just like any other dependency, you’ll be able to determine if the phantom dependency is reachable and should be prioritized for a fix.
Why can the Endor Labs SCA product detect these while others can’t? It mostly boils down to program analysis vs. manifest scanning.
Program Analysis vs. Manifest Scanning
The “source of truth” used by an SCA tool has a significant impact on the quality of JavaScript results. Many SCA tools use the project’s manifest file to determine dependencies, which can be problematic. In JavaScript environments, although the project’s manifest file should outline its full list of dependencies, sometimes the manifest file isn’t an accurate representation of what’s present on the host. Discrepancies between what the project uses and what is declared can happen when:
- Transitive dependencies are used directly
- Packages are added, removed, or upgraded manually without updating the manifest file
- JavaScript’s package resolution logic is changed by the NODE_PATH environmental variable
- The package manager’s (e.g. npm) implementation of the hoisting algorithm for resolving dependencies results in unintended package resolution
Let’s look at an example of the algorithm causing unintended package resolution. Pretend we have a file test.js located at /Users/root/projectRoot/package/foo/test.js.
- test.js uses Package C.
- Javascript's package resolution algorithm looks for Package C in the following order:
/Users/root/projectRoot/package/foo/node_modules
/Users/root/projectRoot/package/node_modules
/Users/root/projectRoot/node_modules
/Users/root/node_modules
/Users/node_modules
/node_modules
This process leads to issues because the algorithm could find Package C in any of the paths above, even if that’s not what the user intended. Even worse, it’s possible the user doesn’t even have control over what’s been added to some of those paths.
To explain how Endor Labs works and why we provide superior JavaScript results, we’ll walk through the differences between program analysis and manifest scanning.
Program Analysis
Endor Labs’ SCA tool uses the application source code as the source of truth, applying a proprietary technology called program analysis to detect dependencies as follows:
- Analyze the application code
- Create an Abstract Syntax Tree
- Analyze types and call flows
- Identify declared and undeclared dependencies
- Compare the versions against a pre-populated database with vulnerabilities
- Generate a call graph to prove whether the dependency is calling the vulnerable code
- Report issues based on “source code view”
With program analysis, we provide a unified view of all dependencies by correlating the dependencies used by the code with the dependencies fetched by the package manager or available in the file system.
Manifest Scanners
Traditional SCA tools (such as Snyk, Veracode, and BlackDuck) solely use the package manifest file as the source of truth, generating dependency lists using the following process:
- Scan a directory for a package manifest files
- Identify the dependencies declared
- Compare the versions against a pre-populated database with vulnerabilities
- Report issues based on “package manager view”
Using just the manifest as the source of truth causes two problems that most organizations avoid at all costs:
- Higher risk of breaches— The tool fails to identify artifacts that contain vulnerable code
- Wasted engineering cycles— The tool can’t properly classify unused or misused dependencies
Get Started with Endor Labs
The new capabilities for JavaScript are available now, along with a slew of others such as secrets detection and Git security posture management. If you want to learn more, we’d love to chat.