The state of DevSecOps: Where teams and tools are at—and where they're going

Efforts to make security a part of software development and release demands modern tools — and empowering your software team. Here's what you need to know about the State of DevSecOps.

Back in February 2010, a trio of security experts released a widely received document, titled The Rugged Manifesto, that encapsulated their vision for how to make software more resilient against security threats.

The document’s authors argued a new model to application security was needed because reactive approaches that relied primarily on finding and fixing vulnerabilities in code were simply not scalable.

In the years since then, awareness has increased significantly of the need for developers to move security further left in the software development lifecycle effort. Efforts to make that happen — labeled variously as DevSecOps, SecDevOps, and Secure DevOps — have intensified in recent years as organizations, looking to optimize operational efficiencies, have adopted DevOps and continuous/integration continuous delivery (CI/CD) models for software development.

Here's what your software team needs to know about the state of DevSecOps — and where it's going next. 

DevSecOps: A work in progress

Yet more than 10 years after The Rugged Manifesto, efforts to make security a part of development and DevOps processes remains a work in progress at many organizations. Numerous surveys in recent years have showed that changes are happening at many companies, but in a slow and often patchy way.

In a 2021 GitLab DevSecOps survey of 4,300 IT and security professionals, 60% of the respondents said they are releasing code twice as fast as before because of DevOps and 19% claimed code was being shipped out the door ten times faster. But most viewed testing—including security testing—as the area most likely to significantly slow that cadence down.

Similarly, the survey showed that many organizations have ramped up use of static and dynamic application security tests—53% use SAST and 44% run DAST scans. But relatively few organizations are making the results of these scans visible to developers. Barely 23% of organizations in the survey made SAST results available to developers and an even smaller percentage (16%) did the same for DAST results

Notably, nearly four-in-10 developers (39%) in the survey held themselves fully responsible for security. Nearly a third (32%) shared the burden with others. Yet, the question of who “owns” security continues to be a thorny one at many organizations and a source of friction between security and DevOps teams.

Secure software is a byproduct of culture

Noted software security expert Josh Corman, one of the authors of the Rugged Manifesto, says secure code really is a byproduct of an organization’s security culture rather than just of controls. Organizations that rely solely on automated scanning tools, red teaming, and penetration tests for assuring software security for instance are not making the software development process itself any more secure.

All they are doing is addressing the symptoms of security issues in the software development process, but not the issues themselves. When security teams insist on force-fitting historical application security models in DevOps environments, progress can be hard to find, he says. Too often, all this results in is an adversarial environment, where security is seen as slowing down the cadence of software delivery.

Instead of a “scan and scold” model think about how you can architect security right from the start into the software development life cycle, he says. The goal should be to ensure that coding happens in a secure manner by training developers to be aware of security issues and planning for them before they even begin writing software (among other things).

“The best time to secure a product is before you have written it."
—Josh Corman

A threat modeling exercise, for instance, can reveal a lot more about risks specific to the way an application is going to be used, than more general penetration tests and red teaming exercises. Similarly, organizations can gain significant benefits by developing a security architecture which clearly outlines the security requirements for every software project, the specific controls for it and also emphasizes concepts like trust boundaries and isolation testing, Corman says. For a company to assure software resilience and security, they need the right people.

“Hiring a security architect is probably the best strategic move.” 
—Josh Corman

Another sign of true DevSecOps is when developers pay attention to things like software supply chain security, and know to make better decisions about using open-source code and maintaining a software bill of materials (SBOM) for all the software components that goes into their code. So too is having some sort of an open-source governance board for ensuring safe use of open-source components, Corman says.

DevSecOps advances with heightened awareness 

More organizations are beginning to pay attention to such practices. A survey of some 300 IT and security professionals that Dimensional Research conducted on behalf of ReversingLabs had more than three-quarters of respondents (77%) saying they saw value in generating SBOMs. Most saw the practice as necessary to protect against breaches resulting from vulnerabilities in the software supply chain. Even so, just 27% said they currently generate SBOMs and 44% said they did not have the expertise to review and analyze SBOMs.

Another federal DevSecOps landscape survey that the Advanced Technology Academic Research Center (ATARC) conducted last year showed that many development teams in the public sector have made significant progress in secure app building by adopting practices like source code management and implementing fully automated CI/CD pipelines. In fact, 57% of these organizations pointed to source code management as playing a key role in helping assure better software security; 39% cited automated security testing and 36% pointed to toolchain integration.

Teaming up security and release engineer teams

J. Paul Reed, DevOps expert and specialist on Netflix's Critical Operations and Reliability Engineering (CORE) team, says one of the best ways to tactically introduce security into the DevOps stream is to get release engineers and security engineers together. Often the two groups have far more overlap in their missions than they might realize, he says.

“A lot of the concerns that build and release engineers have are similar to the ones that security engineers have. The problems that keep the security engineer up at night are the same ones that keep the release engineer up at night."
—J. Paul Reed

For example, both, security teams and release engineers have a keen interest in the software supply chain. Each side might have a different mission. But security engineers and release engineers have the same interest in ensuring the provenance of open source and third-party software components, keeping the software components updated and vetting them for vulnerabilities and other issues that could impact application confidentiality, integrity, and availability. Security engineers are becoming sort of de facto release engineers, in their own right, he says.

“Software engineers are playing the role of release engineers. They are the ones keeping track of all the components that goes into a piece of functioning software."
—J. Paul Reed

Reed says problems can arise when security engineers perceive their role as looking at software for vulnerabilities and approving or disapproving a particular release from going out the door based on what they find. By securing your software development practices, the only time to halt releases is when an outsider has injected malware or otherwise compromised your code.

“[Security engineers] are going to have a rude awakening if [they] think that is where [they] are delivering value."
—J. Paul Reed

The better approach is to be a facilitator of security best practices during the software development process, Reed says. He points to how the role of build and release engineers has evolved over the years to where the biggest value they bring is in enabling an efficient CI/CD pipeline for software delivery. In the same way security teams need to be focused on building, or making available, tools that enable secure software development from the beginning — and are able to confirm all components of software are secure during the development lifecycle, ensuring there are no surprises at the release stage.

Security leaders need to look for opportunities to provide approved tools and libraries to developers that let them make secure choices while coding, and while releasing their software. Companies like Netflix for instance have been working on delivering tools that give developers a way to look at their code and identify and address potential security issues on their own, instead of having a security engineer vet it later.

The goal should be to give the developer and others closest to the work the information they need to make good decisions about security. With this approach, the role of the security team is heavily consultative, rather than just being an enforcer of controls, Reed says.

Corman says organizations in the financial services industry are among those that have had most success integrating security with DevOps, because they have adhered to such practices, he says. Some have chief product security officers bridging the gap between the security group and the team responsible for software development. Such executives have software development and design skills, combined with the security focus needed for secure DevOps.

Dev teams need the right tools

Ultimately, organizations that have the most success in making security a part of DevOps are the ones that can distribute responsibility for security across the entire software development lifecycle, Corman says. These are organizations that have integrated automated testing and security controls into the daily work of software development and deployment.

Modern tools that give greater visibility into software supply chain attacks, highlighted by SolarWinds, Log4Shell and recent NPM attacks, are critical to empowering you software team, and ensuring your CI/CD stays fast and secure.

“When you empower someone to do the right thing, they usually do it."
—Joshua Corman

Keep learning

• Get key takeaways from a survey of 300+ professionals on software supply chain security
• Discover how you can secure your CI/CD workflows
• Explore interactive sample software supply chain security reports