What's the difference between Endor Labs' program analysis based approach and other SCA tools?
This is the prevalent method of doing SCA. The scanner looks at manifest files, which declare the dependencies the app is using. Then, it compares those dependencies to a vulnerability database and surfaces all license and known vulnerability issues associated with those dependencies. Transitive dependencies are often missed, and users can only prioritize on external factors such as CVE criticality or other scores, with no context on whether or not the risk can actually impact their code.
On the other end of SCA range there are runtime solutions. These tools use code instrumentation, eBPF, or other techniques to observe the application in a running state. This produces accurate results on executed calls, but risks false negatives, or requires 100% test coverage - meaning that every single path must be executed, which is hard to achieve. By the nature of how it works, runtime SCA surfaces risks after the code is executed, and months after it's developed, which is often too little too late.
One customer reported 8,568 developer hours saved by prioritizing vulnerabilities with Endor Labs: developers reported it takes upwards of 8 hours to investigate a single instance of a vulnerability. Critical vulnerabilities tend to get pushed to the top of the list, but engineering investigations will often show that the vulnerable function isn’t actually in use. With Endor Labs, security was able to surface that insight in seconds.
Full view of all direct and transitive dependencies including ones not declared in manifest files.
Limited to dependencies declared in the manifest.
Provides visibility all the way down to OS libraries but is often limited to the code that is executed or tested.
By using source code as the ground truth and applying program analysis techniques, Endor Labs can pinpoint every direct and transitive dependency in use, down to the functions being called by your application.
Frequently misses discovering dependencies (phantom dependencies), or guesses incorrect versions.
Risks are unreachable until they are executed. This approach is prone to false negatives because it misses seldomly run code, code not covered in test automation, or code that is exploited into a non-standard execution path.
Cost of remediation
Provide early feedback as new dependencies are being evaluated, intervention with pull-request comments, or policy enforcement in CI pipelines. Only take disruptive action (i.e. break builds) when the risk justifies it across multiple dimensions - reachable, fixable, exploit maturity, deployed in production, etc.
With no context, engineers spend 1000s of hours each month triaging vulnerabilities based on CVSS scores. Any disruptive action such as breaking builds can halt productivity and cause friction with development teams.
The cost of remediation rises exponentially the further you go from development to production. Due to how runtime SCA works, risks will always be flagged closer to production thereby either delaying releases or causing security debt to keep piling up.
Endor Labs provides risk scores based on the popularity, activity, quality, and security of millions of open source packages, so developers can select safer dependencies from the start.
Manifest-based SCA tools typically do not look at risks beyond known vulnerabilities and licenses
Runtime SCA tools typically do not assist with the evaluation and selection of open source dependencies.
Book a demo with one of our specialists and learn how Endor Labs can help you scale your OSS usage.