It’s hard to believe but the conversation around how security fits in DevOps has been going on for years. It was in 2012 when Gartner analyst Neil MacDonald wrote his blog DevOps Needs to Become DevOpsSec. In this blog MacDonald wrote “DevOps seeks to bridge the development and operations divide through the establishment of a culture of trust and shared interest among individuals in these previously siloed organizations. However, this vision is incomplete without the incorporation of information security, which represents yet another silo in IT.”
And he was absolutely correct. Security needs to be incorporated into DevOps practices. It’s why I’ve never been comfortable with the terms DevSecOps or DevSecOps or DevOpsSec. Security should just simply be a part of DevOps like any other quality test. For now, I think it’s important to use the term so people know you are talking about integrating security as it should be. Perhaps one day we won’t need a term at all and security in DevOps is understood as not being something special.
In the meantime, for those working in DevOps environments, based on discussions I’ve had with many DevOps practitioners, the following skills are essential for success.
Train, learn languages. Nothing in enterprises today will continue to exist in a silo. Infrastructure is code, networks are software defined, and everything can be scripted and defined as software. Learn How to script and automate as much of the rote work as possible. And keep learning the development side of this and application security, containerization, microservices architecture, cloud, and how to secure these new technologies and environments.
Don’t fight fate. To this day there are still too many security professionals fighting the cloud and DevOps locomotives. Face it: this is where industry is going and sooner or later much of your organization, if not having done so already, will move here. If you are one of the professionals unreasonably trying to slow down DevOps and cloud adoption, rather than trying to throw up roadblocks, and help the organization to move here as securely as is possible. I’m not talking about those who want to ensure the organization wants to move forward with
Empathy. In DevOps it’s expected folks understand the roles of others, and the importance of empathy is understood. But this too often stops when it comes to too many security professionals. So it’s important to remind security pros that it’s crucial that they try to see the world from the perspective of others. This comes with empathetic communication, understanding the goals and pressures of various team members, and removing blame from post-mortem assessments.
Find ways to help developers. Look for fewer ways to tell developers how they should be developing more securely and find more ways to help support developers at their job. This can include making sure that security tools are tuned properly to providing secured components for reuse to automating what can be automated for them.
More carrots, less sticks. When things go wrong it’s easy to point fingers and cast blame, but it’s not always effective. Lambasting and pointing fingers may feel good at times, especially when someone makes silly mistakes that they should know better. What does have a long term impact is providing positive feedback to individuals and teams as they get things right. So be sure to acknowledge those making the effort and making the moves to do the right things when it comes to security.