Endor Labs has published the 2024 Dependency Management Report, reinforcing a problem many developers have known for years. When you patch something, you are highly likely to break something else. From the report and based on its research, Endor Labs says that the chance of breaking something is as high as 75%.
Darren Meyer, staff research engineer at Endor Labs, said: “A lot of organizations are struggling with managing dependency risks. They’re drowning in vulnerability alerts, many of which don’t represent relevant risk; researching the alerts is expensive for security teams (and software teams), and trying to fix everything is even more expensive.
“Endor Labs research shows that analysis-based vulnerability prioritization has become a critical capability because of this, and highlights other trends and challenges related to dependency management.”
What is the problem with dependencies?
It’s rare that any piece of software is entirely original code. In fact, it’s counterproductive to write everything from scratch. Developers have always reused code, from code libraries in the 1980s to APIs today. Some of that code will be from internal code libraries, where it will have been tested and managed, but an increasing amount comes from external sources.
Third-party APIs from software vendors are an increasing portion of external code. Another significant portion is open-source code, which developers are increasingly adding to their software projects to save time. It’s a sensible move, provided there is a process to document it, test it, and maintain it.
This is where dependency management comes in. Knowing what has changed is key to software integrity. One solution for this is the software bill-of-materials (SBOM). It tracks all the software components, irrespective of where they come from. It lets developers and security teams know when something has changed so that they can check it. However, few organisations have a fully comprehensive SBOM solution in place.
Another part of this solution is the use of public advisory databases by security teams. These databases tell them about known vulnerabilities and what patches, if any, are available. They can use this information to ensure that those patches are applied and that developers can check their code for dependency issues.
AI is exacerbating the problem of dependency management
The role of AI in writing code has been debated over the last couple of years. While it makes it easier for developers to solve problems by suggesting solutions, there is still little trust in the code it generates.
This report cites several reasons for this. The first is that the AI assistants are not linked to vulnerability management. The report states, “We found that remediation of vulnerabilities in dependencies requires a major version update 24% of the time. Minor updates can potentially break a client 94% of the time, and patches have a 75% chance of causing a break.”
The second is phantom dependencies. Endor Labs ties this to the fact that AI software projects are often written in Python. It says it is “notorious for including dependencies that are not declared in manifests.” If you don’t know it exists, you cannot track it. There is a need for AI projects to record ALL dependencies and push them to an SBOM.
The third issue is that the research shows that 56% of library vulnerabilities occur where there are phantom dependencies. You cannot patch or assess the risk from a vulnerability if you don’t know you are at risk from it.
The devil is in the detail
The report looks at the challenge of identifying dependencies and their vulnerabilities. It discusses what organisations can do to understand their risk from open-source and phantom dependencies. The main focus is on building and maintaining trusted manifests around software.
Importantly, it spends time on the challenge of dealing with vulnerability databases. This section has several takeaways that organisations can implement easily to improve security. Many organisations will likely be surprised at the risks they face with their current processes.
The report also discusses software composition analysis (SCA), its role in dependency management, and why it must do more to support remediation. This section makes interesting reading for organisations that currently use SCA tools and are also adopting AI to assist with code generation.
Enterprise Times: What does this mean?
This report examines a specific set of issues with software development. It offers ways to improve, but for many organisations, this will require a rethink of how they work. Importantly, despite the headline figure, this is not about stopping software development or taking too long to patch.
It focuses on the need for better manifests and SBOM usage, along with a better process for identifying vulnerabilities. Taken together, those three things will deliver a highly significant improvement in software quality. They will also raise trust in software and, if done properly, allow greater use of AI for software development.
It will be interesting to see how quickly Endor Labs sees a change in the behaviour of developers.
