James Whittaker here.
One of the first things I did as a new Microsoft employee was tour the company and meet with, literally, dozens of groups that are implementing the SDL. Before joining Microsoft, I had heard many firms claim their passion and commitment to security, and I‘ve always been a little skeptical about big players saying they’re doing something because it is the right thing to do, particularly when the right thing to do requires very serious and long-term dedication. For my part, I was determined to find out the real story behind the claimed turnaround in Microsoft development practices that occurred under the SDL banner. As an employee I would be granted full access to the data and hear the story as it really exists. No official messaging, just the facts.
The question I sought the answer to is: “does this stuff really work and, if so, why?” What place does security really hold in the software development process?
I admit I went into this endeavor with specific expectations. I expected that the mandate from BillG (in his famous Trustworthy Computing memo of 2002) would play a major role in the attitudes of our engineers. After all, having no choice in the matter is a strong behavioral change agent. Also, I was actually hoping to find that the process provided a structure to their work that developers actually welcomed.
But I could find no evidence of either. There were no managers transcribing the mandate on a stone tablet and using it as a license for the wholesale slaughter of sacred coding cows. There were no program managers with clipboards telling developers and testers how to do their job. In fact, the mandate was never mentioned. The process was never worshipped. What really seemed to have caused the change was a real concern for customers and a determination to do everything possible to prevent the kinds of issues they’d been facing over the years because of insecure software. (It’s a constant battle too given that the majority of universities ignore security in their curricula and that education is left up to us. As a former professor, this aspect of my new industry career really hurts.)
It was that attitude that caused a cultural shift across the company. And I believe that more than any other factor, it was this cultural shift that helped the SDL take such a firm hold throughout our developer, tester and program manager ranks. The mandate helped, the process enabled, but it was the sheer determination of the program managers, developers and testers to address customer demand for better security that caused many of our products to improve so dramatically. That fighting spirit is embedded in the SDL as technical mechanisms to make our software more difficult to break. Our engineers are determined to build software that causes adversaries to work inordinately hard to compromise and that sets a high bar for our competitors to match.
Security is not just a word, it’s an attribute that our customers care deeply about and that will make our products more competitive. The SDL is about satisfied customers and increasingly it’s about competitive advantage. Our engineers understand that and they’ve internalized it.
The SDL works because a cultural change has happened at Microsoft. Innovation, security, customer experience are all so tightly intertwined that we don’t think about them as separate entities. We don’t do the SDL because we have to; we do it because we do it. Word is getting around, the cultural change is spreading. The clipboards have been thrown out and the natural resistance to change has morphed into a development culture centered around a secure customer experience.
The answer I sought had nothing to do with mandates or subservience to process. Security has assumed its proper place in the software development process: a natural consequence of designing, writing and testing code. The next step in this evolution will be when we stop talking about the SDL and simply call it software development.