Why Shift-Left Security Keeps Failing (and What Actually Works)
Shift-left sounds right: find bugs earlier, fix them cheaper. It keeps failing because security teams push findings to developers who lack the context to prioritize them.
Shift-left security has been the default advice in application security for over a decade: find bugs earlier, fix them cheaper, ship safer code. The problem is that it keeps failing. Security teams push findings to developers who lack the context to prioritize them, and the backlog grows instead of shrinking.
Neatsun Ziv, co-founder and CEO of OX Security and a former VP of Cyber Security at Check Point, put it bluntly on episode 91: “Shift left as a concept failed us for years. We’ve been trying to make it work, but it’s just that everybody’s got their priorities.” The failure isn’t a tooling problem. It’s a context problem.
What shift-left promised, and where it broke
The premise was sound: bugs caught during development cost less than bugs caught in production. So teams added static analysis, dependency scanning, and secret detection into CI/CD pipelines. Developers got dashboards full of findings. The execution broke down at the handoff, because it assumes developers can act on findings — and that falls apart when they lack the context to tell a critical vulnerability from background noise.
Consider a scanner flagging a vulnerable dependency. The developer has no way to answer the questions that matter: Is this deployed to production? Does the affected path handle externally exposed APIs? Which databases does this service connect to? As Ziv explains, “Most of us are coming blind to those questions.” Without that context, developers either fix everything, wasting time on low-risk issues, or ignore the backlog, leaving real risks unaddressed. Neither is what shift-left promised — and the result is developer security fatigue, which costs the program its credibility with the people it depends on.
Context-first security
The alternative isn’t to shift further left or right. It’s to shift the context to wherever code is being written — automatically enriching findings with the data developers need to act.
| Without context | With context |
|---|---|
| CVE-2026-1234 in package X | CVE-2026-1234 in package X, deployed to prod, handles external API traffic, connected to the customer database |
| Priority: unknown | Priority: critical, fix this sprint |
Security teams stop being ticket generators and start being context providers. Developers stop drowning in unranked alerts and start fixing the three things that would actually cause a breach. It mirrors what’s happening across security broadly: just as microsegmentation replaced blanket perimeter rules with context-aware access, context-first AppSec replaces blanket alerts with threat-relevant, prioritized findings.
How AI coding agents change the equation
AI coding agents create a chance to apply context-first security at the point where code is generated, not after it ships. Ziv’s approach: “If we can load up front the context saying, you are going to touch right now… an API that is externally exposed, these are the databases that this app is connected to… we want you to have those security restrictions and this rate limit and this sanitization.” Instead of asking a developer to review an AI-generated pull request for security issues, the security context is loaded into the agent before it writes the first line — the practical application of least privilege for AI agents. It’s the same discipline behind securing the code AI agents write. When context is embedded in the workflow, review bottlenecks shrink, false positives drop, and mean time to remediation improves.
What a context-driven program looks like
Moving from shift-left to context-first doesn’t require ripping out tools — it changes what information they deliver and when:
- Map your deployment context — which services are externally exposed, which handle sensitive data, which connect to critical infrastructure. This is the foundation.
- Enrich findings at scan time — attach deployment data, API exposure, and data-flow context to every finding before it reaches a developer.
- Prioritize by exploitability, not severity alone — a critical CVE in an internal test service is less urgent than a medium CVE in a payment API.
- Load security constraints into AI coding tools — feed policies, rate limits, and sanitization rules into the agent’s context window.
- Measure what matters — track mean time to remediation for context-enriched findings versus raw ones. The difference validates the approach.
The point is structural: reduce the decision burden on the people who have to act, instead of generating more alerts. That’s the same principle behind how we run penetration testing — surface the findings that would actually cause a breach, with the context to fix them, not a PDF of everything a scanner could flag.