Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

10:00 AM
John Worrall
John Worrall

Why Quality & Security Both Matter in Software

It's time to position quality and security as equals under the metric of software integrity.

Software has forever revolutionized traditional product development. It's what sets companies apart — the ultimate competitive advantage. But it has to be done right.

You can't just ship software. You are expected to deliver high-quality, secure software to realize measurable business benefits, such as enhanced productivity and lower total cost of ownership (TCO). And ultimately, the goal is to make the end user's life better in some meaningful way.

But what, exactly, does "quality" and "secure" software mean? Does good quality software automatically mean it's secure? And if it's really secure, can it be considered inherently high quality? Are they actually the same thing? Well, it's complicated. But for CISOs responsible for ensuring security across software development, untangling these questions is critical.

Define First, Measure Second
Because you can't measure what you can't define, let's start with definitions. Quality software "will execute according to intended design and purpose based on business functionality." Secure software "won't put systems or data at risk of unauthorized access." There's a clear relationship between the two — one that's highlighted in guidance from the authoritative American Society of Quality, which positions security as a key element of software quality.  

Not My Job, Not My Problem
We can blame history for this quality vs. security conundrum. Since the days of linear, waterfall-style development, quality has been king for development teams. They didn't have to think about security — that was security's job. Meanwhile, security worked separately but had the unenviable job of rushing in to "bolt on" fixes at the 11th hour, slowing things down and building contention between the two teams.

Fast-forward to today and it's easy to see why this model won't fly. In the first half of 2019 alone, 3,813 breaches were reported, exposing over 4.1 billion records and costing victim organizations $3.2 million on average. And that's just the breaches we know about. Organizations simply cannot afford to keep security in the backseat — the business and reputational risks are too high.

Call Them What You Want, They're All Problems
It's a fact that humans make mistakes. Plus, many teams just don't have the tools or capabilities to enable the creation of error-free code. Add in constant pressure to move ever-faster and quality issues can quickly turn into security nightmares. Many breaches can be traced back to bugs (that cause software to deviate from its purpose) or underlying quality defects (like the failure to properly delineate code from data or sufficiently validate and filter input). Even if code is designed flawlessly, it's just one cross-site scripting (XSS) attack away from a security breach. It's safe to say a malicious code injection isn't just a security problem. It's also a major quality issue.

Companies create software to fulfill a customer need. That is software's primary business function. If we can agree this is true, then it's safe to assume ignoring unsecure software is not an option.

Four Steps Toward DevSecOps
Security has to become everyone's responsibility. As development, security, and operations start to blend and align to address current realities, security is finally claiming its rightful spot — side by side with quality. While still relatively new, DevSecOps methodology is gaining traction with 8% of companies securing 75% or more of their cloud-native applications with DevSecOps practices today — a number that's expected to jump to 68% in two years.

But this doesn't happen overnight. Embracing this new model requires a significant cultural shift: Developers must buy into the notion that quality software hinges on built-in security at every phase of development. Not only that, they need to view security as a significant piece of their own work.

Here are four specific steps your organization can take right now to start changing mindsets and driving transformation:

  • Take a top-down approach. "Security is everyone's job." This mindset should start at (and come from) the top.

  • Involve security in developer training. For example, conduct "post-mortem" education, sharing source code repositories and establishing authentication/encryption libraries.

  •  Embed consistent security across development. Integrate security scanning consistently across the software development life cycle (SDLC) and monitor all issues in a uniform, centralized way to close detection gaps and maintain a full view of risk.

  • Take advantage of automation. Deploying automated testing on every code commit will help you catch vulnerabilities earlier and cut through the noise so developers can prioritize efforts.

Quality has to translate into secure products. As DevSecOps takes hold, it's time to position quality and security as equals under the metric of software integrity. And CISOs, it's up to you to articulate the value of this symbiotic relationship to your organization, ensuring software can fulfill its ultimate business function of satisfying and protecting the customer in equal measure.

Related Content:

John Worrall has more than 25 years of leadership, strategy, and operational experience across early stage and established cybersecurity brands. In his current role as CEO at ZeroNorth, he leads the company's efforts to help customers bolster security across the software life ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
9/9/2020 | 4:57:33 AM
Why Quality & Security Both Matter in Software
Quality and security both are more important on software because If the software is not secure then anyone can't use it easily without risk. Or the software Is better from according to their competitors and is better in quality because today's quality is more important than quantity. 
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Google Cloud Debuts Threat-Detection Service
Robert Lemos, Contributing Writer,  9/23/2020
Shopify's Employee Data Theft Underscores Risk of Rogue Insiders
Kelly Sheridan, Staff Editor, Dark Reading,  9/23/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-09-27
XSS exists in the MobileFrontend extension for MediaWiki before 1.34.4 because section.line is mishandled during regex section line replacement from PageGateway. Using crafted HTML, an attacker can elicit an XSS attack via jQuery's parseHTML method, which can cause image callbacks to fire even witho...
PUBLISHED: 2020-09-27
An issue was discovered in the FileImporter extension for MediaWiki before 1.34.4. An attacker can import a file even when the target page is protected against "page creation" and the attacker should not be able to create it. This occurs because of a mishandled distinction between an uploa...
PUBLISHED: 2020-09-27
An issue was discovered in MediaWiki 1.34.x before 1.34.4. On Special:Contributions, the NS filter uses unescaped messages as keys in the option key for an HTMLForm specifier. This is vulnerable to a mild XSS if one of those messages is changed to include raw HTML.
PUBLISHED: 2020-09-27
In MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4, Special:UserRights exposes the existence of hidden users.
PUBLISHED: 2020-09-27
In MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4, XSS related to jQuery can occur. The attacker creates a message with [javascript:payload xss] and turns it into a jQuery object with mw.message().parse(). The expected result is that the jQuery object does not contain an <a> ...