Kicking dependency: Why cybersecurity needs a better model for handling OSS vulnerabilities

Most organizations are still immature when it comes to identifying open-source dependencies that can usher in a host of problems when dealing with vulnerabilities.


As a source of insight into this issue, we can take a look at the Endor Labs “State of Dependency Management Report” for 2024, which aims to provide guidance for CISOs and other security leaders.

“Most commonly, dependencies are recognized as third-party libraries, frameworks, or other software components that provide essential functionality without having to write it from scratch,” the report states.

“The rise of artificial intelligence in software development is only accelerating increases in phantom dependencies and rises in cyber-attacks. We’ll never be able to 100% keep up, which means the most important question application security teams have to answer is: Where should we start?”

Vulnerability management relies on context

Relying on legacy approaches such as consulting the Common Vulnerability Scanning System (CVSS) can drown us in toil, using up scarce time and resources to remediate vulnerabilities that aren’t known to be exploited, aren’t likely to be exploited, or aren’t exploitable due to not being reachable.

We know that modern vulnerability management requires context, which can be obtained by leveraging resources such as CISA’s Known Exploited Vulnerability (KEV) catalog, the Exploit Prediction Scoring System (EPSS), and reachability analysis.

These, when coupled with business context such as asset criticality, data sensitivity and internet exposure really help crystallize where vulnerability management capital should be spent.

The Endor report points out that fewer than 9.5% of vulnerabilities are exploitable at the function level; organizations that combine reachability and EPSS see a 98% noise reduction when it comes to vulnerability management.

The vulnerability database ecosystem is broken

One big challenge AppSec teams face in managing OSS dependencies is the fact that the vulnerability database ecosystem is a mess.

NIST’s National Vulnerability Database (NVD) continues to struggle and was essentially faltering and failing to operate effectively in early 2024, a challenge from which it still hasn’t recovered with tens of thousands of vulnerabilities lacking analysis and enrichment with data such as Common Platform and Enumerations (CPE), which are needed to tie CVEs to specific products.

The NVD currently has more than 18,000 unenriched CVEs from February to September 2024 and an enrichment rate of less than 50% for new CVEs monthly since June 2024 and hasn’t even touched a single CVE from February to May 2024.

This problem isn’t likely to change anytime soon either. As vulnerability researcher Jerry Gamblin points out, the NVD currently is seeing 30% year-over-year growth in CVEs  in 2024, making it no surprise it is struggling to keep up.

Delays in vulnerability advisory publication cause problems

According to the Endor Labs report, it takes roughly 25 days between when a public patch becomes available and an associated advisory publication is released by public vulnerability databases such as the NVD.

Even then, only 2% of those advisories include information about what specific library function contains the vulnerability and 25% of advisories include incorrect or incomplete data, further complicating vulnerability management efforts.

The delay of security advisory publications presents challenges for many organizations. Sometimes CVEs see active exploitation attempts as quickly as 22 minutes after a proof-of-concept (PoC) exploit has been made available.

This is problematic for various reasons. As documented in the Endor Labs report, 69% of security advisories had a media delay of 25 days from the time there is a security release to the time an advisory is published in public vulnerability databases.

This presents an initial lag time from when exploitation may occur to when typical security scanning tools, which rely on the public vulnerability databases, would even pick up a vulnerability, let alone the time it takes organizations to resolve them, which is another factor.


Comments