Notifications
Clear all
Topic starter
02/08/2026 11:51 am
TL;DR: AppSec teams are finding more vulnerabilities but fixing them too slowly, and nearly one-third of known exploited vulnerabilities were used on or before public disclosure in 2025, according to Checkmarx. Detection has scaled, but decision-making and remediation workflows have not, so governance now depends on execution inside the pull request, not on more scanning.
NHIMG editorial — based on content published by Checkmarx: AppSec execution is the new bottleneck in AI-scale remediation
By the numbers:
- In 2025, nearly one-third of known exploited vulnerabilities were exploited on or before the day they were publicly disclosed.
Questions worth separating out
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.
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.
Q: What breaks when exploitability is not tested before remediation is closed?
A: Teams may close tickets that reduce paperwork but not attacker capability.
Practitioner guidance
- 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.
- 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.
- Standardise exploitability-based triage Define which signals make a finding actionable, such as reachability, exposure, and known exploit paths.
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
👉 Read Checkmarx's analysis of why AppSec execution is now the bottleneck →
AppSec execution at AI scale: what teams need to change now?
Explore further
02/08/2026 1:00 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AppSec execution is the new bottleneck in AI-scale remediation
