- The hidden units raise invisible risks in modern software systems, says the report
- Function level analysis cuts unnecessary vulnerability corrections at 90%
- Advice delays leave systems exposed to possible farms
As organizations increasingly trust third -party components and open source libraries to accelerate development processes, experts have warned that addressing security risks associated with these units has become a significant priority.
The Endor Labs Dependencies Management Report explores the evolutionary challenges in the management of software dependencies and vulnerabilities, and the analysis of seven programming languages (Java, Python, Rust, GO, C#, .net, Kotlin and Scala ) They found less than 9.5% of the vulnerabilities of vulnerabilities in 2024 were considered ‘real threats’.
“Many organizations are struggling for dependency risk management,” said Darren Meyer, research engineer of Endor Labs staff. “They are drowning in vulnerability alerts, many of which do not represent a relevant risk; investigating alerts is expensive For security equipment (and software equipment), and try to fix everything is even more expensive. “
Dependency management
The management of the dependencies is not a simple task since most software projects are based on multiple layers of dependencies, including first -part code libraries, frames and operational dependencies that admit production environments, creating a Interconnected component network, and any vulnerability within this website could expose an organization to significant security risks.
The use of third -party components, particularly open source software, is a common practice in modern software development because it reduces the time that developers need to pass by writing fundamental code, offering pre -constructed functionalities that accelerate development cycles, but also brings unique security challenges. due to vulnerabilities in these external components.
Many security problems come from “ghost units” or hidden components that are not explicitly documented in the software code and can introduce vulnerabilities that traditional tools cannot detect.
These vulnerabilities are not helped by the fact that almost 70% of the notices issued by vulnerability management platforms, such as the NIST NVD, are published after the corresponding security patch, with an average delay of 25 days.
Endor also states that almost half of the notices in public vulnerability databases lack details at the code level, while only 2% provide specific vulnerability information of the function, which makes it difficult for security equipment to determine If known vulnerabilities can be exploited in their applications.
In addition, the endor analysis of 1,250 updates of non -vulnerable versions shows that 24% of corrections require an update of the main version, while 6% of vulnerabilities could be fixed with minor or patch level updates.
Therefore, Endor argues that not all vulnerabilities pose the same level of risk, and organizations that focus on the most accessible and exploitable vulnerabilities are advised, since only around 9.5% of vulnerabilities in dependencies are exploitable at the function level.
The accessibility analysis, which determines whether the application code calls a vulnerable function in a dependency, arises as one of the most effective methods to reduce noise in vulnerability reports. By focusing on vulnerabilities that have a clear path to be exploited, organizations can reduce their remediation efforts by almost 90%, according to the report.
