Defining quality within software is a work in progress. It’s also a process of evolution, particularly in the way the notion of quality relates to security. The two are inextricably linked—and yet, the relationship is not always clear.
Can we assume quality software is always secure?
Does secure software automatically check the boxes for quality?
When we discuss quality and security in software development, are we talking about the same thing?
All of these queries surrounding the relationship between quality and security are meaningful and worthy of further exploration. Fortunately for industry pros and customers alike, our recent whitepaper, “Are Quality and Security Synonymous in Software?” takes on the challenge of examining this lengthy and intertwined relationship from all angles. Building high-quality software that’s also secure demands a certain understanding of industry expectations, including the business imperative for such discussion.
Untangling the relationship of quality and security in software touches upon more than just compatibility, as it forces us to consider organizational concerns like the total cost of ownership (TCO) and other economic benefits to the enterprise.
Because CISOs are tasked with championing security throughout software development, they are ideally suited to help companies orient themselves more effectively on the value of this symbiotic relationship. Quality may begin as a definition—but it must eventually translate into secure products.
Our whitepaper shares valuable CISO insight on the subject. Here’s a glimpse:
Clear definitions are critical.
For now, keep in mind quality software “will execute according to intended design and purpose based on business functionality.” Secure software “won’t put data or systems at risk of unauthorized access.” Based on these definitions, it will become obvious why quality software must be properly secured. Further evidence for including security as a key element of quality comes directly from the American Society of Quality. Their definition of quality software highlights eight hierarchical metrics, including “security” at number five on the list.
There’s a long and separate history.
Development teams traditionally obsessed over quality while IT teams shouted about security from the back of the room. Interaction between camps was rare, with collaboration virtually non-existent. Historically, security came last in the pecking order behind speed to market and product quality. Understaffed security held the thankless job of attempting to “bolt it on” in a rush to meet deadlines, often viewed as a hindrance to progress by developers.
Today’s security landscape flips the traditional order of quality and security—many believe, for the better. Companies often overlook security at their own peril, risking high financial costs in addition to possibly damaging the brand reputation when a breach goes public. Modern development teams can’t afford to be soft on security, which makes an even stronger case for reframing security in relation to quality.
Flaws can bring dramatic consequences.
Quality bugs can result in dangerous vulnerabilities that quickly become significant security issues. Likewise, even the most well-written and developed code can fall victim to Cross-Site Scripting (XSS) attacks. These malicious code injections create a security breach compromising otherwise quality code, and now a security defect becomes a quality problem.
We can’t ignore un-secure software.
The connection between quality and security runs even deeper, and upon further examination, it becomes obvious why the definition of quality must include security. Remember how quality software is defined as “executing according to intended design and purpose based on business functionality?” If we can agree software’s prime business functionality is pleasing the customer, then it’s safe to assume ignoring un-secure software is not an option. Quality function deployment (QFD), a methodology that stresses honoring the customer’s voice when assessing software quality, supports this reasoning.
There’s a cultural shift happening…
The reframing of security in the context of quality is key to the cultural shift of DevSecOps. Why? Because developers buying into the importance of security is critical when building software of any kind. The emergence of the DevSecOps methodology, which injects the notion of security into the relationship between development and operations, is a big part of why these questions are even questions today. When it comes to software applications, security must finally claim its rightful position next to quality.
Organizations wishing to install DevSecOps successfully need to understand the findings detailed in our recent whitepaper on quality and security. It’s also critical for organizations to learn how they can find a consolidated view of risk with automated scanning and shared tracking systems. DevSecOps succeeds with the creation of a fresh, top-down cultural mindset—all departments now share the responsibility for security, keeping it top-of-mind in their daily routines.
What’s the final word?
If we can agree software’s designed purpose is to meet the business function of pleasing the end customer, will security (as well as quality) be expected? For key insight from industry professionals and an enterprise CISO read our new whitepaper “Are Quality and Security Synonymous in Software?” and find out more about software integrity, including how it leads to better, stronger products for customers. Feel free to contact us for more information.