Do developers take full responsibility for security? MongoDB finds only a third do

MongoDB poll suggests organizations haven't got to grips with DevSecOps but are headed in the right direction.

Less than a third of European developers take 'full' responsibility for security, according to a survey by NoSQL database maker MongoDB. But is that a good thing or a bad thing? 

Who ultimately should have responsibility for security and new software products? Business execs, developers, or IT security pros? Or should it be distributed between teams?

To find answers to those questions, MongoDB surveyed 1,516 developers and IT decision makers in France, Germany, and the UK, looking to understand how organizations divide up responsibilities for security when rolling out new applications and supporting existing ones.

The company found that 92% of developers and 88% of decision makers say they take "appropriate precautions" when building new apps.

SEE: 10 tips for new cybersecurity pros (free PDF)

Also, more developers and IT decision makers saw the security of data as the top priority compared with compatibility with other software and ease of use, meaning the two groups were on the same page in terms of relative priorities. 

However, MongoDB says the alignment between business and developers "splits" when it comes to writing new software. 

The company found that 29% of developers claimed to have the most responsibility for securing an application, while 22% said the main responsibility lies with security specialists, and 18% said it was the exec behind the project who was primarily responsible. 

A further 16% said it was the operations team's responsibility, and 14% said they don't know whose responsibility it was. 

On the business side, 28% reported that a security specialist is primarily responsible for security, while 21% said it was the developer's gig, 21% said it was a business responsibility, and 10% didn't know.

But is the finding that only 29% of developers see security of their code as a prime responsibility a good or bad thing, when in reality it's going to be a team effort supported by security specialists and developers having the right tools and processes to minimize the possibility of creating insecure software?

MongoDB's chief information security officer, Lena Smart, says the finding demonstrates a tension between developers and business that can be resolved with DevSecOps. 

"Control and convenience have long clashed. Developers are under relentless pressure to deliver – on time, to specification, securely and at scale. It's a challenge that will only continue. These conflicts unravel further as we look into how this is handled in businesses today," she said. 

The company says the finding suggests that companies are on the way to building security processes in the development cycle but are not quite there yet. 

DevSecOps, as with Agile and DevOps, aims to ensure software adapts to fluid business requirements while ensuring that security isn't just tacked on at the last minute or simply missed during the development process. But how should organizations make DevSecOps work for themselves? 

SEE: State of DevOps report: DevOps and security go hand in hand

According to MongoDB, there are five elements the organization needs to consider, including the idea that security must be "baked in" to the project, and that organizations need to find the right fit for themselves. 

Additionally, security must be a consideration for all players on a project, from the business to developers, while information must be shared openly between teams. 

Cisco's chief information security officer Steve Martino recently outlined the networking giant's road to DevSecOps. His advice was for organizations to drive security throughout the development process to help boost trust across different teams

He also said security teams and application teams should configure the most important security requirements early on in the project. Martino recommended automating these security requirements and continuously validating and updating them as the project evolves.