Don't Sh*t-Left: How to Actually Shift-Left

Don't Sh*t-Left: How to Actually Shift-Left

Speaker: Ahmad Sadeddin

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: https://www.youtube.com/watch?v=N5u_OYf-5oU

Reading time: 7 minutes

TL;DR

Most "shift-left" security programs fail not because the concept is wrong, but because organizations mistake tool deployment for cultural change. Ahmad Sadeddin, founder and CEO of Corgea, argues that shift-left only works when it treats security as a developer experience problem — and that the rise of AI-assisted coding is expanding the attack surface faster than most appsec teams realize.

Introduction

Shift-left has become one of the most cited concepts in application security. The idea is simple: find and fix vulnerabilities earlier in the development lifecycle, when they are cheaper and less disruptive to address. In practice, according to Ahmad Sadeddin, a significant portion of shift-left programs don't shift anything — they "sh*t-left," dumping noise and friction onto developers without meaningfully improving security outcomes.

Sadeddin is a three-time founder and CEO of Corgea, an AI-powered appsec platform. He spent six years at Kopa (which acquired his previous company), including three years leading the payments product and owning security, fraud, and compliance. That background — product leadership with real appsec accountability — informs a talk that is less about specific tools and more about the organizational and experiential conditions under which shift-left actually works.

The statistics framing his argument are striking: 86% of developers say security is not a top priority when coding. A third of developers spend up to half their time fixing bugs instead of shipping features. 43% of organizations that attempted to shift left saw increased developer workload. Legacy SAST tools produce false positives at rates between 50% and 80% in practice (NIST found rates up to 78% for Java). When everything is high priority, nothing is.

The "Is It Shift or Sh*t?" Quiz

▶ Watch: Interactive examples of real vs. fake shift-left (08:00)

Sadeddin ran an interactive exercise with the audience, presenting three common shift-left scenarios and asking whether each represents genuine progress or security theater.

Example 1: Adding a traditional SAST scanner to the CI/CD pipeline. The audience consensus: this is sh*t-left. The reasoning: approximately 60% of vulnerabilities go undetected by most commercial tools; roughly 30% of what they do report are false positives (and practitioners in the room estimated their real-world false positive rates higher); and developers end up spending time chasing ghosts rather than fixing real issues. A Reddit post about the developer experience with a (redacted) SAST tool was the supporting evidence — the top-voted comment expressed a sentiment that goes unreported in vendor case studies.

Example 2: Training developers on the OWASP Top 10. Also sh*t-left in isolation. Not because developer training is bad — Sadeddin explicitly endorses it — but because knowing a vulnerability category theoretically and knowing how to fix it in a specific production context are very different things. SQL injection alone has over 40 viable mitigations depending on the database, language, and framework. Secure code training covers three. If an organization runs five or six programming languages (which most do), the complexity compounds quickly.

Example 3: Implementing a security champions program. This one the audience and Sadeddin agree is genuine shift-left, when done well. The ratio of appsec professionals to developers at most organizations is roughly 1:200 to 1:1,000. No appsec team can meaningfully review, consult on, or support security for every team at that ratio. Security champions — developers who take on security advocacy for their teams — are the primary scaling mechanism available. Sadeddin noted that in Corgea's customer base, organizations with functioning security champions programs consistently see better outcomes across the board.

What Shift-Left Actually Requires

▶ Watch: The DevX formula for shift-left (17:30)

The reframing at the center of the talk: shift-left is not a tooling problem, it's a developer experience problem. The most common question Sadeddin receives in conversations with prospects and customers is "Do you support IDE? CLI? CI/CD pipelines?" — but those questions are proxies for "Is working with your security tooling a good experience for developers?" Integration points are one piece of the answer, not the whole answer.

The developer experience formula Sadeddin describes has three components:

Clear processes. Developers need to know what is expected of them, when, and by whom. Ambiguity about the security review process — when to request one, who to contact, what the output looks like, where it is delivered — creates friction that causes security work to be deferred or skipped. Whether the output is a Jira ticket, a Confluence page, or a design document matters less than whether the process is consistently communicated and easy to follow.

High-fidelity, context-aware findings. This is where Sadeddin believes the industry most often fails. A finding is high-fidelity when it accounts for context: the specific language, framework, and application architecture in which the vulnerability exists. A generic "SQL injection found on line 47" report is far less actionable than one that explains why this instance is exploitable, how an attacker could reach it, and what the specific fix looks like in the codebase in question. Context is "probably the biggest thing that we miss in security today." Low-fidelity findings with high false-positive rates produce the developer behavior that makes shift-left programs fail.

Assistance and education at the point of need. Paved roads, fix suggestions, and developer education should be delivered where developers work — not in a separate portal they have to navigate to separately. A developer who understands why a vulnerability matters and how to fix it in their specific stack is far more likely to actually fix it.

The Vibe Coding Problem

▶ Watch: AI-assisted coding and expanding attack surface (26:00)

The second half of the talk addresses a challenge that did not exist when most shift-left frameworks were designed: AI-assisted code generation. Research published in late 2024 found that coding agents increase security vulnerabilities in applications by approximately 30%. GitHub Copilot has been purchased by 77,000 organizations in the last two years. The Anthropic CEO stated that AI will write 90% of code within three to six months — a timeline Sadeddin questioned, while agreeing directionally.

The surface area implications are significant. Not only are professional developers using AI assistants (and producing more code, faster, with less review), but non-developers are now building and deploying production-facing applications. Sadeddin described a scenario he has observed directly: a salesperson who builds a client-facing web application using a vibe-coding tool, populates it with customer data, and deploys it on Replit or Vercel — entirely outside the organization's security review process. This is shadow infrastructure, shadow code, and shadow data exfiltration risk, all in one.

The pattern he described from vibe-coded applications is that the first few prompts produce something coherent and functional. As the application grows more complex — fifth, sixth, seventh revision — context windows overflow, files multiply, redundancy creeps in, and the codebase becomes unmaintainable by someone who doesn't write code professionally. Vulnerabilities, particularly business logic vulnerabilities that SAST and DAST tools are poorly equipped to detect, accumulate in the gaps between coherent prompts.

The Response: Enabling, Not Blocking

▶ Watch: How to respond to the vibe coding threat (32:00)

Sadeddin's recommended posture is explicit: trying to prevent developers and non-developers from using AI-assisted coding tools is not a viable strategy. The tools are already in use. The correct response is to build security into the paths people are already taking.

For professional developers, this means the same shift-left formula — clear processes, high-fidelity findings, assistance and education — needs to scale to accommodate higher code volume and AI-generated code patterns that may not resemble what traditional tools were trained to detect. AI-powered security tooling that can understand code context, reduce noise, and serve as a first-line reviewer before human involvement is required is one component of that scaling.

For non-technical users who are now shipping applications, the answer is structured permission, not prohibition. Give them a sanctioned platform — an internal Vercel instance, a v0.dev deployment with organizational controls — with a submission process that triggers automated scanning and a lightweight approval step. Let people build what they want to build, but route it through a path that provides minimum guardrails without creating a bureaucratic barrier.

The broader point is that appsec teams need to reconceive their role. The traditional appsec-to-developer ratio (1:200 to 1:1,000) was already unworkable for pure human review. As AI tools put code generation capability in the hands of every function in the organization, the scaling problem becomes an order of magnitude worse. The only path forward is being an enabler — providing the tools, processes, and education that let people work faster and safer — rather than a gatekeeper who slows things down.

Notable Quotes

"When everything is high priority, nothing is."

"Shifting left is actually quite a big thing. It's not just about tooling."

"The genie is out of the bottle and everyone in the organization will be vibe coding to some certain extent. You have to think about how to enable them to do it safely."

Key Takeaways

• Shift-left is a developer experience problem, not a tooling problem. Deploying a SAST scanner in the pipeline is necessary but not sufficient. The experience of receiving, understanding, and acting on security findings must be designed as carefully as the tools themselves.
• False positives are a security failure. When SAST tools produce 50–80% false positive rates, developers stop trusting findings. A high-fidelity finding that accounts for code context and explains a specific fix path is worth more than ten generic alerts.
• Security champions are a scaling mechanism, not a nice-to-have. At 1:200 to 1:1,000 appsec-to-developer ratios, security champions are among the only realistic ways to extend security coverage across an engineering organization.
• AI coding tools are already in production, in every function. Shadow infrastructure built by non-technical users is a real and growing risk. Building sanctioned, guardrailed platforms for vibe-coded applications is more effective than attempting to prohibit them.
• Shift-left must now include the whole organization. The traditional framing assumes a professional developer audience. As code generation reaches sales, marketing, finance, and other functions, appsec programs must expand their scope and their definition of "developer."