Shifting Left Starts With Design: Lessons From a CISO Panel

By Mike LeBlanc, Chief Revenue Officer, ThreatModeler

Last week, I sat in on a CISO panel discussion, and one theme kept coming up. No matter how different their environments were, they all said the same thing in one way or another: teams are trying to shift left — but most of the pain still shows up late.

And when problems show up late, everything gets harder. Fixes take longer, more people get pulled in, and deadlines start to slip. Nobody enjoys the scramble.

But the interesting thing wasn’t the problem — it was the agreement on why it keeps happening.

Every CISO on that stage said some version of this:

“If we want to shift left, we have to start earlier — before code, before scanning, before the chaos.”

And that message stuck with me.

Because shifting left is a broad idea, but at its core, it’s simple:
Get the right eyes on design decisions before they turn into downstream work.

And that’s exactly where so many teams still struggle.

What “Shift Left” Means Today

If you ask ten people what shift left means, you’ll get ten different answers.
Is it scanning earlier?
Is it giving developers more tools?
Is it changing the pipeline?

Shift left isn’t just about doing the same work earlier in the process.

It’s about looking earlier — before the design is set, before development is underway, and before security is forced to deliver bad news at the end.

When security shows up earlier, something important happens:

• Conversations get easier
• Trade-offs are clearer
• And security stops being the late-stage gatekeeper

One of the CISOs summed it up perfectly:

“We want to be the department of know, not the department of no.”

And that only works when teams can look at the design together and understand where the risks are.

That’s why early architectural insight is becoming such a priority. It’s the part of the process where decisions are still flexible — and cheap — to change.

Why CISOs Are Focusing on Architecture Earlier

Every CISO on that stage had a story about security issues discovered late in the lifecycle — sometimes in testing, sometimes in production.

None of them blamed the tools or developers.

They blamed timing.

It’s like football — if you don’t see the blitz coming until the quarterback is on the ground, it’s already too late. Seeing it early gives you options.

By the time a scan finds something, the design behind it is already locked in. Changing direction means rework.

They also talked about a few common challenges:

• Security reviews happening too late to influence architecture
• Teams working from different assumptions about how the system fits together
• Developers are measured on speed, while security gets measured on risk
• Limited visibility early on, so security ends up reacting instead of guiding

The earlier you catch design issues, the better the entire process goes — for everyone.

That’s where threat modeling comes in.

How Threat Modeling Helps Teams See Things Earlier

Here’s the simplest way to put it:

Threat modeling helps teams see their architecture early and understand where risks are likely to appear — long before they become expensive problems.

It’s the same idea as reading the field — when you can see the pressure coming early, you have more options and less chaos.

Threat modeling gives teams:

• A clear picture of how the system works — the connections, the data flows, the places where trouble could start
• A way to spot issues when they’re still easy to fix
• A shared view so architects, developers, cloud engineers, and security are all speaking the same language
• A repeatable process, not a last-minute scramble
• A consistent way to apply secure design principles across apps, cloud environments, and whatever framework the team prefers

When teams have that clarity early, everything downstream gets easier.
Less rework.
Fewer surprises.
Faster delivery.

That’s what shifting left earlier really looks like.

Shifting Left Earlier: What It Looks Like in Practice

When teams understand the architecture early, a few things naturally start happening:

• They spot risks during design, not after development picks up speed.
• They define security requirements earlier, tied to the actual system.
• Developers get the context they need — not generic checklists.
• Security becomes part of planning, backlog refinement, CI/CD, and infrastructure-as-code.
• Risks and requirements stay current as the system evolves — no manual rebuilds.

Working earlier in the process gives teams a clearer path to secure-by-design without slowing anyone down.

The Path Forward

The biggest takeaway from that CISO panel was simple:

Shift left delivers the most value when teams can look earlier — before they’re stuck responding to late surprises.

Organizations don’t necessarily need more checks at the end.
They need more clarity at the beginning.

Threat modeling isn’t a replacement for every shift-left practice.
But it is one of the ways teams can see the architecture early, align faster, and prevent issues before the work piles up.

When teams get that insight upfront, they:

• reduce rework
• ship faster
• avoid late-stage chaos
• build more secure systems from day one

And in a world where everything moves fast — cloud, code, attackers — the teams who see the field earlier will always have the advantage.

Shift-left isn’t about doing security the “right” way.
It’s about giving teams what they need to work earlier.
Threat modeling is one of the practices that helps make that possible.

If you want to see how your own teams can get earlier visibility into architecture and risk, connect with our team to learn more.