A flaw is a flaw is a flaw. And as DevSecOps practices take root in an enterprise, don’t be surprised when software engineering teams are finally able to let this concept bear fruit in a meaningful way—namely through the practical merger between quality assurance and security.
Philosophically, the idea that security is at least an offshoot—if not a subset—of quality assurance is nothing new. For decades now we’ve heard some prophets in the desert, security and IT generalists alike, shouting about this concept. This paper from SANS Institute circa 2001 is a good example. And this piece from IBM about 10 years later is another.
But nobody’s listened seriously because the cultural DNA of most software teams and IT departments has never been compatible with fully synthesizing security and quality. Sure, QA professionals and security experts deal in the same fundamentals of risk management. But the teams that eliminate functional bugs and those that eliminate security vulnerabilities still typically operate in totally different worlds. QA has long been a part of the engineering team and builds its testing tools to work in lockstep with the development life cycle and toolchain. Even before DevOps came along and demanded greater testing responsibility from developers, this was still frequently true. Meanwhile, security operates in its own orbit, with testing tools that traditionally weren’t built with developer workflows in mind.
The same type of tribalism that kept developers and operations staff completely segregated similarly has kept the bright line between security and QA functions in place long past its expiration date. Just as DevOps served to dismantle the first partition, an even more mature DevSecOps approach is about to take down the second.
While there may not be a seismic shift in 2018, expect to see the idea increasingly gaining traction as a confluence of factors begins to coalesce, including:
- the increased inclusion of security expert input in the requirements stage of development, adding security requirements to the definition of “done” within projects;
- a slow move away from traditional security-only testing tools to alternatives as organizations seek to streamline automated security testing directly into the development toolchain;
- a shift in the role of QA from testers to test automation engineers who help developers customize their test suite to perfectly fit the internal software delivery process; and
- the cultural metamorphosis toward a mindset that requires better cooperation amongst all tribes involved in software delivery.
All of this movement within organizations also will create a gravitational pull on vendors to better integrate existing application security tools into the DevOps toolchain or to build new tools from the ground up that seek out and help organizations prioritize remediation of flaws, regardless of whether they’re “security” or “quality” flaws.
From a career perspective, expect to see those specialists who can cross-train in both quality fundamentals and in security test design command a premium. It’s not as far-fetched as you think: The mentalities behind application security and quality specialties work hand in hand. It all comes down to risk management.
The current difference is that QA’s bias naturally trends toward maintaining user experience, while security leans more heavily toward minimizing risk. The merger hopefully will enable both teams to help bring the whole organization into greater balance between both.