0x01 Intro
Concepts like Shift Left and Secure by Default have been around for a while, but I’ve never seen anyone actually explain how to do it. Which direction is “left” anyway? Today I want to share my take on what Shift Left really means in practice.
0x02 The Breakdown
The original term is “Shift To Left.” I’ll stick with that throughout. To understand what shifting left means, you first need to understand why we’re doing it. The idea is to move your defenses earlier in the process — in other words, bake security defaults in earlier. For applications and infrastructure, think of the flow as going from inside out (from code to production). Shifting left means reversing that — going outside in. For example, moving from perimeter defenses like firewall/anti-DDoS/WAF into SAST/IAST in the CI/CD pipeline — that’s shifting left. For data, which flows from creation to storage, shifting left means pushing security to the point of generation. Think moving from DB-level TDE to integrating encryption at the Application and EaaS (Encryption as a Service) layer.
Beyond time sequences, there’s also a spatial dimension to shifting left — expanding coverage in space, not just in time. For example: a Data Key generated by KMS gets wrapped as a KEK and stored locally. It’s only loaded at runtime, meaning it lives in memory. If you’re still worried about memory dumps, you can take it a step further by combining KEK decryption with an Enclave, so key operations and data computation only happen inside a TEE (Trusted Execution Environment).
Below I’ll walk through three diagrams covering Shift Left for applications, infrastructure, and data.
I touched on the application side briefly in my earlier post on Modern SDLC and Security Architecture Review (there’s also an animated version here). SDLC itself is one of the clearest examples of Shift Left in action. From R&D through to deployment and operations, the blast radius of a problem keeps growing, and so does the cost to fix it. Shifting left lets you catch issues earlier — pushing perimeter defenses into the CI/CD stage or even the architecture design phase.
That said, most of the conversation around this focuses on the product/business side. Enterprises are busy figuring out how to roll SDLC coverage out to their engineering teams. What almost nobody talks about is the support side. Support-side tooling rarely has real security capabilities built in, and since most of these tools are purchased off the shelf, I only kept “runtime” and “architecture design” in that part of the diagram. Think about all the tools your company uses beyond the core product: Confluence, Jira, approval systems, payroll, e-signature platforms, HR systems, OA systems, access management systems. How many of those went through a security review? How many have a solid system architecture? Probably not many. Part of the problem is that most of these systems predate the security team, so context is missing. The other part is that nobody wants to poke the hornet’s nest — these systems have accumulated so much baggage that nobody knows how to untangle them. But that same weakness is exactly what attackers exploit as an entry point.
Now for infrastructure. Applications ultimately run on infrastructure, and yeah, Serverless has been getting a lot of buzz — but it doesn’t solve everything. And companies shouldn’t assume that using Serverless means they can skip the security team. I’ll use cloud platforms as the example here.
Most large companies have standard golden images. You spin up instances from those images and make sure they conform to your baseline config. But in practice, misconfiguration still happens constantly — overly permissive test environment accounts, sprawling permissions, inconsistent resource creation processes. Some teams create resources through a CMP platform, others manually through the console, and others via AK/SK credentials. The diagram shows the alternative: instead of waiting until after an instance is created and then scanning for misconfigurations, you shift left by scanning the IaC code that your CMP platform uses to provision resources — especially the policy sections. For example, Tenable’s CSPM can scan Terraform code for issues. This way you catch configuration problems at resource-creation time, before anything goes live. No more scrambling to fix misconfigs in production. Of course, policies cover the common cases, but for edge cases you’ll still need context-specific policies.
For data, I wasn’t sure which angle to take when I first started sketching this out. I considered framing it from the data-generation perspective, but couldn’t land on a clean scenario. So I ended up using data state as the axis instead.
The diagram starts with data landing in the DB as plaintext. In that setup, a DBA can trivially read everything — and so can an attacker who gets in. The question is: at what point do you make the data encrypted? That’s where Shift Left comes in. You could use TDE (Transparent Data Encryption) at the DB layer, but that only works in commercial editions, and TDE support varies wildly by DB engine — some do row-level encryption, some table-level. So you can move it earlier: to the DAL (Data Access Layer). By integrating EaaS with your DAL, all data gets encrypted before it hits the DB, regardless of which DB engine you’re using on the back end. You can push it even earlier to the Application layer itself, especially in companies where there’s no centralized DAL.
0x03 Wrap Up
After all that, one thing needs to be said clearly: never shift left just for the sake of shifting left. The examples above are all technical — but actually making this work also means thinking about engineering execution and how your security team collaborates with product and R&D. Take the data encryption example: ideally, every application encrypts data before it hits the DAL, so everything is ciphertext as early as possible. But in practice that means every app team has to add encryption logic, which adds dev overhead. Where a DAL already exists, integrating EaaS there is much more practical. Beyond the technical side, Shift Left can also apply at the policy level — by encoding constraints directly into your standards and requirements documents upfront.
And not everything should shift left. As I mentioned in a previous post, testing actually needs to shift right, because you need as real an environment as possible to surface the kinds of problems that only show up at runtime.
Honestly, a lot has been on my mind lately. I’ve got two more posts I’ve outlined but haven’t had time to write yet — one on security products and one on information protection and data security. There’s always more to learn. Once you break through a plateau, you start seeing things you couldn’t see before. Worth revisiting the same topics over time — you’ll notice different things each time.