Even non-developers can fix security vulnerabilities in code at The Big Fix

Here’s the story of how a regular project management task resulted in me opening a pull request to an open source repository on GitHub.

As a new member of Snyk’s Marketing team, I was recently involved in the preparation for The Big Fix, an event that brings together developers, DevOps, and security practitioners of all skill levels to help make the internet more secure by fixing vulnerabilities while having fun and being rewarded with swag.

Everyone’s invited to the gig. Why wouldn’t I fix a vulnerability myself?

Chatting with the team, it occurred to me that the whole process is so easy that even a non-technical person like me could be part of the initiative, and actively contribute to this global effort to make the internet a safer place. So I decided to give it a try.

Step 1: Getting started on Snyk

Registering for The Big Fix was simple. All I had to do was use my Snyk account, which is completely free and can be opened in minutes. Being a pure marketer, I cannot say I was a heavy user of the platform. I merely created my account to take a look at the product and get a reasonable understanding of how it works.

The next step was to connect Snyk to my GitHub account and grant the platform default permissions to scan my projects and propose vulnerability fixes whenever possible.

Step 2: Choosing the right project

With my account set up and connected to GitHub, I had the ability to import a project and scan it for vulnerabilities. Now I had to choose the right project for my contribution. I do not have projects of my own -- only some very insignificant scraps of code. So I had to contribute to another project. Ideally, this project would be open source and related to the cloud-native ecosystem, which is where I’m coming from.

Indeed, in previous lives I have been part of startups and projects that were really focused on Infrastructure as Code (IaC). I had the chance to work on some blog posts where we would list all the cool open source tools that gravitate around Hashicorp Terraform and make it an even greater way to manage your cloud resources. The short list of tools I had in mind was:

• Terraformer (also called “reverse Terraform”): A super cool open source tool created by the SRE team at Waze that scans existing cloud infrastructures created manually and turns them into Terraform code, thus allowing you to re-import them into your IaC codebase.

• TFlint: A linter that statically analyzes your Terraform code, identifies instance types that are not valid, and instantaneously catches typos and mismatches.

• Terratest: A Go library that performs integration tests of your Terraform files.

I decided to go with Terratest because I really like the fact that the team behind this tool cares about testing our infrastructures, which -- let's be honest -- is probably not a very common best practice yet.

In case you are not familiar with it, here's a quick introduction: Terratest was created by our friends at Gruntwork. It is a powerful Go library in which you include your Terraform code and manipulate it programmatically to do absolutely anything you want, and thus perform all the integration tests you need.

Step 3: Choosing the right fix

First things first, I had to scan Terratest to see if I could find any vulnerabilities in the repo. To do so, I just performed a basic fork from their public repository and then imported this fork into Snyk to scan it.

Let’s face it: I’m not a developer. I have some extremely basic skills, and whenever I interact with code I am not in a situation where I can be very useful. Yet I really wanted to be part of The Big Fix and somehow make a modest contribution to this great Terratest project.

Scanning the project, I was lucky enough to spot a very simple fix (upgrading a Docker image) that was within my reach.

Snyk makes it very easy for everyone, no matter your skill level, to spot and fix an issue with a simple Open a fix PR button that takes you to your repository and proposes the most suitable fix for your vulnerability.

I really liked the fact that I could dig a bit deeper into the platform and access the documentation to gain a better understanding of what this vulnerability was about and how it could be dangerous. Essentially, this fix was about updating an old version of an image.

Ready, steady, fix!

So I was all set: the vulnerability was spotted, the fix was ready, and all I had to do was to hit this Open a fix PR button and navigate to GitHub.

On my repository, it was super-easy for me to look into this fix and decide whether I wanted to merge it or not, which I obviously did. (There’s swag to be earned, remember.)

Merging the PR was a no-brainer and left me with an elated sense of purpose and accomplishment.

Wait! I just fixed a vulnerability on a private repo I’m not really using.

Forking a public repo just for the sake of scanning it and fixing a vulnerability inside it is of no use. And even if the prospect of earning a limited edition t-Shirt is appealing, I really wanted to make a real contribution, albeit a very small one.

Never mind!  All I had to do was copy the fix and PR it into the original Terratest repo on GitHub.

And… voilà .  Fixing a vulnerability is fun. Contributing to open source is even better.

Fixing a vulnerability should always come with bragging rights and celebration.

Did I mention the community around The Big Fix?

One of the cool things about this project is the fact that it’s part of a community. The DevSecCon community Discord server is where the magic happens. Upon joining the server, you can head to the-big-fix channel, chat with fellow developers about what you have fixed, and discuss all things related to InfoSec and DevSecOps.

Fixing application security vulnerabilities while having fun — how is that supposed to work?

The whole idea of The Big Fix is to help find and fix vulnerabilities in a fun kind of way by rewarding participants with swag. The way it works is super easy. Participants  just need to:

1. Register for The Big Fix.

2. Log in to their Snyk account (or create a free one if they don’t have one).

3. Import and scan a project.

4. Find a vulnerability (yes, there will probably be vulnerabilities in your projects, no matter how hard you try).

5. Fix it with a PR through the Snyk platform.

6. (optional step) Sit back and reflect on how cool you will look with your limited edition Big Fix t-shirt.

7. Import and scan other projects and fix even more vulnerabilities.

For those of you who would like to be part of that initiative, there are several resources to help you get started if needed. A simple query with #TheBigFix on Twitter is probably the best place to start. Another interesting starting point is to check out the video below about getting started with the VS Code IDE fixes.

What’s next?

One thing to bear in mind is that The Big Fix is a one-month long event. It started back on January 18th, and will end on February 25th with a “Big Fix-a-Thon” in the form of a 24-hour livestream event on DevSecOps and developer security. The good news is that you don’t have to wait until February 25th to find a vulnerability to fix. As I’m writing this blog post, 35,302 projects have already been scanned, 454,116 vulnerabilities found and 82,109 vulnerabilities fixed, which is incredibly exciting!

Join the interactive Big Fix-a-Thon on February 25 for a 24-hour livestream event on DevSecOps and developer security, filled with fun segments and amazing speakers that will help you on your fixing journey.