Integrating Security in the DevOps Workflow: Must You Choose Between Time, Change and Efficiency?

Featured interview with  Manish Gupta, CEO and co-founder of ShiftLeft

Software and app development is moving at warp speed, thanks to the agile approach and role of DevOps. But security struggles to keep pace, as traditional physical and virtual perimeter solutions are not sufficient to address vulnerabilities in code that are being updated and deployed on a daily basis. As a result, DevOps must become more aware of security and rethink how they build it into their software at the code level.

In this Q&A, security industry veteran Manish Gupta discusses how organizations can change their behavior and mindset, bringing security in from the start of the software development process.

• Q. Why should DevOps even worry about security?

A. In the world of shrink-wrapped software, an enterprise would buy software from an independent software vendor (ISV) and deploy it in their data center. The IT team became responsible for the upkeep of the software and infrastructure that the application ran on and the security team, a part of IT team, took the responsibility of protecting the application.

For software as a service (SaaS) or cloud-deployed applications, the software belongs to the company (specifically the developers) and the DevOps team is responsible for deploying it. This implies that either DevOps or a subset of DevOps – DevSecOps perhaps – is responsible for protecting the software.

• Q. What are the best approaches or strategies for integrating security in the DevOps workflow, so that security fits into the fully automated CI/CD pipeline they have built for deploying applications?

A. Once the security ownership is clarified, the following important criteria emerge to enable successful integration of security into the DevOps workflow without impacting CI/CD:

– Agile CI/CD: For a majority of the companies, the speed of CI/CD is paramount, and security, while important, is secondary. In other words, security will fail if it tries to slow down CI/CD.

– Support of popular security tools, such as Jenkins, Circle CI, Travis, or Bamboo, for integration at build-time. These tools are generally used as the CI system of choice by DevOps practitioners.

– Workload distribution: One could be deploying their applications in AWS or Azure, containers or VMs. To avoid vendor lock-in, the security solution should be agnostic to the underlying infrastructure.

– Application is the attack surface: Traditional security products have focused on protecting the infrastructure. For example, firewalls focus on protecting the network and anti-virus protects the operating system. With the movement of software into the cloud, the IaaS/PaaS providers increasingly are responsible for protecting the network and the operating system. An organization, therefore, needs to focus on protecting their application, which is its key asset.

– Application focused, not threat focused: When the applications changed once or twice a year, we could treat them as a black-box and protect them against known threats. But now that applications are changing rapidly, a threat-only focused approach is reactive at best. Security should be customized to each application.

• Q. How does the use of open source components and frameworks in modern application development make it difficult to adopt sufficient security into the DevOps cycle?

A. Open source software and tools are viewed as delivering features with similar or better quality than existing commercial offerings, at near zero cost. Several OSS components (libraries and frameworks) have known vulnerabilities. Additionally, when an application uses an OSS component in a manner that it is not intended to, we open up the application to new unknown vulnerabilities that can be exploited. The DevOps workflow must be able to:

– identify whenever their application is using OSS with known vulnerabilities

– identify when the application is not using the OSS library for its intended purposes, which can cause security problems, and

– get runtime protection against the vulnerability if they are unable to upgrade to the new version of the library or fix the problem in their application.

• Q. How can security be integrated into the DevOps processes with minimal alert fatigue?

A. It is logical to say that trying to adapt off-the-shelf security solutions to today’s distributed and dynamic IT environment is not only humanly impossible, but also inundates DevOps and security professionals with false positives/alerts. The challenge of integrating security into DevOps process with minimal alert fatigue can only be solved when security is informed by first principles, such as the asset that you are trying to protect, which in this case is an application or microservice. This is the area of focus for ShiftLeft, which developed a solution that extracts the security relevant aspects from your application or microservice every time it changes and uses that to inform runtime protection (in production). We call this Security DNA and it results in much more precise security and, therefore, provides accurate alerts to the DevOps without false positives.

• Q. Does DevOps have to choose between change (implying speed) and security? Or can they achieve both?

A. A critical part of enabling DevOps to embrace speed and security is to integrate into the tools and processes they use. Integrating security transparently into build systems can aid in understanding the application, as well as with deployment in production without compromising on speed. ShiftLeft does exactly this – it combines the understanding of software from build-time into a runtime microagent to protect the application in production. And it can achieve this in five minutes or less for every new release of every application.

The DevOps teams must rethink how to secure their rapidly changing applications, since current security solutions were developed for monolithic applications that were upgraded once or twice a year. There is an opportunity to leverage the agility of modern CI/CD to enhance security by both getting accurate runtime protection and eliminating problems at the source code level.

Bio of Manish Gupta: Manish Gupta is the CEO and co-founder of ShiftLeft. Manish has overseen the growth of a number of security firms during critical periods. As chief product and strategy officer at cybersecurity firm FireEye, he expanded the company’s portfolio from two to more than 20 products and increased the company’s bookings tenfold. Before helping FireEye expand its offerings, Manish served as vice president of Product Management for Cisco’s $2 billion security portfolio. He also helped grow McAfee’s network security business as the vice president and general manager of the firm.