No, we’re not talking about politics or the dance that’s been done at every wedding reception in the last decade. In a traditional software development model, requirements are kept on the left side of the plan while delivery into production and operations are on the right. Shift Left security is simply building security into an organization’s DevOps process or designing security controls earlier in the software development lifecycle so that security doesn’t become an afterthought. In other words, move security to the left side of the plan. This increases quality and makes the DevOps process more efficient. Teams can identify and respond to issues more quickly than spending months developing, only to find out there’s a security problem that requires redesign. This is a bit of a conceptual change for many security teams, putting security in the middle of development, building tests to be automated and run alongside traditional unit testing and integration tests.
What is the DevOps Lifecycle?
We find that many clients are not familiar with this lifecycle and a poll we conducted in a recent webinar we held on this topic reflected that trend. Half of the audience felt they were only “somewhat familiar” while nearly 20 percent said, “what’s DevOps?” So, we start with the foundation.
This chart outlines the steps we believe are needed for the Shift Left DevOps lifecycle, along with common tools for each step, although there are several tools organizations can choose from. Beginning with code, we follow the lifecycle through deployment to operation and monitoring. Automation of this process enables continuous integration and deployment.
The Shift Left Approach and Cloud
In a Shift Left approach, the focus is on the first four stages of the DevOps lifecycle: code, build, test and release. From a Shift Left perspective, the idea for doing security in this stage is to perform security checks in the code repositories themselves, look for key issues related to very common security vulnerabilities in code, such as injections or misconfigured code. We like to think of building these checks into the developer IDE as kind of a “spell checker” for security – as code is written, the static code scans are taking place simultaneously. As mentioned above, issues can be identified and resolved while the developer is writing the code in the IDE, making the process more efficient and security more ‘top of mind.’
What about Shift Left security in the cloud? We looked at common cloud architectures and defined the right side of the equation to show the value of a Shift Left security model. Those include:
- Infrastructure as a Service (IaaS) – the most common architecture; highly customizable but less responsibility for the cloud provider
- Platform as a Service (PaaS) – the cloud provider manages the platform. The client simply deploys data or code to the service and configures it
- Containers as a Service (CaaS) – Using a container engine to create applications that are independent of each other. Complexities of container-based environments can increase risk
- Functions as a Service (FaaS) – This option is serverless – a very highly managed option as the cloud provider manages all infrastructure and the client provides the code to execute
As we move from IaaS to FaaS and think about shifting left, we consider customizability vs. manageability. The left side is much more customizable, the right side is much more manageable. With a high level of customization comes the likelihood of introducing more vulnerabilities.
Who’s Responsible for Security?
Clients often misunderstand who will be responsible for security in the various types of architectures. Generally, we say, ‘what you create, you secure.’ Organizations should always think of themselves for being responsible for security in the cloud. Regardless of the type of architecture, anytime the organization interacts with the software will impact the responsibility level. A simple way to look at it is illustrated below. The customer (organization) is responsible for security ‘in’ the cloud while the provider (here, AWS as an example) is responsible for security ‘of’ the cloud. The provider is responsible for the network, but once the organization creates its virtual system on that infrastructure, the client owns the security of that infrastructure. It is very important to understand that delineation.
Over time, we have learned that the DevOps and security teams need to work cohesively to make a Shift Left approach work for the organization. Best case scenario, security and DevOps operate as one team. Everyone is focused on the same mission: a secure product that’s embraced by the end users. Shift left empowers the organization to reduce risk and accelerate the speed to market. It’s not just a technology shift – it’s a process and cultural change. Shift Left is a new way to help mitigate risk and drive value for the business.
We recently presented a webinar detailing the Shift Left approach. To view that webinar, click here.
