Shifting Left: Smarter not Harder

Hi everyone! It’s been a while, but I’m finally back and I’m excited to share my brand-new blog and my first blog post in four and a half years. In today’s post, I’m tackling ‘Shift-Left’ security. I’ll be breaking down why it has become such a major pain point for many organizations and, more importantly, how we can fix it by doing things differently. So, grab a cup of coffee, get comfortable, and let’s dive in. Cheers!

Shifting Smarter — shifting smarter is the only way, shifting harder is not.

For the past decade, “shift-left security” has been the go-to buzzword/slogan for DevSecOps presentations, security sales pitches, and internal developer programs. The core idea was simple and compelling, move security earlier in the software delivery process, fix vulnerabilities while code is still being written, and empower developers to act as the first line of defense.

But if you talk to most engineering teams today, you rarely hear that success story. Instead, you hear about tool fatigue, noisy alerts, and dashboard hell. IDEs and CI pipelines are crammed with scanners, leading to endless security tickets. There is a growing sense that security is just being dumped onto developers without proper context or support.

At the same time, the software industry is rapidly evolving. We are now in an era dominated by cloud-native architectures and artificial intelligence. AI is radically changing how we build and operate softwares copilots generate code, agents act autonomously with production credentials, and risks have shifted from static vulnerabilities in the code to unpredictable behaviors at runtime. Because of this, the traditional way we do “shift-left” security is failing. Rather than speeding up secure delivery, it has created unmatched bottlenecks, overwhelming mental load, and widespread developer burnout.

Engineer Burnout — very smol infographics about engineer burnout!

The problem isn’t that shift-left was a very bad idea. It’s that we implemented it as “shift harder way” more tools, more checks, more alerts, more pipelines without redesigning the operating models to support them. This phenomenon, often termed “shoving left”. The way forward is “shift-smart” instead of just dumping more scanners or pipelines into the SDLC, we should focus on smarter guardrails, platform-led paved roads, context-aware intelligence, and continuous runtime governance.

The Broken Promise of Shift-Left

Before criticizing shift-left, it’s worth remembering why it became so popular in the first place. At its heart, shift-left is simply the practice of moving security activities like design-reviews, code analysis, dependency management, and threat modeling, earlier in the software development lifecycle (SDLC). Instead of waiting until the end to check for problems, the goal is to bring security into the planning and coding phases.

Companies like Palo Alto Networks promote this approach because it embeds protection early on. The idea is to catch vulnerabilities and misconfigurations before they become major issues, allowing teams to ship secure software at scale rather than relying solely on “perimeter” defenses at the very end.

Traditionally, there were three big promises behind this:

Cheaper fixes: It is much faster and cheaper to fix a bug while the code is being written than it is to fix it once it’s already live in production.
Fewer defects: By providing continuous security feedback in the pipeline, we should catch critical issues long before they ever reach the customer.
Developer empowerment: By giving developers the right tools and guidance, they become active partners in security, rather than just waiting for an auditor to hand them a list of problems later.

On paper, shift-left looked like the perfect bridge between security teams and modern engineering. It fit perfectly with Agile, CI/CD, and the “you build it, you run it” mindset. The trouble started when organizations tried to put this into practice at scale. We often tried to solve the problem by just adding more tools, rather than actually rethinking how security and engineering teams should work together.

The Breakdown of Traditional Shift-Left

When organizations try to fix security by just adding new tools to traditional workflow, wiring them earlier into the pipeline, and routing all their findings to developers, the system inevitably breaks. Here are the three biggest reasons why the traditional shift-left approach is failing today:

1. Tool Sprawl and Alert Fatigue

The clearest sign that a security program is failing is “alert fatigue”. Traditional scanning tools operate in a vacuum. Organizations pack their development pipelines with a massive stack of security tools, like SAST, SCA, DAST, secrets scanners, and infrastructure-as-code (IaC) linters, which flag every theoretical vulnerability they find, even if it poses no real-world danger.

Because each tool comes with its own dashboard, its own alert stream, and its own special definition of what qualifies as a “critical” issue, it creates two major problems:

Alert Fatigue: Developers are constantly flooded with security notifications. When every single pull request (PR) triggers a list of dozens of warnings, developers quickly learn to ignore them just to get their work done.
The “Ghost” Vulnerabilities: Traditional tools look at code in a vacuum. A tool might flag a vulnerable library, but if your application never actually uses that specific part of the library, the risk isn’t real. Developers end up spending hours chasing these false alarms instead of building new features.

2. No Context, and Conflicting Goals

Security tools are great at finding potential issues, but they are terrible at understanding context. Many tools report issues in total isolation. They will flag a vulnerable dependency or an overly permissive cloud policy without connecting it to what actually matters:

Business Impact: Does this piece of code touch sensitive customer data, or is it just an internal tool?
Real-World Risk: Can an attacker actually reach and exploit this vulnerability in real life?
Existing Safety Nets: Do you already have other security measures in place that block this specific threat?

Without this context, teams cannot prioritize their work. To make matters worse, development and security teams are often judged by completely opposite goals. Developers are judged on feature velocity, system uptime, and customer impact. And, Security teams are judged on lower vulnerability counts, closing tickets, and strict compliance only rules/policies.

When security’s success depends on closing tickets, but development’s success depends on shipping features fast, friction is inevitable. Shift-left quickly turns into “shift-blame”, where security adds blockers, developers feel stuck, and teamwork breaks down.

3. Developer Burnout and “Security as a Chore”

When you mix endless noisy tools, constant alerts, and conflicting goals with a lack of context, you get a serious cultural problem. Security starts to feel like a chore or a punishment rather than a shared engineering responsibility. Instead of being a helpful partner, security shows up as a late-stage failure on pull request or a sudden flood of automated tickets. Because the feedback is often generic and disconnected from how the application actually works, developers begin to view security as a frustrating chore that gets in the way of real engineering.

Hidden Cost by the Approx Numbers

This broken workflow isn’t just annoying, it has a measurable impact on productivity and morale. Read: gitlab survey ai paradox and cloudaware devsecops statistics.

Operational Metric	Traditional Shift-Left Impact	Current Industry Reality
Toolchain Density	High fragmentation, multiple standalone scanners	60% of teams use 5+ security tools
Productivity Loss	Frequent context switching for alert triage	~7 hours lost per week per team member
Remediation Time	Slower due to manual triage and false positives	47% increase in time to fix security flaws since 2020
Deployment Velocity	Blocked by manual reviews and rigid gates	82% of teams deploy weekly, heavily compounding friction
Security Posture	Illusion of security; high volume of unverified alerts	50% of organizations hold critical, lingering security debt

the bottom line

The philosophy of shifting left is sound. But the common implementation, piling on more tools and more alerts without changing how we actually work, is deeply broken. And as we enter the era of AI, these cracks are becoming impossible to ignore.

AI-Generated Code: Faster Production, Faster Flaws

Traditional shift-left security was built for a world where humans wrote all the code and configurations. Today, however, AI has completely changed the game. Risk has officially moved from static code to runtime behavior, what happens while the software is actually running. This major shift is driven by two main factors, the explosive volume of AI-generated code and the rise of autonomous AI agents.

Right now, about half of all developers use AI coding assistants to save hours of work every week. While this absolutely turbocharges software delivery, it also creates a massive wave of new code and dependencies that security teams have to review properly.

The reality is that AI generated code is often less predictable and more fragile than human code. Here is why:

The Internet’s Bad Habits: AI models are trained on massive amounts of public data. This means they inherit and copy the insecure coding patterns, outdated habits, and logic errors found across the open-source.
The 40% Risk Factor: Research from Stanford and NYU shows that AI-generated code suggestions contain security flaw about 40% of the time. In actual banking and enterprise environments, internal scans have shown that over 60% of AI code suggestions contain high-severity vulnerabilities.
Common AI Blunders: AI assistants consistently prioritize making code work over making it secure. Security audits show that AI tools frequently make databases open to SQL injection, use weak passwords, and forget basic security implementations that protect user sessions.

The even bigger shift is the rise of agentic AI. These aren’t just tools that suggest code snippets, these are autonomous AI agents given specific goals, credentials, and memory, allowing them to act across multiple systems without a human constantly watching over them. Because these agents think and adapt on the fly, their risks are entirely behavior-driven. The OWASP GenAI Security Project highlights several major risks unique to these autonomous systems (you can also read this):

Goal Hijacking: Attackers trick the AI agent into changing its original instructions to pursue dangerous outcomes.
Tool Misuse: The agent uses its connected tools in unsafe ways, or an attacker exploits the tool’s interface to cause damage.
Privilege Abuse: The agent accidentally (or maliciously) misuses its credentials to access sensitive data it shouldn’t be touching.
Unexpected Code Execution: The agent generates and runs its own code at runtime to solve a problem, creating sudden operational risks.

OWASP AGENTIC TOP 10 — credit: owasp, owasp agentic top 10 at a glance

The OWASP GenAI Security Project emphasizes that AI threats are fundamentally behavior driven. They don’t just sit quietly in a codebase as static vulnerabilities, instead, they emerge dynamically during execution as agents plan, adapt, and chain tools together in real time.

Data from the NHI Management Group reinforces this reality. While traditional “shift-left” controls are great for reducing defects before deployment, they fall short post release. Once an agent goes live, it operates with its own credentials and a high degree of autonomy, introducing an entirely new risk profile. They highlight scenarios where agents act beyond their intended scope, abusing tokens or chaining tools to reach sensitive systems, underscoring that runtime governance is essential.

Because these risks stem from unpredictable sequences of actions rather than isolated code flaws, traditional shift-left tools are completely blind to them. They can validate your code and configurations up to the moment of deployment, but they cannot predict how an active agent will behave in the wild. If your security program stops at “we scanned the code before deploy,” you are blind to a large part of modern AIdriven risk.

From “shift-left” to “shift-smart”

Shifting smart means evolving security from a question of timing to a discipline of absolute precision. We must move beyond pre deployment checklists and reframe our approach around: risk, context, platform, and behavior. To actually shift smart, we have to rebuild our security programs around four core realities.

Principle 1: Focus on Risk and Context

A smart security program doesn’t treat every piece of code the same way. Instead, it groups your systems by how much impact they have and who can see them, separating public-facing services and sensitive data from internal tools and experimental features. This means you can confidently apply stronger controls to high-risk areas, like public APIs that handle regulated data, while keeping things lighter for low-risk utilities. By pairing lighter controls with great monitoring where the risk is low, you avoid burning out your team on tasks that don’t add much value.

Context-aware tools take this a step further by connecting security findings directly to your business reality. They look at actual user traffic, digital identities, and data types to figure out which vulnerabilities are truly dangerous and exploitable. If a bug is impossible to reach or already blocked by another security measure, the system automatically drops or downgrades the alert. This completely solves the common nightmare of having too many alerts and too little useful information, keeping your team focused on what actually matters.

Principle 2: Platform-led Security and Paved Roads

Smart security programs don’t just push checks earlier in the timeline, they build security directly into the underlying platform. By weaving guardrails into Internal Developer Platforms (IDP) and cloud setups, organizations can provide developers with secure defaults through “paved roads”. This means infrastructure modules like terraform come with strict access controls and logging out of the box, while delivery pipelines automatically handle artifact signing and tracking without requiring any extra setup. Centralizing these guardrails ensures that clear expectations are set automatically whenever a new service is built.

Industry leaders like HashiCorp emphasize that embedding security directly into the platform resolves the classic conflict between developers and security teams by making the secure choice the absolute easiest choice. Platforms like SecPortal prove that managing this posture at scale is much simpler when you centralize guardrails and exceptions around a single record for each service. Ultimately, instead of awkwardly bolting tools onto every single team’s pipeline, a shift-smart strategy consolidates these capabilities into the platform itself, letting engineering teams easily consume them as well-designed, ready to use services.

Special Mention: The Netflix, Productizing Security

Netflix gave us the perfect example of how to make this work when they needed to secure their rapidly growing studio applications. Originally, developers had to grind through a massive, complex security checklist before launching any app to the public. They had to manually configure encryption, user logins, rate limits, and security headers. It was a slow, frustrating process that delayed product launches and buried the security team under manual audits. Read from here

To fix this, Netflix turned their security requirements into an actual product. They built a system called “Wall-E”, which acted as a smart gateway for their applications. The security team built features like Single Sign-On, firewalls, and logging directly into this gateway. Just like that, a confusing 10page manual checklist vanished and was replaced by one simple question for developers, “Will you use Wall-E?”

To make adoption even easier, the platform team made setup completely automated. Developers just filled out a simple configuration file stating what they needed, like their domain name and who should have access and the system handled all the complex networking and certificates behind the scenes. What used to take weeks of manual work was cut down to less than ten minutes. Netflix proved that security works best when it is a smooth, helpful service rather than a frustrating roadblock.

Principle 3: Use Guardrails, Not Just Gates

Think of it this way, gates block you, but guardrails guide you. A smart security program uses both, but it heavily favors guardrails to keep teams moving fast. Great guardrails include secure base templates that development teams inherit automatically, alongside automated policies that check for minimum safety requirements based on the risk level. These systems are flexible enough to allow controlled, temporary exceptions when teams need to keep moving, ensuring security never becomes a bottleneck.

Hard blocks, or security gates are strictly saved for situations where the risk is completely unacceptable or where everyone has agreed on non-negotiable safety rules. By leaning on helpful guardrails rather than constant roadblocks, a shift-smart strategy steers teams away from dangerous paths while keeping the development process smooth and efficient.

Principle 4: Be a Coach, Not a Cop

At the end of the day, company culture matters just as much as security controls. A developer-first approach means security shows up as helpful coaching while code is being written, rather than strict enforcement after the fact. Instead of waiting to fail a build, smart teams provide real-time guidance directly inside the code editor, using lightweight tools that clearly explain the issue and propose a quick fix.

This strategy also replaces boring annual training with just in time learning. When developers run into a specific vulnerability, they get targeted, relevant training right then and there, making the lesson actually stick. When security professionals act as supportive partners who help teams ship safer systems, developers actively engage and learn. On the other hand, if security teams only act as gatekeepers who say “no,” the whole process falls apart, leading to blame games and teams actively avoiding security tools.

Principle 5: Watch AI and Automation at Runtime

When it comes to AI agents and digital identities, a smart security approach recognizes that the real risk shows up when the software is actually running. Industry standards, like the OWASP Agentic AI guidelines, emphasize that we need to actively watch what these agents do in production. This means validating the AI’s goals to prevent its system from being hijacked, and strictly limiting what tools it can access so it doesn’t accidentally misuse them. We also need to keep a close eye on the system to catch unexpected code execution or rogue behavior if an agent starts drifting outside its boundaries.

To handle these unique challenges, modern security relies on smart practices like temporary credentials and checking permissions for every single action an agent takes. Instead of just relying on rigid, one-size fits all rules set during deployment, this ensures that every move an AI agent makes is authorized based on what is happening in the moment. Ultimately, shifting smart means embracing the idea that how an AI behaves in the real world is just as important as what the code looks like before release, and building our safety controls to match.

Word Cloud — smol word cloud of terms, and tools used in shift-left!

A Practical Playbook for Shifting Smarter

To make your shift-smart strategy actionable, here is a concise playbook designed to help you build a sustainable security posture without slowing down your engineering teams.

Phase 1: People and Alignment

Adopt Developer-First Practices: Shift your security training away from boring annual videos and move to justintime, issue-driven content that relates directly to real incidents in your environment. At the same time, introduce in-flow guidance like lightweight text editor tips and command-line helpers, that actually explain and fix issues instead of just failing builds. When security teams act as supportive partners, developers stay engaged and keep learning.
Establish a Joint Council Across Security, Platform, and Engineering: Break down silos by bringing leaders from security, platform engineering, and software development together. Align everyone on a shared roadmap where new security features are treated as core platform capabilities rather than external mandates.
Redefine KPIs to Include Both Speed and Security: Track standard delivery metrics like deployment speed, change failure rates, and recovery times to understand how your security controls affect actual shipping speeds. Balance this by tracking fix times, your vulnerability backlog, and developer sentiment. This ensures you are reducing real risk without burning out your teams.

Phase 2: Process and Architecture

ReTier Applications and Controls: Classify your services and AI agents based on how much impact they have on your business and who can see them. Apply heavier checks and active monitoring to high-risk areas, like public APIs that touch sensitive data. For lower-risk areas, keep the controls light and rely on strong monitoring so you don’t overwhelm your teams where the upside is small.
Move from Rigid Gates to Flexible Guardrails: Stop relying on strict blocks that freeze deployments completely. Save hard stops exclusively for high-confidence, critical threats that have immediate, automated fixes. Route all other minor findings into a manageable feedback loop governed by clear response time goals, keeping your engineering team moving fast while staying secure.
Automate with Dynamic Configuration Management: Say goodbye to making developers manually script their infrastructure environments. Use platform orchestrators to handle configurations dynamically. Developers simply describe what their application is supposed to do, and the platform automatically generates secure templates and deploys the workload. This eliminates manual errors and configuration drift with every single code commit.

Phase 3: Technology and Tooling

Consolidate Tools into Productized Platform Features: Take a look at your current security tools and see where they can be unified under your internal developer platform or cloud environment. Expose security features as ready to use blueprints, like pre-configured infrastructure modules and automated pipelines rather than awkward, ad-hoc integrations. Make the secure choice the easiest choice.
Clean Up and Simplify Your Toolchain: Aggressively audit your security scanners to cut down on noise and friction. For a fast, developer friendly pipeline, stick to lightweight, high-impact open-source tools like semgrep, dependabot, kingfisher, trivy, cosign etc.
Deploy an ASPM for Real-World Visibility: Bring your separate scanners under an Application Security Posture Management framework to easily map attack paths across cloud setups, user identities, and code flaws. Use tools to analyze if a vulnerability can actually be reached and to predict the impact of code upgrades. You can also use platforms like Wiz for fantastic runtime visibility to spot live cloud and access risks. Pick tools that reduce alert noise and focus on a great developer experience.
Secure the AI Supply Chain and Runtime Governance: Enforce strict, temporary permissions for all AI tools so an AI agent can never alter core infrastructure without a human serving as a final circuit breaker. Use automated software tracking to verify the origin of both open-source components and AI-generated code. Finally, restrict tool access based on the agent’s goal, and log all AI actions as auditable events so you can catch rogue behavior if an agent drifts outside its boundaries.

Closing: Security as Part of Engineering

The original goal of “shifting left” was never to spark an arms race of security tools or to start a blame game. It was simply meant to make safety a natural, everyday part of building software. In a world full of AI generated code and automated systems, the answer isn’t to cram more scanners earlier into the pipeline. Instead, the answer is smarter security, using platform-led paved roads, smart guardrails that understand context, developer-first coaching, and active monitoring for both human and machine behavior.

The common belief that early security fails because developers just don’t care is completely wrong. The strategy breaks down at scale not because humans are stubborn, but because companies try to enforce security by constantly interrupting the developer’s workflow instead of upgrading their actual system architecture. In a fast-moving world driven by AI agents and complex cloud environments, security can no longer act like an outside auditor showing up late to the party.

Shifting smart requires a real shift in mindset: security needs to transform from a loud gatekeeper into a silent helper. By investing heavily in strong platform engineering, automated setup tools, and smart systems that check if bugs can actually be reached, organizations can build smooth roads that ensure safety by default. If we can make secure workflows the absolute fastest and easiest workflows to follow, developers will instinctively choose them. That is how we finally deliver on the true promise of modern security—without burning out the people who build and run our systems.