Discover Open Source Risks with Endor Labs
Use Endor Labs to get accurate dependency inventories and complete vulnerability data sources.
Use Endor Labs to get accurate dependency inventories and complete vulnerability data sources.
Use Endor Labs to get accurate dependency inventories and complete vulnerability data sources.
Use Endor Labs to get accurate dependency inventories and complete vulnerability data sources.
Use Endor Labs to get accurate dependency inventories and complete vulnerability data sources.
.png)
This article is a part of a 3-part series on the three steps of a vulnerability prioritization workflow:
- Discover Open Source Risks with Endor Labs (this article)
- Prioritize Open Source Risks with Endor Labs
- Fix Open Source Risks with Endor Labs
The “vulnerability prioritization workflow” is one of the primary areas of responsibility for an AppSec team. And while that workflow will vary from place to place, they can all be summarized in a three-step process:
- Discover risks— Identify the vulnerabilities that could threaten your business.
- Prioritize risks— Eliminate irrelevant findings and determine are the greatest threats.
- Address risks— Accept risk, remediate, or mitigate the vulnerabilities.
Software composition analysis (SCA) tools are a common part of this workflow, used to automate toil so AppSec owners with limited resources can focus on higher-order tasks. In this series, we talk about the role SCA can play, shortcomings you might encounter, and what “better” looks like. We’ll start at the beginning of the process with identifying risk.
Identifying Open Source Risk
This first step in the vulnerability management workflow includes two core requirements:
- Create an accurate inventory of your third-party components, including open source software (OSS)
- Highlight risks associated with each component
You probably already use an SCA tool to help you with this. At their most basic, your SCA tool must generate an accurate inventory of your third-party components, but a really good SCA tool will Identify other supply chain risks (even if they aren’t security-specific), like malware, abandoned OSS projects, outdated and unused components, and so on.
The Problem With Traditional SCA
Discovering risks involves correlating a list of vulnerabilities with your application code to see if you’re potentially exposed. Mapping vulnerabilities requires an accurate software inventory (including both direct and transitive dependencies) and a robust vulnerability database. An SCA tool is typically used to automate this task. While this sounds like a low bar, tools often struggle to generate an accurate inventory and there are wide disparities between vulnerability databases. We’ll take these issues one at a time.
Traditional SCA Problem: Inaccurate Dependency Inventories
The two most common approaches to building a software inventory are static analysis using manifest files and runtime analysis.
- Manifest file scanning produces lots of false positives and false negatives.
When a developer commits their code, this type of SCA tool uses manifest files or lockfiles to assess which software dependencies are used by an application. Lockfiles are used to build software consistently. Manifest files are declarations of developer intent and rely on a package manager to create the bill of materials. Not every software ecosystem and package manager supports lockfiles. For these ecosystems, SCA tools that don’t actually build the software, or look at it after it has been built, attempt to predict what the package manager will install. This technique can be likened to using a recipe to make assumptions about ingredients contained in a cake. Like a recipe, the manifest is a starting point for the developer. Since the package manager decides what to install, just looking at a manifest file may result in an inaccurate or incomplete software inventory. - Runtime analysis produces too many false negatives.
A runtime SCA tool observes what is installed at runtime. Depending on what it supports, it may miss dependencies that are used by certain applications. Runtime tools know what is installed on a system but don’t always know if a software is used. They also require authentication credentials or agents to be provisioned and installed, which can impact application performance, which creates longer lead times to installation.
Traditional SCA Problem: Inaccurate or Incomplete Vulnerability Data Sources
Most SCA vendors seek to supplement vulnerability information with their own proprietary databases. It’s difficult to compare results across proprietary databases because they’re a company’s “secret sauce,” so it’s hard to figure out which is the “best”. However, we hear from our customers that these proprietary databases rarely meet their requirements because they have:
- Insufficient historical data: There is a mismatch between the age of your dependencies and the age of the vulnerability data. For example, if a database doesn’t have advisories older than 2020 and you have dependencies dating back to 2019, there might be inadequate vulnerability data for many dependencies.
- Inadequate ecosystem coverage: There is a mismatch between the Open Source packages you use and the vulnerability data available to the product. This can result from not supporting the right package management ecosystems for the languages you use, or a product relying on too few data sources for vulnerabilities. When asking a vendor about language support, make sure to also ask them which package ecosystems they support and where they get security advisory data for those ecosystems.
- Infrequent updates: The database isn’t updated frequently enough to catch emerging risks before they can be exploited by bad actors.
SCA is Dead. Long Live SCA.
The problems with traditional SCA tools all stem from the same source: They don’t understand how your 3rd-party dependencies interact with your application code. A tool that doesn’t understand your application can’t accurately identify risk.
There is a better way. Endor Labs was founded on the idea that we should expect more from SCA.
By using program analysis at the time of build, we can see exactly what is in your 3rd-party dependencies and how they interact with your application code. When an SCA tool understands how your application works (including direct and transitive dependencies), you can get an accurate software inventory (and represent it as a Software Bill of Materials, or SBOM) because you know exactly what’s being used.
Discover Risks with Endor Labs
Using program analysis, Endor Labs creates a simulation of your application at the time of build using a combination of the information from your package manager and analysis of your code. The output is an accurate software inventory based on how the code you write interacts with the code you reuse (your software dependencies).
Next, we correlate your software inventory to the Endor Labs Vulnerability Database, which is based on NVD, GHSA, and OSV data along with a manually-annotated, function-level database for vulnerabilities going back to 2018 for 11 languages (and growing). This database is updated every 12 hours and analytics are re-run automatically for every project at least once every 24 hours (or sooner based on project configuration), which means that new vulnerabilities are automatically reported, without customers needing to rescan their projects.
SCA That Meets Your Expectations
With the Endor Labs approach to SCA, you can stop stressing about hidden risks, noisy tools, and mysterious upgrades. We provide:
- Faster risk reduction
- Improved developer productivity
- Accelerated compliance management
Stay tuned for the next article where we delve into the next critical step: Prioritize Risks with Endor Labs.
Book a 20-minute demo to learn how Endor Labs turns your vulnerability prioritization workflows dreams into a reality or start a free, full-featured 30-day trial that includes test projects and the ability to scan your own projects.
