Top 10 Open Source Software Risks of 2023

Outdated software, unapproved changes, name confusion attacks and compromise of legitimate package remain the Top 10 open source software risks of 2023.

Adam121 Adobe Stock 315095274
adam121 AdobeStock_315095274

Outdated software, unapproved changes, name confusion attacks and compromise of legitimate package remain the Top 10 open source software risks of 2023, according to Endor Labs.

“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,” says Henrik Plate, lead security researcher at Endor Labs. “This is the first comprehensive study to cover both operational and security issues in highlighting 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.”

From Endor Labs:

The top 10 risks identified include:

  1. 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.
  2. OSS-RISK-4 - 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.
  3. 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).
  4. OSS-RISK-2 - 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. OSS-RISK-5 - Outdated Software. A project may use an old, outdated version of the component (though newer versions exist).
  6. OSS-RISK-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 SBOM, SCA tools are not run or do not detect it or the dependency is not established using a package manager.
  7. OSS-RISK-7 – License and Regulatory 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. 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.
  9. 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.
  10. OSS-RISK-10 - Under/Over-Sized Dependency (provenance). Details about the source code, build process or the distribution process of a component may be unknown or non-verifiable, e.g., the source code repository of the respective project, the commit used for building the binary artifact, or the build job definition and log.

“Just as the OWASP Top 10 ranking has become the definitive list of web application risks, the Endor Labs Station 9 report is designed to serve as the gold standard for gauging open source risks,” Plate adds. “We will update it regularly because these threats apply to every constituency from app developers to downstream consumers, and they deserve greater attention. It’s well-known that open source is oftentimes more performant and secure than proprietary software; 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.”