Bionic Uncensored Ep #4

Shift Left is Not Perfect

Shift left is not perfect. 

A lot of people use the term, “shift security left” because they believe that you must shift security left in order to save money. But is pushing everything to the left in your software development life cycle, your development process, your DevOps process, the way to go? 

If you look at the DevOps process, an infinity loop or a bow tie, it’s constantly moving, it’s constantly changing. There are constantly things happening at every step, whether it’s a black, or blue, or green specific area on this DevOps loop.

Thinking about the concept of shift left, where would shift left be in this?

Software development today is typically a living breathing thing, it’s constantly moving, it’s constantly changing, and it’s not one step after the other. It’s not something that needs to happen for the next thing that happened, it’s constantly iterating.

Where is left on this? How can you shift security left? Think about that for a second. Is there a place where it is left?

But the application itself is made up of a lot of different pieces. When we’re talking about the app itself, we’re talking about custom code, frameworks, third-party libraries, open-source libraries, APIs, and the database. All these things are working together to provide a functioning application that lives on the infrastructure.

But everyone’s response to that is, “Oh, there are tons of application security testing tools out there.”

Remediation = "Left"

Thinking about the next step in the process is yes, left is still important because in my world left is the place that you actually perform remediation. Remediation is the fixing of these identified security issues. 

It doesn’t matter if you’ve done that through manual code reviews, or an automated scanner of some sort, or architectural review. There are risks that need remediation, remediation is done on the left. 

Where is Identification?

However, if you’re really thinking about it, and I’m gonna use the glass board here, identification of risk is done everywhere. I really believe that the best place to do identification of risk is part of that CI/CD process that’s releasing the software. 

The reason why is you’re looking at the artifacts of the application itself. If they’re being released, and built, and pushed to a production environment, they are actually parts of the holistic application. 

Component vs Holistic

If you’re looking at the left, you’re only getting the context of the components of what the developer’s looking at.

If you’re performing testing only on the left, you’re only finding a very narrow lens of risk. If you’re holistically looking at the whole process, the left, the middle, and the right, especially that CI/CD process of all the artifacts of the application, then you’re identifying holistic risk, and then you can push that risk to the left for remediation.

Bionic - Understand the Holistic Picture

Again, there are two variables that we’re really talking about and that’s remediation and identification. And the left is not representative of those. The left is just usually depicted as the developer working on the code itself.

We need to shift things up to really focus on how to not only identify risk but make your apps more secure by understanding the holistic picture.

See for yourself

Visualize every architecture drift, security risk, and compliance violation that each code change introduces, in real-time.