Welcome to the Secure Development Handbook

As someone working with developers and concerned about software security, you want the ‘how to do it’. Not the technical detail, but what you can say to your boss/customer/end user to convince them that you’ve done the right thing. You reach for the dummies guide, and it’s not there. Until recently the book didn’t exist. So here it is.

So, you’re working with a software development team. Perhaps you’re a technical lead, manager, security expert, external consultant, or best of all a team member with inspiration. You know it’s vital that the team – developers, testers, product managers and all – address software security properly. What do you do next?

Looking for a Guide?

You look to the literature, and find that oddly enough there’s very little available. There are lots of books and websites terrifying you with all the things that can go wrong; there are one or two draconian-sounding ‘secure software development processes’. But where’s the ‘dummies guide’? Where’s the ‘easy introduction to software security for people who’ve other things on their mind’?


This guide fills that gap. It incorporates several years of research by the authors, first leading secure development projects, then interviewing a wide range of software security experts, then trialling the techniques on professional development teams. From that experience – and a good deal of reflection and discussion – comes step-by-step instructions how to help a professional development team get up to speed with software security. There’s science behind it too: our paper on these techniques is here


Our mission with this guide is to help you to get your team good enough at software security, with a minimum of effort and even a certain amount of fun. 

Handbook Structure

In this handbook we introduce a suite of techniques to help any software development team improve. If you’ve considered using them all already: congratulations, you’re well on the way to good software security. If you’re not, read on!


The techniques are:

1. Incentivisation Event
2. Threat Modelling Workshop
3. Security Negotiation
4. Security Champion
5. Component Choice
6. Automated Static Analysis
7. Code Review
8. Penetration Testing
9. Continuous Reminder


We’ll explore these in the short ‘chapters’ of this handbook. There are many excellent resources out there to help, and we provide links to some of them too.

About the Handbook

Secure development involves a range of people: programmers, testers, project managers, product owners and perhaps other roles. Throughout this handbook, we’ll refer to all of them as ‘developers’.


We’ll also include quotations from experts. And much as we’d like to give full credit, the quotations come from interviews done on condition of anonymity – so instead we have cited the role of the speaker.


This guide will continue to develop. Some sections are currently rudimentary; we’ll improve them. As people tell us what’s wrong and what can be done better we’ll incorporate their ideas. 

Our Philosophy

We're positive people... One of the most frustrating things we found encountering books and writing on security is how negative everything seems to be within them. Security experts continuously harp on ‘bad things that can happen’ and ‘things you must not do’; even their most positive contributions tend to be “this clever way I’ve found of making bad things happen to you”. Even the rare books that offer solutions seem to do so as a last resort after terrifying us with the problems. As software developers ourselves, we reacted against this: please don’t tell us what not to do – tell us how to do it right. And there the experts were mostly silent; there were a few terrifying Secure Development Processes, and little else.


So, in our research we decided to look for the positive: positive things developers can do to improve matters. We asked experts what were the positive things they did with developers to improve security. The experts told us a range of effective such ‘interventions’ used in companies and teams successful at software security. 



But in our research we wanted something even more positive – techniques that would suit almost any development team. Some of these interventions identified by the experts were successful, but expensive: penetration testing, for example, requires skills that are hard to find. So, we offer these with a health warning - a few techniques are only for those who need to spend money on security. Most, though, work for everyone.