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

Share

link

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

Overall Average 80

25

Python

40

Java

49

.NET

56

Go

174

JavaScript

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?

50%

40%

30%

20%

10%

0%

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.

Snyk Image

49

vulnerabilities
per project

close

40%

of all vulnerabilities
are transitive,

18-20

transitive
vulnerabilities

part two

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

Share

link

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?

Yes

No

Don’t know

0%

10%

20%

30%

40%

50%

60%

70%

Organization size:

1-499

500-5000

5000+

All

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%

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?

80%

70%

60%

50%

40%

30%

20%

10%

0%

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

Snyk Image
format_quote

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

Security Engineer

Citrix

part three

Takeaways from Log4Shell

Share

link

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

10%

8%

6%

4%

2%

0%

Dec 27

Jan 10

Jan 24

Feb 7

Feb 21

Mar 7

Mar 21

Apr 4

Apr 18

part four

Finding a complex solution for this complex problem

Share

link

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?

50%

40%

30%

20%

10%

0%

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 by severity over time

120

100

80

60

40

20

0

2018

2019

2020

2021

Severity:

critical

high

medium

low

Time to fix for proprietary projects vs. open source projects

120

100

80

60

40

20

0

2018

2019

2020

2021

Project type:

Proprietary

Open source

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.  

Snyk Image

Dive in deeper

Open source software security is more important than ever. Learn how organizations manage open source risk in this report from Snyk and The Linux Foundation.

file_downloadDownload the full report