Connect with us

Hi, what are you looking for?



Security vs. Quality: What’s the Difference?

Secure Software Development

Quality and security. Two words that share an interesting relationship and no small amount of confusion.

Secure Software Development

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. 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.

Advertisement. Scroll to continue reading.

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.

Written By

Click to comment


Daily Briefing Newsletter

Subscribe to the SecurityWeek Email Briefing to stay informed on the latest threats, trends, and technology, along with insightful columns from industry experts.

Join the session as we discuss the challenges and best practices for cybersecurity leaders managing cloud identities.


SecurityWeek’s Ransomware Resilience and Recovery Summit helps businesses to plan, prepare, and recover from a ransomware incident.


People on the Move

Former DoD CISO Jack Wilmer has been named CEO of defensive and offensive cyber solutions provider SIXGEN.

Certificate lifecycle management firm Sectigo has hired Jason Scott as its CISO.

The State of Vermont has appointed John Toney as the state’s new CISO.

More People On The Move

Expert Insights

Related Content


Less than a week after announcing that it would suspended service indefinitely due to a conflict with an (at the time) unnamed security researcher...

Data Breaches

OpenAI has confirmed a ChatGPT data breach on the same day a security firm reported seeing the use of a component affected by an...

IoT Security

A group of seven security researchers have discovered numerous vulnerabilities in vehicles from 16 car makers, including bugs that allowed them to control car...


A researcher at IOActive discovered that home security systems from SimpliSafe are plagued by a vulnerability that allows tech savvy burglars to remotely disable...

Risk Management

The supply chain threat is directly linked to attack surface management, but the supply chain must be known and understood before it can be...


Patch Tuesday: Microsoft calls attention to a series of zero-day remote code execution attacks hitting its Office productivity suite.


Patch Tuesday: Microsoft warns vulnerability (CVE-2023-23397) could lead to exploitation before an email is viewed in the Preview Pane.

IoT Security

A vulnerability affecting Dahua cameras and video recorders can be exploited by threat actors to modify a device’s system time.