It’s Not You, It’s Not Me, It’s We: DevSecOps
I have recently returned from Jenkins World, where I hosted a panel called, “It’s not you, it’s not me, it’s we,” which was about DevSecOps and what you really need to be successful “in making security everyone’s responsibility.” I was very lucky to be supported by an all-star panel made up of Pete Chestna of Veracode, Andrew Storms of New Context, Anders Wallgren of Electric Cloud, Curtis Yanko of Sonatype and Rob Stroud of Forrester.
Jenkins World was a great venue for this panel—although there were a few security folks in the audience, it was made up largely of Dev, Ops and DevOps people. The panel, which was held in a corner room, was standing room-only and we had a very engaged audience.
My premise in drawing up the title and abstract for this panel was that security cannot be just the job and responsibility of the security team. To do so will sentence every company to sub-par security postures always. Security always will be a drag on the IT business and, as an industry, the security community will lose a golden opportunity to fundamentally change the equation for the better.
We must engage with the developers and ops people and involve them in the security process. That means we need to entrust these people as partners and we need to trust that security is important to them as well. It will mean a combination of education, cultural change and tools. Lets look at each of these:
- Education – To make Devs, Ops and DevOps more security-aware there must be more security-awareness training. All factions need to understand the basic requirements of many of the compliance rules and regulations we deal with. Of course, specific tool training will be required as well.
- Cultural change – this isn’t going to be easy. But we need to make security part of the culture of the IT team. It really has to be a case of security truly being everyone’s job; that security really is part of the IT team and must have a seat at the table from the get-go. Perhaps most importantly, the cultural view that security has to take a back seat to time and speed has to change. Yes, we need to release on time, but we need to release securely on time.
- Tools – We need tools that developers can use to ensure security is not slowing them down, but rather is built into their software supply chain and development life cycle. As much as possible, we need to automate, automate, automate. The more we can automate security into the CI/CD process, the more secure and the better off we will be.
But that’s not all that is needed. It’s not just them, it is us. Over the last two weeks I have been reminded of how self-important some in the security field feel. Yes, security is important, but when you start thinking that your needs or tasks are more important than others’, you’re setting yourself up for problems. Also, we need to stop embracing our “otherness” and relish being part of the team.
One other thing, and this is important: R-E-S-P-E-C-T. Respect for the jobs and roles that others play. Developers are not dumb; neither are Ops or QA people. We need to respect and try to empathize with their own issues and outlooks. Empathy is a big part of the DevOps mantra.
While we are talking about DevOps, it would do the security industry well to stop treating it like it is just some mumbo jumbo. It is real and it is changing the way IT is done. It is going to change the way security is done, too. Stamping your feet, digging in your heels saying, “DevOps is not real,” and, “DevSecOps is a BS term,” isn’t going to win you any friends or allies. Worse, it is not going to result in our organizations being any more secure.
Let me share a secret with my security friends: DevOps people don’t like the term “DevSecOps” either. There is only one DevOps. It is the same across Dev, Ops, QA, security and everything else. The Sec is in there to make sure security feels part of the program. For those who think it should be SecDevOps or SecOps: please. We are not the center of the universe, we are part of the team. So whether you want to call it DevSecOps, Rugged DevOps or just DevOps, just make sure we are part of it.
Fundamentally, this is a huge cultural change that we need to bake in security if we are going to really grasp the opportunity that DevOps affords us to make our code, apps and organizations more secure.
Make no mistake about it: It is this opportunity to make security better—to build security in rather than bolt it on—that led me to found DevOps.com more than three years ago. I still believe that DevOps represents a “last best hope” for security to fundamentally change the status quo and make us more secure.
At the end of the day, we must remember when it comes to DevOps and security, it is not just me, it is not just you, it is we.
