DevSecOps has become one of the hottest buzzwords in the DevOps ecosystem over the past few years. In the abstract, it’s easy to understand what DevSecOps means and why people care about it: it’s a strategy that extends DevOps efficiencies to software security. But when you sit down and actually start implementing DevSecOps, things can get trickier. There is no switch you can flip to go from DevOps to DevSecOps. Implementation requires a set of tools and practices.

Last year the Log4J vulnerability perfectly illustrated how properly shared SBOMs would have helped users find and mitigate the “vulnerability of the decade”. And over the last few days we’ve been worried that we’re in the same place with OpenSSL 3.x. Why will this keep on happening? A lot has happened since The White House issued Executive Order 14028.

The trouble with allowing developers to deploy code directly to production is that security threats are often overlooked in the process. These vulnerabilities only show up later during runtime. Once this happens, it falls on the shoulders of the Ops team or SREs to engage in firefighting.

Developer-centric security movements have dominated discussions in software development over recent years. The concepts are clear — integrate security early and find issues faster. But how does an organization measure the success of its developer security program?

Let's first take a look at what DevOps (Developer Operations) is so we can better understand why it has now evolved into DevSecOps (Developer Security Operations). DevOps is a combination of philosophies, practices, and tools that increases a business's ability to deliver better development in less time (Higher velocity). This can be applied to building a new product or the process of continuous improvement that applies to most products we see today.