Should you shift left or not?

Shifting left is now a popular trend in information security. Does that mean that you should hop on the bandwagon and tear your hair out just to shift your security left? No, it does not. Actually, in most cases, if you blindly jump on this bandwagon, you could be shooting yourself in the foot. Here’s why.

What is this shift left thing anyway?

Shift left is not a new term. It is not a web application security term. It is not even an information security term.

What shifting left applies to is, basically, finding all types of software defects as early as possible. This applies to information security or web application security vulnerabilities, but it may just as well mean business logic defects that have nothing to do with security.

Why this strange combination of words? Well, software development organization diagrams usually go from left to right, where on the left you have the earliest stages of development and on the right you have the release. Therefore, moving the testing phase towards the earlier stages is, on the diagram, synonymous with shifting a box from right to left.

The term was coined all the way back in 2001, just before Acunetix was born. It was first used in an article by Larry Smith in Dr. Dobb’s Journal. As Larry Smith wrote, “shift-left testing is how I refer to a better way of integrating the quality assurance (QA) and development parts of a software project.”

The ideology of shifting left goes very much in line with agile development practices. In the case of such methodologies, QA is included in the development process, not just pushed back to the later phases before release as in older methodologies such as the waterfall.

What does shifting left mean for you?

Let’s start by making one thing clear. If your business does not develop its own software but uses third-party software, shifting left does not apply to you in any way. If your web applications are just instances of, for example, WordPress or Magento, you have no way of shifting anything left. If your web presence is managed by a third party, you have no way of shifting anything left. If you work with an MSSP on your web app security, you also have no way of shifting anything left.

So, all in all, if there are no web developers in your company, you can stop reading this now and forget about this term completely.

If you’re still reading this, it is likely you have at least some web development going on. In that case, shifting left with web application security may apply to you, but that also depends on your work organization. Again, blindly jumping on the bandwagon may, instead of helping, actually create problems. That’s why you have to very carefully consider your particular situation, talk to a good consultant (like ours), and figure out the way forward.

The worst choice of words ever

The biggest problem with the term shift left is that it is very likely to be misunderstood. The word shift means to move or cause to move from one place to another, especially over a small distance. Therefore, shifting left means removing testing from later phases.

Instead of the term shift left, we should be using the term expand left! Otherwise, many people in their excitement to follow the trend will actually take their security efforts away from staging environments and attempt to do everything at the earliest possible stages. And that is a horrid mistake.

It is also a mistake that is actually encouraged and advantageous for vendors of solutions, which only work in the early stages, for example, SAST tools. A SAST tool cannot be used in later stages (unlike a DAST tool which can) because it deals with source code or precompiled code only. If you misunderstand the term shift left you may actually think that scanning your web apps with a SAST tool will be enough for their security. Well, it won’t.

Be just as careful with shifting right

The term shifting right was coined to counter the misunderstanding of the term shift left but it is also apt to be misunderstood. Before any shifting, testing is performed in staging environments (which are on the right side of diagrams). Therefore, if we shift left and shift right from the original position of testing (already on the right), we get testing in early development and testing in production (which is to the right of staging). This means no tests in staging remain!

Also consider the fact that while our software is absolutely able to test an application in production, you should very carefully review potential consequences. Sure, our applications perform tests in a harmless way, but the testing can be very intense and have side effects, which may include accidental denial of service, email flood, and more. Unless you are aware and ready to mitigate such side effects, testing in a live production environment may actually be more harmful than not testing at all.

Don’t misunderstand me, testing in production is great if done the right way and very carefully trialed before with proper mitigation and awareness. Just as shifting left, expanding right is just something that should not just be blindly followed!

Expand left, keep right!

So here’s my global call (hey, worth a try) to stop using the term shift left and substitute it with the term expand left. Or, at least, always accompany the term shift left with keep right. Same with the term shift right (for production testing): let’s try using expand right instead.

To be sure that you have your web application security covered, there is no way in the world that you can skip the last stage of testing when everything is in a staging environment. After all, it is only here that you have time to do additional manual penetration tests to uncover vulnerabilities that automated tools cannot find.

I would even go further. Unless your main business is software development and you represent a larger organization, consider staying where you are with your security testing stage. Of course, you can add Acunetix scans to the early stages of development (we fully support this with integrations), but make sure to keep the late-stage scans and complement them with manual penetration testing. Otherwise, you risk leaving a gaping hole in your web application security.