In an industry full of acronyms and buzz words, the term “shift left” surfaced as a result of organizations waiting to perform software security
testing until the end of the development process
. The problem here is that the industry still tends to think of developing, testing, and delivering software as if someone was reading a book in English, from left to right. If you’re testing your software to detect security vulnerabilities
near the end of the process (on the right), the recommendation is to “shift your testing farther to the left” and perform security
testing sooner within the development process
itself. However shift left makes very little sense overall, since DevOps
is not linear like the Waterfall software development
as depicted in the figure below.
really doesn’t have left or right in comparison to the more-linear processes used in the past. Sure, Dev is on the left and Ops is on the right, but DevOps
is more like a figure-8 infinity loop that has no beginning and no end. The Dev process
never stops and the Ops process
never stops as well. If someone were to shift left in the figure above, where is “left”?
A better recommendation would be to shift center
and add application
security testing solutions throughout the entire Dev process
. Here is an analogy that may help make better sense of the notion of shift left and why it really doesn’t fit in DevOps
Linear vs. Circular – An Analogy That Should Help
When you’re riding on a train and someone wants to get on or off the train, what does the train do? The train stops, passengers get on, and passengers get off. Then the train starts to move slowly, eventually gaining speed, only to do the same thing farther down the track. This is definitely not the way we want to add software security
testing solutions to our DevOps
initiatives, since it would most likely be a disaster. The whole point of Continuous Integration and Continuous Delivery (CI/CD) is that the “train” is never supposed to stop. Instead let’s look at a better analogy that may hint of a new method of adding security
into DevOps processes.
The London Eye
is one of the world’s tallest Ferris wheels. The interesting part about the London Eye is that when it’s open and running, the Ferris wheel never stops to on-board or off-board passengers. People get on, people get off, but the wheel continues without hesitation. No one on the ride knows when someone gets on, or when someone gets off the other “pods”, since from their perspective there’s no impact to their own ride experience. This is the way organizations need to think about adding software security
environments—in a way that never stops the development and delivery processes. New software initiatives get on the “wheel” on the left so to speak, while old software initiatives are retired on the right, effectively jumping off the ride altogether.
Another interesting concept concerning the figure above is that there are two “wheels” shown. The one on the left is Dev and the one on the right is Ops. As new business requirements drive new software initiatives, the Dev process goes from Design, Code, Check-in, Build, and Test/QA. Then the software moves
to Ops through the Deploy, Operate, and Monitor processes. Interestingly enough, at the point where the two wheels intersect, the software moves from one wheel to the other wheel, without stopping the wheels and hopefully without invoking any delays. A simple analogy would be two London Eye Ferris wheels, built next to each other, with an intersection point between the two of them. Passengers move from the wheel on the left to the wheel on the right, moving from pod to pod, with no delays, no stops, and without ever leaving either of the two rides.
The whole point of this discussion was to somewhat refute the notion of shift left, since it makes little sense when observing the double-helix, infinity loop represented by the figure above. There really is no “left” in DevOps
. Therefore, how should organizations embed security
within the Dev “wheel” on the left? Downloading and reading An Integrated Approach to Embedding Security into DevOps
is a great place to start.
fully demonstrates how organizations can shift center, and add software security
throughout the entire Dev process