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.