Secrets of ‘shift left’ success

When Delphix moved from selling only packaged software to also developing new Software-as-a-Service solutions, it found something lacking in the DevOps principles it had been following for years.

Company leaders noticed the absence of security and thought it, too, should be included in processes alongside development and operations.

So, as it moved into SaaS products about a year ago, the company decided to incorporate the security function into the development cycle and to embed it within the earliest stages.

“That changes how we build and deploy our software,” says Delphix CTO Eric Schrock. “When someone now wants to change code, there have been changes to how we review it and how we assess it for its security.”

Delphix is following the shift left movement, which advocates for bringing both security considerations and security expertise into the software development process earlier rather than leaving it to the final stages as had been the common practice for decades.

To make that work, Delphix is implementing DevSecOps, building on its DevOps practice by hiring new security professionals to work with its existing SaaS team and adding security tools and automation into the early development phases.

Rise of a movement

Both software vendors and enterprise IT departments have made security a priority. Consider, for instance, that Gartner Inc. is predicting that enterprise security spending will total $96.3 billion in 2018, up 8 percent from the 2017 figure – a rise it attributes to a growing awareness of emerging threats as well as increased regulation and the evolution of digital business.

Yet in many places cybersecurity remains a standalone function, where security concerns are considered as the last step in a software development or implementation project and where security measures are “bolted on” once all the other development work has been done.

The shift left movement is a reaction to that. Depicting software development as a linear process, the movement professes the belief that putting security on the left side of that line (i.e., earlier in the development cycle) produces a more secure product at a lower cost.

“People are paying more attention to the fact that, besides having to set up defenses around software after you deploy, they should develop secure software to begin with. And there are various places where they may want to integrate security measures in the development lifecycle and, inside of that, where they can continue to shift left,” says Rami Sass, co-founder and CEO of WhiteSource, an open source license management and security solution.

The need for this has been a long-time coming, says Frank Kim, a senior instructor at the SANS Institute, the founder of the security consulting and CISO advisory firm ThinkSec and a former cybersecurity executive.

He notes that technologists for years have known that “software was being built with bugs and vulnerabilities.” The typical process, though, had developers pushing those problems through to the quality assurance (QA) and the security teams to solve.

But an evolution in software development thinking – from Microsoft’s 2002 Trustworthy Computing Initiative to the emergence of agile methodologies to the growing use of automated testing software – has prompted leaders to rethink their siloed approach to security.

At the same time, however, agile methodologies, DevOps and automation along with competitive market dynamics enabled, encouraged and even demanded that IT teams deliver new software faster, Kim says.

As such, development teams and the business people whom they served chafed at the idea of slowing the production process by stopping it for drawn-out security reviews – no matter how much the security check was needed.

Shift left, Kim says, addresses both the security needs and the desire for speed.

Reducing friction

Moreover, security professionals welcomed this push to include them earlier in the process, as they too see earlier inclusion as producing more secure products more quickly.

“As a result, a lot of people are seeing the need for this security shift to the left,” Kim adds, explaining that shift left is more of the mantra with DevSecOps being a particular methodology to make that happen.

“The idea is very simple: Reduce the time it takes for software to reach production. It’s part of the digital transformation that organizations are making to be faster and more agile,” says Sharon Besser, vice president of product at GuardiCore, a software security vendor who uses the DevSecOps approach for its own product development.

He adds: “To delay production for a security review simply does not work anymore.”

Besser says developers at GuardiCore now have a level of responsibility for security. As such, they leverage automated testing tools with built-in security policies and take ownership of tasks like patching. They’ve also learned to be accountable for security and not think of it as someone else’s problem.

“In the old world, security things were addressed not just in a different order but in a different department,” Besser explains. “Now the developer is thinking about the code he’s creating, so if he’s using something like an open source component, he now is the person responsible to constantly check for newer versions and releases. He needs to verify that whatever was changed will still work. And because the developer is the person who needs to verify things, and because he’s closer to the code, the verification process is faster.”

Delphix has taken a similar approach. Colin Rand, the company’s vice president of engineering for cloud products, came onboard in part to implement DevSecOps as Delphix launched its SaaS offerings.

“The status quo would have been a dedicated security team who handled a distinct step at the end of process. It introduced a lot of friction into the process, and compromises had to be made late in the process,” Rand says, echoing a common complaint in organizations where security issues are addressed toward the end of the development cycle. “So we evaluated all the practices that were going on and shifted security all the way to the left.”

That meant hiring a security architect and making that position and QA professionals part of the full-stack engineering team. It meant training engineers on secure coding practices and code review processes. And it also meant including automated testing tools such as static code analysis and dynamic analysis technologies as part of the team’s toolkit.

Using such technologies, Rand says engineers start to find vulnerabilities on their own.

Rand says that does not suggest, however, that dedicated security professionals aren’t needed. He says security experts continue to play a vital role in helping other team members understand security issues.

“You need someone there to say, ‘These are the critical issues to address before you push this software to the next step,’” he explains.

There are clear benefits for moving security earlier into the development process and, in the case of enterprise IT bringing in and customizing solutions, earlier into the adoption and implementation cycle, experts say.

“Cost is at the highest point when security is at the end,” says Daniel Kennedy, research Director for Information Security for 451 Research’s Voice of the Enterprise (VoTE) quantitative research product. But if security issues are caught earlier in the process, when they can be more quickly addressed and changes can be more easily made, the costs are much less. Moreover, he says, the end results are generally better, meaning a more robust security posture overall for less money.

Application security tools shift left too

More and more technologists are noticing that ROI. 451 Research’s VoTE Vendor Evaluations 2017 research found that 30.5 percent of application security tools are allocated to application development vs. 16.6 percent in QA, 44.7 percent in information security and 8.1 percent in “other.”

Although the percentage of security tools found in application development is significantly less than in the information security function, it’s important to note that the numbers look very different than they did two years ago.

The portion of application security tools found in application development has grown from 22.7 percent in 2015 to 27.6 percent in 2016 to 30.5 percent in 2017.

Meanwhile, the portion of application security tools found in information security shrank from 57.3 percent in 2015 to 46.2 percent in 2016 to 44.7 percent in 2017.

As Kennedy says: “People are moving left in the process. The word is out. But there’s room for improvement, no question about it.”

Obstacles ahead

Like any other process or workplace change, adoption of shift left ideas as well as DevSecOps does take time. And adoption comes with challenges.

Kennedy and other experts list typical obstacles.

Developers on a whole don’t learn secure coding practices, so enterprises need to train them. Companies typically need to bring in more automated security technologies to support shift left and identify the appropriate points to insert them in the development cycle. And developers, security experts and QA professionals must learn to work together as a team.

At the same time, companies of all kinds continue to struggle with finding the skilled security workers they need in a labor market where demand far exceeds supply.

Experts say it takes all these factors to come together to enable shift left ideas to deliver ROIs.

“It’s not just putting security into the loop earlier, it also requires the culture to support it and the tools to enable,” Kim says. “It’s not just about finding those security issues, but weeding out the false positives and finding the high value items and working together to do so.”