...to Identify Top 10 Open Source Software Risks of 2023
20 CISOs and technology veterans collaborate with Endor Labs’ Station 9 research team to develop first comprehensive report to analyze both operational and security Open Source Software risks
Endor Labs, creators of the Dependency Lifecycle Management platform helping development and security teams maximize the use of open source software (OSS), today 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. Adhering to the spirit of collaboration that benefits the whole community, the report features contributions from some 20 industry experts, including CISOs from HashiCorp, Adobe, Palo Alto Networks, and Discord. This is also the first research of its kind to encompass operational risks alongside security threats.
“The majority of the code in new applications comes from open source components, and it’s clear that such heavy dependence on open source also implies serious risks,” 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 the consumption of open source components, all leading to problems that can compromise systems, enable data breaches, undermine compliance or hamper availability. We believe it offers an unprecedented and critical dive into the complexities of open source software reuse.
“Just as the OWASP Top 10 has become the definitive list of web application security risks, the Endor Labs Station 9 report is designed to serve as a standard for gauging open source risks,” Plate continued. “We will update it regularly in order to reflect both technological advances and a quickly evolving threat landscape. It’s well-known that open source is oftentimes more performant and secure than proprietary software, but it’s also clear that open source software comes as-is, without warranties of any kind, and any risk of using it being solely on downstream users. That’s exactly why the industry should be aware of these risks.”
From a topline view, 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, e.g., through hijacking the accounts of legitimate project maintainers or exploiting vulnerabilities in package repositories.
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 (or not at all) by the original open source project.
OSS-RISK-5 - Outdated Software: A project may use an old, outdated version of the component (though newer versions exist).
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.
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.
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, 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.
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).