Put the hack back in hackathon

Nandy Vaisman
Vim Engineering
Published in
4 min readJan 22, 2020

Our journey started a few months ago during a broader discussion about positioning application security as a core value of our engineering culture, a topic I’ll cover in a different post. In today’s post, I’d like to focus on Vim’s first-ever hackathon and how you can replicate our success.

Being in the healthcare industry means the stakes are high and we must be vigilant at all times. We just don’t have the option of sitting back and relaxing while thinking that we’re 100% safe.

So, what do we do? Give a few hackers a chance to try penetrating our platform? Start a bug bounty program? There seem to be a lot of solutions out there. Some are more appropriate for a company of our size, while others aren’t. There’s no one-size-fits-all solution, so we had to be creative.

Our Director of Engineering asked himself, “Who knows our platform better than our developers?” and immediately answered, “Let’s get them to look for vulnerabilities in our platform!

And, with that, we started planning Vim’s first-ever Hackathon.

Unlike other Hackathons, our goals were a bit different and were mostly focused on:

  1. Positioning application security as a core value of our engineering culture
  2. Empowering our team by creating a competitive and fun activity
  3. Nurturing and embedding an application security mindset deep in our SDLC (Software Development Life Cycle)
  4. Reducing the overall risk of security bugs that could lead to exposure of PHI

We have many developers with varying knowledge in application security, and we wanted them all to be engaged. After all, application security training is tedious and time-consuming, and most developers forget what they were taught in less than a week. We wanted something different. We wanted it to stick. The question was how.

In their book “Made to Stick”, Chip Heath and Dan Heath map out what it takes for an idea to stick. It must be simple, unexpected, concrete, credible, emotional and easy to act on.

First, we had to decide on a fun and exciting concept. How do you do that in the application security world? Presenting the “No Work — Just Hack” day!

That’s right, you get to break the system and get some company swag, free food and a break from your daily routine.

Secondly, we wanted to use the tools we had at our disposal to address the knowledge gaps and make the most out of this day. In the run-up to the hackathon, I ran a half-day secure code gaming tournament using an online third party application that brings a game-like experience with step-by-step training for those who are less familiar with application security and hacking concepts.

The tournament allowed the team to deal with coding errors in a language they know, and learn about the issues that coding errors create in a matter of minutes, without the need to listen to a bunch of tedious application security presentations.

Now I had the training segment and the main competition activity nailed down, but something was missing.

I often hear developers doubt that someone would decide to target Vim. After all, we’re a small company, it’s not like we’re a prime target, are we? Real-life scenarios and stories are a great place to start with gluing the parts together and building a broader understanding.

We decided to interview a few application security experts and build a short presentation and demo to provide a sneak-peek into a hacker’s mind. We partnered with a white hat hacker to present the hacker point of view and walk the team through all the various parts of an attack with real-life examples and data related to Vim directly.

The event lasted for a day and a half, starting with a secure coding tournament, followed by a short presentation/demo to bring our team one step further into a hacker’s world, and ending with a furious multi-group competition.

Our superhero developers in a Marvel-themed hackathon

The event was a huge success and surpassed our expectations. The team was deeply engaged and made some extremely valuable findings. We assembled a 3-person committee (including myself, our CTO, and Director of Engineering) to review and rate all findings, while the team gathered and anxiously awaited the results and announcement of the winning team.

And, now it’s time to get back to chasing everyone to mitigate these findings ASAP.

--

--