Shift Security Left: Solving the Challenges of DevSecOps

Identify and correct problems sooner, rather than later: That’s the heart of the “shift left” slogan. But to do so with security — to cultivate not just DevOps, but DevSecOps — is one of application development’s thornier problems.

Here are a few ideas to help your team shift security work left effectively.

Challenges: Span, Incentives, Openness

It helps first to understand what can go wrong. DevOps has been a success largely because, left to themselves, development and operations teams too often optimize for partial goals that inadequately serve businesses and their customers. Putting them together has improved software development lifecycle (SDLC) reliability and quality.

So if DevOps is good, then DevSecOps must be even better, right? Not necessarily. Cultivating workers who simultaneously juggle development and operations perspectives is difficult. To go from these two perspectives to three, though, with the inclusion of security, isn’t 50% harder; it’s more like three times as hard. One index of that difficulty: Hysn Technologies Inc reports that the entry salary for beginning DevSecOps employees in the US is $119,080 annually.

Moreover, a span that includes security also introduces real cultural strain. DevOps workers are accustomed to thinking of what they do in terms of positive actions: They construct features, they raise performance, they fix bugs, and so on. Security is frequently about what does not happen. To prevent hostile actions is so different from building new features that quite a few DevOps employees are never able to make the transition. Even when they can do the work of identifying and patching vulnerabilities, say, many are never able to negotiate their value within an organization the way they can carry on conversations and make plans about positive features.

Another cultural difference of security work is its infinitude. DevOps recognizes the need for continuous learning: New tools, frameworks and libraries emerge daily. Still, when a particular implementation accurately fulfills a specific collection of requirements, DevOps workers know they can relax, at least temporarily. A program without bugs and with the right functionality is good enough. Security doesn’t have such clear limits. Security is more open-ended. Security never gets to as clear-cut a stopping point.

Payoff: Faster Delivery, Fewer Vulnerabilities

If we can overcome these difficulties, though — if an organization nurtures a team that thinks in simultaneous terms of development and operations and security — the potential payoffs are large. To identify and solve security problems as early as possible promises to slash their cost of repair by a factor perhaps as large as 15, accelerate the speed of delivery to customers, and protect the organization and its customers from the alarming costs of security vulnerabilities. DevSecOps is expensive, but less so than the alternatives.

How does an organization win these benefits? Start with mindset and attitude. Practice continuous delivery. Allow and encourage the whole team to be accountable for security. Align product, development and security to be equally cloud-native.

With the whole team aspiring to the same consolidated achievement of continuously delivered, high-quality, secure software, appropriate technical milestones include automated left-shifted security scans, training in security topics for those coming from a DevOps background, and explicit attention in product plans to security expectations.

Opportunities for leadership will abound. When someone in a daily standup raises concern about how authentication functions, for example, the group response defines the organization’s long-term security prospects. Does the team as a whole believe something closer to “That’s a security problem; we can return to that after you finish coding the functionality,” or “Thanks for spotting that problem. Let’s get help in and make sure we thoroughly settle the security questions before they have a chance to impact the rest of the software”?

An attitude like the former means that the team isn’t ready for true DevSecOps yet. It’s not in a position to pay the costs or gain the advantages.

Conclusion

DevSecOps, like agile, is more about culture than processes or tools. Certainly different individual contributors will have more or less background in the development or security or operations legs of DevSecOps. For DevSecOps to work, though, the entire team, from marketing and product through to QA, needs to share the attitude that software is not just a bundle of features, but a trustworthy software construction.

Build in security from the beginning. Take security problems as seriously as visual designs, lookup algorithms or scalability measurements. Support the team in the effort not only to get security right from the beginning, but to continue learning how to get security right and to obtain the tools to support correctness.

Purchasing and installing left-shifted security tools is easy once the right culture is in place.