Chapter 9. Build Security

Philosophy: Never depend on security through obscurity.

Michael Howard, author of Writing Secure Code

If you are considering or have considered outsourcing your development, one of the first questions you will probably ask yourself is, "How will I secure our company's intellectual property (IP) from potentially malicious offsite developers in the United States or abroad?" I answer those questions in the following pages, using Microsoft's methods as an example.

Even if you don't plan to outsource your development or have developers work offsite, unless you're writing freeware or running a software development charity, this subject is important to your software business. It's such a delicate subject that I was told that there are some secret security projects at work at Microsoft; furthermore, if the person I spoke to talked about the projects, it would be considered a breach of security and would be grounds for termination. I guess part of being secured is being a little paranoid.

Thus far, the chapters in this book have focused on the build process without regard to where your development work is done. What we have really been talking about up to this point is having the ability to track source changes to the owner and holding the owner of the code accountable for his/her work. Now, we look at how to secure that process.

Security is a broad subject, and I can't cover everything in this brief chapter. Instead, I focus on the following topics:

• Securing your source code from software pirates

• Supporting multiple site developers and teams or outsourcing your development

• Providing stability to your application

• Improving your Software Configuration Management (SCM) process

Figure 9.1 shows the typical track that a piece of source code follows at Microsoft. If you configure your shipping process to what is outlined in this book, your source life cycle will look like this, too. The illustration looks more complicated than it really is. Reading from left to right, the source code can reside in four places: anywhere, source lab, build lab(s), and release lab. In some groups and companies, the three labs are in one location, but they don't necessarily have to be. What is important is adequate security for each group.

Figure 9.1. Source life cycle.

The best way to provide adequate security is to take a multilevel approach:

• Physical security Doors, locks, cameras, and so on.

• Tracking source changes The build process.

• Binary/release bits assurance The tools process.

• IT infrastructure Company-wide policy and security.

Taking this four-pronged approach to security is what has evolved over the years at Microsoft. This might sound like a naïve statement, but in all the time I have spent working with developers and architects, I truly believe that their approach was (and still is to some extent) that they were working in a trusting environment. I also believe that a lot of companies I work with start with this position. Unfortunately, enough "bad apples" out there force Microsoft to take all of these security measures to protect its code. It's never too early for a company to take the same approach.