Dispelling DevSecOps Myths and Maximizing the Potential

As federal agencies grapple with evolving mandates, increased cloud adoption, and higher constituent expectations of the digital experience, many are turning to DevOps to accelerate the development process.

Through bringing together traditionally separated teams and automating tasks like code deployment, DevOps makes it quicker and easier for organizations to update applications and software. DevSecOps adds security into the mix, incorporating security tools and processes into every stage of the development lifecycle and providing a methodology for reacting to changes in the environment. This greatly increases the speed and efficiency by which organizations discover and correct system flaws—essential for federal agencies that handle classified data and need to comply with stringent security and data privacy requirements.

Most federal agencies today understand the concept of DevSecOps and recognize its value. But certain misconceptions still linger about DevSecOps: that it’s purely about technology or speed, that it’s a replacement for agile, and that it requires a massive investment in “super developers” or relinquishment of control.

Key clarifications follow.

1. With DevSecOps, organizations gain—rather than give up—control.  

Development is filled with manual steps. DevSecOps uses repeatable processes to automate these steps. It takes individual steps out of human hands, which gives some federal IT leaders trepidation, but it lessens variability, strengthens predictability, and removes human error from the development process.

Decreased human error and increased predictability are good things to have for organizations dealing with classified information and sensitive data. As the International Association of Privacy Professionals writes about today’s cybersecurity environment: “The majority of incidents are inadvertent and unintentional and can be classified as human error. And these incidents still trigger the same regulatory obligations as intentional and malicious incidents.”

2. DevSecOps doesn’t require a big investment in “super developers.”  

Many federal IT leaders fear the price tag involved in acquiring the full stack of DevSecOps skills. And understandably so. The annual salary of a DevSecOps engineer can run into the high $100,000s, which surpasses the G15 pay grade.

Fortunately, DevSecOps doesn’t require an organization to concentrate specialized (and expensive) knowledge into a small team of specialists who know everything and are responsible for everything. The reality is actually the opposite: An organization’s whole development team, across skill sets, receives training on universal DevSecOps methodology and processes that apply throughout the delivery lifecycle. And ultimately this team will work faster and smarter because they understand the full picture of product development.

3. DevSecOps involves more than buying a certain technology or tool.

Federal IT leaders often ask us, “What’s the best tool for DevSecOps?” Our response: None—if you plan to use the same siloed channels and development processes as before.

Imagine building a four-lane highway but the processes governing this highway allow people to drive in only one lane. That’s what happens when organizations bring DevSecOps in purely through the use of tools. They don’t realize the full value of DevSecOps and they miss the core idea. DevSecOps is about communication and cultural norms as well as architecture and efficient processes. Organizations gain efficiencies through the ways their teams interact in addition to the technologies they deploy.

4. DevSecOps is a complement to—not substitute for—agile.

Agile is still in the adoption phase in the federal space, and as agencies continue to incorporate it into their development processes, they need to understand agile’s limitations. Specifically, agile does not cover the delivery of software through an organization’s testing, quality assurance, and production environments. DevSecOps does. To move features and changes through the full development and deployment lifecycle, federal agencies need both agile and DevSecOps.

5. DevSecOps is about more than just speed.

Some federal IT executives don’t see the need for speed (“We’re not Amazon”) and others believe velocity is king—if bumps or issues arise, they’ll just deal with them afterward.

Both views miss a critical point: The automation processes that help teams achieve quality and compliance do enable faster deployments. But the foundational value of DevSecOps is its ability, through automation and repeatable processes, to build stability and security into every stage of the development lifecycle. Velocity is simply a byproduct of these benefits.   

Federal IT executives can and should take the next step in implementing DevSecOps at their agencies. But they need to move forward the right way. This involves clearing up common misperceptions, approaching all aspects of DevSecOps from an informed perspective, and shifting from the traditional view of procurement—in which individual departments procure siloed technologies for specific problems—to a fresh way of thinking: aligning performance requirements and SLAs and acquiring tools that integrate successfully into all layers of the organization.

By taking these actions, federal agencies will soon be on the path to meeting the government’s rigorous security requirements as they rapidly innovate for their constituents and missions.

Jimmy Pham is a principal and Martin Folkoff is a chief technologist for Booz Allen Hamilton.