State of Open Source Security 2023

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.

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.

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%.

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. 

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).

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. 

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.

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. 

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.