Here are slides for my presentation, “DevOps Is Automation, DevSecOps Is People”.
For me, automation is one of the most compelling aspects of DevOps. Without automation you won’t reach scale, you’ll struggle with maintenance and patch management, and you’ll only have a foggy notion of the risk your app has.
In addition to scaling, we want to make repetitive and complex tasks automatic for the people who do them. Exposing DevOps teams to the tasks of building and maintaining software shows that everybody hurts sometimes.
The cloud has enabled systems to be abstracted to code and APIs. This doesn’t mean that they’ll be more secure, but it does mean that the maturity you bring to code quality for you app can translate to the code quality for your systems and architecture. What we don’t have are APIs for people.
And software is ultimately made by and made for people. You might even say it’s made of people. (Some apps are more people than others….)
This presentation was a bit of a survey of topics, comments, and examples of how to improve not only how we work with people to add security to the DevOps pipeline, but additional things to consider as we build threat models for the apps being deployed. For example, it’s one thing to talk about weakness in “business logic” that may lead to privilege escalation or data theft. It’s another to consider how an app’s features can be used to abuse or harass other users.
In appsec we have lists, more lists, recommendations, secure coding guidelines, and more lists. But they’re meaningless without people to place them in context and take action. Communication and empathy are key to understanding how to improve the way we integrate security into processes successfully and build apps that serve people well.
In a way they’re like tabletop role-playing games. RPGs have lists and tables and appendices and dice and more tables and lists. They have threats and unexpected situations. But it’s the people that bring the game to life.