Application Security Was Always Your Responsibility, DevSecOps Didn't Change That
I’ve been part of development teams that have transformed themselves into the DevOps culture and lately, DevSecOps. In a nutshell, DevOps means that instead of separating the development and operations teams, you encourage them to collaborate, sometimes merging the functions completely. A DevOps team has one unifying goal: to address the needs of the end user of their application.
DevSecOps adds security explicitly into this model. But there’s nothing magical about DevSecOps. Saying that you’re doing DevSecOps doesn’t suddenly make you secure.
Saying that you’re doing DevSecOps should mean that you do security job as part of your normal development cycle. Not just when an accident or a breach happens. You have to do this, because you are deploying new versions of your application at such a high frequency that the normal gate keeping mechanisms cannot keep up with them.
I’m a stern proponent of both ideas, but to me the change in responsibilities doesn’t feel that radical. In my opinion, the final responsibility of the security of the application has always been in the hands of the development team. It’s just that in the “old model” (the world of strictly separated development and ops teams) it has been very difficult to have a say about certain things critical to the application’s safety, which too often just meant that no one did anything.
There are lot of different definitions of responsibility, especially related to cyber security, but here I define the responsible party as someone who can and will do something about the security, because no one else will. It would be nice to say that the cyber security team of your organisation is responsible for the cyber security of your application, but it would be a lie, because they can’t actually be responsible for your application. You can and you should.
Now, there are aspects of security related to your application that are not directly covered by DevSecOps and the shift from the old model to the DevOps might leave some of these unattended. I’m not saying these aspects are irrelevant and that the old world didn’t have its strengths too. Usually, there were structures, like a team or organization responsible for cyber security, which had their say and responsibility of the overall security. I am saying, however, that the actual and desired speed of delivery has and will increase to a point that the development team is the only one who can keep up with the understanding of the application or service that you’re developing.
There is a big cultural shift and a lot of new things to do if you are now handling the infrastructure too instead of sending a binary of your application to an operations team and letting them handle the rest. To me this just means that I can do the things I had to do anyhow, but without going through a horribly complicated hoops. A simple change in the infrastructure managed by someone else was always a process that would take weeks and sometimes we simply hit the wall and the change never got done.
The point of all that is not to bemoan about the relative speed of things happening in these different worlds, but that the problems related to your application are pretty much never going to be fixed by anyone else but yourself. In the old separated world of dev and ops, you could duck behind the fact that you can’t access the production environment, but that would just mean that no one else fixed your security issues.
The other side of the coin is that in the complete DevSecOps world you now have the infrastructure as a code at your hands and it might be that some or most of your team doesn’t know how to handle infrastructure stuff. It doesn’t make sense to dump the responsibility of maintaining an infrastructure to people that don’t know how to do it and don’t even want to.
So before transforming into the DevOps culture you do need to support the development teams in this process. Part of the support is to motivate the team to understand that infrastructure is part of their application and they should want to maintain it. This is helped by modern cloud environments which make the bulk of the maintenance work either obsolete or often much easier than in a traditional on-premise environment.
But if you get the support and have the motivation to take the actual responsibility then in this new world you also get the possibility to improve (almost) all aspects of your application’s security, instead of ducking behind excuses of it being “someone else’s problem”. Good luck!