Did you know?
As reported by the Linux Foundation, 70% – 90% of modern software applications contain open source software.
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.
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
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.