A Modern Shift-Left Security Approach

Source:-https://www.forbes.com

The concept of shifting security left is not new, but historically this has meant little more than inserting security processes in the middle of development and slowing everything down. In this article, I’ll describe older shift-left methods that have not worked — and how a modern approach to shifting left can have a high impact on risk reduction and create a healthy balance of freedom and responsibility for cloud-native development teams.

I believe CISOs have no choice but to embrace this industry change. They must enable development teams to move faster while simultaneously reducing the catastrophic risk of deploying broken infrastructure.

The DevOps Shift-Left

Traditionally, for an application developer, the infrastructure you needed was a server. So you would file a ticket, and someone from the ops team would create a VM instance or order a physical server. Some number of days, weeks or months later, the server would be delivered through a combination of ClickOps, scripts and manual processes.

Today, modern application developers are directly provisioning applications to the cloud by using cloud platforms like AWS, Google and Azure without any additional assistance from IT or platform teams. Developers release and update software on demand in the cloud using continuous integration and continuous deployment (CI/CD) for rapid software releases and updates.

ow using declarative Infrastructure as Code (IaC) — things like Terraform, CloudFormation, Kubernetes manifests, Helm Charts, etc. — to automate the provisioning of their cloud infrastructure. The code manages the resources for their applications — servers, databases, networks, logs, application deployment and configurations — and reduces the burden for IT, Ops and site reliability engineering (SRE) teams.

This has shifted DevOps left and allowed developers to provision their own infrastructure using software development practices such as writing, testing and executing code. If they want to make changes or tear down the infrastructure, they code it, test it and then deploy the changes.

Volumetric Rise In Attack Surface

The power and scale of modern software development cycles adds a new risk dimension to security. Software provisioned with IaC can go from developer laptops to clouds to customers in seconds.

The problem is that there is often little to no room for traditional security intervention in this development process. Rapid deployment of IaC by multiple developers of varying skill and experience levels means there’s a high chance for mistakes. These problems manifest at runtime, where security teams have good visibility with solutions that detect configuration problems. The problem is that by this point, these problems can be difficult and costly to fix.

Last generation’s shift-left security has been trying to shift left for years. You can try to catch vulnerabilities and misconfigurations before they are exploited to reduce the risk of breaches in production. You can run a static analysis of application code and dynamic analysis of live applications, generate reports, pummel your ticketing systems for remediation work, and curse at false positives. It’s a frustrating process that was designed to work in slow multistep release cycles with defined approval gates. It requires pauses between deploys to complete security scans, and then it requires time for remediation activity to catch up.

Inserting security into development has also traditionally meant hiring and deploying software security experts into development teams. These experts may be available for a plethora of tasks: “threat modeling” new architectures, defining security features, consulting on risk priority, training up security champions and such. All of these tasks are costly and time-intensive.

On top of this, in most organizations I’ve worked with, security is vastly outgunned in headcount. Large development teams (DevOps, SREs, developers) that are armed with CI/CD and IaC are unstoppable. I’d estimate that the current industry ratio sits around 1.5 security experts per 100 software engineers. This model simply does not scale when companies are confronting modern decentralized development. To quote Bilbo Baggins in The Lord of the Rings, “I feel thin, sort of stretched, like butter scraped over too much bread.”

The Modern Shift-Left Security Strategy

A modern shift-left approach shifts security responsibilities to those creating software, the developers, and it shifts it to the beginning of the process when the developers are provisioning infrastructure. By testing Terraform and CloudFormation for security before execution, just as they would test their application code for quality and reliability, developers can make any fixes before committing code to production — where it could affect customers and result in data loss.

This shift weaves security into the existing CI/CD processes. Developers should leverage APIs to integrate security solutions into the tools they already use while giving security teams visibility into what has been tested and fixed. If there are issues, the security team should track them back to dev owners and establish policies and templates so that they don’t repeat the same mistakes. This approach could finally help security make a significant impact on reducing risk for cloud-native software development. Development teams don’t have to experience security as “yet another tool” or as “yet another process” that slows things down. Security should become a key aspect of the development process and enable developers to ship secure, reliable solutions without thinking too hard.