Security and the protection of data is the top priority for both IT decision makers (ITDMs) and developers when looking to procure a new piece of software, but there is little consensus on which function is actually responsible for the ongoing security in doing so.
This is according to a new piece of research carried out by MongoDB, which surveyed over 1,5000 developers and ITDMs across Europe. The findings suggest that enterprises, whilst aware of their security responsibilities, are yet to establish a ‘gold standard’ approach to building and deploying products.
MongoDB’s director of developer operations, Joe Drumgoole, is advocating that an extension of DevOps to DevSecOps could be the answer, creating a ‘security as code’ culture.
DevOps is the practice of automating processes between development and IT teams, so that teams can build, test and release software more often and more reliably. MongoDB is advocating that a security function should become part of that process.
Drumgoole also suggests that moving to the cloud can reduce some of the pressure, given that the largest cloud providers have huge amounts of resources and invest in security at scale.
The survey results
Perhaps unsurprisingly, 92% of developers and 88% of ITDMs said that they take appropriate precautions when building new applications. Equally, the security of data is the top priority for both developers (47%) and ITDMs (53%).
However, things get more interesting when you dig a little deeper into the findings.
When developers were asked who has the most responsibility for securing an application, just 29% cited themselves, while the rest pointed to security specialists (22%), the business leaders that briefed the project (18%), the ops team (16%) and even security members that they don’t know (14%).
Meanwhile, the majority of ITDMs (28%) believe security specialists hold the most responsibility. They then point to business leaders (21%), ops teams (17%) and unknown specialists (10%).
In other words, there isn’t consensus within the enterprise about where responsibility lies, which is concerning given the high priority on security.
DevSecOps as an answer
We spoke with Drumgoole ahead of the research being released to get a better understanding of the findings and to establish why he thinks that DevSecOps could be an answer.
Drumgoole, whilst promoting DevSecOps, also acknowledges that it is very early days as a practice. He said:
I still think we are at the start of a journey around how to do security right. There’s a huge awareness and I think DevSecOps is the start of a more structured approach to security. But I do think we are still finding our way. If you said to me, what’s the capability maturity model for security? I don’t think there is one yet.
My advice is, start to learn about DevSecOps. DevOps was a response to - ‘it’s impossible to be agile if you can’t deploy fast into production’. Agility doesn’t make any sense unless you can get into production fast. There’s no point in producing a release every two weeks, if it takes four weeks to get into production.
DevSecOps takes the same approach. If security takes four weeks, and you’re releasing every day, you’ve got a mismatch. You’ve got a mis-gearing of the system. It requires that you embed your security team into your development processes. They can’t be sitting to the side, reviewing stuff later. You have to have that review process at the point where you’re doing the development.
Drumgoole said that DevSecOps is still an emerging practice and that any development organisation is just starting to scratch the surface of how it works as an approach.
He added that lessons need to be learned from the mantra of ‘move fast and break things’, which clearly hasn’t worked for some high profile organisations.
We all laugh about the Facebook mantra of move fast and break things - we’ve seen how that worked out for Facebook. The largest reputational damage to a business ever created was created by Facebook. We want to move fast, but keep things working.
Once security and DevSecOps is embedded in everyone’s psyche, life gets easier because you’re doing it all the time, in the same way you’re doing code quality and testing and feedback from users. DevOps was about building fast and with agility, DevSecOps was about building fast and with agility, but also with security as a high part of the profile of the development.
MongoDB, as part of the research, outlined the following five guiding principles for getting DevSecOps - and thinking about security more broadly - into the enterprise:
- Baked in - Security must be baked in. Consider any and all negative impacts a new feature may unknowingly cause, rather than just focusing on the positive impact it may generate
- Get specific - Determine your own organisation’s needs and goals and choose the right solutions for your situation. Not one size fits all.
- Adopt a people approach -Infuse security principles at every step, and into every collaborator, including developers. It’s a team sport where skills and culture matter equally.
- Share information - Open collaboration is essential in DevSecOps. Share, learn and improve constantly by communicating internally to meet your goals.
- Be ambitious - Don’t put your ambitions on the back burner. Many cloud platforms today offer built-in security controls for all your data. Take the leap to the cloud.
On the final point, Drumgoole suggests that companies should be recognising that cloud is an enabler to better security. He said:
We would recommend that anybody that wants to approach security from a sophisticated development model, is move to cloud. The cloud developers - whether it’s AWS, Google, Azure, or us - invest millions of dollars in making sure the security infrastructure is excellent.
You’re never going to get there on your own. If you look at the security teams in most of the enterprise places I’ve worked in, they’re relatively small. One or two people. We have 40 people that just get up every day and think about security.