Real Software Does Have Bugs (and Vulnerabilities Too)

I was recently interviewed by a business journalist at CNBC for a story on high-profile software glitches that impacted operations of a trading company and an airline. The interviewer was seeking insights into the relationship between these glitches and security.

These interviews are always a refreshing opportunity to explain complex concepts in simple terms and to educate our audience about assumptions that we typically take for granted.

This interview was no different. The reporter wanted to understand how an organization could guarantee “bug-free” software. The sad truth is that no one can guarantee bug-free software and I ended up explaining the role of software quality as a discipline within software engineering. Large scale software applications are like airplanes, you cannot guarantee they will not fail. However, reputable airlines with a rigorous maintenance process have a much better safety record than airlines with unreliable maintenance practices. The same is true for software: Carnegie Mellon’s Software Engineering Institute has published extensive research that shows a direct correlation between the number of software defects and the maturity of the organization developing the software. The more mature the software development process is, the fewer defects the software has. But, the number of defects, even for the organizations with the most mature development process is never zero.

So the real question is not, “How can software development organizations guarantee bug-free software?” but rather “What process do they follow to reduce the occurrence of bugs in the software they produce?”

What is the relationship with security?

Vulnerabilities in software are nothing more than software defects that impact security. Therefore, they follow the same law: Real software does contain vulnerability and a strong secure software engineering process does reduce vulnerability count.

This simple law of software vulnerability is sometimes lost in the emerging debate around the best way for a buyer to measure the security of an IT product. In companion blog posts (here and here) recently published on the SAFECode blog, Steve Lipner from Microsoft and I have shared additional insights on this topic, which will hopefully steer the software security measurability debate in a productive direction.

About the Author: Eric Baize

Throughout his career, Eric Baize has been passionate about building security and privacy into systems and technology from design to deployment. He currently leads Dell EMC’s Product Security Office and serves as Chairman of SAFECode, an industry-led non-profit organization dedicated to advancing software and supply chain security best practices. At Dell EMC, Eric leads the team that sets the standards and practices for all aspects of product security for the product portfolio: Vulnerability response, secure development, consistent security architecture, and code integrity. Eric joined Dell through its combination with EMC where he built EMC’s highly successful product security program from the ground up and was a founding member of the leadership team that drove EMC’s acquisition of RSA Security in 2006. He later led RSA’s strategy for cloud and virtualization. Prior to joining EMC in 2002, Eric held various positions for Groupe Bull in Europe and in the US. Eric has been a member of the SAFECode Board of Directors since the organization was founded in 2007 and also serves on the BSIMM Board of Advisors. He holds multiple U.S. patents, has authored international security standards, is a regular speaker at industry conferences and has been quoted in leading print and online news media. Eric holds a Masters of Engineering degree in Computer Science from Ecole Nationale Supérieure des Télécommunications de Bretagne, France and is a Certified Information Security Manager. Follow Eric Baize on Twitter: @ericbaize