Fixing half a million security vulnerabilities
Tags: java, javascript, python, ruby
Published: 2023-06-21 15:46:33

Hackathons are well known among software development teams for driving innovation and collaboration. So, what if we applied that model to cybersecurity to improve an organization’s application security posture? That would be a dream come true for any CISO and security practitioner — and is exactly what we set out to do at Snyk in February 2023.


![](https://res.cloudinary.com/snyk/image/upload/v1683218277/blog-bf-wrap-up-panel-1.jpg)
![](https://res.cloudinary.com/snyk/image/upload/v1683218277/blog-bf-wrap-up-panel-2.jpg)
Check out some of the [funniest moments from our panels](https://youtu.be/ZjWuYFGY7kM).


  

We set out on this mission to fix 200,000 security vulnerabilities. Here’s how it ended up.


![](https://res.cloudinary.com/snyk/image/upload/v1683218277/blog-bf-wrap-up-goal.jpg)
Running a security fix-a-thon
-----------------------------


The core of running a successful event is ensuring that developers and security professionals have fun while learning new skills they can apply to their personal or professional projects. To that end, we established the following:


1. **Through continuous support**, hackathon participants are invited to join their peers in Snyk’s [Discord community](https://devseccon.io/discordcommunity) for security lessons and help with fixes.
2. **A 24-hour live stream** that delivered on our promise to foster education was a key event in this year’s Big Fix. We hosted the worldwide [24-hour live stream](https://www.youtube.com/watch?v=ZjWuYFGY7kM&list=PLQ6IC7glz4-UGstRigtYzMhYoDKaQ5luA&index=1) on YouTube and Twitch, featuring speakers from Atlassian, Dynatrace, Morgan Stanley, The Linux Foundation, Sysdig, AWS, StackHawk, and others.
3. **Prizes**: We wanted to recognize every participant's efforts toward creating more secure software. As such, everyone who fixed at least one security vulnerability was gifted a limited edition The Big Fix t-shirt or a $15 OpenCollective credit they can use to donate to open-source projects and maintainers.
4. **Leaderboard**: To add some competitive edge to the mix, we featured a leaderboard of the top fixers. The three participants who fixed the most security vulnerabilities were awarded a VR headset (1st place), a wireless speaker (2nd place), and an Arduino starter kit (3rd place), respectively.


![](https://res.cloudinary.com/snyk/image/upload/v1683218277/blog-bf-wrap-up-leaderboard.jpg)
One of the great things about the hackathon is that you didn’t need prior application security or cloud security experience to participate and climb the leaderboard..


That is thanks to Snyk’s developer-first mindset, rich ecosystem integrations, and automated fix capabilities that allow you to find and fix security issues easily. Whether you’re a developer, DevOps, security, or quality assurance engineer, Snyk has the tools you need to dive right in.


Now more than ever, it’s a great opportunity to start with [Snyk Code](/product/snyk-code/), [Snyk Open Source](/product/open-source-security-management/), [Snyk Container](/product/container-vulnerability-management/), and [Snyk Cloud](/product/snyk-cloud/).


Securing the world’s software
-----------------------------


So, how did we do? Now that The Big Fix has wrapped up, let’s dive into the data and review the outcomes of running an event that empowers developers to fix security issues.


In a month, participants of The Big Fix event contributed 597,589 security fixes to their software projects, whether closed or open-source. We welcomed more than 1800 users who registered for the event. Participants included more than 120 Snyk employees, more than 220 customers, and more than 1,480 engineers from different companies.


We dug deeper into the Snyk database with the aim of determining what security impact the event had on projects monitored with Snyk. As such, the following metrics and insights present all the product analytics gathered for any account activity registered to the event — spanning more projects and security vulnerabilities found and fixed than merely the projects added to the hackathon.


### Container images are most prone to vulnerabilities but also most fixable.


Out of millions of security vulnerabilities detected across container, code, and infrastructure projects monitored with Snyk, those classified as Docker container projects featured a 73.3% fix ratio. Safe to say that a large contributor to this high fix rate ratio is the fact that [Snyk Container](/product/container-vulnerability-management/) provides automated pull request fixes with base image recommendations that proactively suggest alternative container images with lower vulnerability counts.


![](https://res.cloudinary.com/snyk/image/upload/v1686670904/blog-bf-wrap-up-issues-monitored.png)
Code and dependency-based security actions feature an insignificant rate of security fixes applied. [Snyk Code](/product/snyk-code/) was able to find more than 82,160 potential code security vulnerabilities with a 10.2% fix rate by participants. [Snyk Open Source](/product/open-source-security-management/), which detects publicly known vulnerabilities in open-source dependencies, had a 14.4% fix rate. Given that dependency, fixes are automated via pull requests, and that code security issues are handled inside the IDE with Snyk’s recommendation engine, there are thousands of security vulnerabilities that were mitigated early (and swiftly) in the development process.


Let’s look closer at the data set for container image projects. The top 10 docker container projects that were monitored by Snyk feature an incredibly high rate of security issues fixed — which supports the previous claim that they’re a lot easier and faster to fix. Ubuntu base distributions and container images, such as `ubuntu:rolling` and `node` images, present more than 90% security issue fix rates.


![](https://res.cloudinary.com/snyk/image/upload/v1683218277/blog-bf-wrap-up-fixed-vs-container-images.jpg)
### 13%-30% of all publicly known security vulnerabilities are fixed earlier, and faster


When we drill down to specific language ecosystems, we can also observe the security fix rates applied to each programming language. These may be skewed due to vulnerabilities discovered in low-importance security issues such as those reported for development dependencies. Other reasons may be due to unfixable security issues due to unmaintained code projects. Overall, dependency-based security vulnerabilities feature a fix rate of roughly 13%-30%, which can be automated to help software developers focus on building applications rather than sorting out security issues.


![](https://res.cloudinary.com/snyk/image/upload/v1683218277/blog-bf-wrap-up-fixed-vs-project-eco.jpg)
### Go code prone to denial of service, control flow, and pointer secure coding errors


Top fixed vulnerabilities in Go demonstrate that developers are spending time mitigating secure coding errors relating to program control flow, denial of service, and pointer handling. The following are the top 5 security vulnerabilities fixed in Go projects:


* CWE-400: Uncontrolled Resource Consumption
* CWE-266: Incorrect Privilege Assignment
* CWE-787: Out-of-bounds Write
* CWE-674: Uncontrolled Recursion
* CWE-476: NULL Pointer Dereference


### Python projects are most vulnerable to memory issues, input validation, and program control flow


The top Python vulnerability types share similarities with Go projects, such as uncontrolled resource consumption, out-of-bounds write, and out-of-bounds read. Other top vulnerabilities identified in Python code bases include:


* CWE-369: Divide By Zero
* CWE-617: Reachable Assertion
* CWE-1333: Inefficient Regular Expression Complexity


### Java and JavaScript code bases share common top vulnerability types


Out of the top 10 vulnerability types we monitored throughout The Big Fix,, we identified a set of CWEs that are shared among Java and JavaScript code bases:


* CWE-400: Uncontrolled Resource Consumption
* CWE-94: Improper Control of Generation of Code ('Code Injection')
* CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
* CWE-200: Exposure of Sensitive Information to an Unauthorized Actor


### Ruby most vulnerable to denial of service, cross-site-scripting, and HTTP request smuggling


Ruby, best known for Ruby on Rails, is mostly affiliated with web development. As such, it’s no surprise to find that its top 5 security vulnerabilities, which were also fixed during the event, involve risks to web applications:


* CWE-1333: Inefficient Regular Expression Complexity
* CWE-400: Uncontrolled Resource Consumption
* CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
* CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
* CWE-200: Exposure of Sensitive Information to an Unauthorized Actor


In fact, one of the top vulnerabilities participants found and fixed is a lesser-known security issue — HTTP Request Smuggling.


### Most fixable security vulnerabilities discovered with Static Application Testing


Static Application Testing is an approach that uses code-level insights and code path workflows, such as abstract syntax trees, to identify potential vulnerabilities and insecure coding conventions. It’s a great way to provide early feedback to developers and raise security concerns while they write the code — instead of later in the process after features are already built.


Snyk Code provides IDE-integrated security insights and fixe recommendations that developers can easily adopt by installing the VS Code extension (IntelliJ and other IDEs are supported to!). Brian Clark and Nate Michalov show how to find and fix security issues in this live coding session:


 [![](https://img.youtube.com/vi/rbTe4PFu91c/maxresdefault.jpg)](https://www.youtube.com/watch?v=rbTe4PFu91c)
Of all the issues that were detected by Snyk Code SAST tool, the following vulnerability types were the msot common:


* ​​CWE-94: Improper Control of Generation of Code ('Code Injection')
* CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
* CWE-916: Use of Password Hash With Insufficient Computational Effort
* CWE-798: Use of Hard-coded Credentials
* CWE-352: Cross-Site Request Forgery (CSRF)


What’s next?
------------


We want to thank everyone that participated in The Big Fix this year, and take the opportunity to invite you to one of our upcoming public events — where you can learn more about application security and meet other cybersecurity peers:


* [CTF 101 Workshop](https://go.snyk.io/202305-all-email-capture-the-flag-101-apj.html) (May 25, 2023): A hands-on workshop that teaches you how to solve capture-the-flag challenges!
* [Ethical Hacking Workshop](https://go.snyk.io/202306-ethical-hacking-101-workshop-2.html) (June 21, 2023): A hands-on workshop that teaches you how to conduct ethical hacking and responsible disclosure.
* [DevSecCon](https://www.devseccon.com/) (June 27, 2023): Our flagship community conference about all things DevSecOps.


Finally, if you are interested in connecting with like-minded developers and security professionals, join the [DevSecOps Discord](https://discord.gg/NXuz63GmUt).