After Five Years, SAFECode Sees Software Security Progress, But Challenges Remain

Software security, code quality and the iea of building security into applications from the design phase forward have become touchstones for any conversation about how to improve the security of the Web and the general IT infrastructure. But it wasn’t always thus. In fact, it wasn’t too many years ago that the idea of software security took a back seat to the more traditional security disciplines. That’s changed of late, and one of the groups that’s been in the middle of the transformation is SAFECode, the industry organization comprising Microsoft, Adobe, SAP, EMC and others, that’s designed to advance software security methods and practices.

SafecodeSoftware security, code quality and the iea of building security into applications from the design phase forward have become touchstones for any conversation about how to improve the security of the Web and the general IT infrastructure. But it wasn’t always thus. In fact, it wasn’t too many years ago that the idea of software security took a back seat to the more traditional security disciplines. That’s changed of late, and one of the groups that’s been in the middle of the transformation is SAFECode, the industry organization comprising Microsoft, Adobe, SAP, EMC and others, that’s designed to advance software security methods and practices.

SAFECode is now five years old and attitudes about software security have changed quite a bit in that time, not just among users, but also among vendors. Dennis Fisher spoke with SAFECode board member Eric Baize, senior director of the product security office at EMC, about the changes in the landscape and what’s ahead for software security.

Threatpost: What’s the biggest change you’ve seen since SAFECode started five years ago?

Eric Baize: Five years ago, a lot of people were very skeptical about vendors building security into products. There was a lot of suspicion about how committed we were. We came together to make sure we were documenting the parctices we were using and increasing overall trust in IT products. This was the goal then and remains our focus now. We’re pretty pleased with the progress we’ve made. My yardstick is how the conversation has evolved. It’s no longer whether the vendor is building security into its products. We have been the first ones to document the processes we put in place. We have a paper around security development practices, the security of the supply chain. It shows everyone how committed we are to the topic and documents the first-hand practices we have put in place. 

Threatpost: How have those efforts had effects in other companies?

Eric Baize: We’ve helped organizations that want to start software assurance programs, using the same practices that we have spent years developing. It’s valuable for them to understand the practices we’ve developed so they can have confidence in what we provide. The whole ecosystem is more secure now. SAFECode published two guides around the security of the supply chain when few people were paying attention to the problem. We like to talk about software integrity control. How do you ensure that the software and the hardware you sell doesn’t have malicious programs? That contributed greatly to education and explaining the problem.

Threatpost: What are the remaining challenges you see ahead?

Eric Baize: We’re always fearful of simplistic solutions that don’t take into account the complexity of the problem. Five years ago, there was a lot of talk about regulating where software is developed. It’s not so much the location as the process. If your process is bad, your software will be bad. The challenge is continuing to operationalize software development practices. You need to document and adopt the agile development processes. SAFECode members are doing well, but customers use smaller vendors too. We also need a work force that understands that software development is part of computer science, not just a field for experts. 

Threatpost: What else would you like to see done?

Eric Baize: The other challenge is measurement. Now that there’s more faith in IT vendors and the practices we’re using, we see a lot of discussions about how we can measure that trust model for the software. I like to compare it to health care. If you want to know if someone is likely to die from a heart attack, you have two ways: Measure their blood pressure; and the other is too look at their lifestyle, which we think is a much more accurate measurement. We’ve seen similar approaches with software security, when so many customers are looking at magic tools to tell us how secure software is. We have a role to play in educating customers.

Suggested articles