Addressing cybersecurity challenges in open source software with the Linux Foundation

Snyk recently partnered with the Linux Foundation to produce a report focusing on the state of security in the open source software (OSS) space. The report was based on 550+ survey responses and 15 interviews with OSS maintenance and cybersecurity experts.

Following the report's publication, experts from Snyk held a webinar with the Linux Foundation to discuss some of the key insights: Addressing Cybersecurity Challenges In Open Source Software: Expert Panel. Participants in the webinar included: Mic McCully (Field Strategist, Snyk), Matt Jarvis (Director of Developer Relations, Snyk), and Steve Hendrick (VP of Research, Linux Foundation).

Read on to learn more about improving open source security and sustainability.

Software supply chain vulnerabilities

As software supply chains grow in complexity, open source security is becoming more critical than ever before. For example, most software today has many indirect or transitive dependencies, which are challenging to visualize and assess from an application security perspective.

When developers bring in an open source package, inside of that package there’s very often references to other open source projects, so you get this hierarchy associated with it, and the lower level packages are often referred to as indirect or transitive dependencies.

According to the recent report, the average OSS project has 49 vulnerabilities spanning 79 direct dependencies. This varies across ecosystems, however, with JavaScript projects having substantially more vulnerabilities than Python, Go, Java, and .NET projects.

Even more insightful is where those vulnerabilities lie within packages. The report revealed that over 40% of these security issues are found in indirect dependencies, meaning development teams often aren’t aware that they’re pulling vulnerable code into their projects.

As we’ve seen at Snyk, these vulnerabilities can be very deeply nested. Some of these issues within the software supply chain can often come from dependencies that are four or five levels deep.

The need for SBOMs and OSS security policies

Since security issues are often hidden deep within complex dependency trees, the idea

of creating a software bill of materials (SBOM) is growing in popularity. SBOMs are formal records of a software’s components and supply chain relationships with the aim of improving transparency.

The reality is that we need knowledge about what’s in a component. We need to understand how usable it is and whether we can trust it. When you have transitive dependencies, getting this information can be very hard.

Part of the reason many companies aren’t building SBOMs is the overall lack of open source security. In fact, the report survey results revealed that only 49% of organizations have a security policy that addresses open source security.

Without an OSS policy, you can’t effectively manage risk. You don’t really know enough about what you’re going to do when it comes to vulnerabilities, and your security posture suffers.

How are organizations checking the security of OSS packages?

While the report found that 44% of companies have developers examine source code for vulnerabilities, there are nearly a dozen different types of tools they use to do so. Two of the most popular include static application security testing (SAST) and software composition analysis (SCA).

Another common way organizations are checking the security of OSS packages is by vetting them before they’re adopted. They look for OSS projects with positive ratings, an active community that's frequently releasing new code changes, and a publicly disclosed security policy. However, these components could still have vulnerabilities within the transitive dependencies if the project maintainers aren’t proactively implementing OSS security themselves.

What we're starting to see across the industry is new ways of providing that information about security and trustworthiness to OSS consumers. We started with GitHub stars, but now we have OpenSSF Scorecards and other sources of detailed information.

The impact of Log4Shell in the Java community

The report also revealed some interesting insights about the widespread Log4Shell vulnerability in the Java community. Most notably, 79% of projects affected by Log4Shell have more than one Log4Shell vulnerability within the codebase, and 60% of the instances were found in indirect dependencies.

Log4Shell has really illustrated this idea that open source projects can become victims of their own success. When you have an open source library that’s used in such a wide range of projects like Log4j, the impact of security issues can be gigantic. This really brought the need for SCA scanners to the forefront.

Open source vulnerabilities are becoming harder to fix

Software supply chains are getting more complex, and visibility into security is becoming a greater challenge for many organizations. As a result, open source vulnerabilities are becoming harder to fix as well. In fact, time to fix vulnerabilities has increased from 49 days in 2018 to 110 days in 2021.

Over the span of three years, the time to fix has more than doubled. At the same time, two other things have happened: 1) software use and development has grown at a tremendous rate 2) we’re paying much more time and attention to security.

Another challenge organizations are facing with the increase in remediation times is resourcing. Some companies are, in fact, fixing critical issues faster than before, but low priority vulnerabilities are being addressed too slowly due to a lack of application security resources. That’s why SAST and SCA tools are the top two ways companies say they’re addressing security concerns.

SAST and SCA scanning tools can be integrated into CI/CD pipelines and the development process to automate the detection and remediation of many open source vulnerabilities. This helps organizations overcome some of the application security resource challenges they face.

There’s a very strong correlation between deployment pipeline automation and the time to fix security issues, because when you have a fully automated CI/CD, you have a lot of hook points to integrate security checks.

The state of open source security in 2022

This conversation between Snyk and The Linux Foundation covered some key insights from the report, but there is much more to uncover. Download the full report to learn more about the complexity and risk associated with today’s software supply chain landscape: State of Open Source Security 2022.