Did you know?
As reported by the Linux Foundation, 70% – 90% of modern software applications contain open source software.
A look at software supply chain complexity and risk in collaboration with The Linux Foundation.
Part One
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.
Java
40
.NET
49
JavaScript
174
Python
25
Go
56
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.
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
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.
As reported by the Linux Foundation, 70% – 90% of modern software applications contain open source software.
Part Two
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.
Organization size:
1-499
500-5000
5000+
All
Yes
No
Don't know
0%
10%
20%
30%
40%
50%
60%
70%
80%
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.
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
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.
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
Learn more about the risks of using open source software during development, and what you can do to stay secure.
Part Three
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.
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
79% of projects affected by Log4Shell have the vulnerability more than once, with 60% of instances found in indirect dependencies.
Part Four
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.
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
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.
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
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
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
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.
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.
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.
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.
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.
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.