DevSecOps Isn’t Sexy but among the Key Tools to Strengthen Cybersecurity

The persistent quest to improve enterprise cybersecurity commonly sparks a host of big-picture topics. Among other things, there is the desire to ramp up cybersecurity analytics and the growing movement in corporate boardrooms to improve oversight of cybersecurity strategy.

There is also the ongoing need to find more qualified cyber-pros, and, where practical, the desire among some forward-looking companies to embrace at least a taste of cutting-edge cybersecurity technology, such as homomorphic encryption.

Less known but at least as important today as any of these themes is the admittedly unsexy topic of cybersecurity software development. It has begun changing for the better—almost certainly much better—because of the growing trend to merge security code into the design and development of application software and attendant IT operations from the get-go.

The trend is called DevSecOps—short for development, security and operations—and its mantra is to make everyone accountable for security with the objective of implementing security decisions and actions at the same scale and speed as development and operations decisions and actions. This replaces the imperfect practice of bolting security onto other software code after it has already been developed, which tends to foster security gaps.

Some proponents of this new approach, which is a technological mindset as much as anything else, sagely contend that ignoring security issues in the software design and production stages—when it is easier to get it right and/or fix—is akin to trying to push water uphill with a rake.

Sponsorships Available

Sponsorships Available

Sponsorships Available

The momentum for change is unmistakable, as reflected by aggressive moves to embrace DevSecOps among substantial companies and entities, such as online payments company PayPal, shipping giant Maersk, the U.S. Food and Drug Administration and the National Institute of Allergy and Infectious Diseases. 

If nothing else, it’s a good way to boost educational attainment in the IT world. At least that’s the way Christopher Kiem, senior IT project manager at the FDA, sees things. “We want our operations talent to provide security insights and guidance to our developers in what we hope will become a loop of continuous conversation in which everyone is learning from each other,” Kiem recently said publicly.

Things seldom improve without substantial effort, however, and DevSecOps represents a radical change in enterprise culture. So it can be difficult to embrace.

Security pros, for the most part, are accustomed to a markedly different rhythm and cadence. A typical security organization, for example, might need several days to do a complete static and dynamic analysis on a code that needs to be deployed. Software developers, on the other hand, are high speed-driven to meet project deadlines and get to market rapidly in a highly competitive environment.

To be sure, not everybody in the software development and IT infrastructure world believes that the push to DevSecOps is a good thing.

One of their arguments is that infrastructure integration and the way business is done in general has radically changed in today’s digital world. They say that this requires that software developers and IT operations managers continue to stay separate from security software pros to keep better abreast of their ever-widening and already increasingly difficult specialty. Making their field even more complicated, they add, is the movement toward a multitude of smaller applications and heightened integration with clients and other business partners.

But change, as always, is winning, spurred by the enormous pressure to improve data security.

You need look no further than at cyber-breaches regularly in the headlines—a nagging reminder that pretty much no matter what is done, there is a continuing inability to deliver software without vulnerabilities. This, unfortunately, is a longstanding issue, fueled by constant iteration among cyberattackers and mediocre enterprise practices and policies that have built up over decades. Corporate victims this year alone already include Nintendo, MGM Resorts, Estée Lauder, Carnival Cruise Lines, Marriott International and web hosting site GoDaddy.

As a mindset, more than a formal set of rules and tools, it can be challenging to cite some of the distinguishing characteristics of DevSecOps. But it does incorporate lots of automation, and this, in particular, stands out. Here are a few examples:

+ Automated operations security. Because visibility into operations security can be limited, security-as-code is probably more effective. New techniques in public cloud infrastructure and elsewhere make it possible to reliably and consistently audit security and compliance with less effort.

+ Operations engineering. It can take humans hours or even days to detect an intrusion and take action. In secure infrastructure-as-code environments, response capabilities can instantly redirect data traffic, freeze nodes for later inspection and notify system operators—all automatically.

+ Security at the source. The self-service security capabilities of DevSecOps can find cyber-vulnerabilities early in the application development cycle, reducing the need for rework. Cyber-pros then provide appropriate feedback.

+ Open collaboration on shared objectives. This trait, notably, is not automated, and yet among the greatest strengths of DevSecOps. It creates shared expectations and metrics for measuring success, based on business priorities.

In addition to the strengths of DevSecOps, it’s important to be mindful of myths surrounding the methodology. One is the premise that you might need to recruit certain people with magical coding skills. Unless you cannot train your existing staff, this simply isn’t so. DevSecOps aims to break down silos of expertise—not dismiss the expertise of their efforts.

Also, contrary to some opinions, DevSecOps cannot replace popular “Agile” software development, a host of techniques to enhance software development. DevSecOps complements Agile; it doesn’t act as a substitute. Like DevSecOps, Agile fosters collaboration and constant feedback, but unlike DevSecOps doesn’t cover software delivery through testing.

Last, ignore a less common but truly baseless myth that you can buy DevSecOps. Flat out, this is false. You can only buy tools used to implement it.

In a nutshell, embracing DevSecOps offers a lot of advantages over not doing so, not the least of which is that it places a much higher priority on security at a time when it’s becoming the top IT priority at a growing number of enterprises. DevSecOps identifies vulnerabilities at a very early stage in the product development pipeline, making it far easier to fix, and also enhances threat-hunting capabilities.

This is big stuff, and for an eminently predictable reason. Like never before, the more secure a product, the easier it is to sell.