WIP: Principles of Secure Software Development

This is a work-in-progress, but I’d like your opinions on it:


 Principles of Secure Software Development


  1. You’re not that good – someone will find a hole in your software. Find as many as you can, first.
  2. You’re still not that good – you didn’t find all the holes.  Someone will find a hole in your software. Have a plan in place for when that happens. Pay someone to find holes.
    [Corollary: If you aren't that good now, you weren't any better before, and you'll be just as bad in the future - so when someone finds a hole, scan for other similar behaviours in the rest of your code, and put processes into place that prevent you from making the same mistake in the future.]
  3. Someone else is better (or has had more time to iron out the wrinkles) – if someone else has written it well already, use theirs. Make sure you keep up-to-date with fixes on it!
  4. Even they are not that good – review and test for security threats in anyone else’s software you use.
    [Corollary: You were never that good, nor was anyone else, and you / they never will be. Re-visit old code with new understanding. Document new code as you write it and as you change it, and make sure it is simple enough to understand. Complex code has complex bugs that are hard to find.]
  5. They wrote it for themselves, not for you – if you use someone else’s software, review their assumptions and see if they still apply in your environment. [c.f. Rocky Horror Picture Show, "I didn't make him for you"]
  6. Comments are not code (but code should read like comments) – use comments as a suggestion of how the code was supposed to run, and remember that code is often changed without updating comments. Make your code tell all the story it needs to.
  7. If it’s not your code, it’s data, and data is evil until proven good – anything that you don’t hard-code into the program is data. That includes mouse movements, window messages, network traffic, keyboard input, etc, etc. Anything that isn’t in your source code should be treated as malicious until proven otherwise.
  8. People are replaced easily, processes are not – ensure that your secure development processes revolve around processes, not personalities.
  9. Secure development just plain takes longer – so make time for it. If you don’t have time to do it right, when will you have time to make it right?
  10. Secure code just plain works better – it’s more reliable, has fewer bugs, is simpler to maintain. It may bring you to market slightly later, but a “second-to-market” product can beat a “first-to-market” product if it has an improved reputation for reliability.

So, let me know what you think of these – ten is a number picked rather arbitrarily, I could extend or reduce the list if you think I should.

5 thoughts on “WIP: Principles of Secure Software Development”

  1. Hi Alun,

    After looking just briefly, the #8 looked a bit strange, esp. this bit: “ensure that your secure development processes revolve around processes”. Probably too much emphasis on the process?

    Besides, however good development process is, people are still the key: I have tested security of software products done by fully ISO, CMM and RUP-certified organisations, with disastrous results. I don’t know how to put it here, but one of the questions is: do you trust your developers? And if not – how the code is checked for back doors etc.? “Pay someone to find holes” doesn’t quite cut it.

    And I’ll never agree to the #3 – “Someone else is better”. Sometimes not.

    How about creating a wiki for this?

  2. #3 is about getting over your own ego, and searching for that better person, or that better tool. If you really find that there’s nothing out there better than what you could do, then fine, there is noone better than you for that task.
    #8 is a little awkward, yes, but I’m trying to get across the concept that personalities are temporary, processes last. Use the personalities to set up processes and make people use the processes; but make sure that the processes can last after the personalities move on to something more interesting.
    As for “pay someone to find holes”, yeah, that’s a little weak – but I’m trying to emphasise that you can’t expect people to find holes in their own code strictly for fun’s sake, so you have to include more people, and you have to make it worth their while to find the holes. Your attackers already have found it worth their while to find them.

  3. Sometimes it’s hard to get the project teams to slow down and embed security into the process. Deadlines drive the project and development teams and *some think* it’s easier to go back and fix the problem.

  4. Sorry, Phil, but you’re wrong.
    It’s _always_ hard to get the project teams to slow down and embed security into the process. You are absolutely right that deadlines drive projects, and that there is little consideration given to “it just took longer than we planned, because we’ve never done anything like this and had no idea how difficult it would be.”
    There’s a book title that I remember – “If you don’t have time to do it right, when will you have time to do it over?”
    That’s why on my own projects, I try really hard not to announce or sell features until they are completed. Obviously I don’t have that luxury on work I take part in for other people, whether they’re employers, or consulting clients.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>