A practitioner's guide to software security

An interview with Gary McGraw.

Software security guru Gary McGraw is back with a new book, Software Security: Building Security In,which is the third in a series and described as a practitioner's handbook. Network World Editor-in-Chief John Dix caught up with McGraw to talk about the book, the state of software security and the approaches he recommends for doing it better. (McGraw was interviewed in 2004 about his book Exploiting Software: How to Break Code.)

You organize your new book, in part, around what you call touchpoints. What's that all about?

One of the things you need to know about software developers is they have different religions when it comes to their methodology. So there will be people who do something called extreme programming, and people who do the Capability Maturity Model, people who do Spiral Model. And when you go to a developer and say, 'Let's talk about how you develop software,' they're always excited about their own methodology. So the last thing I wanted to do was invent another methodology.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Software security guru Gary McGraw is back with a new book, Software Security: Building Security In,which is the third in a series and described as a practitioner's handbook. Network World Editor-in-Chief John Dix caught up with McGraw to talk about the book, the state of software security and the approaches he recommends for doing it better. (McGraw was interviewed in 2004 about his book Exploiting Software: How to Break Code.)

You organize your new book, in part, around what you call touchpoints. What's that all about?

One of the things you need to know about software developers is they have different religions when it comes to their methodology. So there will be people who do something called extreme programming, and people who do the Capability Maturity Model, people who do Spiral Model. And when you go to a developer and say, 'Let's talk about how you develop software,' they're always excited about their own methodology. So the last thing I wanted to do was invent another methodology.

So the idea behind the touchpoints is to create some lightweight security best practices that can be used no matter what your methodology religion is.

The idea came about because I was thinking: What do all these software methodologies have in common? They have in common a set of artifacts. Code is an artifact that you create when you're making software. Or architecture documentation, or test plans and test results. So these artifacts are produced no matter which methodology you're following.

And the touchpoints are about each artifact. There's a picture in the book that shows how the touchpoints align with the artifacts. So the artifacts along the bottom are things like architecture and design, test plans, code, test results and feedback from the field. Those are the things you pile up when you're building software.

And once you have those, you can talk about particular best practices. With code, for example, I can do code review using a static-analysis tool to look for bugs. Given architecture, I can do risk analysis.

So those are some examples of the touchpoints. Out of all of the touchpoints I'd say the two you should absolutely do are code review with a tool and architectural risk analysis. And the reason for that is software problems come in two flavors. They come as bugs, like a buffer overflow on line 47, and as flaws, like you didn't do your error handling consistently among all these gazillions of classes. So you want to be able to cover both of those since they're divided roughly 50/50. And that's why the first two touchpoints are what they are.

Is your book aimed at individual developers or teams of developers?

Both. The middle section is a bunch of chapters about the touchpoints. So there's one chapter for each point, which is great for individual developers and software security analysts and people who run projects. Part 3 of the book is called "Software Security Grows Up," and it's about how to take a large organization and try to instantiate the touchpoints.