You cannot have an insecure app that is also high quality. But you can have a secure app, that is very buggy and otherwise of low quality.
Join the DZone community and get the full member experience.
This topic has come up a few times this year in question period: arguments that quality bugs and security bugs « have equal value, » that security testing and QA are « the same thing, » that security testing should « just be performed by QA » and that « there’s no specific skillset » required to do security testing versus QA. This article will explain why I fundamentally disagree with all of those statements.
First, some definitions.
A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
A security bug is specifically a bug that causes a vulnerability. A vulnerability is a weakness which can be exploited by a threat actor, such as an attacker, to perform unauthorized actions within a computer system.
QA looks for software bugs (any kind); security testers look for vulnerabilities. This is the main difference — their goals.
Just as all women are human beings, but not all human beings are women; while all security bugs are defects, not all defects are security bugs.
Now let’s dissect each of the claims above.
If a security bug can lead to a low risk vulnerability, it does not have « the same value » as a non-security-related bug that is making the system crash over and over. The same as if a security bug is creating a situation of a potential data breach, or worse, it’s not equivalent to the fonts not matching from page to page. I am of the opinion that security bugs are more likely to be able to cause catastrophic business harm than a regular bug, due to the fact that if your system has fallen under the control of a malicious actor, creativity is the only limit. Malicious actors never cease to amaze me with the damage they can do.
The goals of security testing and quality assurance testing are different, which I feel makes them obviously different (if they were the same, why would they not be called the same thing?). However, I want to get deeper into this idea.
Security is a part of quality.
I often say “Security is a part of quality” because I believe this to be true. You cannot have a high-quality product that is insecure; it is an oxymoron. If an application is fast, beautiful, and does everything the client asked for, but someone breaks into it the first day that it is released, I don’t think you will find anyone willing to call it a high-quality application.
