AppSec execution is the new bottleneck in AI-scale remediation

At a glance

What this is: This is an AppSec analysis arguing that modern security programmes now have a remediation and decision-making bottleneck, not a detection gap.

Why it matters: It matters because identity, code, and application security teams must govern how findings become actions across developer workflows, especially as AI-assisted development increases code volume and operational pressure.

By the numbers:

• In 2025, nearly one-third of known exploited vulnerabilities were exploited on or before the day they were publicly disclosed.

👉 Read Checkmarx's analysis of why AppSec execution is now the bottleneck

Context

Application security is increasingly constrained by remediation capacity rather than detection capability. Teams can see more issues than ever, but that visibility does not reduce risk unless findings are translated into consistent decisions and fixes. The primary challenge is now operational, with AI-assisted development adding more code and more potential exposure into already stretched delivery pipelines.

For identity and governance teams, the relevance is indirect but real. AppSec findings often intersect with secrets, service accounts, tokens, and deployment permissions, which means the decision layer is also an identity control layer. When security decisions are made outside the workflow where code changes happen, accountability weakens and audit evidence becomes harder to defend.

Key questions

Q: How should security teams implement AppSec governance in pull request workflows?

A: Security teams should make the pull request the place where findings are reviewed, prioritised, and approved. That means defining merge criteria, attaching remediation guidance to the code change, and preserving the decision record automatically. The goal is not to automate responsibility away, but to make security decisions repeatable where developers already work.

Q: Why do AppSec programmes struggle when detection improves faster than remediation?

A: Detection creates more findings, but each one still needs human judgment, ownership, and a fix path. If those steps stay manual and inconsistent, backlogs grow and teams start shipping with unresolved risk. The problem is not visibility. It is the lack of a decision layer that can turn findings into action at release speed.

Q: What breaks when exploitability is not tested before remediation is closed?

A: Teams may close tickets that reduce paperwork but not attacker capability. That creates a false control assurance signal, especially when the vulnerability can be chained into account compromise or other business-impacting outcomes. Retesting is the check that proves the fix changed real risk, not just documentation.

Q: Who is accountable when a vulnerable embedded component ships in production?

A: Accountability usually spans build engineering, product security, and release management because no single team owns the full chain from source revision to deployed image. Governance works only when one function can answer which artefacts were rebuilt, which products consumed them, and which devices still need replacement.

Technical breakdown

Why detection scales faster than remediation

Modern scanners can produce continuous coverage across source code, dependencies, and build pipelines, but they do not remove the human work required to decide what matters. Triaging a finding still requires context, reachability analysis, exploitability judgment, and ownership assignment. When that work is repeated manually across teams, the same issue can be treated differently in different repositories, which turns a security signal into operational noise. AI-generated code increases the throughput problem because it expands the number of changes requiring review without reducing the cost of interpretation.

Practical implication: measure remediation throughput, not just scan coverage, and assign clear ownership for triage decisions.

Why the pull request has become the real control point

The pull request is where code is reviewed, debated, approved, and merged, so it is the most natural place to apply policy consistently. Tickets and dashboards can record findings, but they rarely control the merge decision itself. When security guidance arrives too late or outside the workflow, developers are forced to translate advisory output into action, which adds delay and inconsistency. Embedding reviewable remediation in the pull request creates a governed decision layer where evidence, approval, and change history sit together.

Practical implication: move security decision-making into pull request workflows and make merge criteria explicit.

How decision infrastructure changes AppSec governance

Decision infrastructure is the layer that classifies findings with reasoning and routes them to the correct action. It distinguishes exploitable issues from low-risk noise, surfaces remediation guidance in context, and preserves the rationale for audit and review. That matters because governance is no longer just about producing findings or writing policy. It is about proving that the programme can make repeatable decisions at speed while keeping human oversight intact. This is especially relevant where security controls intersect with code ownership, secrets handling, and release approvals.

Practical implication: standardise decision criteria for exploitable findings and retain evidence of each remediation choice.

Threat narrative

Attacker objective: Exploit the gap between vulnerability discovery and remediation to reach production systems before defenders close the window.

1. Entry occurs through rapid code production and continuous vulnerability introduction, including AI-assisted changes that outpace manual review.
2. Escalation happens when noisy findings overwhelm triage queues and exploitable issues remain unresolved across releases.
3. Impact follows when known vulnerabilities ship into production because remediation decisions are slower than delivery.

NHI Mgmt Group analysis

Execution debt has overtaken detection debt as the dominant AppSec problem. Most programmes already know where their findings are, but they cannot convert that knowledge into consistent remediation at speed. That creates a governance gap where backlog size becomes a proxy for risk, even though the real issue is whether the organisation can make and prove decisions before release. Practitioners should treat remediation capacity as a control objective, not an operational afterthought.

Pull-request governance is now the most credible control plane for AppSec decisions. Policy documents do not stop risky code from shipping if the merge decision happens elsewhere. The pull request is where context, approval, and evidence already exist, so it is the right place to embed security reasoning and enforce standards consistently. For teams managing identity-adjacent controls such as secrets, tokens, and deployment permissions, that workflow is also where access and code governance converge.

AI-assisted development is amplifying governance inconsistency, not just code volume. More generated code means more findings, but also more opportunities for teams to diverge in how they interpret the same issue. That makes remediation a repeatability problem as much as a speed problem. Decision infrastructure: the ability to classify findings, assign action, and preserve rationale in the workflow. Practitioners should expect this to become a baseline expectation for scalable AppSec programmes.

AppSec maturity will be judged by outcome quality, not scan density. Boards and regulators care less about the volume of findings than about whether known issues are remediated before they become incidents. The operational question is whether security teams can demonstrate controlled execution across repositories and release cycles. That means prioritising measurable time-to-decision, not just mean time to detect.

What this signals

AppSec teams should expect governance pressure to shift from reporting quality to execution quality. If findings cannot be resolved inside the same workflow that ships code, the programme will keep creating visibility without reducing exposure.

Execution latency: the delay between identifying a vulnerability and making a recorded remediation decision. This is becoming a better indicator of programme health than scan count alone, especially where AI-assisted development raises the volume of code changes and the number of issues requiring triage.

For identity teams, the important signal is that secrets, tokens, and deployment permissions increasingly sit inside the same release flow as application risk. That makes code governance and identity governance operationally connected, even when the underlying tools are managed separately.

For practitioners

• Measure time to decision, not only mean time to detect Track how long findings remain unresolved from discovery to an explicit fix, defer, or accept decision. Break the metric down by repository, team, and severity so you can see where manual triage is slowing the programme.
• Embed merge-gating controls in pull requests Require security checks, ownership acknowledgement, and approval criteria inside the pull request rather than in a separate ticketing flow. That keeps the decision attached to the code change and preserves an auditable trail.
• Standardise exploitability-based triage Define which signals make a finding actionable, such as reachability, exposure, and known exploit paths. Consistent triage rules reduce conflicting decisions across teams and make remediation more predictable.
• Route secrets and token issues through identity governance Treat credentials, API keys, and service tokens as identity objects with owners, lifecycles, and approval paths. That prevents application findings from becoming unmanaged access problems.

Key takeaways

• The core problem is no longer finding vulnerabilities, but proving that the organisation can close them fast enough.
• AI-assisted development raises the volume of findings and makes inconsistent triage more damaging.
• Pull request-based decision infrastructure is emerging as the practical control point for scalable AppSec governance.

Key terms

• Decision Infrastructure: The operating layer that turns security findings into explicit, reviewable actions. It classifies risk, routes ownership, preserves rationale, and makes sure decisions happen inside the workflow where the work is done. In AppSec, it is what connects detection to controlled remediation.
• Execution Gap: An execution gap exists when policy is defined correctly but cannot be carried out consistently in the target system. In identity governance, this usually appears where integrations are missing, evidence is fragmented, or lifecycle actions depend on human coordination instead of deterministic enforcement.
• Pull Request Governance: The practice of applying security, approval, and evidence requirements directly in the code review and merge process. It matters because the pull request is where code decisions become release decisions. When governance lives there, it becomes enforceable instead of advisory.

What's in the full article

Checkmarx's full article covers the operational detail this post intentionally leaves for the source:

• How Triage Assist and Remediation Assist are positioned inside the pull request workflow
• The practical distinction between findings that must be fixed, deferred, or accepted under policy
• How the source article frames decision infrastructure, governance evidence, and human approval in AppSec execution
• The article's discussion of AI-generated code, delivery velocity, and how these pressures affect remediation flow

👉 Checkmarx's full article covers pull request remediation, decision infrastructure, and governance evidence in more detail

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity security. It is designed for practitioners who need to connect identity controls to broader security governance.