“Shifting security left” is not a new concept and is one that many technologists understand at a high level. It means implementing security policies and controls at early stages of the software development process and not just when apps go into production. Shifting security left requires your application developers and DevOps teams to consider security an integral part of their apps and processes (and in particular to test it at all phases of the CI/CD pipeline), and as a result fundamentally strengthens the security of your apps when they reach production.
Despite the agreement on what shifting left means, controversy arises when the conversation turns to which tools and approaches are best suited to the task. Much of the public discussion focuses on tools for code scanning and automated patching, or on new security tools designed specifically for modern applications and infrastructure. Often ignored are tools such as web application firewall (WAF) that have long been used to enforce run‑time security policies in both test and in production environments. Why is that? Do legacy security tools really not have a place in today’s enterprise? Not so – the need to protect enterprise applications from targeted and always‑evolving attacks is greater than ever, and requires a multi‑layered approach.
Has Shifting Left Increased the Divide Between Security and DevOps?
Before digging deeper into the details, let’s ask an even more basic question: if shifting security left is the right thing to do, why haven’t we always done it? It has to do with how enterprises usually manage their traditional apps and infrastructure: centrally, by a NetOps, IT, or Infrastructure & Operations team. Under that model it makes sense to consolidate security enforcement at the edge of the infrastructure – also centrally managed – that applications are deployed on.
When modern enterprises start to embrace digital transformation to become more efficient and agile, however, things tend to decentralize. Application development decentralizes across multiple teams, the underlying infrastructure for the applications decentralizes, operations decentralize (and shift left), and the applications themselves decentralize into a collection of services, endpoints, and devices which interact via APIs over the network. All of these components are often managed by Dev and DevOps teams, outside the scope of traditional and centralized infrastructure teams.
This decentralization has led some to argue for making security more application‑centric and inserting it earlier in the development process, because there’s no longer a centralized gatekeeper at the edge to rely on. Unfortunately, the decentralization has led to significant friction between Dev and DevOps teams on one side and Security teams on the other.
What is the source of this friction? Much of it is because transformation has not been happening at the same pace across all teams. Security’s playing field has morphed from a well‑understood application perimeter surrounding a single data center to a very large and hard-to-define attack surface made up of modern application workloads running in multiple locations, communicating with each other across networks (often public), and pulling data from devices and users all over the globe.
Shifting security left also dramatically broadens the circle of people Security must interact with – many of them with limited security expertise – while Security itself hasn’t necessarily been given the budget to grow. Adding to the challenge is the fact that many of the legacy tools familiar to Security teams have not fully embraced the shift‑left concept, leaving the teams no choice but to try inserting them into the pipeline even though they’re not designed for automation and modern infrastructures. The tools don’t generally don’t provide self‑service, either, so Dev and DevOps – mandated with moving fast but forced to wait for Security to implement policy changes – view security as a speed bump and often try to find a way around it, resorting to the dreaded “shadow IT.”
Help Bridge the Divide between DevOps and Security with the Right Security Tools
Getting back to the original question, is there a role for security tools such as WAF in the shift‑left story? The answer is a resounding yes. As mentioned above, you need a way to protect your apps and APIs from targeted attacks as well as ensure your applications meet your risk management and compliance requirements.
But to be effective the WAF itself needs to evolve and shift left. A lightweight WAF that deploys easily into multiple environments and is optimized for modern infrastructure and modern pipelines enables you to stress‑test the efficacy of your security policies during the build and functional testing phases of application components and APIs, before the applications are running in a run‑time environment. The key is to find a WAF that automates security configuration and policies so you can provision it within your pipeline. You are never going to have enough security people on staff, so automation is always your friend in a decentralized environment.
Shift Left Successfully with the Right Tools and Guardrails in Place
Finding the right WAF and shifting it left is just part of the story, however. There’s friction among teams in a modernizing enterprise not just because security controls and processes are outdated, but because of how security mechanisms that meet the needs of the enterprise are delivered to Dev and DevOps. An analogy that works well is that Security needs to build guardrails, not gates, into development processes and pipelines.
Too often security is interrupt‑driven, with Security teams insisting that development comes to a halt while they audit and evaluate the security policies and processes. Dev and DevOps are much happier when Security provides the type of guidance that allows development to continue while ensuring it happens in a secure manner. In other words, security itself becomes as ‘continuous’ as the other parts of your CI/CD pipeline.
One way to achieve this is picking security tools that can be inserted into the pipeline as code. But it also requires that Security teams change how they think of security procedures for increasingly decentralized and distributed applications. Security procedures themselves need to evolve, become much more application‑centric, and shift left in response to all kinds of factors, ranging from the audience for the application, how the application is built, which environments the application is deployed to, and standard compliance requirements.
A control plane for orchestrating security across a wide range of applications can really add value in such an environment. It makes it easy for Security to set appropriate security guidelines that are then matched to the underlying applications based on parameters set by Security. Setting guardrails enables Security, Dev, and DevOps to work together with minimal interaction or interruption. This is an evolving space as control planes shift to become more application‑centric, with many different approaches emerging.
For a broader look at how the application security landscape is changing and what you can do to adapt, download our free O’Reilly eBook, Web Application Security.