Quick Guide to the OWASP OSS Risk Top 10

CVEs, or known and cataloged software vulnerabilities, dominate the discussion about open source software (OSS) risk. In 2016, 6,457 CVEs were reported. That number has grown every year since, reaching 28,961 CVEs reported in 2023—an increase of nearly 4.5 times in just seven years. 2024 is already on track to beat 2023, and we will likely see even faster growth once AI is earnestly set to the task of finding vulnerabilities (not to mention creating them).

But there’s more to OSS security than CVEs. In fact, an OWASP-endorsed team of CISOs and other experts came together to think about the risks to OSS besides CVEs. Their newly published list is titled OWASP Top 10 Risks for Open Source Software.

Let’s learn about them.

OSS-RISK-1: Known Vulnerabilities

OK, yes, we just said that there are risks beyond CVEs, but those already discovered vulnerabilities sitting cataloged in databases like the National Vulnerability Database are still the number one risk. Open source developers are amazing but they sometimes make mistakes that leave security weaknesses in their code. Known vulnerabilities may or may not be exploitable (use EPSS scores and public exploit advisories to find out) or patched, but they exist at least theoretically, and you need to be aware of them.

OSS-RISK-2: Compromise of Legitimate Package

Provenance matters, but unlike MC Hammer, no package is 2 legit 2 quit—and by “quit” we mean “be perfectly uncompromisable”. In the famous SolarWinds attack, a threat actor was able to sneak malicious code into the build, which was then signed and distributed to tens of thousands of SolarWinds customers. SolarWinds’ Orion wasn’t open source, but this kind of attack could happen to OSS, too. Attackers use several methods to get malicious code into legitimate packages, such as taking over the accounts of maintainers, exploiting vulnerabilities in repositories, and posing as a genuine contributor and hiding malicious code in ordinary test files, as we just saw with XZ-utils.

OSS-RISK-3: Name Confusion Attacks

There are many ill-intentioned, illegitimate, and downright malicious packages posing as friendly code out there. Bad actors use names, logos, and other visual markers to trick tired and unsuspecting developers into downloading their packages instead of the real ones. These packages may even work just like their legitimate counterparts but include backdoors that may go undetected. Once these packages end up in your system, you’re not simply vulnerable, you’re under attack. Remember when we said provenance matters? This risk highlights why.

OSS-RISK-4: Unmaintained Software

Creating OSS is very often a labor of love and something developers do for kicks in their free time. When that love or free time goes away, so do regular updates and security patches. Developers outside of the original project team can make their own patches, but their relative lack of experience with the component may lead to longer times to resolve issues. 

OSS-RISK-5: Outdated Software

Sometimes we don’t update our components, whether that’s due to forgetfulness, not knowing there’s a new version available, or because we don’t think we have the time. The problem is, old code is risky code and the more versions you ignore, the more difficult updating will be if a big security issue is found.

OSS-RISK-6: Untracked Dependencies

It’s hard to secure things you don’t know you have. Dependencies can go untracked for many reasons: receiving incomplete software bills of materials (SBOMs) is one reason. Or you’re just not using a tool to automate tracking and there are simply too many dependencies to handle. Even if you are using a tracking tool, it can miss components that have been placed into the project as code snippets or installed without a package manager.

OSS-RISK-7: License and Regulatory Risk

Not all open source licenses give the same permissions, and they’re not all compatible with each other. And some seemingly “open source” projects actually have no license at all. Using OSS without considering licensing can put your projects in troublesome legal territory. Additionally, OSS components can fail to meet the requirements of regulatory initiatives like FedRAMP, making your final product ineligible to sell to certain entities.

OSS-RISK-8: Immature Software

While many OSS projects are created by highly seasoned and adept developers, some, frankly, are not. That inexperience increases the risk of poor coding practices, such as inadequate testing between updates, little or no documentation, or using confusing non-standard versioning schemes that create breaking changes when updating. All of this can increase the amount of effort and time your developers spend making these components work. And, of course, sloppy coding practices may also introduce a number of security vulnerabilities.

OSS-RISK-9: Unapproved Change (mutable)

Your OSS components likely bring in code and data from other artifacts, which, if not sourced and linked to with care, can change or be tampered with without the knowledge or approval of the OSS developers. These unsanctioned changes can come from unversioned resources, insecure data transfers, and versioned resources that have been changed, which can happen when OSS developers use wildcards when naming package versions, or point to a git repo’s head instead of a specific version. Even without any security issues being introduced, mutable components can cause stability issues and builds that cannot be reproduced.

OSS-RISK-10: Under/over-sized Dependency

Under-sized dependencies are those that contain so few lines you probably could (and should) have just written them yourself. Since any OSS package could suffer from an account takeover or a malicious pull request making its way through, every OSS dependency you take on adds that much more risk. How securely maintainers guard their account passwords, for instance, is entirely out of your control and that risk just isn’t worth it for things you can easily write yourself. On the flipside, using just a small portion of the functionality of a component with many, many others introduces its own risks. The size of such a package naturally comes with an increased attack surface and the excessive functions may take that surface increase further if they can do things like establish network connections. At the very least, getting vulnerability scan alerts for functions you’re not using is annoying.