The adoption of DevSecOps – the practice of integrating security throughout the software development lifecycle — is happening faster than expected, a new report has suggested.
In an international survey of 1,500 IT professionals around the world by the Synopsys Cybersecurity Research Center (CyRC) and market research consultancy Censuswide, 63% reported that they are incorporating at least some DevSecOps activities into their development pipelines.
Around a third described their DevSecOps programs as mature or deployed widely in their organization, with another three in 10 reporting limited but expanding use.
Someone else’s problem
However, there’s no real consensus on which application security tools should be used, with even web application firewalls – the tool with the highest adoption rate – used by fewer than half of respondents.
“The report shows that tooling adoption is low, indicating that, for many teams, security information and security practices may be viewed as belonging to another team,” Tim Mackey, principal security strategist at the Synopsys CyRC, tells The Daily Swig.
“As DevOps promotes the concept of taking shared responsibility for code quality, that only 47% of respondents indicated development held a role in application security is [also] concerning.”
Only 38% of those polled use software composition analysis (SCA) tools – a finding backed up by Gartner’s recent Market Guide for Software Composition Analysis, which also describes corporate adoption of SCA tools as still being at a relative early stage.
“Without the use of an SCA tool, which is designed to identify open source usage, knowing where open source components are used and what the current patch status of each component is can be challenging,” cautions Mackey.
Yet, as the Synopsis report points out, 72% of organizations say they have a published policy for open source use – prompting the question of how the rest are managing their use of open source components in the absence of formal guidelines.
“Are they employing manual processes to manage open source? Are they depending on a developer honor system that policies are being followed?” asks the report.
Lack of urgency
While half of respondents says security and component vulnerabilities are the number one consideration when vetting a new open source component, these concerns don’t often seem to be followed through with much urgency once they’re in place.
More than half said it takes two to three weeks for their organization to apply an open source patch, with another quarter saying that it can take up to a month – even when the patch addresses a critical issue.
Just over half of US organizations said they’d had their software delivery schedule affected in the past year by the need to address a critical open source patch, more than the 40% of global respondents who had done so.
“Unlike the software from commercial vendors, the patches from an open-source project perform a full upgrade from a prior version to the patched version,” says Mackey.
“This means that if it’s been some time since the last update, applying the patch might also include significant functional changes as well – each of which should be tested.”
For shame
Nearly half of respondents said that media coverage of open-source issues affects how their organizations manage open source risk – the fear of shame, perhaps, prompting them into action.
“Media coverage will always tend towards a headline worthy component, like a vulnerability in Docker, Kubernetes or Linux, or a headline-worthy victim, such as Equifax,” says Mackey.
“These high profile scenarios increase overall awareness of application security issues, but if a business relies upon the media as their primary security news feed, then they are exposing themselves to greater risk than they should.”
Source: https://portswigger.net/daily-swig/report-devsecops-adoption-gathers-pace-but-record-on-applying-security-updates-is-patchy
