Why Should I Care About DevSecOps?
Are you a frustrated security professional, trying to get your organization to change (aren’t we all)? Or perhaps, you are trying to get management to value security more? Or maybe, you are a security conscious Developer (wait, do those actually exist? Yes, yes, they do) or Sysadmin who knows you need more security in your development and deployment process? Then, DevSecOps is “a thing” you need to take a serious look at. Here’s why. DevSecOps is about repositioning security as part of the value creation process within your organization. Instead of being perceived as a bottom line cost, the goal is to add value, by creating better products. With DevSecOps, “we are explicitly inviting Security to the game of delivering customer value faster” – Curt Yanko.
But, how do you get management to take this seriously? The first step in any new adoption of any new technology, process, or cultural change, is to educate yourself on what it is, and why the organization should care. The next step, is learning how to position it in a way that management understands “what they get” – this is critical. I hate to break it to you, but everybody is in sales, even security…
But, What’s Different Now?
There are some key things happening in the world that are facilitating this change in people, process, and tools.
- People – there are still domain experts. That doesn’t go away. There are people specialized in Java App Servers, Databases, Operating Systems, Security, and Performance. I hate to break it to everyone, but all of these people still contribute in the modern world of software delivery – be it Cloud Servers, Containers, or Serverless. The changes in process and tools are allowing these people to collaborate in new ways.
- Process – DevOps, while not a process in and of itself, set the stage for expansion of the value stream. Rather than development alone, it expanded to the operations teams that run these services. Operations moved to the topline, contributing to the product development processes. Processes now extend over both teams – Development and Operations. Expansion to Security is a natural progression.
- Tools – CI/CD, Containers, and a converged supply chain (with containers) are game changing. Together these three things, change the way software is delivered so fundamentally, that new forms of collaboration are now possible. Again, extending to Security is a natural next step.
The Bigger Context
DevSecOps should really be thought about in the context of a bigger change happening in software as a whole. Everyone is more connected to the value stream creation, henceforth called a “product.” Let’s start with a high level understanding of all of the different functions. Forgive this oversimplification:
- Product Management gathers customer requirements
- Engineering builds product
- QA/QE tests product
- Operations delivers product
- Marketing tells customers why product exists
- Sales convinces customers it’s worth paying for
- Customer buy product
- Customers want new features
But, wait, how does product management know what customers want and need? Value creation isn’t just about building stuff, it’s about building stuff that people want and need. That means, feedback must be gathered:
- Customer wants new feature and tells Sales
- Sales brings in Product Marketers and Product Managers to understand
- Product Managers explain to Engineers, Finance, Security and Operations what needs to be built, bought, partnered or repackaged (the often forgotten forth one).
- Operations & Engineers work with QA/QE to build the right tests
This flow is grossly simplified, but it should be pretty obvious that Security needs to be part of every step, from Product Management gathering requirements, to Engineering building new features, to Sales and Marketing telling the story of why these security features matter.
Learn More
Curtis Yanko and I wrote a short, but concise book that helps explain Why, What DevSecOps is, as well as some starting points on People, Process, and Tools. I invite you to come read it, or listen on Audible.
Conclusion
In this day and age, we are all encouraged to think like product managers, asking how we prioritize time, cost and value. Security is a critical prioritization that has tremendous value to customers – be them internal or external. The processes highlighted above, and in the book apply to internal and external customers. For internal projects, you might not have marketing and sales functions. That just means, you are in sales and marketing. But, the function still exists, and Security is part of it. It’s a big change in thinking.
Come join the discussion – you can find us on Twitter – Curt Yanko (@CMYanko) & Scott McCarty (@fatherlinux)