Once upon a time, development and operations groups had very different views of vulnerabilities, and what to do about them. As discrete teams, with the exception of handoffs when developers delivered the latest version of code to operations, there wasn’t always a great deal of interaction between the groups.
From a security standpoint, developers ran static and dynamic test tools – or, more likely, an application security team ran the tests on their behalf. That exercise would result, typically, in a massive list of vulnerabilities. Arguments would ensue about which “findings” were real, if they were exploitable, and the like. Since testing often occurred near the end of the development lifecycle, many flaws went uncorrected, as teams pressed on to meet deadlines.
Things weren’t much better from an operations perspective. They took little interest in the code itself, instead running vulnerability scans or engaging with pen testers to identify problem areas at the network and server layer. Like the developers, disagreements would result over the actual severity of a given vulnerability, and teams struggled – trying to avoid downtime and potential instability – to find a time when patches (assuming the vendor had provided them) could safely be applied.
It’s no wonder then we find ourselves in a difficult situation.
– As developers and operations teams evolve into DevOps, the combined groups lack a single view of vulnerabilities across the “full stack”of the application. There’s no basis for shared prioritization of potential security problems, or prioritization of fixes.
– The combination of vulnerability data from multiple sources – AST, SCA, pen testing and bug bounties, vendor advisories, scanning results, and more – overwhelms teams who have no idea where to begin assessment and triage tasks.
– Line of business, application owners, and security management continue to lack a view into the risk posed by the applications and systems that support their organization.
Its a bad situation, especially considering the vast attack surface applications, and their supporting infrastructure, expose to attackers.
For some time, operations teams have made use of threat and vulnerability management solutions (from vendors like Kenna Security, NopSec, NetSPI and several others) to consolidate and correlate vulnerability information. For their part, developers had similar solutions – dubbed application vulnerability correlation tools, from companies like CodeDX and ThreadFix – to perform similar tasks for the problems discovered during security testing.
About a year ago, I predicted https://www.gartner.com/doc/3783139 the distinctions between those two tools, and their underlying markets, would begin to fade. Driven by the needs for DevOps to have a single source of security data, as well as for growing demands on the part of management for a view of application risk, the two categories would begin to merge.
We’ve seen signs of that consolidation over the year, including last week’s announcement, by Kenna Security, of their Kenna Application Risk Module. The module expands and formalizes support for Kenna’s ability to integrate data from various SAST, DAST, and SCA tools into a common repository. The data is combined with additional information, including the results of vulnerability scans, pen testing and bug bounties, and exploit information. Vulnerabilities are logically associated with specific applications, and multiple factors – including the likelihood of exploit – are considered to prioritize individual issues, as well as to provide a high level risk score. Extensive automated integration is supported, including CI/CD tool chains, ticketing systems and risk management platforms.
These combined AVC/TVM platforms offer the potential to realize a number of benefits. With the availability of a combined, prioritized view of all types of application vulnerabilities, DevOps teams are in a better position to focus limited resources on the most critical bugs – reducing attack surfaces and helping to prevent breaches and security incidents. At the same time, senior management is in a better position to understand the risk applications introduce to their operations – clarifying decision-making and helping to support requests for budgets and staffing to deal with AppSec risks.
Expect to see further consolidation in the market. I’ll be presenting on this topic at Gartner’s Security and Risk Management Summit in Washington , DC the first week of June. And I’ll also have further research, targeted for publication later this year, to examine the progression of the market and examine how organizations are making use of these tools.
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.