Endor Labs, creators of the Dependency Lifecycle Management platform helping development and security teams maximise the use of open source software (OSS), has unveiled the top 10 open source software risks of 2023. The report is compiled by the company’s Station 9 research team, which brings together global researchers and software development specialists to uncover shortcomings in traditional methods of open source security. The report outlines risks introduced through the dependency on open source components throughout the software development process, from security risks like known vulnerabilities, name confusion attacks and compromise of legitimate packages to operational risks such as outdated, unmaintained or immature software. The report features contributions from some 20 industry experts, including CISOs from various companies. This is the first research of its kind to encompass operational risks alongside security threats.
“Open source software represents a goldmine for application developers, but it needs security capabilities that are equally effective — and in an environment where more than 80% of the code in new applications can come from existing repositories, it’s clear there are serious risks involved,” said Henrik Plate, Lead Security Researcher at Endor Labs. “This report covers both operational and security issues to highlight the top 10 risks associated with open source components, all leading to problems that can compromise systems, enable data breaches, undermine compliance and hamper availability. We believe it offers an unprecedented and critical dive into the complexities of open source software reuse.”
The top 10 risks identified include:
- 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.
- 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.
- OSS-RISK-3 – Name Confusion Attacks: Attackers may create components whose name resemble 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).
- 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 (if at all) by the original open source project.
- OSS-RISK-5 – Outdated Software: A project may use an old, outdated version of the component.
- OSS-RISK-6 – Untracked Dependencies: Project developers may be unaware of a dependency on a component at all.
- 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 aren’t or cannot be met.
- OSS-RISK-8 – Immature Software: An open source project may not apply development best practices, e.g., not use a standard versioning scheme, or have no regression test suite, or review guidelines or documentation. As a result, a component may not work reliably or securely.
- OSS-RISK-9 – Unapproved Changes (mutable): A component may change without developers being able to notice, review or approve such changes.
- 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).
