The Tug of War of Security in the PDLC

The Problem: 3 Dynamics at Play in the PDLC

Every product development lifecycle (PDLC) goes through a series of loops - design (design loop), development (“inner loop”), and deployment (“outer loop”) - and at each stage (or loop), three dynamics evolve and interact in different ways.

The first is the economic benefit of finding security issues early. It is well known that the earlier you find and fix a security issue, the less costly it is - or put another way, the greater the economic benefit. During design, the savings are immense because issues can be resolved before they ever reach code. But this benefit steadily declines as the product moves toward development and deployment stages, when fixes become more costly, disruptive, and sometimes require architectural rework.

The second is the focus (and hence spend) of security teams. In today’s environment, the security team’s spend at the beginning of the PDLC is low - and security involvement in the design phase often stays low to none. As ‘Shift-Left’ practices caught on, investments in the DevSecOps pipeline trended upwards with more tools (DAST, SCA, etc.) embedded into CI/CD workflows. But as products inch toward production (or the ‘outer loop’), security involvement picks up sharply with a plethora of monitoring, policy, controls, and observability tools. Ironically, costs peak at the exact point where returns are smallest.

Finally, there’s the developer’s perception of security. Early on, developers often feel that security slows down their ability to ship products to market. Their resistance is highest during design, when requirements feel abstract and potentially obstructive, and only softens as they move into development and deployment where security feels more like a checklist or compliance gate.

The paradox is therefore quite clear: the moment when security provides the highest value is also the moment when it feels like the biggest blocker.

Why Does This Happen?

In my personal experience, having run product organizations for years, I’ve seen this play out repeatedly.

The root cause is that involving security early requires a very different skill set and people dynamics than most organizations are structured for.

Security professionals who can meaningfully contribute in the early design phases of the PDLC need to understand the product & market needs deeply, almost like product managers themselves. This is an unfair ask from them, because most security teams are spread thin across multiple product lines within an organization. Expecting them to have the full context into every PRD, user story, and design discussion is simply unrealistic. This is the context-gap issue.

Assuming the above is somehow solved and they get the required product context, the expectation from them is to add security and compliance requirements (i.e. non-functional requirements) to the functional product requirements. This requires careful trade-offs, and they must do this while navigating the hardest part of any organization: people’s egos, personalities, and opinions. Too often, security input at the design stage is met with skepticism or pushback in the form of, “Why is a security personnel telling me to modify my product requirements? This is going to delay the delivery.” This is the collaboration-gap issue.

To make matters worse, security teams typically don’t speak the same language as product and engineering teams. Their vocabulary is often rooted in policy, frameworks, and compliance, not in customer requirements, feature trade-offs, and delivery velocity. This mismatch makes communication clunky and results in the communication-gap issue.

As a result of these issues, security involvement is often deferred until much later in the process. By the time they step in, features are already built or close to shipping. At that point, the economic benefit of identifying risks has eroded, and the total cost of product delivery goes up.

The Net Effect: Conflicting Curves

These three issues - context-gap, collaboration-gap, and communication-gap - are exactly why the dynamics move in opposite directions.

• The savings curve goes down because the context-gap issue keeps risks undiscovered until late.
• The spending curve climbs because the collaboration-gap issue pushes hard trade-offs and fixes downstream.
• The developer perception curve stays high in frustration because the communication-gap issue positions security as a late-stage burden rather than a design enabler.

Instead of reinforcing one another, these dynamics collide. Security becomes expensive when it should have been cheap, and developers resent it when they should have welcomed it as a partner in smart design.

How Agents Can Help

The way forward is not to ask humans to simply “try harder” or “hire more”, but to give them intelligent assistants - AI agents - that can address the very issues holding security back from being effective in the design phase.

• The Context-Gap Issue: Security professionals are rarely experts in the product’s domain. Agents can close this gap by absorbing design documents, user stories, and architecture context, then surfacing relevant risks and requirements. This way, security feedback feels connected to the product rather than generic or abstract.

• The Collaboration-Gap Issue: Instead of requiring endless back-and-forth between security and product teams, dev and sec agents can interact and translate design requirements into security insights automatically. This reduces friction and allows teams to stay focused on building, while still ensuring that security considerations are embedded from the start.

• The Communication-Gap Issue: To prevent security teams from being seen as an outsider, security agents can incorporate themselves directly into the workflows developers and product managers already use, and translate security concerns into the same functional language that product teams use to define requirements and priorities. This makes communication seamless and security becomes a natural part of the shared vocabulary of product development, rather than an external imposition.

Across design, development, and deployment, agents provide a consistent layer of intelligence and automation that connects these phases together. They make it possible to align economic savings, reduce unnecessary spending, and minimize developer friction - all without slowing innovation.

Closing Thought

The product lifecycle often feels like a tug of war between saving money, spending money, and losing time. The underlying causes are the context-gap issue, the collaboration-gap issue, and the communication-gap issue that prevent security from being effective where it matters most - at the beginning.

AI agents offer a path to bridge these issues - bringing in context, defusing collaboration friction, and streamlining communication so security becomes a natural part of product development.

At the same time, organizations are also evolving structurally. In my previous blog on the emergence of the Product Security Officer, I wrote about how companies are beginning to create new roles dedicated to embedding security into the product lifecycle. This structural change complements the agentic approach - ensuring that both technology and organizational design move in lockstep to resolve the long-standing gaps.

When these two forces come together - AI agents driving efficiency and new roles like the Product Security Officer driving accountability - the dynamics no longer work against each other. Security becomes proactive, cost-effective, and innovation-friendly - finally giving the PDLC what it has always needed: security accelerating innovation instead of holding it back.