This is a work-in-progress, but I’d like your opinions on it:
Principles of Secure Software Development
- You’re not that good – someone will find a hole in your software. Find as many as you can, first.
- 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.]
- 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!
- 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.]
- 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”]
- 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.
- 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.
- People are replaced easily, processes are not – ensure that your secure development processes revolve around processes, not personalities.
- 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?
- 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.