Snyk Report

State of Open Source Security 2022

A look at software supply chain complexity and risk in collaboration with The Linux Foundation.

Part One

Open source security becomes a greater challenge as the software supply chain grows in complexity

Dependencies are increasing the complexity of the software supply chain

Open source packages are a key ingredient of all modern software applications. Developers use many open source packages in their projects, and often these dependencies introduce vulnerabilities into an application. Our data revealed that the average project has 49 vulnerabilities spanning 79 direct dependencies.


Average count of dependencies per project

Java

40

.NET

49

JavaScript

174

Python

25

Go

56

Direct dependencies create risk; indirect dependencies create invisible risk.

It’s difficult to maintain visibility across all open source components used within an application. Dependencies in open source packages introduce risks that are often overlooked. It’s critical to track every open source dependency within an application — including both direct and indirect dependencies (also called “transitive dependencies”). Over one-quarter of survey respondents are concerned about the security impact of their direct dependencies, while only 18% of respondents are confident of the controls they have in place for their indirect dependencies.

How concerned are you about dependencies being malicious or compromised?

Direct
Indirect

50%

40%

30%

20%

10%

0%

0%

10%

20%

30%

40%

50%

We don't have good controls and it concerns me.

We don't have good controls, but this doesn't concern me.

Direct dependencies are easy to track, but we struggle with indirect dependences.

We have strong controls and I'm confident in the security of our dependencies.

Don't know or not sure

We don't have good controls and it concerns me.

We don't have good controls, but this doesn't concern me.

Direct dependencies are easy to track, but we struggle with indirect dependences.

We have strong controls and I'm confident in the security of our dependencies.

Don't know or not sure

Transitive dependencies are complex and more challenging to fix

With 40% of all vulnerabilities found in transitive dependencies, and an average of 49 vulnerabilities per project, roughly 18-20 vulnerabilities per project originate from transitive dependencies. Detecting and fixing vulnerabilities in those dependencies is challenging and requires security tooling and processes because direct fixes are rarely simple.

Did you know?

As reported by the Linux Foundation, 70% – 90% of modern software applications contain open source software.

Part Two

Most organizations don’t prioritize open source security / don’t understand the scope of potential risk in open source packages

To be secure, you need an open source security policy

Our survey found that only 49% of organizations have a security policy for OSS development or usage. This is understandable in smaller organizations where resources are limited. But the survey also found that 27% of medium-to large companies don’t have an established security policy in place. This number is more alarming.

Do you have a policy in place for open source usage or development?

Organization size:

1-499

500-5000

5000+

All

Yes

No

Don't know

0%

10%

20%

30%

40%

50%

60%

70%

80%

Who is responsible for security anyway?

Survey respondents are conflicted regarding ownership of security standards. Especially alarming is that 30% of organizations without an open source security policy openly recognize that no one on their teams is addressing open source security.

Who is responsible for defining your open source security policy?

50%

40%

30%

20%

10%

0%

0%

10%

20%

30%

40%

50%

Security team and/or CISO

Multiple teams

Open source maintainers

No one

Developer or core maintainer

Operations or Site Reliability Engineers (SREs)

Contributors from other teams

Don't know or not sure

Security team and/or CISO

Multiple teams

Open source maintainers

No one

Developer or core maintainer

Operations or Site Reliability Engineers (SREs)

Contributors from other teams

Don't know or not sure

Many organizations score poorly on on open source security

41% of organizations don’t have high confidence in their open source software security — or in the security of their software development process.

On a positive note, however, 72% of organizations believe the security of open source software development will improve by the end of 2022, as the vendor community adds increased intelligence to widely leveraged security tools.

How do you see the security of the open source software you use or develop?

Today
By the end of 2022
By the end of 2023

90%

80%

70%

60%

50%

40%

30%

20%

10%

0%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

Highly insecure

Somewhat insecure

Neither secure nor insecure

Somewhat secure

Highly secure

Don't know or not sure

Weighted score

Highly insecure

Somewhat insecure

Neither secure nor insecure

Somewhat secure

Highly secure

Don't know or not sure

Weighted score

"It’s hard to have good visibility into millions of lines of code. Snyk has improved our dependency hygiene and the overall health of our SDLC."

The risks of open source software

Learn more about the risks of using open source software during development, and what you can do to stay secure.

Part Three

Takeaways from Log4Shell

The Log4Shell vulnerability allows attackers to execute code remotely in affected environments.

Log4Shell received a 10 — the most severe rating — from the Common Vulnerability Scoring System (CVSS).

Due to Log4j’s broad developer adoption, when the Log4Shell vulnerability was first discovered, our data showed that 8.3% of Java projects were vulnerable due to their direct dependency on Log4j. As of April 2022, over 2% of all Java projects monitored by Snyk still had open Log4J vulnerabilities.

Log4j was widely used as a transitive dependency, a dependency of a dependency. In December 2021, 60.8% of all Java projects that included Log4J also used the package as a transitive dependency.

This highlights the systemic risk posed by vulnerabilities that live deeply nested inside of an application.

Percent of all Java projects scanned by Snyk containing the Log4Shell vulnerability

dataset

10%

8%

6%

4%

2%

0%

0%

2%

4%

6%

8%

10%

Dec 27

Jan 10

Jan 24

Feb 7

Feb 21

Mar 7

Mar 21

Apr 4

Apr 18

Did you know?

79% of projects affected by Log4Shell have the vulnerability more than once, with 60% of instances found in indirect dependencies.

Part Four

Finding a complex solution for this complex problem

Multiple tools are competing for developer adoption

A diverse set of tools is necessary to address the complex issue of open source security.

Respondents noted that other than SCA (software composition analysis) tools, additional security instruments used depend on the organization’s approach to development and preferences regarding security testing. SAST tools (36%), IaC tools (35%), and web application scanners (32%) all effectively compete for developer and security team adoption while providing their own unique security benefits.

What tools do you use when developing open source software?

60%

50%

40%

30%

20%

10%

0%

0%

10%

20%

30%

40%

50%

60%

Software composition analysis (SCA)

Static Application Security Testing (SAST)

Infrastructure as Code (IaC)

Web application scanner

Security test cases in software quality testing

Infrastructure as code scanners

Fuzz testing tools

Threat modeling tools

Cloud security posture management (CPSM)

Other

Don't know or not sure

Software composition analysis (SCA)

Static Application Security Testing (SAST)

Infrastructure as Code (IaC)

Web application scanner

Security test cases in software quality testing

Infrastructure as code scanners

Fuzz testing tools

Threat modeling tools

Cloud security posture management (CPSM)

Other

Don't know or not sure

Open source vulnerabilities are becoming harder to fix

Data shows that the time it takes to fix vulnerabilities in open source projects has steadily increased from 49 days in 2018 to 110 days in 2021.

Fixing vulnerabilities in open source projects takes almost 20% longer (18.75%) than in proprietary projects. This finding emphasizes the need to measure and — proactively work to improve — the security posture of your open source dependencies.

Time to fix for proprietary projects vs. open source projects

Project type:

Proprietary

Open source

140

120

100

80

60

40

20

0

0

20

40

60

80

100

120

140

2018

2019

2020

2021

Time to fix by severity over time

Severity:

critical

high

medium

low

140

120

100

80

60

40

20

0

0

20

40

60

80

100

120

140

2018

2019

2020

2021

Did you know?

Software security must be managed across each step and accomplishing all of this with just two or three tool categories is not feasible. Therefore, organizations should take a closer look at adjacent and complementary security tools markets and determine where incremental tools can add the most value.

Part Five

Recommendations

Define robust cybersecurity policies and procedures.

There are many sources of information on how to establish a security policy (and process) that will help you monitor and manage the number of vulnerabilities in your codebase, minimize risk, and maximize efficiency. The Snyk guide to defining a secure open source policy is a great place to start.

Encourage developers to improve their security knowledge.

Many software developers have not been trained in how to develop secure software. The Open Source Security Foundation provides training courses and certifications that can help developers become in-house security champions. Resources like Snyk’s freely available vulnerability lessons can dramatically improve a developer’s security understanding and awareness.

Leverage specialized security tools.

SCA (software composition analysis) and SAST (static application security testing) tools are the leading instruments for addressing OSS security at growing organizations. IaC (infrastructure as code) tools and DAST (dynamic application security testing) tools can also be useful as part of an organization’s security architecture.

Utilize automation to incorporate security checks into your developers’ existing toolchain.

Many security tools provide a way to streamline and automate security checks in your CI/CD pipelines, as well as developer IDEs, and command-line interfaces, while simultaneously eliminating threats. By integrating security into your developers’ existing workflows, you’ll be more likely to find and fix security issues quickly.

Use the most secure open source projects available for your projects.

Knowing that your open source dependencies are as secure and up to date as possible stops many vulnerabilities before they start. Sites like Linux Foundation LFX Security and Snyk Open Source Advisor provide a method of researching the dependencies you’re currently using and getting notified of new vulnerabilities.

About this report

This project was a partnership between Snyk and the Linux Foundation, with support from OpenSSF, the Cloud Native Security Foundation, the Continuous Delivery Foundation, and the Eclipse Foundation. It is based on a survey of over 550 respondents in the first quarter of 2022 and data from Snyk’s Open Source solution.  


Patch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo Segment

Snyk is a developer security platform. Integrating directly into development tools, workflows, and automation pipelines, Snyk makes it easy for teams to find, prioritize, and fix security vulnerabilities in code, dependencies, containers, and infrastructure as code. Supported by industry-leading application and security intelligence, Snyk puts security expertise in any developer’s toolkit.

Start freeBook a live demo