Shift It Right, Too?
July 09, 2019

Brook Schoenfield
IOActive

"Shift Left" has become an ever-present meme amongst DevOps and the security folk concerned about or working with DevOps. To "shift left" means to attend to something as early in development as possible, based on the assumption of left-to-right mapping of development activities.

Whether the activity is design, testing, or even operational activities, timeliness provides benefit. Obviously, the earlier we attend to security fixes, or really, any issues, the better.

Much data has been assembled about the benefits of finding and fixing bugs as early as possible; there should be little controversy about the efficacy of "shifting fixes left." At the heart of "shift left" is preparedness, planning, and appropriate timing of activities, all of which are signs of a mature development process. And, to my mind, these values are part of the DevOps revolution as teams break down artificial role boundaries and convert operational tasks into code.

Secure design's place has been at the "right side" of development, that is, early in the process, before designs are baked and it becomes too late to build security needs as a part of building software. Numerous Secure Development Life cycles (SDL or S-SDLC) and security standards explicitly place tasks like architecture risk assessment (ARA) and threat modeling early during development. This is not new: one of the first standards describing early security requirements is NIST 800-14, published in 1996! Though many organizations still struggle to identify security requirements early enough, there should be little doubt about the need to start designing security early in a development process. Importantly for this discussion, these critical design activities have typically been seen as right-side (early) only, or worse, single, point-in-time activities.

Experience, especially with iterative development approaches, has taught me that seeing design as only right-side (beginning), or worse, a point-in-time task is a mistake, as equally destructive as late-cycle security tests, or worse, identifying security needs after software has been built.

Once we start thinking iteratively, it becomes clear that point-in-time SDL tasks are more likely to gum up the works, to become an impediment because security isn't matching the way that software is built. Often, several development tasks are taking place in parallel. Among these will be:

■ Refine architecture

■ Specify design

■ Draft code

■ Test

■ Release software

■ Ongoing sustainment and operations

The above activities quite often all occur simultaneously. Each activity has particular security responsibilities which are best executed as a part of that portion of the work. Threat models must be refined as architecture is solidified; security requirements must be specified as part of designs; code is best checked for security errors as it's drafted; obviously, security is something that must be proved right along with everything else that's been implemented.

In fact, in my humble experience, allowing threat models to iterate leaves room for security requirements to improve just like the code is expected to improve through iterative development methods like Agile.

We might say, "shift secure design right," in comparison to "shift security left." But that doesn't really capture the spirit of iteration, continuous delivery, or DevOps, to my thinking.

Would it be more precise to say, "continuous security"? Thinking about security as a continuous process fits well with Continuous Integration/Continuous Delivery (CI/CD) and Agile models. Though, perhaps "continuous security" is less meme-worthy?

Let me at least point out the trouble that point-in-time threat models generate, particularly in the context of rapid or continuous development strategies. Too often, point-in-time security requirements that are never adjusted for subsequent learnings and changes result in requirements that have not, cannot, will never be implemented as specified. That's a loss for everyone involved.

If you prefer to say "shift left," then by all means, let secure design tasks "shift right" as well. I think of SDL security tasks as "continuous":

■ Give developers the tools they need to check code for coding mistakes.

■ Threat model throughout structure and design changes.

■ Have penetration testing prove security requirements and assumptions, enabling an organic feedback to revise requirements and assumptions.

Above all else, break down artificial role barriers that slow us down and obscure shared responsibilities.

Brook Schoenfield is Advisory Services Director at IOActive
Share this

Industry News

March 23, 2023

Ambassador Labs released Telepresence for Docker, designed to make it easy for developer teams to build, test and deliver apps at scale across Kubernetes.

March 23, 2023

Fermyon Technologies introduced Spin 1.0, a major new release of the serverless functions framework based on WebAssembly.

March 23, 2023

Torc announced the acquisition of coding performance measurement application Codealike to empower software developers with even more data that increases skills, job opportunities and enterprise value.

March 23, 2023

Progress announced a free online training and certification program for Progress® OpenEdge®, the flagship Progress application development platform.

March 22, 2023

Opsera announced five patents have been issued to enable enterprise engineering leaders and teams to gain unprecedented end-to-end visibility into their software delivery and accelerate the speed and security of delivery, all while maximizing their investment.

March 22, 2023

DuploCloud announced the general availability of its on-prem solution built on top of Kubernetes, focusing on containerized workloads with near term plans to integrate with on-prem compute, storage and networking vendors.

March 22, 2023

Postman announced the general availability of Postman Flows, a visual tool for creating API applications. Postman Flows simplifies building software by using APIs as the building blocks, allowing anyone to produce workflows, integrations, and automations in a collaborative environment without needing to write a single line of code.

March 22, 2023

SecureAuth announced an alliance partnership with HashiCorp®, enabling organizations to leverage SecureAuth’s advanced passwordless authentication and Multi-Factor Authentication (MFA) device recognition.

March 22, 2023

Backslash Security, a new cloud-native application security solution for enterprise AppSec teams, emerged from stealth.

March 21, 2023

OpenText launched the latest version of ValueEdge -- an innovative modular, cloud-based DevOps and value stream management (VSM) platform.

March 21, 2023

Oracle announced the availability of Java 20, the latest version of the programming language and development platform.

March 21, 2023

Rafay Systems introduced Environment Manager, a solution that empowers enterprise platform teams to improve the developer experience by delivering self-service capabilities for provisioning full-stack environments.

March 20, 2023

To meet the growing demand for Oracle Container Engine for Kubernetes (OKE) with global organizations, Oracle Cloud Infrastructure (OCI) is introducing new capabilities that can boost the reliability and efficiency of large-scale Kubernetes environments while simplifying operations and reducing costs.

March 20, 2023

Perforce Software joined the Amazon Web Services (AWS) Independent Software Vendor (ISV) Accelerate Program and listed its free Enhanced Studio Pack (ESP) in AWS Marketplace.

March 20, 2023

Aembit, an identity platform that lets DevOps and Security teams discover, manage, enforce, and audit access between federated workloads, announced its official launch alongside $16.6M in seed financing from cybersecurity specialist investors Ballistic Ventures and Ten Eleven Ventures.