Skip to main content
Report

State of Open Source Security 2023

This report explores the adoption of security tools, practices, and technologies and the impact of automation and artificial intelligence (AI) in software development.

Part one

Open source security tools: Processes not keeping pace with development

80% of organizations ship code daily or weekly, but only 27% audit continuously

The more frequently code is changed, the greater the risks of supply chain vulnerabilities and the faster patches must be applied. We found that 80% of organizations are shipping code daily or weekly, likely indicating a shift towards more modular code architectures built on open source applications and libraries which require constant updates due to their complexities and dependency structures. Our survey found that 66% of organizations can remediate critical open source vulnerabilities within a day, and 27% within a few hours. There remains room for improvement as only 27% of organizations continuously audit code for vulnerabilities and another 28% audit code daily. Continuous or high-frequency audits improve safety due to the increasing number of zero-day vulnerabilities.

Code Deploy Frequency

Daily

134

Weekly

199

Monthly

53

Quarterly

14

DK

4

40% of organizations still don’t use key supply chain security technologies like SCA and SAST

Despite cyber attacks hitting records year over year and an increasing number of attacks focusing on open source code, a high percentage of responding organizations still don’t use the two most fundamental supply chain security technologies — software composition analysis (SCA, for open source dependencies) and static application security testing (SAST, for non-public implementations of open source code and proprietary code). Cloud native security measures, like configuration checks for infrastructure as code tools and secrets scanning, are adopted by even fewer.

Security Processes Organization Applies

300

200

100

0

0

100

200

300

Software Composition Analysis (SCA)

Static Code Analysis / Static Applications Security Testing (SAST)

Automated Package Management

Dependency Analysis

License Scanning

Secrets Management

Configuration Checks

None of the above

Software Composition Analysis (SCA)

Static Code Analysis / Static Applications Security Testing (SAST)

Automated Package Management

Dependency Analysis

License Scanning

Secrets Management

Configuration Checks

None of the above

Only 40% of organizations use formal security rating tools to check open source package safety

Checking the security posture of open source packages is critical for maintaining software supply chain security and  automated systems to check that packages follow security best practices, such as Snyk Advisor or OpenSSF Scorecard, are the most reliable way to programmatically analyze risk. These systems, however, are the least popular methods for checking the safety of open source packages. Only 40% of respondents use Snyk Advisor and only 34% use security scorecards.

Surprisingly, only 52% of respondents verify that all packages have a “responsible disclosures” policy — which should be table stakes for any package that’s being used.

How do you check the safety of open source packages?

300

200

100

0

0

100

200

300

I use the information in the registry or package manager

I use a tool like Snyk Advisor

I look at repository ratings or package downloads statistics

I look at the frequency of releases/commits/etc.

I check that the project has an active community

I check that the project has a responsible disclosure policy (such as a SECURITY.md)

I check the security scorecard

I don’t check the safety of open source packages.

I use the information in the registry or package manager

I use a tool like Snyk Advisor

I look at repository ratings or package downloads statistics

I look at the frequency of releases/commits/etc.

I check that the project has an active community

I check that the project has a responsible disclosure policy (such as a SECURITY.md)

I check the security scorecard

I don’t check the safety of open source packages.

31% of respondents ignore invisible risk of indirect dependencies

A critical challenge in open source security is monitoring dependencies of third-party open source packages and libraries. Organizations clearly recognize that dependency tracking is critical to security, with 67% of organizations using a tool like Snyk to track direct and indirect dependencies. Another 25% track direct dependencies only. Tracking indirect dependencies produces a more holistic and accurate view of the entire attack surface, often surfacing hidden supply chain security weaknesses. These weaknesses often cannot be easily remedied due to the fact that nested dependencies are embedded in open source packages and libraries maintained by parties with at least one degree of separation from the direct dependency.

Does your company track which open source libraries your applications are using?

No

23

Direct Only

103

Direct + Indirect

270

Not Sure

8

Security tooling has not fully shifted left: Only 40% of organizations have security tooling in their IDE

Shifting security to the left has been a priority for many engineering organizations seeking to proactively improve code security and reduce vulnerabilities that are inadvertently inserted into code during software development. This improves speed and efficiency in the SDLC as fewer builds are blocked in pre-deployment testing and routed back to developers to fix. Shifting left also remains unfinished business as only 40% of respondents indicated that their organization deploys security tooling into IDEs, with an even smaller percentage using them locally on the command line.  The most common locations for security tooling are in build tools and code repositories, both around 65%.

Where do developers have security tools integrated into their workflows?

300

200

100

0

0

100

200

300

IDE

CLI

Build system

Pre-Commit Checks

Code Repository

CI/CD pipeline

Don't know

IDE

CLI

Build system

Pre-Commit Checks

Code Repository

CI/CD pipeline

Don't know

Secure your indirect dependencies with Snyk

Snyk Open Source finds and fixes vulnerabilities in both direct and indirect dependencies.

Part Two

Software supply chain attacks & SBOMs

87% of respondents were impacted by one or more supply chain security issues

The responses to the survey indicate that the software supply chain security crisis is real and impacting organizations in a variety of ways. The strong majority of respondents were impacted by one or more supply chain issues within the past year. Regarding specific impacts, 53% had to patch one or more vulnerabilities, and 61% implemented new tooling and best practices for open source and supply chain security, indicating that many are taking action only after the impacts of a supply chain attack affect them directly. 

Impact of Open Source Supply Chain Security Vulnerabilites in the past year

250

200

150

100

50

0

0

50

100

150

200

250

We had to patch one or more supply chain vulnerabilities

We implemented new tooling and practices to better handle supply chain vulnerabilities

We trained our development team to help them better understand supply chain vulnerabilities

We have not been impacted by open source software supply chain vulnerabilities in the past year

We had to patch one or more supply chain vulnerabilities

We implemented new tooling and practices to better handle supply chain vulnerabilities

We trained our development team to help them better understand supply chain vulnerabilities

We have not been impacted by open source software supply chain vulnerabilities in the past year

94% of organizations made significant changes in response to Log4Shell

This mirrored the overall response to Log4Shell, where clearly organizations are responding with significant changes. In response to the incident, 63% of respondents said their organization’s increased code scan frequency, 59% added new tooling, and 53% gave dev teams additional training on secure coding practices. Log4Shell also appeared to improve the security hygeine of most organizations — 58% of respondents said they applied required patches more quickly, motivated by Log4Shell. While the incident may have caused short-term chaos as organizations frantically sought to identify and patch nested exposures, the longer-term impact appears to be beneficial — teams have upped their security game at least in part as a direct response to the incident.

Security practices changes in response to Log4J

300

200

100

0

0

100

200

300

Increased code scan frequency

Gave development teams additional training

Applied patches more quickly

Added new security tooling

None of the above

Increased code scan frequency

Gave development teams additional training

Applied patches more quickly

Added new security tooling

None of the above

96% of organizations are taking specific actions to shore up supply chain security

Actual adoption of software supply chain security best practices appears scattered and only 53% of organizations have a formal supply chain security program. This could be because software supply chain security is considered a subset of the general security practice, but it does beg the question of whether supply chain security has yet become a burning issue for organizations (or enough of a burning issue to merit a program-level view and plan). In terms of more specific practices, only 42% of organizations are using SBOMs, 58%, are implementing code signing for attribution of code, and 62%, are adopting a software lifecycle assurance process (such as SLSA).

Adopted Open Source Supply Chain Security practices

300

200

100

0

0

100

200

300

Formal software supply chain security program

SBOMs

SLSA

Code signing

Regular Audits

None of the above

Formal software supply chain security program

SBOMs

SLSA

Code signing

Regular Audits

None of the above

SBOM confusion: Rapid growth in usage but scattered correlation

Clearly, the message that SBOMs are a useful tool is getting through to engineering and security teams. 42% of respondents are already using SBOMs, and 31% plan to adopt them in the near future, forecasting impressive growth. That said, respondents said they are generating SBOMs from various software development and CI/CD tools, as well as from dedicated supply chain security systems. This may be due to the relative fragmentation in the SBOM technology space. There remain two dueling standards (Cyclone, SPDX) with no accepted standards for interoperability. This likely indicates fragmentation and disconnection in the space — an SBOM tower of Babel. While SBOMs are primarily generated by code scanning and security tools (68%), other common systems used to generate SBOMs include build tools (58%), CI/CD tools (45%), and dedicated supply chain security tools ((53%)

Tools that generate SBOMs

300

200

100

0

0

100

200

300

CI/CD tools

Build tools

Code scanning and security tools

Dedicated supply chain security tool

None of the above

CI/CD tools

Build tools

Code scanning and security tools

Dedicated supply chain security tool

None of the above

Part Three

The impact of AI on open source security

The AI paradox: 77% say AI tools improve code security, but 59% worry AI tools will introduce more security vulnerabilities

AI code-generating tools have achieved blanket penetration and are now being deployed by 92% of organizations. 76.5% of respondents believe that these tools have improved their organization’s code security. Only 14.9% of respondents said the AI tools had introduced “a lot” of vulnerabilities into their code. In contrast, 73% said AI had introduced “very few” or “a moderate amount” of vulnerabilities into their code. Yet, 59% of respondents said they are concerned that AI tools will introduce security vulnerabilities into their code, and 50% are concerned AI will introduce licensing violations into their code. In a nutshell, developers believe AI is improving their code security without introducing a lot of new vulnerabilities, but they remain skeptical of these newer systems.

Are you concerned AI tools will introduce vulnerabilities?

Very few

132

A moderate amount

165

A lot

56

None

15

Don’t know

9

Not Applicable

27

False positives and automation overload: 61% of respondents say automation has increased false positives

A high percentage of organizations are automating some or all of their security measures in the code pipeline. 64% of organizations have automated code analysis, 61% have automated software update management, 59% have automated testing (unit, security), 58% have automated secure coding practices (linters, formatting, etc.), and nearly half have automated container and infrastructure configuration scanning. Respondents indicated that automated security tooling has considerably increased the rate of false positives in vulnerability reports, with 60% stating automation had increased false positives versus 30% saying automation had decreased false positives.

False positives causes by automation

Increased

246

Decreased

121

Don’t know

22

NA – We don’t use automation

15

62% of respondents say one quarter or more of alerts were false positives

The percentage of false positives was non-trivial. 62% of respondents said that 25% or more of vulnerability alerts they received were false positives, and 35% said false positives represented 50% or more of vulnerability alerts. This high rate of false positives likely contributes to on the surface would seem to be a surprisingly low vulnerability fix rate.

What percentage of security alerts are false positives?

0-25%

139

26-50%

110

51-75%

93

76% - 100%

47

Don’t know

15

AI purpose-built for security

Snyk DeepCode AI utilizes multiple AI models trained on security-specific data with curation from top security researchers to give you all the power of AI without the drawbacks.

Part Four

Open source security vulnerabilities

Most ignored vulnerabilities: JavaScript and Java top the ranks

For this analysis, we considered vulnerabilities that at least 20 organizations had chosen to ignore (based on Snyk data). With a vast ecosystem of legacy code and a packaging system (.jar files) that frequently obfuscates vulnerabilities and dependencies, it’s no surprise that Java has the largest percentage of ignored vulnerabilities at 42.5%. JavaScript, with its numerous packages – many for minute functions and functionalities – is understandably second, with 30.6% of ignored vulnerabilities. Debian, the Linux distribution family, takes a distant third, at 13.6%. If anything, this distribution understates the attack surface because Java and JavaScript also dominate not just by count but also in weighting. The top 34 ignored vulnerabilities in terms of the number of organizations ignoring these vulnerabilities are all Java and Javascript.

Ignored vulnerabilities by ecosystem

debian

13.6%

alpine

0.5%

golang

3.8%

python

6.6%

js

30.6%

java

42.5%

ruby

0.2%

ubuntu

0.5%

dot.net

1.7%

Ignored vulnerability types: DDoS, prototype pollution, and deserialization dominate

The type of vulnerabilities ignored by organizations provides useful information on attack surface and risks that are accepted, either consciously or subconsciously. By far, the dominant type of threat among the CVEs ignored by at least 50 accounts were flavors of denial of service (DoS). These vulnerabilities made up 31.3% of all ignored vulnerabilities. While serious, DoS attacks are often proactively mitigated at the CDN or infrastructure level, so many teams understandably deprioritize these CVEs. Deserialization of untrusted data made up 14.3% of CVEs ignored by over 50 accounts. This is a relatively broad class of vulnerabilities potentially impacting multiple languages. This can often be the first step in chained or compound attacks, making it a serious vulnerability. The third most common, prototype pollution (at 12.5%), mostly impacts the JavaScript community. 

Ignored vulnerabilities by type

Remote Code Execution

3.6%

Denial of Service (DoS)

14.3%

Deserialization of Untrusted Data

14.3%

Prototype Pollution

12.5%

Information Exposure

7.1%

Regular Expression Denial of Service (ReDoS)

17%

Directory Traversal

2.7%

Improper Verification of Cryptographic Signature

2.7%

Arbitrary File Write

4.5%

Other

21.3%

Part Five

Vulnerability fixes in open source

Open source fixing vulnerabilities faster than proprietary software

Since the dawn of open source, the argument has raged about whether open source software is, in fact, more secure than closed source software. Vulnerabilities are published and in the open, as are the accompanying fixes. So it is possible to track data on time-to-fix (TTF) using vulnerability databases. We tracked TTF over the past four complete calendar years and found that the average TTF has steadily increased for proprietary applications and steadily decreased for open source applications since 2019. To be fair, both genres reduced TTF in 2021, but for the first time since we have tracked this metric, TTF for open source applications fell below TTF for proprietary applications. This implies the open source ecosystem is improving security response over time and trending towards providing better security than the closed source world.

Average time-to-fix

Open Source

Proprietary

300

200

100

0

0

100

200

300

2019

2020

2021

2022

Better scanning of open source code results in faster fixes of critical vulnerabilities

After witnessing a major spike in TTF average of critical and high-priority vulnerabilities, for the past two years has fallen dramatically. This spike could be an indication that open source scanning had increased in those years, shining a light on vulnerabilities that had previously been unseen. From 2021 to 2022, the average TTF for those two critical designations fell roughly by half,  -51% for critical and -49.4% for high-priority vulnerabilities. There could be a number of explanations for this steady decline, including wider adoption of open source security tooling such as SCA, more funding and personnel going towards fixing critical open source vulnerabilities, and greater recognition in open source projects that security is a top priority. Regardless, the signs are good and trending strongly in the right direction for continued improvement in OSS security. 

Average time-to-fix by severity

Critical

High

Medium

Low

1,500

1,000

500

0

0

500

1,000

1,500

2018

2019

2020

2021

2022

Most major open source ecosystems are making fixes faster

The TTF did vary across open source ecosystems and declined markedly for the majority of major open source ecosystems tracked by Snyk. The greatest declines in average TTF were in Java and Python, at 50.8% and 43.4%, respectively. All five of the ecosystems that recorded declines did manage double-digit reductions. The largest total decline in terms of days was in Go and Python, with Go logging a 147-day reduction in average TTF and Python notching a 115-day reduction. Two ecosystems did regress. The C and Ruby ecosystems showed a 144.7% and 102.1% increase in average days TTF, with total days increasing by 55 and 49 for the respective ecosystems. Open source ecosystems are improving security response times and, by extension, strengthening supply chain security by shortening the window between publication and remediation of vulnerabilities.

Ecosystem average time-to-fix

2021 to 22

2022 to 2023

400

300

200

100

0

0

100

200

300

400

cpp

dotnet

go

js

java

php

python

ruby

Conclusion

Open source security is getting better, but there's room for improvement

Over the past few years, technology organizations have made great strides in improving open source and supply chain security. They have learned the lessons of Log4Shell and made adjustments — including more tooling, more training, and greater scan frequency. On the flip side, there remains considerable room for improvement in open source security. Concerningly high percentages of organizations are still not using foundational security technologies like SCA and SAST. Open source security has clearly come a long way, and we are, in the aggregate, more secure as a community than before. Much progress has been made, but there remains much room for improvement — in the adoption of supply chain security technologies, new and mature, in reducing the workload and improving prioritization for stressed security teams, and in making supply chain security a core foundation of the software development lifecycle process.