For two decades, developer security friction has kept security and engineering stuck in a loop. Security scanners flag an issue. The developer disagrees. Someone wins the argument. The ticket sits open while the SLA gets breached. A lot of findings don’t get resolved, and products continue to build security debt. We’ve called this a culture problem, a tooling problem, a process problem, and invented a plethora of solutions for each: shift-left, IDE plugins, dashboards, policies, stacking platform on platform. Every wave of AppSec promised the friction would finally go away, and none of them moved the needle.
The Agentic SDLC introduces the opportunity to break the loop by bringing security guidelines directly into the agent’s context window – making security the first thought rather than the last. When the unit of work shifts from hand-written code to intent and design, security stops being the thing that arrives late and starts being the thing that arrives first. Timing and knowledge stop being separate problems, and finally get solved together.
The three roots of developer security friction
For a developer, the friction is not one problem but three: volume, credit, and cost. First the volume, security teams hand over numerous findings, and many of them are time consuming false positives. Unfortunately, investigating security issues is one of the most challenging tasks in an organization. Second, getting credit for fixing security issues is too rare, as teams set off scanners but don’t get story points to compensate. Lastly, the cost: the findings that do matter are expensive to fix and don’t drive the increase in revenue new features do.
False positives
There is no shortage of data, or opinion, on false positives. An academic study of five static analysis tools found 76% of their warnings irrelevant to the actual vulnerability; Ghost Security’s analysis of nearly 3,000 repositories put the false positive rate at 91%. The problem is that most scanners have an incentive to maximize the findings they show, as they don’t want to risk missing a potential issue during a test drive. The result is a number of findings too high to triage, where vulnerability counts only go up.
Reachability
Reachability is simply the goal of discovering the exploitability of a vulnerability. From runtime to function level, there are numerous ways of trying to filter out the noise from exploitable code in your environment. While numerous approaches exist, we’ve written about how the truth is much more complicated – there’s no single silver bullet for finding exploitability. The goal is clear: stop wasting developer time on findings that don’t matter; however, the reality is more complicated, as patching even a single vulnerability can have widespread impact depending on the overall design and architecture of your environment. The Agentic SDLC does help here, as “just patching everything” becomes slightly more achievable for organizations who have been unable to keep up with the often major code changes required for major version changes.
Remediation cost
No one talks about how not only are security findings high volume, but they often involve layers of major architectural context. When James started doing application security, almost every security finding ended up in the hands of the chief architect. Applying a late fix means unwinding work that has already shipped: re-touching major decisions made years ago, re-opening decisions the architecture has already locked in. The bill is never just the patch, it’s the sunk cost of having your best developers involved in what’s often a false positive. A scanner can flag a vulnerability (or ten) in a second, but those findings can take months to resolve.
How AppSec tried (and failed) to solve developer security friction
Shift-left was the most intuitive idea for security teams, and was a fair answer to the failure before it. The complaint was real: security showed up after the code shipped, when changing anything was expensive, so the fix was to move detection earlier, into CI, before the merge. But most teams moved the scan while ignoring their backlogs, and the way that they grow. They wired the same findings into the pipeline and turned the merge into a gate, so security still arrived as a final checkpoint, now with the power to block the build. This made the problem worse, as security blocked code changes irrelevant to the problems, over vulnerabilities outside of a developer’s control. To make things worse, delaying a push could even delay an image rebuild, leading to a net increase in vulnerabilities!
IDE plugins answered the next complaint, that feedback living in a separate tool was too far from developer’s work to act on. So the findings moved into the editor and the pull request, inline on the offending line. But proximity is not context, and doesn’t force work to get done. Every scanner brought its own plugin, its own severity model, its own bot on the same diff, and the developer’s workspace became a second inbox. Overload a developer with fifteen security tasks per line of code and you do not get vigilance, you get muted notifications.
Ironically, organizations that made meaningful dents in their backlog reverted to ticketing. Ticketing was the retreat when inline noise stopped working: route every finding to a backlog, assign an owner, track closure, report the numbers up the chain. This led back to the problems shift left tried to solve – creating developer/security friction, while increasing the backlog of work.
The Agentic SDLC: security’s compiler moment
Last-generation AppSec was built around one artifact: the code. Every attempt to solve developer security friction centered around that artifact, but code was the wrong vehicle for the fix. The Agentic SDLC changes the artifact, just as compilers once did. When high-level languages arrived, the work climbed off the machine and up to intent, and programmers got to think about what a program should do instead of how to spell it in machine instructions. The Agentic SDLC makes the same climb: the implementation falls to the agent, and the developer’s real work becomes ideation, architecture, intent. That moves the artifact from hand-written code to intent and design, so security stops being the thing that arrives last and becomes the thing that arrives first. It moves security training from a once a year activity into an ongoing process on every prompt.
Secure by design becomes operational
When intent and design are the artifact, the constraint comes first. You can state what a system is allowed to do, what data it can touch, what it must never expose, before any of it is built, and the agent generating the code is bound by that statement rather than trusted to remember it. The developer gets clear constraints instead of late rejections, and secure by design turns operational instead of aspirational: enforcement is a property of the design the code is generated from.
Fixing becomes economic
When an agent generates the fix and checks it before a human is involved, the cost of remediation collapses to almost nothing, and most importantly, story points don’t need to get assigned. GitHub measured its own Copilot Autofix cutting median remediation from about 90 minutes to under 30, and agentic fixing is only moving further in that direction. Once a fix costs less to apply than to debate, the debate becomes the expensive line item, and a team that used to weigh whether a finding was worth the work just applies the change instead. Remediation becomes the default rather than an argument about if it’s worth it.
Patching becomes background
Patching for minor versions already runs in the background at the dependency layer, where automated updates can pull in safe changes, limited only by the maturity of your test suite. The Agentic SDLC extends that pattern to application code: a coding agent runs alongside the work, proposes the fix, and validates it against the build before anyone is paged. Patching stops being a project a person owns and becomes a process the system runs, and the dependency churn that once landed on a developer’s afternoon gets absorbed by the system that proposed the change.
Developer security friction is gone. Security isn’t.
The Agentic SDLC removes the structural reason developer security friction ever existed. That is not the same as removing the need for security, or the need for developers and security to work together. Both are as real as they ever were. What changed is the world around them. Software is now built by agents, and the old answers no longer fit: security practiced the way it always was, beside a developer-security relationship run the way it always was, will only manufacture new friction against an Agentic SDLC. Each has to turn agentic too.
Security’s job shifts from reviewer and gatekeeper to architect, encoder and enforcer. The context that let a senior practitioner judge a real vulnerability, what an application does and where it can be reached, used to live in too few heads and arrive only after the code was written. Now that same context has to be readable for the agents writing the code, encoded into the build and enforced as the code is written.
The relationship has to change the same way. A security champion program used to exist to push security knowledge into developers, training and nudging them into caring enough to fight the friction. An agentic security champion program starts from the opposite fact: the agents already hold that knowledge. The work becomes orchestration, knowing how to direct those agents well, when to pull a human expert into the loop, and how to build on judgment the team no longer has to carry in its own head. That is the program worth building now.
