Why you should send your developers to our security workshop

Note: the vast majority of our content is meant to be useful without you having to pay us any money. This article is an exception: it is 100% sales pitch. If that turns you off, you probably want to stop reading now and go back to whatever you were doing.

If you’re interested in either doing our security workshop in-house or sending your developers to a public one, please read on.

We run a regular one-day workshop that teaches developers how to identify vulnerabilities in Ruby on Rails applications. We teach them by giving them time-boxed challenges based on real-life vulnerabilities that they have to complete over the course of a day.

Here are the reasons why you should either send your developers to one of our public workshops or run a workshop with us in-house.

Your developers will enjoy the workshop

One of the most common items of feedback we get is that the workshop is fun. While they may have read blog posts or articles about security in the past, almost no developers have spent time actively hunting for vulnerabilities in their day-jobs.

We think it’s fun because it allows them to use their existing skills and knowledge in ways they may not have considered before. They’ve honed their ability to create software for years. For one day, they get to use those same skills to destroy software instead. Your developers will probably enjoy it too.

Your developers will stop vulnerabilities before they get to production

One of the goals of the workshop is to get developers to think about security before they ship code. We want them to have an intuitive distrust for all code around your basic security mechanisms, so they double check to make sure it leaves no open avenues for attack.

We do this by bombarding attendees with reference experiences. By the end of the day they will have attempted to bypass the security of eight Ruby on Rails applications. All of the applications are insecure in different ways. This teaches them to check for those insecurities in any code they write in the future.

Your developers will find security flaws in your code

All software has security vulnerabilities in it, and all developers write insecure code. That’s not up for debate. The only question is how much effort you put into finding and fixing security vulnerabilities in your software.

In the weeks after the first workshop, we received multiple emails telling us that attendees had found vulnerabilities in their code at work, similar to the ones in the challenges. In our most recent workshops, developers had to leave during the workshop as they realised the code they were running in production was vulnerable.

Either now or in the future, we’re willing to bet that developers you send to the workshop will use what they learn to fix security bugs you have in production today.

Your developers will spend an entire day improving their skills

Finding time for training is difficult. Even if you have “20%” time, it’s hard to decide what and how to focus your efforts to increase the quality of the software that a developer produces.

Security is not the only measure of software quality, but it is an important one. By taking our workshop, your developers have an excuse to spend an entire day learning and thinking about security.

Many attendees are mentally exhausted by the end of it and so don’t stick around for the after-workshop dinner and drinks. There’s no version of this story where they complete the workshop and learn nothing of value.

This is good for the developer. It increases the quality of the software they produce on an axis that is massively important to users, to you, and to the general public.

This is good for you as their lead or employer. It signals that you care both about the security of the software that you’re creating and about the long term career prospects of developers on your team.

Many other teams have put their developers through the workshop

We’re not suggesting that you should do things just because other people do them.

We are saying that other teams have sent developers to the workshop and have left us overwhelmingly good feedback. This might be construed as evidence that the workshop will be worth it for your developers too.

We’ve run the workshop for developers at New Bamboo, Digital Science, and the Ministry of Justice. Lonely Planet, Future Learn, Reevoo, Friday, My Society, Payment Card solutions, and many other companies have sent developers to our public workshops. We’re also the de facto security advisors for a number of startups and small businesses that seem to be happy with our services.

That’s all

As a former developer, I’m hesitant to make claims about any of our offerings that I can’t back with evidence. I’m as allergic to sleazy sales pitches as you are. I’ve tried to lay out some reasons why our workshop will be valuable for you and your developers, based primarily on the feedback we’ve received from past attendees.

Some developers find the workshop too easy, others impossibly hard. We’ve tried to address that by adding multiple levels of hints and challenges of varying difficulty. Most developers find it just challenging enough that they complete about 80% of the exercises in time.

At this stage, based on past feedback, I’m willing to bet that our workshop is probably good. There’s not much more I can say to convince you of that.

If it sounds like something you’d like to run for your team then please get in touch at ali@happybearsoftware.com. If you’d instead like to send developers to the next public workshop, tickets are available here: https://ti.to/bearclaw/rails-security-workshop-september-2017.