Top 10 Open Source Software (OSS) Risks

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.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Contributors and Reviewers

Kathy Wang,
CISO, Discord
Talha Tariq,
CISO, Hashicorp
Anshu Gupta,
VP Security, Fast
Niall Browne, CISO,
Palo Alto Networks
Maarten Van Horenbeeck,
CISO, Adobe
Yassir Abousselham,
CISO, UiPath
Selim Aissi,
CISO, Blackhawk Network
Jonathan Meadows
MD Cybersecurity, Citi
Ody Lupescu,
VP Security, Ethos
Clint Maples,
CISO, Robert Half
Justin Dolly,
CSO, Sauce Labs
Arkadiy Goykhberg,
CISO, Branch Insurance
Gerhard Eschelbeck,
CISO, Kodiak Robotics
Colin Anderson,
CISO, Ceridian
Ralph Pyne,
Rachit Lohani,
CTO, Paylocity

80% of code in modern applications is code you didn’t write, but rely on through open source packages. 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. The selection, security, and maintenance of these open source dependencies are crucial steps towards software supply chain security. 

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. In our previous report, The State of Dependency Management, 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. 

The Top 10 OSS Risks

Risk Description Category
OSS-RISK-1 Known Vulnerabilities A component version may contain vulnerable code, accidentally introduced by its developers. Vulnerability details are publicly disclosed, e.g, through a CVE. Exploits and patches may or may not be available. Security
OSS-RISK-2 Compromise of Legitimate Package Attackers may compromise resources that are part of an existing legitimate project or of the distribution infrastructure in order to inject malicious code into a component, e.g, through hijacking the accounts of legitimate project maintainers or exploiting vulnerabilities in package repositories. Security
OSS-RISK-3 Name Confusion Attacks Attackers may create components whose names ressemble names of legitimate open-source or system components (typo-squatting), suggest trustworthy authors (brand-jacking) or play with common naming patterns in different languages or ecosystems (combo-squatting). Security
OSS-RISK-4 Unmaintained Software A component or component version may not be actively developed any more, thus, patches for functional and non-functional bugs may not be provided in a timely fashion (or not at all) by the original open source project Ops
OSS-RISK-5 Outdated Software A project may use an old, outdated version of the component (though newer versions exist). Ops
OSS-RISK-6 Untracked Dependencies Project developers may not be aware of a dependency on a component at all, e.g., because it is not part of an upstream component's SBOM, because SCA tools are not run or do not detect it, or because the dependency is not established using a package manager. Security, Ops
OSS-RISK-7 License Risk A component or project may not have a license at all, or one that is incompatible with the intended use or whose requirements are not or cannot be met. Ops
OSS-RISK-8 Immature Software An open source project may not apply development best-practices, e.g., not use a standard versioning scheme, have no regression test suite, review guidelines or documentation. As a result, a component may not work reliably or securely. Ops
OSS-RISK-9 Unapproved Change (Mutable) A component may change without developers being able to notice, review or approve such changes, e.g., because the download link points to an unversioned resource, because a versioned resource has been modified or tampered with or due to an insecure data transfer. Security, Ops
OSS-RISK-10 Under/over-sized Dependency A component may provide very little functionality (e.g. npm micro packages) or a lot of functionality (of which only a fraction may be used). Security, Ops