Top 5 Open Source Security Risks IT Leaders Must Know

Lurking in the open source software (OSS) that pervades applications around the world are open source security risks technology leaders must be aware of. Software is one of technology’s most vulnerable subsets with over 70% of applications containing security flaws. Here are the open source security risks IT leaders must be aware of to protect technology and help it scale safely. 

Why Address Open Source Software Security Risks 

On December 9, 2021, a Tweet exposed a vulnerability in the widely-used OSS library Log4j. It didn’t take long before attackers around the world were working to exploit the Log4j vulnerability. This incident was a wake-up call to how the security of a library can quickly change and proactive measures must be in place to protect from this danger.  

Log4j is just one example of how vulnerabilities in open source pose significant risks that can impact operations, data security, and overall IT health. Strategic technology choices can make a big impact on how much risk your open source is exposing you to. New SEC regulations make it clear that security is no longer only for the “cyber person,” and we all play our part in security. 

Since you won’t be addressing open source software security risks by getting rid of your use of OSS altogether, here are the risks you need to know about and how to tackle them. 

Risk 1: Known Vulnerabilities in Open Source Libraries 

Open source libraries, or 3rd party libraries, contain vulnerabilities that are standardized in the National Vulnerability Database (NVD). The NVD is a product of the National Institute of Standards and Technology (NIST) made to be “the U.S. government repository of standards based vulnerability management data.” To rate the severity of security vulnerabilities, it makes use of the Common Vulnerability Scoring System. 

As in the Log4j example above, one huge risk of these vulnerabilities is that once they are known to the NVD, they are known to attacker, too. It's very likely that attackers who know about it have already formulated a way to leverage the vulnerable vector. Many times, an attack is discovered weeks or months AFTER it’s already been in play. 

The State of Software Security 2023 states: “Make sure your Software Composition Analysis (SCA) solution leverages multiple sources for flaws (not just NVD) to give advanced warning to teams. Once a vulnerability is disclosed (even via unofficial channels), it’s a race against the clock to when active exploitation begins. It might take weeks to months for a vulnerability to appear in the NVD, and by then, in-the-wild exploits may have already begun.” 

Risk 2: Lack of Timely Updates and Patches 

Another open source security risk comes from a lack of timely patches. Failure to update your open source dependencies can lead to leaving systems exposed to known vulnerabilities. You must keep up with updates to secure versions of libraries. A Software Bill of Materials (SBOM) helps you keep a current inventory of what’s in your applications. 

Going back to our Log4j example, it revealed that there is a “give a mouse a cookie” affect with things breaking due to accrued library update security debt. Our CTO and Founder, Chris Wysopal, shared: "Log4j created awareness that you should have as much security testing automation in build processes as possible. It was also a wake-up call to how security technical debt, when left unaddressed, can cause urgent issues to take an enormous amount of time to fix.” 

Risk 3: Compliance and License Risks 

There are specific usage terms for many open source licenses with which you must comply. Imagine the nightmare that unfolds when you have a large application and one small part of it uses a library you don’t have a license for (let alone know who added it and why). 

Again, this is where the SCA and SBOM solutions help immensely. By scanning libraries, SCA helps you know if you are calling anything you need a license for and will actively manage license risk. Especially important for commercial applications, the SBOM is the record that shows verifiable proof that you have a license for everything in the application or applications being sold or acquired. 

Risk 4: Community Dependence and Maintenance of Open Source Libraries 

A critical OSS security risk is that an open source project may or may not still have a developer updating the project. Data from the State of Software Security 2023 tells us, “One out of every 10 repositories had their last commit more than almost six years ago.”  

Adding to this risk of inactivity, you’re at risk of there not being a big (or engaged) enough community maintaining the OSS you’re dependent upon. The following State of Software Security 2023 figure shows Percent of Applications by Activity and Developer (by Language). Shockingly, 92% of JavaScript applications use at least one library maintained by a single contributor with zero contributions in the last year. 

Risk 5: Software Supply Chain Security Risks Due to Malicious Packages 

In contrast to accidental vulnerabilities in open source, another significant risk is deliberately malicious packages that contain malware. These malicious libraries can be mistakenly used with their malware properties unbeknownst to the developer.  

One way they get in your supply chain is a form of typosquatting where an attacker creates a package that’s nearly identical to the real package, like “myUsefulFunction” vs “myUsefulFunctions.” Another way is in the compromise of an existing package by either an account takeover of the maintainer or just a simple offer to help out. 

Whereas accidental security flaws might require expertise to covertly exploit, malware is designed to be hard to detect, and once inserted, it may be operating for a long time before discovery. Since these attacks are deliberate, the probability of exploit is orders of magnitude higher. In fact, they are guaranteed in the case of attacks that automatically begin using your compute resources for nefarious operations.  

One way to reduce the risk of malware from malicious packages is robust testing during initial software build and any time an application is rebuilt. You can learn about this and securing the software development lifecycle in our eBook, 6 Steps to Secure the SDLC. 

Open Source Security Strategy Resources to Measurably Reduce Risk 

Now that you know the top open source security risks, here are the top tips and vital strategy resources to help you keep your technology safe while increasing agility.  

• Know what's going into the software you make. With SCA and Infrastructure as Code scanning, you can make a constrained subset of allowable modules developers can use. Make sure you optimize for risk with a solution that can identify the vulnerable methods that really matter. 

• Know what’s in the software you're using. Ask for an SBOM for third party software you install. It's likely that at some point the software you make or the software you use will contain a vulnerability derived from an open source component. Being able to quickly identify and remediate it might keep you out of serious trouble. 

• Help development teams reduce new technical debt into the code base by giving them access to interactive, hands-on secure coding training (like Security Labs) and allowing them to see flaw and remediation recommendations in the tools they use every day (like with Veracode Fix). The more automated the flaw recommended remediations are, the better! 

IBM’s Cost of a Data Breach 2023 tells us that the adoption of a DevSecOps approach is the most impactful factor when it comes to reducing the cost of a data breach. The successful DevSecOps approach includes open source security as a factor integrated into the steps. We show you how to do this in our DevSecOps Playbook.  

Development teams play a huge role in reducing open source security risks. Our research team has done the work of finding secure development practices that make open source security tangible for developers. They are compiled in the following blog series, Secure Cloud-native Development: The Top Five Security Pitfalls and How to Avoid Them