Why it’s time for more CISOs to embrace DevSecOps

While nearly one in five companies say they are releasing code 10 times faster than in the past, more software means more security flaws, and greater opportunity for bad actors to take advantage of them.

The faster pace and increasing risks highlight the need for IT leaders to get serious about embracing DevSecOps, a management approach that makes security a shared responsibility among development, security, and IT operations teams. One indication that DevSecOps is gaining traction in the enterprise: Nearly half of development teams used application security tools in 2020, compared to just under 30% in 2015, according to 451 Research, part of S&P Global Market Intelligence.

DevSecOps is the methodology and practice of addressing security alongside both development and operations from the very beginning of the software development process. The formation of these teams fosters a shared responsibility for security, as well as a streamlined means to identify and fix vulnerabilities more quickly.

DevSecOps also creates a cultural advantage for organizations: promoting knowledge sharing and an all-for-one environment in which domain experts learn from one another, says Mandy Andress, chief information security officer at Elastic. Andress has been implementing DevSecOps practices and processes since joining the company in 2018.

For CISOs considering a transition to DevSecOps, here are several strategies experts recommend to guide implementation.

Embrace security tasks earlier on

Software engineers and security teams have historically not been close collaborators. To developers, security professionals are hell-bent on slowing the rapid pace of software launches and updates. Security pros see developers as too eager to push out code without sufficient regard for managing risk.

DevSecOps was conceived, in part, to build a bridge between the two factions. One core mandate of DevSecOps is to “shift left,” meaning that security tasks that might have occurred later in the development cycle, or to the far right on a timeline, take place early in the design phase. Additionally, shifting left cements the cultural advantage of integrating security into every aspect of product development and deployment.

Previously, security teams weren’t brought in to conduct security tests — a labor-intensive task — until developers wrote their code. With DevSecOps, those teams initiate tests during early phases of development. This speeds up overall development by identifying security holes early enough to avoid forcing engineers to go back and make substantive changes.

“The need for developers and everyone along the cycle to have core security skills has become essential,” says Jayne Groll, CEO of the DevOps Institute, an industry group that offers training and certification programs for DevSecOps practices. “We can’t look at security as an afterthought anymore.”

The value of a high-ranking champion

Like any major broad change in technology development, DevSecOps needs to be driven by a high-level executive, typically a CIO, CISO, or an engineering executive, says Bill Curtis, executive director of the Consortium for IT Software Quality.

While providing access to application security tools is vital, so too is senior leadership making sure security is as great or greater priority than new features. An effective DevSecOps leader may insist teams set aside time (or even full releases) just for closing vulnerabilities as opposed to introducing new features, says Curtis.

Share expertise

Many developer, security, and IT operations teams need to be inspired, cajoled, or compelled to share their expertise — a challenge that people with highly technical skills can find difficult when working outside their domain.

Team leaders can help, says Groll, by holding sessions so all groups understand the business impact of the other two, and making sure everyone’s metrics take security into consideration. Developers will be more likely to ask their security counterparts for advice, and security teams will be more likely to give it. “The biggest obstacle to DevSecOps is as much human as it is technical,” Groll says. “We have to be comfortable stepping outside of our traditional comfort zones.”

“It used to be that if you just got the technology right, you were good,” adds Andress. “Today’s security teams are much more driven by empathy and an understanding of human behavior.”

Stay flexible

There is no one-size-fits-all blueprint for implementing DevSecOps, says Andress. Rather, leaders need to set the necessary guardrails and give teams the freedom to operate within them.

At Elastic, “we ask security teams to set frameworks for how security testing should operate, and make sure that developers have the right tools and processes to work in these frameworks,” Andress says. “Then they can work out what’s best in terms of timing, and which processes to adopt.”

The US Navy, for example, recently launched a DevSecOps program with a process that focused on cultural rather than technical issues. The group appointed three leaders to champion the needs of products, engineers, and end users. Then it set up the cross-functional team in its own location and held sessions to develop a “social contract” on how members from different disciplines would interact and how they wished to be treated. Using the new process on a first project — to create a new tool for aircraft maintenance-scheduling — the Navy completed a product that met all security requirements in just six months.

As with any culture change, corporate inertia can get in the way. That’s even truer when it involves melding three distinct cultures into one. But given the need to maintain the pace of innovation and improve security, it’s a challenge many companies can no longer postpone.