What is DevSecOps? (And DevOps)

Is it too on the nose to use an image of a waterfall for this article? Sure, it’s the classic example of a one-way process but it’s also continuous delivery of water. Keep reading for more incredible insights!

In the Beginning

Some of us have been around for a very long time. We remember dial-up internet, BBSs and Webrings and we’ll bore you senseless with repeated stories of how nothing’s changed in tech, really, but somehow and at the same time everything’s changed and completely for the worse.

In that time we’ve seen a lot of things repeat themselves. One of them is the IT industry taking the simple evolutions in our understanding of how best to build software systems and turning these incremental advancements into big, defined delivery frameworks. These come with brand names and bandwagons that people can hitch themselves to and build consultancies, expos, book-signing tours and other exciting things that make it look, from the outside, like we’ve totally got our act together¹.

Fitter, Happier, More Productive

Agile software development is the classic example. Here’s the original Manifesto for Agile Software Development. Don’t worry about going there, I’ll include the full definition right here:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That’s… it. If you, as a team, acknowledge there is value in the things on the right, but value the things on the left more, then you’re an agile software development team. Congrats.

Agile got turned into such a monster by people pushing an agenda that many still feel like they don’t understand what it is. Neatly bringing me to DevSecOps. What DevSecOps is depends on what DevOps is. Is it:

Option A

The automation of build, test, deployment and operational activities. Or,

Option B

1. The fast flow of work from Development to Operations to the customer
2. The fast and constant flow of feedback from right to left at all stages of our value stream, and
3. Continually shortening and amplifying feedback loops to create a culture of continual learning and experimentation

If it’s option A then we can have DevOps engineers, DevOps teams and a Head of DevOps with accountability for the machinery that supports the delivery of software being as efficient and resilient as possible. This is an important part of delivering software! Especially when you’re delivering an awful lot of it. The machinery gets complex, and the ROI from improving its performance, reliability and observability is enormous. If DevOps is this then DevSecOps is automating build, test, deployment and operational activities securely and it’s very much about the technology you’re using and putting those tools in pipelines.

If it’s option B then none of that makes much sense. The automation of build, test, deployment and operational activities certainly helps achieve our three goals but having an engineer responsible for DevOps, or a team that does the DevOps for everyone, or an individual that’s accountable for DevOps happening runs counter to everything that DevOps is.

DevOps in this case is systemic and requires the whole organisation to work towards making it happen. It’s modern product development teams with great domain and technical knowledge, working autonomously in the best and most efficient way possible, continuously improving their understanding and the way they do things. If DevOps is this then DevSecOps is achieving the three things listed above securely and it’s very much mainly about your people and your delivery processes, enabled by the technology you’re using.

The Reveal

DevOps is option B. You can (and should!) read a book about it. Our three goals listed in the definition above are the three ways of DevOps as detailed and illustrated in the book.

Option A is build, release & deployment engineering and system administration. I spent five years in build, release & deployment engineering before DevOps was coined as a term. It was very interesting, being in the “meta” of software development, and enabling multiple development teams to deliver their best work was very rewarding. I watched this field co-opt the term “DevOps” and, much like with agile software development, it continues to cause confusion to this day. Consultancies, never ones to pass up an opportunity to profit from confusion, sold “DevOps Consultants” to large organisations to do the DevOps for them. As if having two people somewhere in the building with basic scripting skills who’d heard of AWS would transform you into a high-performing, generative organisation.

So, what is DevSecOps? DevSecOps is securing the activities and output of modern product development teams that are continuously shipping changes to their customers, operating their services with heavy automation and great observability, and striving to continuously improve how they’re working. If you want to know more about the details of how we go about securing modern product development, you can read our series of articles on Securing the Digital Factory. Pretty much every article on this site gets into the subject, in fact.

If you’re responsible for delivering digital products, services, software systems, applications, smart connected devices, pretty much anything technological and you’d like some help in making sure that everything is as secure as it needs to be then use our contact form below and we’ll get in touch for a chat.

Epilogue

I must admit, I didn’t give you the full definition of agile software development. Beyond the four value statements in the manifesto, there are the twelve principles of agile software. I’m going to list these principles from 2001 here with a little additional categorisation.

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. First way of DevOps

• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Second Way of DevOps

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. First way of DevOps

• Business people and developers must work together daily throughout the project. Third way of DevOps

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Third way of DevOps

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Second Way of DevOps Third way of DevOps

• Working software is the primary measure of progress. Second Way of DevOps

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Third way of DevOps

• Continuous attention to technical excellence and good design enhances agility. Third way of DevOps

• Simplicity—the art of maximizing the amount of work not done—is essential. Third way of DevOps

• The best architectures, requirements, and designs emerge from self-organizing teams. Third way of DevOps

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Third way of DevOps