What Executives Should Know About Shift-Left Security

What Does Shift-Left Security (Really) Mean?

The term “shift left” is a reference to the Software Development Lifecycle (SDLC) that describes the phases of the process developers follow to create an application. Often, this lifecycle is depicted as a horizontal timeline with the conceptual and coding phases “starting” the cycle on the left side, so to move any process earlier in the cycle is to shift it left. “Shift-left security” is the concept that security measures, focus areas, and implications should occur further to the left—or earlier—in the lifecycle than the typical phases that used to be entry points for security testing and protections.

How Did the Term Shift-Left Security Originate?

Shift-left security spawned from a broader area of focus known as shift-left testing. The term was first coined by Larry Smith in 2001. Since then, the concept of shift-left security has continued to gain traction as organizations’ reliance on the cloud has grown and as higher-profile cyberattacks increasingly target development tools and pipelines for apps that are cloud-delivered and/or SaaS.

Why Is Shift-Left Security Important in Cybersecurity?

Simply stated, while the advancements of cloud services for developer and product teams provide incredible speed and breadth in delivering applications, it has also led to some extreme challenges in maintaining regulation and control. Security needs to keep up with the fast-paced growth and agility of development cycles and be flexible enough to support a broad array of cloud-delivered solutions. The only common denominator in these new development workflows is the code that underlies everything from application to infrastructure is open and manipulatable to the development teams. As such, bringing security all the way “left” to the coding phase wraps security around the source of what malicious actors attempt to attack, leading to the greatest reduction in risk of exploits possible.

What Is the Spin Around This Shift-Left Security Buzzword?

Like many cybersecurity buzzwords, many vendors treat shift-left security as “the only thing you need to be secure,” as if it were a panacea to security issues when in reality, this breaks the idea of Zero Trust as you would be implicitly trusting the developer/s and their coding abilities. Also, there is a distinct lack of consistent understanding and standard practice for how application development should work in a modern DevOps department—such as code supply chain (open source packages and drift) or integration tools (Git, CI/CD, etc.). This creates risks. For example, if an organization believes, “Our data storage is freely open to everyone on the internet, but that’s not an issue because all the data is stored in an encrypted format,” this belief allows attackers to simply make a copy of the data and then work to either brute force the decryption, or look for the keys in whatever storage place they happen to be.

What Executives Should Consider When Adopting Shift-Left Security

Shifting security left in your SDLC program is a priority that executives should be giving their focus to. The pervasive reach given to development teams to not only create business-critical applications via code but also to handle every step, from coding the application to its compilation, testing, and infrastructure needs with additional code, is an extraordinary amount of control and influence for a department that is singularly focused. Extending security into all the workflows that development teams are moving into is the core ideology of shift-left security. However, it would be exceptionally risky to abandon or discredit the security programs that remain in the later or “right-side” stages of the lifecycle. Security needs to be wrapped around the entire lifecycle, from building the code to staging the surrounding deployment to, ultimately, the application and environment handling it.

Here are some questions to ask your team for a successful shift-left security adoption:

• How can we envelop all of the phases of our SDLC into our security program without creating a massive overhead of new tools to learn for each step covered? • How do we enable our development team to correct simple security mistakes without delaying or blocking their ability to release critical applications and updates?
• We must integrate into the tools and workflows that our development uses to code, aggregate, test, and deploy. How do we accomplish this while still meeting the needs listed above?
• Suppose something does happen to be deployed insecurely. How do we send the request for a fix back into the workflow that our developers utilize with actual coding changes included automatically?
• Are there any platforms that can handle our need to shift left, protect our runtime environment, and feed into our security operations, governance, and compliance; infrastructure architects’ workflows to provide visibility, protection, and auditing layers for our entire application landscape?