Most security leaders are not struggling because they lack visibility. They are struggling because execution does not scale.  

Triage capacity, decision consistency, and remediation throughput are being outpaced by modern development velocity, especially as AI-assisted coding becomes standard practice. The operating environment has changed. There is more code, more change, more dependencies, and more AI tooling.  

These conditions are turning manual triage into a governance and audit liability. The only sustainable path forward is to move security decisions and remediation into the pull request. There, risk decisions are documented, fixes are verified, and accountability already exists through governed, reviewable AI-assistance that accelerates execution without surrendering control. 

The Reality Security Executives Are Living In 

Security and AppSec leaders are seeing the same pattern repeat across teams: findings accumulate, remediation cycles aren’t keeping pace with development, and audit conversations are becoming more demanding. The reason isn’t just rising expectations, but the reality that modern software delivery keeps expanding the attack surface while simultaneously making risk decisions harder to track and standardize.

This exposure isn’t an insufficient tooling or coverage problem. Application security testing has expanded significantly over the past decade, introducing more scan types, deeper integrations, and great vulnerability visibility. Despite this progress, a consistent pattern remains: organizations often release new software even when they know risk is present, simply because their operating model cannot keep pace with delivery. 

Checkmarx research found that 81% of organizations knowingly shipped vulnerable code, and 98% experiences a breach tied to vulnerable code within the last year. Risk exposure is not cause by a lack of awareness; it’s a breakdown in execution. As AI-assisted development becomes the norm, that pressure only grows.

Leaders at major software organizations have publicly stated that AI now generates a significant share of their code, with some estimates ranging from 20 to 30 percent of code in repositories and more than a quarter of new code.  

As software production accelerates, risk enters at the same pace. And when risk enters the system faster than teams can triage it, remediation becomes unpredictable. That unpredictability is what boards and regulators ultimately penalize. Detection has scaled. Execution has not. 

Detection Scaled, Execution Didn’t. Now What? 

Application security programs have made substantial progress over the last decade. Most enterprises now operate with broad coverage that includes SAST, SCA, CI/CD integrations, and developer-focused tooling. However, many programs are now over-detecting vulnerabilities relative to their ability to act on findings. This imbalance creates operational friction and weakens overall security outcomes. 

The symptoms are consistent across organizations. Triage bottlenecks form as teams struggle to review large volumes of findings. Identical issues are handled differently across teams, creating inconsistency in decision-making. Findings remain unresolved for extended periods because priority is unclear, or remediation effort is high. Backlogs grow with items that are technically valid but not treated as immediate risk, while other issues are escalated without sufficient context. 

This dynamic explains why more findings rarely reduce exposure. When everything is flagged, nothing gets fixed. Security leaders feel this as a credibility gap: dashboards show activity, but stakeholders want to know if the organization is getting more secure. That’s a hard question to answer when decision-making is inconsistent, and remediation throughput cannot be predicted. 

The NIST Secure Software Development Framework reinforced this shift, by requiring organizations to document how risk decisions are made and demonstrate evidence of secure development practices. Detection alone is not sufficient. Organizations must show that vulnerabilities were evaluated in context and resolved in a consistent, auditable way.  

Detection is not the end state. Evidence-backed execution is. 

Why Manual Triage Is Now a Business Risk 

At enterprise scale, manual triage is no longer simply inefficient. When security teams manually interpret findings across hundreds of repositories, inconsistency is inevitable and becomes an operational and governance risk. Depending on the team reviewing, identical findings receive completely different treatment. One team immediately remediates, another dismisses it, and another marks it as accepted risk without a standardized rationale. That inconsistency becomes a liability as regulators and auditors increasingly expect organizations to formally document how vulnerabilities are categorized and managed. When the answers to basic governance questions vary across the organization, regulators interpret that variability as a lack of control. Who made the decision? What evidence supported it? Which policy is applied? Without consistent answers, risk exposure becomes unpredictable and difficult to defend.  

These growing expectations arrive precisely when teams are least equipped to meet them. Security teams face ongoing budget pressures and staffing shortages while vulnerability volumes keep rising. Headcount cannot scale in proportion to code volume.  Instead, organizations need to scale execution by relying on more consistent, efficient, and automated approaches to vulnerability management. 

The Pull Request Is the New Control Plane 

If risk is introduced continuously throughout development, governance must be applied at the point where decisions are actually made. In modern engineering environments, that point is the pull request. 

The pull request is where code changes become official: approvals granted, discussions recorded, checks enforced, and ownership is established. It is the only place where execution can be observed and governed at the same speed as development.   

Security decisions belong where code is reviewed, approved, and merged, not buried in dashboards and ticketing systems. 

 Checkmarx’s Triage Assist and Remediation Assist operate directly within pull requests, ensuring that risk decisions are made in the same place where change control already exists. The principle is straightforward: if security execution is not visible within the pull request, it cannot be governed. 

From Alerts to Outcomes: What Changes 

This shift does not eliminate human involvement; It just changes where human judgment is applied. Instead of spending time manually investigating large volumes of findings, teams focus on policy definition, exception handling, and approval. 

Triage Assist introduces a contextual, risk-based prioritization model that converts scan output into decision-grade outcomes. It evaluates vulnerabilities using attackability-driven analysis, combining reachability, exploitability, and policy context to determine which issues require action. This approach moves triage away from severity-based sorting toward context-based decision-making. Findings are classified into clear outcomes such as false positive, acceptable risk, or action required, enabling consistent and defensible decisions across teams. The shift toward context-driven decisioning aligns with broader industry efforts such as the Vulnerability Exploitability eXchange (VEX), which communicates the exploitability of a vulnerability in context , not simply if it’s present. 

Remediation Assist addresses the next stage of execution. Once a decision is made, it generates reviewable, merge-ready fixes directly within the pull request workflow. These fixes are delivered as diffs or remediation pull requests that align with existing development processes. Nothing merges automatically; developers review and approve changes as part of their standard workflow, preserving governance while accelerating remediation throughput. 

Together, Triage Assist and Remediation Assist transform application security from a process centered on alerts to one focused on outcomes. 

Governed AI, Not Autonomous Chaos 

Security leaders don’t need autonomous systems making unchecked changes to code. They need governed execution that improves speed while maintaining control. This distinction matters more as AI expands both development capabilities and the attack surface that comes with it. 

New risks, including prompt injection, supply chain manipulation, and excessive agent permissions, require careful control over how AI is used within development workflows. Even systems that include human oversight can introduce risk if decisions are not transparent or if context is incomplete. Industry frameworks such as the OWASP Top 10 for Large Language Model Applications highlight emerging risks including prompt injection, supply chain manipulation, and excessive agent permissions, reinforcing the need for controlled and explainable execution. 

Read more: When the AI Lies: A New Threat Emerges for “Human-in-the-Loop” Security 

A governed approach to AI-driven security execution is grounded on clear principles. Human review remains mandatory through established approval workflows. Decision rationale is preserved to support auditability. Usage is scoped and controlled across repositories and environments. Automated changes are never merged without review. 

This model ensures that AI accelerates your execution without also introducing uncontrolled behavior. It aligns with the needs of regulated, audit-driven environments where traceability and accountability are essential.

What Success Looks Like for Security Executives 

The goal isn’t better visibility alone, but predictable execution with measurable outcomes: reduced time to decision, faster remediation cycles, and smaller vulnerability backlogs. Standardized, evidence-based triage reduces the need to repeatedly evaluate the same issues across teams, which improves both efficiency and consistency. 

Higher fix acceptance rates and fewer regressions indicate that remediation is delivered in ways that fit developer workflows, without destabilizing applications. Consistent outcomes across teams means that governance is being applied systematically rather than left to individual judgement.

Audit readiness matters just as much. Security artifacts must be tied directly to execution, including pull request discussions, approvals, and documented decisions. This reduces reliance on retrospective explanations when auditors and boards come asking. These outcomes are becoming more critical as exploitation windows continue to shrink. Vulnerabilities are often exploited shortly after disclosure, which mean delayed triage is no longer a workflow preference. It’s a business risk.

The Strategic Shift 

Security leaders do not need more alerts, they need more finished work. Moving away from manual triage is not about reducing security effort, but about operationalizing security in a way that scales with modern development. 

Effective application security requires decisions that are grounded in context, remediation delivered within the development workflow, and governance preserved through auditable processes. This is the shift toward agentic application security, where the gap between how quickly software is created and how quickly risk is understood and mitigated can be closed without slowing innovation. 

Ready to move from manual triage to scalable, governed execution? Explore Checkmarx’s Agentic AI Buyer’s Guide to see how leading teams are operationalizing this shift.