So there are a lot of non-contiguous ideas behind what DevSecOps is and why it is an important evolution of roles in the software development industry and I feel it's important to add my opinion to the general mix. For those who are unaware there is a whole manifesto that captures the general essence of the idea behind the role and how it can help development teams and even non-development teams to be more secure without slowing things down. It's short, to the point and has 9 maxims that define broad differences to traditional security.

More importantly than the differences from traditional security, of which the manifesto is largely derived, DevSecOps is embedded security. Not in the sense of a political officer in your team to enforce compliance. But rather that the DevSecOps takes broadly skilled people who can contribute at many different levels and embeds them in teams to help in many ways, but most importantly in their ability to provide immediate security insight into all team coding and infrastructure operations. Like a DevOps engineer, the DevSecOps engineer works closely with developers to create secure code, and securely implement the systems to run the code.

A DevSecOps practitioner must be an IT polymath, comfortable writing code to at least some appreciable level of the coding specialists of the team and capable of implementing the infrastructure systems to an appreciable level of an operations specialist as well. On top of this they must have the talent of spotting the weaknesses in systems and understand how to secure dangerous operations and design secure systems. This is not a simple role, it is really a triple major in IT and a talent in misbehaving.

DevSecOps requires the generalist, the person who is maybe not great at certain things, but good at many things.

It's quite a challenge to have a staffing requirement of a bunch of triple majors, even if ample time and resources are given to train up. So there is a practical side to implementing DevSecOps that requires everyone in the DevSecOps role to work closely with one another to balance different strengths and weaknesses. So that any organization that contains more than one DevSecOps practitioner must also create the meta team of all DevSecOps practitioners. Such that practitioners that come from coding backgrounds help members that come from operations backgrounds and vice versa. Such that the team trains itself to be more generalist. Care must be taken in staffing to ensure the 3 domains are evenly represented, and cross training fostered. This is different from the traditional IT culture of letting each person to their own specialty, in a DevSecOps the team must be focused on evening the specialties of the 3 knowledge domains. Everyone in DevSecOps must be comfortable with their knowledge and experience weaknesses, and strive to even out their weaknesses, while letting go of and sharing their own strengths.

So what does a team get by adding a DevSecOps engineer or architect to the team?

Built in, continuous security, and educated, immediate security response. Trusted council on security matters and "what could go wrong" right on hand (no more waiting for a security review, or scan, or scheduled meeting). Security that doesn't slow down development, because your security knows your development as well as almost anyone else on the team and cares about deadlines and deliverable pressures in the same way as the rest of the team does.

Much like DevOps, or SRE, the role never ends as long as the capability it is supporting exists. Like there is always room for operational improvements and code refactoring, there is also always an ever evolving landscape of security threats and mitigations. The automation and hardening of systems is never done, and never will be done, security is not a solved problem, and until it is the DevSecOps practitioner will always have work to do. To the point that if you cannot figure out what to work on next, you can then be certain you are missing something.