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.

At the heart of having a successful vulnerability management program is alignment between development, security, and operations teams (dubbed DevSecOps) in being able to achieve both innovation and security when delivering products—the ultimate end game. This requires having a common set of goals. Without them, or if teams don’t communication well or collaborate, any DevSecOps initiative will all be for naught.

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.