Most AppSec teams are not failing to detect risk. They’re just failing to remediate it fast enough. 

Security programs now find more vulnerabilities than they can fix, and remediation hasn’t kept pace with how fast teams ship code. AI-generated code has made that gap worse, adding volume and complexity faster than security processes have adapted. 

Coverage has expanded, scanning is continuous, and visibility is no longer the bottleneck – but the ability to act on that visibility at scale hasn’t kept up. Backlogs grow, MTTR stays stubbornly high, and the same classes of vulnerabilities reappear across releases, even as detection improves. 

The gap isn’t that security teams lack maturity. It’s that AppSec was never built to operate at this scale. 

Detection Has Scaled. Execution Has Not. 

A growing share of organizations now acknowledge shipping software with known vulnerabilities to keep delivery moving But the pace of exploitation is accelerating at the same time. Research shows that the average time to exploit newly disclosed vulnerabilities has dropped dramatically in recent years, with attackers increasingly weaponizing vulnerabilities within days of disclosure and sometimes within hours. In 2025, nearly one-third of known exploited vulnerabilities were exploited on or before the day they were publicly disclosed, leaving organizations little time to evaluate and remediate risk.  

The distance between discovery and remediation is no longer a theoretical chasm. It is operational, measurable, and increasingly visible to boards, regulators, and customers. 

Detection Solved Visibility, Not Outcomes 

For more than a decade, AppSec investments focused on improving detection – and that initially worked. Coverage expanded across proprietary code and open-source dependencies, scanning became faster, findings became richer,  and dashboards and reporting improved. But risk outcomes did not. 

Security teams now operate in an environment where visibility is abundant, but action is constrained. Thousands of findings accumulate without clear prioritization, causing analysts to spend hours validating reachability and exploitability. At the same time, developers receive findings without enough context to determine what actually matters. Different teams end up making different decisions on identical issues and the result is a system that knows more but fixes less. 

This mismatch is becoming more pronounced as AI continues to accelerate development velocity. Leaders at major software organizations have publicly stated that a significant portion of new code is now generated with AI assistance and only reviewed by engineers before release. 

More code, shipped faster, means more potential risk, and more risk requires more capacity to remediate, not just more capacity to detect. Detection surfaced the problem. It didn’t solve it.  

The Execution Gap Is the New AppSec Bottleneck 

The execution gap is not a single failure point, but the accumulation of small inefficiencies that compound at scale.  

Triage still depends on human judgment that gets repeated inconsistently across teams, with prioritization varying based on who happens to review a given finding. Fix guidance is often advisory, leaving developers to interpret and implement solutions themselves. And governance tends to exist in policy documents instead of the workflows where decisions are actually made. Individually, these issues are manageable. At AI-scale, they become systemic, thereby compounding AppSec challenges, not because teams lack tools, but because the system connecting detection to action is inconsistent. When execution varies, risk becomes unpredictable and auditability degrades. When workflows depend on manual interpretation, service-level commitments become unenforceable. 

 What looks like a technical problem is, at its core, actually an operational one. 

The Pull Request Is the Only Place Execution Can Scale

For years, AppSec findings have flowed into tickets, dashboards, and reports – but that’s not where fix decisions get made.  

Execution happens in the pull request, where code is reviewed, discussed, approved, and merged. It is where context exists, accountability is enforced, and decisions are recorded by default. Pull requests can be configured to block merges until required checks pass, including security scanning results.  

In practice, this means remediation decisions and risk acceptance already occur in the pull request workflow, whether security teams formally recognize it or not. So why are security decisions still being made outside of this workflow? 

From Detection to Decision Infrastructure 

Modern AppSec needs a system that can turn findings into decisions. Not every vulnerability is exploitable; some represent real, reachable risk, others are false positives, and others fall within acceptable risk thresholds depending on context. Today, this distinction is made manually and inconsistently.

Decision infrastructure changes that. It classifies findings with reasoning, distinguishes between what must be fixed and what can be deprioritized, and surfaces those decisions directly in the pull request. It enables guided, reviewable remediation that is aligned with how the application actually works.

The industry has largely moved toward context-driven prioritization, with modern vulnerability management frameworks emphasizing exploitability and real-world impact over severity scores alone. But translating detection signals into actionable risk decisions requires decision infrastructure, and without it, the value of detection is incomplete.

Where Triage and Remediation Actually Happen 

Modern AppSec programs are beginning to embed agentic workflows directly in the pull request, delivering security decisions and fixes where code is actually reviewed and merged. Checkmarx One is built on this model. Triage Assist addresses the first execution bottleneck: deciding what requires immediate action. It evaluates findings using contextual analysis to determine whether a vulnerability is reachable, exploitable, and relevant within the application environment. Instead of presenting developers with raw scan output, it produces decision-ready outcomes that identify which issues must be fixed, deferred, and or represent acceptable risk under policy. 

This shift replaces manual triage queues with consistent, evidence-based decision logic that can be applied across repositories, teams, and applications. Decisions become standardized, rationale becomes visible and governance becomes enforceable. 

Remediation Assist addresses the second execution bottleneck: turning decisions into completed work. Once an issue is identified as requiring action, remediation guidance is delivered directly in the pull request as a reviewable code change that aligns with the application’s frameworks and dependencies. Developers evaluate the proposed fix using their existing review process, preserving accountability and control while accelerating resolution. Human approval remains mandatory, but developers don’t need to start from scratch when addressing security issues. The path from detection to remediation becomes shorter, more predictable, and easier to govern. 

Together, these capabilities transform the pull request into a true execution layer for application security. Risk decisions are made where code changes occur, fixes are delivered where developers work, and evidence is recorded where auditors expect it.  

And this approach scales. 

Why Governance Must Be Embedded, Not Enforced Later 

When governance exists outside the workflow, it is optional by default. It relies on teams remembering to follow it, interpreting it correctly, and applying it consistently. At scale, that approach breaks down. 

But when governance is embedded in execution, it becomes part of how work gets done. This principle is increasingly reflected in secure software development standards. Frameworks such as the NIST Secure Software Development Framework emphasize the importance of maintaining evidence and artifacts that demonstrate how security decisions were made and implemented throughout the development lifecycle. 

That requirement changes what AppSec governance actually means.  Policy alone isn’t sufficient; what matters is documented execution that preserves human oversight, where prioritization criteria are applied consistently, remediation is scoped and controlled, and decisions are captured automatically without additional administrative overhead. This is the difference between policy and control. Triage and remediation capabilities built directly into development workflows don’t replace decision-making, they structure it, bringing prioritization, reasoning, and fix guidance into the pull request where decisions are already happening. The result is governed execution, not autonomous remediation.

What Changes When Execution Is Operationalized 

When execution is built into the workflow, the system begins to behave differently. 

Manual triage effort drops because classification is no longer repeated across teams. Time to decision shrinks because context and reasoning are already available. Remediation becomes more consistent because developers are not guessing what matters or how to fix it. Risk acceptance becomes explicit, not implied. Auditability improves because decisions are captured as part of normal development activity.  

Perhaps most importantly, the relationship between security and engineering changes. When developers receive clear, contextualized guidance in the pull request, security stops being perceived as noise and starts being seen as actionable input, reducing friction. The conversation shifts from asking why a finding exists to deciding what action should be taken. 

This shift is increasingly necessary as development complexity grows. Software supply chain risk, third-party dependencies, and AI-assisted development are expanding the attack surface faster than traditional workflows can keep pace.

Recent reporting shows that most organizations have experienced supply chain attacks within the past year, reinforcing the need for consistent, scalable remediation processes.  By adopting this approach, AppSec can scale effectively without requiring a proportional increase in headcount. 

The Necessary Shift to Agentic AppSec 

Detection is table stakes in 2026. The organizations that optimize detection alone will continue to generate more findings than they can act on. Backlogs will grow and the gap between visibility and execution will widen. Security teams will remain overwhelmed, and risk decisions will remain inconsistent.  

The organizations that operationalize execution will close that gap. They will make decisions where work happens. They will standardize how those decisions are made. They will embed governance into the workflow instead of enforcing it after the fact. And they will measure success not by how much they find, but by how much they fix.  

This shift is defining modern, agentic application security. 

Read the next article: Attackability: Why Context, Not Reachability, Should Drive Remediation

Learn how modern AppSec teams prioritize vulnerabilities based on reachability, exploitability, and real-world impact to reduce noise and focus remediation where it matters most.