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.