Managing Agentic Security at Scale

On the code we scan at depth, the volume of findings is now the constraint: frontier models plus an agentic harness surface more real, exploitable findings than engineering can absorb. We can find vulnerabilities faster than engineering teams have historically been able to act on them. The harder question now lives downstream: when a pipeline returns far more findings than a team can process, which ones deserve engineering attention, and on what timeline?

Across the industry, AI has accelerated vulnerability discovery faster than the rest of the lifecycle has evolved. Validation still depends on environment access, credentials, and expert judgment, and remediation follows the review and release processes that keep production stable. The result is a lifecycle running at two speeds: machine-speed discovery and human-speed remediation. Closing that gap starts with deciding which findings deserve attention, and how to group them.

This is the question we’re working through at Salesforce. The leverage came from how we organize what happens after a finding leaves the pipeline. We built it around two approaches. 

Two approaches, two clocks:

Today’s vulnerability remediation runs at two speeds: machine and human. At Salesforce, to meet this, we’ve found it makes sense to adopt two separate approaches that use two clocks. One of these focuses on the broader, systemic picture on a longer timeline: we call this our strategic approach. The other is more focused on narrower elements on a tighter timeline: we call this our tactical approach. Using these two approaches together has enabled us to better address the two-speed nature of today’s vulnerability threat environment.

Strategic: systemic risk identification. When most of what a deep audit surfaces traces back to a concentrated set of architectural decisions, the engineering move with the most leverage is to fix the architecture itself: frequently this will resolve vulnerabilities in bulk as a consequence with no more action needed. 

Tactical: exploit chain closure. The clock here is not ours. Somewhere on the other side of the internet, a motivated researcher or bad actor is, in expectation, working on the same chain in parallel. Whichever side reaches a working exploit first sets the outcome. That is why a multi-step exploit chain, a sequence of individually low-severity steps that can be assembled into a working attack against a service-specific risk, has to be closed where it lives, on a cadence that ranges from hours to occasional weeks.

First, a quick look at the pipeline both approaches run on.

The vulnerability pipeline at a glance

The pipeline is intentionally divided into stages as each of our two strategies is most effective at a specific stage.

• The strategic approach operates across two clustering levels: defect-level deduplication during verification, and systemic grouping at the reporting stage—where findings are clustered by shared libraries and sinks into high-leverage choke points (systemic risks) so a single fix retires many findings at once
• The tactical approach focuses on the Validate and Re-attack stages. This is where we prove a specific exploit chain works end-to-end and close it before an attacker can complete it.

Strategic: systemic risk identification and reduction

This is the approach with the greatest engineering return-on-investment (ROI) per unit of effort, and we think most published work in this area underplays it.

When we audit a mature codebase at scale, the findings tend to cluster: most of them trace back to a small number of shared root causes (the same platform default, the same unsafe primitive, the same missing check) rather than being spread randomly across the codebase. The right unit of remediation, then, is rarely an individual bug. More often, it’s a change to a platform default, a guardrail at a shared boundary, or a library migration that propagates everywhere downstream. We saw this concretely in our own audits.

Deep audits of large codebases tend to show heavy clustering: most findings trace back to a small set of shared design decisions, such as a common library default or a widely reused call pattern. Fix that shared point once, and the findings downstream of it retire together. We saw the same dynamic across multiple audits on different codebases. A single bad primitive can produce hundreds or thousands of findings on its own, and risk fans out from a few choke points than a verdict on the codebase. The useful inversion: fix the choke point once, and the same hundreds or thousands of findings retire with it. That’s the lever engineering should pull on.

On a second audit, against a different codebase, we saw the same pattern (sharper, if anything). The overwhelming majority of findings collapsed into a small group of related architectural patterns, with a thin tail of one-offs left over. Different codebase, different specifics, same underlying dynamic.

This is consistent with what we’ve seen before: vulnerabilities have been observed to concentrate this way for decades. What’s worth flagging is that the same pattern shows up on security-relevant findings in large and internally-consistent codebases. This concentration of vulnerabilities is a decades-old phenomenon, appearing prominently in large, internally consistent codebases built on shared platform primitives where a single fix propagates widely.

Where the structure does hold, the economics of remediation shift sharply.

Per-finding remediation retires findings one at a time; each fix is small, individually owned, and slow to compound. Systemic remediation retires findings in bulk: each unit of engineering work eliminates many findings at once by changing the architectural decision that produced them.

Filing every finding as its own bug creates a queue of small, individually-owned units of work, each needing review, deploy, and re-test. That model breaks under scale; the queue grows faster than any team can drain it, and most items age out before anyone touches them. Filing a handful of architectural risks instead gives an engineering leader something they can actually resource, sequence, and run on a release cadence. On our side, that’s what gave us a remediation canvas an engineering leader could own. Figure 3 shows per-finding remediation retires findings one at a time, while a single architectural fix retires many at once.

This has held up well for us. At Salesforce, security generates the map, engineering owns the drive. It also highlights an essential dependency: systemic risk findings require clear engineering governance to translate insights into technical roadmaps. Scaling the discovery pipeline takes raw compute; absorbing what comes out of it at production scale takes deliberate organizational design, and the second part has to be built on its own.

Tactical: exploit chain closure

The second strategy carries equal weight, and a very different clock. Strategic reduction is the right move against architectural patterns that produce many findings at once. It does not close a specific, validated exploit chain that lives in one service, on one code path. Tactical closure isn’t a fallback for what strategic can’t handle; it’s a structural complement.

For multi-step exploit chains, the validated end-to-end exploits that compose multiple steps into a working attack against a specific service, the unit of remediation is the chain itself. Each chain has to be discovered, validated as exploitable, fixed at the service, and re-tested. Every chain is its own remediation, with its own runway.

What makes this strategy urgent isn’t the count of chains. It’s the adversary on the other side of every chain.

The tactical strategy runs on a different cadence than the strategic one. Both have to coexist in the same program, because the underlying risks are shaped differently.

For our highest-criticality targets, we validate the chain against a running staging instance. That last step is the difference between “reachable in theory” and “landing in practice.”  

This is bigger than it sounds. Static-only chain construction has a non-trivial false-positive rate. A path that looks reachable in the call graph can turn out to be guarded at runtime by configuration, feature flags, or middleware the static reasoner missed. Running the exploit is what separates the false positives from the real chains: the theoretical paths fail here, and only the actual exploit chains land. An exploit that runs hands engineering something unambiguous, and once a developer sees a working exploit, the debate ends. On the high-confidence findings that survive this filter, the success rate (an actual working exploit, on a real target) has been high.

An external validation worth mentioning: on a recent run, our pipeline surfaced a critical finding that turned out to match an independently-filed bug-bounty submission from an external researcher. Same chain, found two different ways. That’s the kind of evidence we trust.

The constraint on this approach is per-target setup cost: standing up a service cleanly enough to test takes meaningful time, and much of the context needed lives with the team that owns it. That makes it impractical across an entire estate, so we scope it to high-criticality targets. The path forward is shared: when service teams ship a working container or compose definition alongside their service, validation can be automated, and both teams spend their time on the fix.

The portfolio: why both, why neither alone

These approaches are complementary and equally essential.

Strategic reduction efficiently addresses architectural debt but can miss specific, validated exploit chains that library migrations cannot retire. Relying solely on this leaves active exploit chains in production.

Conversely, a tactical-only approach fails to scale. Remediating every finding individually collapses budgets and overflows engineering queues without achieving compounding results.

A portfolio approach succeeds by balancing long-term ROI from strategic cleanup with immediate threat reduction via tactical patching. Mismatching these risks by treating only one as the complete solution is a common failure mode.

Takeaways for security leaders running similar work

If you are running, or planning to run, a pipeline that combines frontier-model reasoning, automated static analysis, and validated exploit execution across a production estate, the vulnerability-volume problem will become the binding constraint long before the discovery problem will.

Here is what we would offer from the last year of operating one:

• Frame remediation as a portfolio of two approaches. Strategic cleanup compounds engineering ROI on a release cadence; tactical patching closes live chains under adversary time pressure, and a serious program runs both.
• Match the unit of remediation to the shape of the risk. Systemic risk wants an architectural fix on engineering cadence and multi-step exploit chain wants a patch on adversary cadence; mismatching the two is the single most common reason we’ve seen these programs stall.
• Treat systemic risk as a first-class output type. Build the cluster object before you scale the volume, because a bug tracker that only ingests individual findings has already lost the leverage.
• Findings without an owner go nowhere. If you don’t have named engineering leaders ready to take systemic-risk reports as architectural work on a real release plan, fix that before you scale discovery any further.
• Treat tactical chains with adversary-clock urgency. Validated, exploitable chains aren’t backlog items; the metric is the window between our discovery and the adversary’s, set against the time it takes to ship a patch.
• Invest in the harness. The methodology compounds; the underlying analysis engine is a swappable component. Design the pipeline so engines can be swapped without rework, and evaluate engines against your task mix on operator-in-the-loop cost and reliability.