The popular Java library for logging error messages in applications is one of the most deployed pieces of open-source software (OSS).

But it wasn’t until December 2021 that Log4j became a security pejorative: A vulnerability within the software has impacted an estimated 44% of corporate networks worldwide (and, experts say, that number is most likely higher, as new instances are continually being discovered).

The incident provided a cautionary, eye-opening tale on the dangers of open-source software, which is, almost nearly, everywhere: It is estimated that open source constitutes 70 to 90% of any given piece of modern software.

“Open source software touches every corner of today's software development ecosystem,” said Henrik Plate, lead security researcher at Endor Labs Station 9. “But while the adoption of open source has steadily increased over the decades, the security of our software supply chains has long not been given the attention it requires.”

To help refocus this, the dependency lifecycle management platform has released a list of the top 10 open source software risks for 2023.

Compiled by Endor’s Station 9 research team, the report outlines risks introduced through open-source components throughout the software development process. These can ultimately compromise systems, enable data breaches, undermine compliance, or hamper availability.

“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,” said Plate. “That’s exactly why the industry should be aware of these risks.”

More than 20 industry experts — including CISOs from HashiCorp, Adobe, Palo Alto Networks, Databricks and Discord — contributed to and peer-reviewed the report, which is intended to serve as a “Top 10 Oss risks framework” akin to the OpenSSF scorecard project.

The top 10 risks identified in the report include the following:

1. Known vulnerabilities: A component version may contain vulnerable code that is accidentally introduced by developers. Those vulnerability details are publicly disclosed through a common vulnerabilities and exposures (CVE) system, and exploits and patches may or may not be available.
2. Compromise of a legitimate package: Attackers may compromise resources that are part of an existing legitimate project or of the distribution infrastructure to inject malicious code into a component. Such as through hijacking the accounts of legitimate project maintainers or exploiting vulnerabilities in package repositories.
3. Name confusion attacks: Attackers may create components whose name resemble those 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).
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.
5. Outdated software: A project may use an old, outdated version of the component (even if newer versions exist).
6. Untracked dependencies: Project developers may not be aware of a dependency on a component at all because it is not part of an upstream component’s software bill of materials (SBOM), because SCA tools are not run or do not detect it, or because the dependency is not established using a package manager.
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.
8. Immature software: An open source project may not apply development best-practices — that is, 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.
9. Unapproved changes (mutable): A component may change without developers being able to notice, review or approve such changes. This can be 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.
10. Under/over-sized dependency: A component may provide very little functionality (that is, npm micro packages) or a lot of functionality (of which only a fraction may be used).

High-profile vulnerabilities including Log4Shell, Heartbleed, Shellshock, and the proliferation of malicious software components are significantly changing how organizations view open source, said Plate.

“Today, developers and open source consumers alike are faced with a fast-moving threat landscape on one side and numerous security initiatives and products on the other coming from industry, academia and regulatory bodies,” he said.

Endor Labs CEO and cofounder Varun Badhwar agreed that, “open-source risk management has fallen behind open source usage.”

At their core, most open-source security programs focus on license compliance and known vulnerabilities, he said, both of which do not capture the biggest risks to modern software supply chains. Instead, the industry should take a holistic approach to open source risk management that encompasses security, operational, and legal aspects.

“We believe [the report]  offers an unprecedented and critical dive into the complexities of open source software reuse,” said Plate.

However, he emphasized that the report is not meant to criticize open source projects. The goal is to help professionals pinpoint the most serious security and operational risks of upstream components and deploy the best remediation strategies. Endor will update it regularly to reflect both technological advances and a quickly evolving threat landscape.

“Most organizations heavily rely on OSS today, but we don't have a holistic way to talk about and measure OSS risks,” said Clint Maples, CISO at Robert Half, who reviewed the report. “Endor Labs has taken the lead in building a great framework that gives security and development teams a productive way to understand, measure, and mitigate OSS risk.”