.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
OWASP Top 10 Risks for Open Source
The station 9 research team teamed up with over 20 CISOs and CTOs to identify the top 10 security and operational risks introduced through reliance on open source code.
The station 9 research team teamed up with over 20 CISOs and CTOs to identify the top 10 security and operational risks introduced through reliance on open source code.
The station 9 research team teamed up with over 20 CISOs and CTOs to identify the top 10 security and operational risks introduced through reliance on open source code.
The station 9 research team teamed up with over 20 CISOs and CTOs to identify the top 10 security and operational risks introduced through reliance on open source code.
The station 9 research team teamed up with over 20 CISOs and CTOs to identify the top 10 security and operational risks introduced through reliance on open source code.
Despite the heavy reliance on OSS in the software supply chain, the industry lacks a consistent way to understand and measure risk for OSS. Risk management in OSS started with license management, and then evolved to CVEs, but we still lack a holistic approach to OSS risk management that encompasses security, legal, and application resiliency. With this document, we’re excited to collaborate with industry experts and leaders to create just that.
Over the last decade of reliance on OSS, known vulnerabilities, captured as CVEs, have emerged as the key metric of security. Known vulnerabilities, while an important signal, typically capture mistakes made by well-intentioned developers. These mistakes could be exploited by attackers and should be fixed, but they hardly encompass the full spectrum of risks that a reliance on OSS includes.
Operational risks, like ones introduced by outdated or unmaintained software, or next-generation supply chain attacks like name confusion attacks, cannot be captured by CVEs. These risks are significant, as highlighted by the recent Open Source Security and Risk Analysis report by Synopsys:
- 89% of codebases contain OSS that is more than 4 years out of date
- 91% of codebases contain components that have had no new development in over two years
In the State of Dependency Management 2022, the Station 9 research team uncovered that 95% of vulnerabilities exist in transitive dependencies (the software packages automatically brought in by the OSS selected by developers). And out of those, many are not actually reachable, or will cause a devastating ripple effect of incompatibility if they were updated. So in this report, the team sought to find the top risks security and development teams should be ready for, both operational and security.
Over 20 CISOs and CTOs contributed and reviewed the research, which was led by Henrik Plate and Dimitri Stiliadis. The research also includes detailed examples and mitigation tactics.
OSS Top 10 Risks
Authors and Contributors
Dependency Management 101
To better understand how these risks may affect us, let us quickly review some basic concepts of dependency management using a simple example. Just skip this section if you’re familiar with dependency management.
The root node of the dependency graph displayed below represents the example project. The child nodes of the root represent 9 open source components the project “directly” depends on. Those components, however, depend on other components as well, all of which become “transitive” or “indirect” dependencies from the perspective of the top-level project.
Direct dependencies are consciously selected by the project developers, e.g., through the declaration in a manifest file such as package.json (Node.js/npm) or pom.xml (Java/Maven) file. Package managers take care of downloading and installing those direct dependencies from 3rd party package repositories to the developers workstation or a CI/CD system. When doing so, package managers also identify transitive dependencies, resolve potential version conflicts and install them locally. In other words, plenty of components are downloaded in an automated fashion in order to make sure all code required by the example project (and more) is present on the developer machine.
This high degree of automation boosted the reuse of open source components in today’s software development. As a result, large portions of modern software have not been specifically developed for an application at hand, but come from generic open source projects. Looking again at the dependency graph, it is not surprising that the ratio of code written for the project itself (the root node) to the code of open source components is 1:4 or less. And we haven’t even touched upon IDEs, build tools etc.
Risk Overview
Every single open source dependency of a software development project has plenty of properties - both the component (i.e. the code or binary artifact downloaded) and the corresponding open source project with all its stakeholders (e.g., contributors, maintainers) and systems (e.g., source code management, build systems).
The list above provides an overview of 10 problematic properties, which can result in significant security or operational risks for downstream consumers. Security risks can result in the compromise of system or data confidentiality, integrity or availability. Operational risks can endanger software reliability on the one hand, but can also increase the efforts and investments required to develop, maintain or operate a software solution.
Read the full report to better understand how each risk works, and can be mitigated.
Want to stay in the loop?
Want to stay in the loop?
Sign up for our newsletter.
Want to stay in the loop?
Sign up for our newsletter.
Want to stay in the loop?
Sign up for our newsletter.
Want to stay in the loop?
Sign up for our newsletter.