A new report from vulnerability management platform Rezilion and the Ponemon Institute finds that vulnerability backlogs are tending to get the better of DevSecOps, with nearly half of respondents reporting backups of 100,000 to 1.1 million vulnerabilities. Even more troubling is that a little over half of these firms say they have been able to clear less than half of these hefty backlogs.
“The State of Vulnerability Management in DevSecOps” study included over 16,500 IT leaders and experts from a variety of organizations that have either implemented DevSecOps or are in process of adopting a DevSecOps approach.
Vulnerability management becoming a major burden for many organizations
Vulnerability management backlogs are huge, and they are not getting smaller. 66% of the study respondents are sitting on a backlog of at least 100,000 vulnerabilities; 25% have more than a million, and 8% have more than five million. 47% say that in the past year they have identified applications that were vulnerable, but were not remediated during that time; on average, organizations say that they are now happy if they can get to just 29% of their vulnerabilities.
Response time is also a serious vulnerability management issue. On the production side, 77% of respondents say it takes over 21 minutes to detect and remediate each individual vulnerability. On the development side, 80% of the respondents say this process takes at least 16 minutes each time.
What are the barriers to adopting a DevSecOps approach that could potentially automate and streamline this process? Organizations say that their biggest problem is a lack of appropriate security tools, followed by inability to integrate workflows and the need to immediately address an already titanic vulnerability backlog. Only a little over half of the respondents (55%) say that they feel their teams are currently aligned to understand overall security posture and the responsibilities of each. 53% are concerned about the risk to product security created by a lack of visibility, and less than half (47%) feel that the development team is able to deliver both a secure and customer-focused product.
Why are vulnerability management systems allowing these backlogs to pile up? Respondents say the primary problems are information and tools. 45% say they don’t know enough about vulnerability risks, and 43% say they do not have an effective arsenal of security tools. Organizations also say they are struggling more with patching than with vulnerability identification and prioritization. The main holdup in patching is the lack of effective tracking systems, followed by inability to halt normal work processes so that vulnerabilities can be patched in a timely manner.
And what is making it hard to get to vulnerabilities once they are identified? 55% say they are having trouble identifying them fast enough, 49% say they cannot patch quickly enough once something has been identified, and 43% say they need better tools for this task. Attack surface knowledge is also lacking; only 45% of respondents feel their organizations are at least effective in this area.
Over half of respondents have adopted automation as part of their DevSecOps approach, and these organizations say that it is making a difference in the time consumed by vulnerability management. 60% of these respondents say that automation has improved remediation times, with 43% saying it has made a “significant” difference. One aspect of automation that has substantial room for growth is the Software Bill of Materials (SBOM), which only 41% of respondents say they are using. Of those that have implemented SBOMs, only 47% are using them for continuous updates.
DevSecOps maturity: Room to grow
Only 29% of the respondents say that their DevSecOps is in the “mature” stage, but an additional 40% say that they are in a “middle stage” with a plan laid out to get to full maturity. 31% say they are just starting out with a DevSecOps approach.
The top two reasons for adopting DevSecOps are to improve patch times and to improve collaboration between different departments. Other common answers include automating the delivery of secure software without slowing the development cycle, reducing time and expense of fixing code, eliminating unnecessary reviews and rebuilds, and centralizing the approach to code review. Strangely, despite consistently naming it as a major issue, only 19% say that they intend for DevSecOps to address the vulnerability backlog.
Respondents also answered some questions about what the biggest problems were with the software toolkit they presently use to remediate vulnerabilities. 53% said that their current setup was overly complex, 47% said that they have had issues scaling it, 45% report interoperability issues, and 42% said it has been too difficult to implement properly. Only 18% said that cost was a barrier for them.
One of the key points revealed by these responses is that as application security “shifts left” toward primarily falling on app developers, these developers need the right toolkit to keep development from slowing down as a result. Rezilion CEO Liran Tancman also notes that there may be some intentional foot-dragging on adoption of SBOMs due to the “dirty laundry” they will inevitably reveal, with some organizations about to have their hands forced on this issue by new regulations requiring them.
