Quality and security. Two words that share an interesting relationship and no small amount of confusion.
What is certain is that both words are meaningful in the context of software. Quality essentially means that the software will execute according to its design and purpose. Security means that the software will not put data or computing systems at risk of unauthorized access. While quality seems to be easier to measure, both are somewhat subjective in their assessment.
The real confusion comes when you consider the relationship between quality and security. Are they the same thing or is one a subset of the other? If I have quality, does that mean I’m also secure? Are quality problems also security problems or vice versa?
Defining quality and security defects
For those who take a holistic view of software design and development, quality and security issues both fall into the broad category of defects. BusinessDictionary.com defines a defect as a “frailty or shortcoming that prevents an item from being complete, desirable, effective, safe, or of merit, or makes it to malfunction or fail in its purpose.” For example, I can use a fuzzing tool to test software by essentially bombing the software with randomized input data. This process may force the software to respond in a manner that is not within the predefined parameters for the execution flow. Applying the definition of “defect”, the software malfunctioned or failed in its purpose. This would be a defect and would fall into the category of quality.
Determining if the defect has a security component will take more digging. If I can demonstrate that exploiting this issue in some way to gain unauthorized access to data or the network, then this would also fall under the category of security. It is entirely possible that the defect may simply be a logic issue and, while potentially annoying, does not create an exploitable vulnerability.
Based on my scenario above, we can then draw the conclusion that security is a subset of quality.
Or maybe not.
Clarifying the misunderstandings between quality and security
A simple coding bug such as cross-site scripting (XSS) may counter our argument. The developer can code the software within adherence to the requirements and still make the code vulnerable to an XSS attack. The associated defect would be security related, but does reflect a defect from a quality point of view. Many would argue that a security vulnerability is a quality problem. I could easily get behind that line of reasoning, but others would invoke the stricter interpretation. This disabuses the notion that security is a subset of quality.
Part of the misunderstanding between quality and security was that the two were functionally separated in traditional development shops, and the groups that owned them rarely interacted. Quality was the purview of the quality assurance team, who normally resided somewhere in the development organization. This team provided quality assurance and testing services to the developers. Security was handled by the security folks within IT. In many organizations, the relationships with development were not well-defined and even more poorly executed. IT Security and QA could have existed on separate planets and not known the difference.
What the two groups shared was that they were often viewed as a hindrance to development. When a defect was discovered by either QA or IT Security, developers were forced to stop what they were doing and remediate the code. The constant stream of interruptions had a predictable effect on development and the attitudes of the developers. QA and IT Security shared one common bond—they were viewed as an impediment to progress by the developers.
Combining quality and security to enable the developer
As development practices have evolved and agile methods continue to take root, the traditional quality and security silos have had to come down by necessity. Security is being integrated into the development process with the notion of enabling developers to build good security practices into their code. Similarly, the responsibility for quality is now shared by the developers. There is also higher awareness of the architecture, design, and requirements process and how that process affects quality and security.
From a manufacturing angle, defects are viewed as non-conformance with specified requirements. This raises the ever-present question of whether the organization should integrate security into the architecture and design process or take a “test and patch” approach to software security. This is a subject I have touched on in earlier columns, noting that 50% of security defects are flaws that have their genesis in the architecture and design phase. The other 50% of security issues result from the development process and are called “bugs.”
Broadening the quality and security perspective
In the end, quality and security are critical components to a broader notion: software integrity. Which one gets the most emphasis is in the eyes of the beholder? For example, if you were building the Mars Rover or a self-driving car you would want to ensure that the software on board was of the highest quality. If you were writing a banking application or software for a medical device, security would be a strong driver. Neither case is mutually exclusive, so there will be elements of both.
Ultimately, developers strive to develop the best software possible. This implies that defects—quality and security—should be minimalized, or, at best, eliminated. If we agree that quality and security problems are both a form of defect, then we must sufficiently address both to produce software of the highest integrity.
