Endor Labs vs. Traditional SCA

Software Composition Analysis (SCA) tools were originally developed to tackle license management in Open Source Software (OSS). However, over the years they have been adopted as the de facto standard for OSS security as well, mostly by scanning metadata and comparing the results to known vulnerability databases. This has led the industry to confuse compliance with security. 

This issue can be broken down into a few major areas:

Known vulnerabilities are a lagging indicator for risk - Most of today’s OSS supply chain attacks are confusion attacks that target the method in which code is consumed. For more information about OSS supply chain attacks see the Risk Explorer. Known vulnerabilities typically represent mistakes by well-intentioned developers, rather than malicious actors. Relying on CVEs alone leaves organizations largely exposed. 

Operational risk - Not every risk is a CVE. Much of the risk in relying on open source code is operational. What’s the impact of an update? Who will be affected? What happens when an OSS dependency is no longer maintained? These considerations eat up thousands of engineering hours and are largely ignored by SCA tools, which do not have full visibility into how software dependencies are used in the organization. 

Security noise -  Since SCA tools ultimately have the sole purpose of surfacing known vulnerabilities, they tend to surface a lot of them. In many programming languages, it turns out that over 80% of vulnerabilities identified by SCA tools are in parts of the code that developers aren’t even using in their applications. Based on these findings, security teams are often thrown into a back and forth with engineering that wastes thousands of hours.

The cost of noise

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.

The Endor Labs approach

Endor Labs takes a different approach to software supply chain management and open source security, Dependency Lifecycle Management. Endor Labs considers both security and operational risks. Quality, popularity, use of best practices, supportability, and other metrics go into a holistic risk score that helps developers select better dependencies, and security teams set policies that reduce long-term risk.

		SCA Tools
Vulnerability prioritization	Endor Labs uses static analysis to map how dependencies are used in the org, and is able to prioritize the ones that are actually reachable, cutting security noise by 80%.	SCA tools tend to use the severity of known vulnerabilities as the only prioritization metrics, which creates tech debt as even unreachable vulnerabilities are prioritized due to a “high” or “critical” severity.
Scan accuracy	Endor Labs uses data from both manifest files and the outputs of the build system (npm, maven, etc.), and then applies static analysis to build call graphs that determine reachability.	SCA tools typically rely on manifest files only, which results in unresolved versions and missed transitive dependencies, leading to incomplete results and inaccurate SBOMS.
Risk indicators	Endor Labs considers both security and operational risks. Quality, popularity, use of best practices, supportability, and other metrics go into a holistic risk score that helps developers select better dependencies, and security teams set policies that reduce long-term risk.	SCA tools consider only known vulnerabilities, which are important but a lagging indicator of risk, that typically reveals mistakes by well-intentioned developers, not malicious actors.
Application Optimization	Endor Labs helps developers understand the “blast radius” of software updates, and the operational risk of taking on new dependencies, or relying on existing ones that are unmaintained or have compatibility issues.	SCA tools typically don’t consider operational risk, and focus on known vulnerabilities as the key metric of security.