Go Beyond DevSecOps to Continuous Security

Rob Cuddy and Colin Bell highlight that DevSecOps is not the same thing as continuous security—and that the latter requires the real attention and focus. 

DevSecOps

The biggest focus of DevSecOps has been on getting security into the development pipeline (as well as every part of the process). As 2020 has rolled forward, the pandemic highlighted the importance of security in every person’s role. That’s something that hasn’t always been as obvious to everyone. 

While DevSecOps is on the rise, continuous security isn’t yet there. The focus is on getting testing into the pipeline, and there’s so much more to do there. To be clear, pipelines are great, but if bad things are in the pipeline, success won’t come out of it. 

Where is Security Today?

Security gets organized around the standard agile development phases: 

The automation space is where today’s shift-left mentality has gotten incredibly prominent, with flavors of code analysis tools and myriad other activities. But look at the ends of the pipeline: a similar depth of activities simply aren’t present today. Moving from DevSecOps to continuous security is really about adding activities across that full spread of phases. 

Maturity levels are a common operational frame in the classic CMMI style, but they don’t really capture the feedback loops that are key to DevSecOps and continuous security. 

Continuous Security

Continuous security can be described in a loop consisting of three phases: 

1. Construct
2. Intensify
3. Assure

These surround the classic agile development phases, as shown below.

The most mature DevOps organizations, per the State of DevOps Report from Puppet, are applying security within the design phase. In practice, that looks like threat modeling and vulnerabilities being discussed with development teams before code has been written. The intention is to expose developers to these risks and threats and improve the security from the beginning by having developers call out issues and find appropriate test cases. 

The automation phase already consumes a lot of attention. But we shouldn’t be automating just for its own sake. It’s key to understand what the scans are finding and what trends are emerging instead of focusing only on the number of scans conducted. The key to unlocking continuous security success here is that results are integrated into the pipeline and those results are trustworthy and actionable for developers. 

When continuous security rotates to educate, the focus is on ensuring developers have the level of training and knowledge to recognize security flaws and vulnerabilities in the wild. And interestingly, developers that receive this training are five times more likely to be happy in their work based on a Sonatype survey. 

To be great in this stage, understand the effectiveness of the training on actual outcomes and observe it being applied in practice. 

Governance and Audit

Quite often, organizations that scan for the sake of scanning do so out of a misplaced sense of governance. Effective governance within this model should help identify the controls and standards that will make the entire continuous security program effective. Success here looks like understanding why controls and validations are in use and there’s a broad knowledge of why something is done, not just that it’s done or how it’s accomplished. 

When audit is typically discussed, it tends to mean penetration testing. But the more powerful way to apply an audit is as the owner over the entire program. Used well, audits provide verification that the entire program is being effective and delivering on its objectives. Mature DevOps teams are twice as likely to have automated governance and compliance through a strong audit capability. 

Measurement

Many elements fall under the heading of measurement currently, but key to continuous security are two points: health and risk. Great measures help assess the health of the process and system and to understand the risks associated with it. 

Measurement effort should be put on business outcomes that can be translated into development terms. It’s better to have teams going deep on a few things than to focus on having lots of teams operating at a shallower level. 

Ideally, measurement ties back to governance and provides confidence on how the program is operating. It should also support analysis across teams that shows a movement towards improvement. 

The revised order of activities within the ideal continuous security program should start with governance and proceed as shown below. The metrics and reporting activities provide the feedback loop within each step to drive the necessary learning and improvements in every area. This will lead to lasting success in the program:

Conclusion

What’s ultimately desired is improved outcomes. Continuous learning is the way to drive those outcomes and continuous security as outlined in this talk will evolve you from DevSecOps to this new approach. 

This post was written by Daniel Longest. With over a decade in the software field, Daniel has worked in basically every possible role, from tester to project manager to development manager to enterprise architect. He has deep technical experience in .NET and database application development. And after several experiences with agile transformations and years spent coaching and mentoring developers, he's passionate about how organizational design, engineering fundamentals, and continuous improvement can be united in modern software development.