8 Simple rules for developing more secure code

Directory

Habit 1: Take responsibility

Habit 2: Never believe in data

Habit 3: Simulate a threat to your code

Habit 4: Always one Step ahead

Habit 5: Blur!

Habit 6: Do not write unsafe code

Habit 7: Identify policy asymmetry

Habit 8: Use the best tools possible

I am honored to have worked with thousands of outstanding developers in the past few years, and they want to know how to write more secure software. In the meantime, I've learned a lot from people who have done well in building security systems, which makes me think about a problem. I wonder if there is a common skill or habit between security developers. The answer is of course there! This article describes a series of habits that are common among security code developers.

One thing I can be sure of right now is that anyone who has read this article will immediately discover the habits they don't have. It's very good. I know there are other good ideas in addition. Here's just a list of what I've observed! So here are a few of the typical habits I've noticed over the years.

Habit 1: Take responsibility

This is a long-standing shift from the idea of "no silver Bullet", which was put forward 25 years ago by Fred Brookes in his "man-Moon Myth". It is entirely up to you to make your product safe enough. No one else or any good tool or programming language can solve all the security risks. Don't get me wrong, I like the source code analysis tools, but they can't magically fix all of your security vulnerabilities. Only you can do it yourself.

Only developers who create security designs and write secure code can build a security product. Finally, writing code is done by individuals. A tool cannot replace an individual to do this work. Therefore, the security of your product is your responsibility! The Blaster and CodeRED worms use code that is written by individuals (see Figure 1).

Figure 1 The code for weakness is written by people.