Top 10 Open Source Software Risks of 2023

Software supply chain issues continue to be a concerning subject of late. Open source software (OSS) has many benefits, yet relying on many open source dependencies could cause security woes if it isn’t managed correctly. This problem has come into focus as more vulnerabilities present themselves and attacks on open source software ecosystems become more sophisticated.

Endor Labs has unveiled its list of the top 10 open source software risks of 2023. Compiled by its Station 9 research team, the comprehensive list considers the shortcomings of traditional dependency management techniques, which tend to rely on known vulnerabilities. Therefore, it mentions these plus operational risks developers will likely encounter when using open source throughout the software development process.

Below are the top 10 open source risks as identified by the Endor Labs Station 9 team. I’ll outline each of them and consider general ways to mitigate these threats.

1. Known Vulnerabilities

The first risk refers to vulnerabilities that have been discovered and are publicly documented as Common Vulnerabilities and Exposures (CVEs). Either developers accidentally added them when integrating dependencies with known vulnerabilities, or they were discovered after the package was installed. Known vulnerabilities may or may not have patches available.

2. Compromise of Legitimate Package

This vulnerability occurs when an attacker compromises a legitimate software package. For example, this could happen if a black hat steals a package maintainer’s login credentials. Or, they may leverage privilege escalation within compromised package repositories. If an attacker can compromise a legitimate package, they could sneak malicious code into a component and have it integrated unknowingly into many software systems.

3. Name Confusion Attacks

Attackers may create malicious libraries whose names resemble popular open source libraries and upload them to registries. For example, a package might impersonate the popular npm library lodash and reupload it with a typo as lodas. Common name confusion attack types include typo squatting, brand jacking and combo-squatting.

4. Unmaintained Software

Many open source software packages are mature and well-supported. However, some projects are abandoned and left unmaintained. These components that aren’t actively maintained present a risk since patches to bugs or known vulnerabilities may not be issued in a timely fashion.

5. Outdated Software

This vulnerability is rather straightforward. Software consumers may use an outdated package version even if newer versions exist. This could pose a severe vulnerability. For example, one-fourth of Log4j implementations still possess the infamous vulnerability, largely due to the simple fact that these consumers haven’t upgraded their installation.

6. Untracked Dependencies

It’s not uncommon for developers to be in the dark concerning the dependencies their software relies on. In fact, 95% of open source vulnerabilities are linked to transitive dependencies hidden deep within the software chain. Untracked dependencies may persist if the component isn’t listed in an SBOM or is undetectable using software composition analysis.

7. License and Regulatory Risk

Often, engineers hastily integrate components without much care for considering the license it has. Yet, OSS may not have a license at all or may possess one incompatible with the project at hand. Issues with licensing could pose a risk to the ecosystem and business availability.

8. Immature Software

Another risk is that the OSS itself may not follow best practices. For example, the package may not have adequate testing, documentation or design review guidelines. Not following best practices may mean the component doesn’t behave as expected or isn’t adequately secured. Not to mention that poor visibility into package contents could hinder efforts at diagnosing errors.

9. Unapproved Changes (Mutable)

Changes to the component may occur that developers are not aware of and have not approved. Perhaps the download link points to an unversioned resource, or maybe the version has been tampered with. Whatever the reason, this means that developer consumers have no way of knowing that the package is altered.

10. Undersized/Oversized Dependency

Certain components might carry a lot of functionality, but the application only uses a fraction of the total features. Shipping the entire dependency could bring unnecessary exposures and risks, not to mention additional unused dependencies. On the other hand, even small components with a few lines of code can carry risks.

Mitigating the Top Ten Open Source Risks

Open source is a top business driver in 2023—a Red Hat study found that 90% of enterprises now rely on open source technologies. Since OSS is so embedded into the fabric of modern digital enterprises, we must work to use it safely instead of ripping it out entirely.

Furthermore, determining the provenance of open source software isn’t always that straightforward. Another vulnerability could have to do with the source of the code. For example, details about the source code, build process or distribution process may not be known or verifiable.

Understanding the potential risks associated with OSS use is the first step. The next is mitigating each of these potential threats. Here are some ways to slim down the risks of the top 10 list:

• Ease the discovery of known vulnerabilities with automated vulnerability scanning.
• Continually update software and have a consistent routine for patching.
• Try to use mature, stable projects that are actively maintained.
• Closely review new dependencies to ensure they are legitimate.
• Adopt registries that verify the provenance of packages.
• Request a software bill of materials (SBOM) from your software vendors to discover hidden dependencies.
• Contribute back to the open source packages that your company uses.

OSS maintainers should seek to protect their account details and logins and quickly patch known vulnerabilities. For more information, Endor Labs has released a full copy of the report on their website and on GitHub with more detailed descriptions, examples, references and mitigation controls for each of the abovementioned risks.