State of Dependency Management 2023
As modern software trends toward distributed architectures, microservices, and extensive use of third party and open source components, dependency management only gets harder. Our latest report explores emerging trends that software organizations need to consider as part of their security strategy.
- AI and LLM caused an explosion of OSS - 70% of packages using OpenAI's APIs are brand new packages.
- AI does not replace AppSec engineers - Current LLM technologies have a low precision rate of less than 10% when analyzing malware.
- 55% of applications have calls to security sensitive APIs in their code base, but that rises to 95% when dependencies are included.
- 71% of typical Java application code is from open source components, yet apps use only 12% of imported code.
As modern software trends toward distributed architectures, microservices, and extensive use of third party and open source components, dependency management only gets harder. Our latest report explores emerging trends that software organizations need to consider as part of their security strategy.
- AI and LLM caused an explosion of OSS - 70% of packages using OpenAI's APIs are brand new packages.
- AI does not replace AppSec engineers - Current LLM technologies have a low precision rate of less than 10% when analyzing malware.
- 55% of applications have calls to security sensitive APIs in their code base, but that rises to 95% when dependencies are included.
- 71% of typical Java application code is from open source components, yet apps use only 12% of imported code.
As modern software trends toward distributed architectures, microservices, and extensive use of third party and open source components, dependency management only gets harder. Our latest report explores emerging trends that software organizations need to consider as part of their security strategy.
- AI and LLM caused an explosion of OSS - 70% of packages using OpenAI's APIs are brand new packages.
- AI does not replace AppSec engineers - Current LLM technologies have a low precision rate of less than 10% when analyzing malware.
- 55% of applications have calls to security sensitive APIs in their code base, but that rises to 95% when dependencies are included.
- 71% of typical Java application code is from open source components, yet apps use only 12% of imported code.
As modern software trends toward distributed architectures, microservices, and extensive use of third party and open source components, dependency management only gets harder. Our latest report explores emerging trends that software organizations need to consider as part of their security strategy.
- AI and LLM caused an explosion of OSS - 70% of packages using OpenAI's APIs are brand new packages.
- AI does not replace AppSec engineers - Current LLM technologies have a low precision rate of less than 10% when analyzing malware.
- 55% of applications have calls to security sensitive APIs in their code base, but that rises to 95% when dependencies are included.
- 71% of typical Java application code is from open source components, yet apps use only 12% of imported code.
As modern software trends toward distributed architectures, microservices, and extensive use of third party and open source components, dependency management only gets harder. Our latest report explores emerging trends that software organizations need to consider as part of their security strategy.
- AI and LLM caused an explosion of OSS - 70% of packages using OpenAI's APIs are brand new packages.
- AI does not replace AppSec engineers - Current LLM technologies have a low precision rate of less than 10% when analyzing malware.
- 55% of applications have calls to security sensitive APIs in their code base, but that rises to 95% when dependencies are included.
- 71% of typical Java application code is from open source components, yet apps use only 12% of imported code.
From CI/CD security to secure images, from SCA to IaC, the term “Software Supply Chain Security” has come to mean different things for different people. We believe that at the foundation of it all, is the code you choose to include in your applications at the earliest stage.
80% of code in modern applications is code you didn’t write, but rely on through open source packages. The selection, security, and maintenance of these dependencies is the first and most crucial step towards software supply chain security. Open source has clearly won as the method to deliver incredible value quickly, while leveraging the work of others, and hopefully contributing back so that others may benefit from your work as well.
In its inaugural report, the Endor Labs research team, Station 9, chose to focus on exploring the complexities of selecting, securing, and maintaining open source dependencies.
- What constitutes a “critical project”?
- Is the latest version always more secure?
- Where are most vulnerabilities found?
- What methods can be used to determine the best course of action?
Author Henrik Plate attempts to answer these questions and more in his research.
Key Insights in 2023
“The fact that there’s been such a rapid expansion of new technologies related to Artificial Intelligence, and that these capabilities are being integrated into so many other applications, is truly remarkable—but it’s equally important to monitor the risks they bring with them,” said Henrik Plate, lead security researcher at Endor Labs Station9. “These advances can cause considerable harm if the packages selected introduce malware and other risks to the software supply chain. This report offers an early look into this critical function, just as early adopters of matching security protocols will benefit most from these capabilities.”
The report reveals that:
- The vast majority of all vulnerabilities, 95%, are indeed found in transitive dependencies, making it very difficult for developers to assess the true impact of these issues, or whether they’re even reachable.
- A comparison between the two most popular community initiatives to identify critical projects–Census II and OpenSSF Criticality Scores–reveals that determining criticality is far from simple. In fact, 75% of the packages in Census II have a Criticality Score of less than 0.64; organizations have to decide for themselves which open source projects are critical.
- Dependency confusion has been a major benefit to the bad guys in recent supply chain attacks, while the risk indicators covered in widely used initiatives typically can’t flag these attacks.
- Trouble ahead– 50% of the most used Census II packages didn’t have a release in 2022, and 30% had their latest release before 2018 - these can cause serious security and operational issues in the future.
- New does not mean secure - When upgrading to the latest version of a package, there’s still a 32% chance it will have known vulnerabilities.
- Reachability is the most important criteria when prioritizing; doing it on the basis of security metrics alone (such as CVSS scores) or ignoring vulnerabilities in test dependencies only reduces the likelihood of a vulnerability by 20%.
It’s been barely five months since ChatGPT’s API was released, but Endor Labs’ research has already identified that it’s used in 900 npm and PyPi packages across diverse problem domains. 75% of those are brand new packages. While the advances are undeniable, organizations of all sizes need to practice due diligence when selecting packages. That’s because the combination of extreme popularity and a lack of historical data represents fertile ground for potential attacks.
Focusing specifically on LLM applications in security, the research uncovers how LLM can effectively create and hide malware, and even become a nemesis to defensive LLM applications. Given this landscape, organizations will need to document the components and vulnerabilities their applications include, such as through a Software Bill of Materials (SBOM). Applications typically use only a small percentage of the open source components they integrate, while developers seldom understand the torrent of dependencies in each of those components.
To satisfy transparency requirements and protect the brand, it’s important for organizations to go beyond standard SBOMs. They need to understand not only the list of components but also how they’re being used within their applications, and which vulnerabilities are exploitable. This will enable a better understanding of risk, improve productivity and reduce cost.
About the Author
The State of Dependency Management was researched and written by Henrik Plate, lead security researcher on the Station 9 team.
Henrik Plate is a security researcher working with Endor Labs, aiming to improve the security of today’s software supply chains, and in particular the secure consumption of open source.
He formerly worked for SAP Security Research, where he led the focus topic ‘open source security’ starting in 2014. He co-authored several academic papers on this topic, presented at academic and industry conferences like the RSA, is the project lead and core-developer of Eclipse Steady (an open source solution using program analysis techniques to assess the exploitability of vulnerabilities), and contributes to the Risk Explorer for Software Supply Chains (an open source solution to understand supply chain threats and safeguards).
He also worked on security policies, leading a 3y public-funded collaborative research project as technical and scientific coordinator, participated in M&A technical due diligence, created and rolled-out company-wide secure development training, and participated in product security assessments.
He received his MSc in Computer Science and Business Administration in 1999 from the University of Mannheim, Germany, and holds a CISSP certification.
The Risk Explorer - A visual way to learn about supply chain security
As if dependency management wasn’t complicated enough, security and development teams must also educate themselves on potential supply chain attacks and mitigation tactics. As attackers evolve, many of these attacks can no longer be detected by vulnerability scanning or other traditional methods. As open source becomes prevalent, attackers shift their focus to the way we consume open source software, or the maintainers themselves.
The Risk Explorer, co-developed by Henrik together with Piergiorgio Ladisa (SAP Security Research), Olivier Barais (University of Rennes) and Matias Martinez (Université Polytechnique Hauts-de-France), is a project that aims to create a taxonomy of the attack vectors at the disposal of malicious actors.
Download the Report
Request a Demo
Request a Demo
Meet with a specialist to discuss your use cases.
Request a Demo
Meet with a specialist to discuss your use cases.
Request a Demo
Meet with a specialist to discuss your use cases.
Request a Demo
Meet with a specialist to discuss your use cases.