AppSec capacity limits, not negligence, drive vulnerable code shipping

At a glance

What this is: This is an independent analysis of why vulnerable code still ships, arguing that AppSec teams are constrained more by remediation capacity than by lack of awareness.

Why it matters: It matters to IAM practitioners because the same capacity bottlenecks appear in secrets management, privilege cleanup, and identity governance, where finding risk is easier than closing it.

By the numbers:

• Eighty-one percent of organizations knowingly ship code with vulnerabilities, according to Checkmarx's 2026 Future of AppSec survey of over 1,500 CISOs, AppSec managers, and developers worldwide.
• Developers only get to 32% of known vulnerabilities, according to the article's cited analysis.

👉 Read Pixee's analysis of why teams knowingly ship vulnerable code

Context

Application security often fails because the organisation cannot absorb the volume of findings it already knows about. In practice, that means teams prioritise delivery over remediation, and the gap becomes structural rather than accidental. The primary AppSec problem in this article is capacity, but the identity security lesson is familiar: when remediation is slower than exposure, secrets, service accounts, and access paths remain live far longer than governance expects.

The article also reframes a common blame pattern. If teams knowingly ship vulnerable code because they are under deadline pressure or discover issues too late, then the real control gap is the absence of enough remediation capacity, not awareness alone. That is typical across AppSec programmes and closely mirrors NHI and IAM environments where review and revocation queues outgrow the people and automation assigned to them.

Key questions

Q: What breaks when vulnerability discovery outpaces remediation capacity?

A: When discovery moves faster than validation and patching, the backlog becomes the control failure. Teams may still know where the weaknesses are, but they lose the ability to act before exploitation. That creates a timing gap between exposure and enforcement, which is where machine-speed attacks gain advantage. Capacity, not visibility, becomes the limiting factor.

Q: Why do deadline pressures increase security risk in AppSec and IAM programmes?

A: Deadline pressure pushes teams to optimise for delivery, not closure. That means known defects, excessive access, and stale credentials are deferred into later cycles where they become harder and more expensive to fix. The problem is a governance model that treats remediation as optional when release pressure rises.

Q: What should executives measure to know remediation automation is working?

A: Executives should look at time to first action, mean time to remediate, and the share of critical issues closed within the agreed service level. Those measures show whether the programme is reducing exposure, not merely producing cleaner dashboards. If the numbers do not improve, the workflow is still the bottleneck.

Q: What should security teams do when they cannot fix everything they find?

A: They should rank work by exposure path, business impact, and exploitability, then define explicit acceptance rules for what can wait. If the team cannot say which issues are allowed to remain open and why, the backlog is functioning as unmanaged risk rather than controlled prioritisation.

Technical breakdown

Why vulnerability backlogs become a governance failure

A backlog becomes a governance problem when the organisation can find risk faster than it can close it. AppSec tools surface issues continuously, but remediation still depends on human capacity, prioritisation, and release timing. If teams treat every finding as equally urgent, the queue stalls. If they delay fix work until late in the cycle, the cost rises and the backlog compounds. The operational issue is not ignorance. It is a mismatch between detection throughput and remediation throughput.

Practical implication: define which findings actually block release and assign explicit owner, severity, and fix windows.

How deadline pressure distorts application risk decisions

Deadline pressure changes the control environment because it makes shipping the measurable objective and security remediation the negotiable one. When teams believe vulnerabilities can be fixed later, they often defer work until the defect is buried under new code, dependencies, or release constraints. That dynamic is not unique to application security. It appears anywhere risk work is treated as backlog hygiene instead of production control. The result is predictable: known issues persist because the organisation optimises for delivery velocity over closure velocity.

Practical implication: tie release readiness to remediation completion for defined vulnerability classes, not to scanner output alone.

The capacity gap between detection and fix work

Detection is cheap relative to repair. Modern pipelines can generate large numbers of findings from code, dependencies, containers, and infrastructure, but each fix still requires context, testing, and validation. That creates a throughput gap that grows as tooling improves. In identity programmes, the same pattern appears when teams can enumerate stale accounts, leaked secrets, or excessive access faster than they can retire them. The technical lesson is that visibility without closure capacity produces backlog, not security.

Practical implication: invest in automation that validates and applies fixes, not just in more scanners or more alerts.

Threat narrative

Attacker objective: The attacker objective is to turn a known but unfixed application weakness into access, persistence, or exfiltration before the organisation closes the gap.

1. Entry begins when insecure code, vulnerable dependencies, or exposed secrets reach production because remediation could not keep pace with delivery.
2. Escalation follows when attackers exploit those weaknesses to gain execution, credential access, or broader application and cloud privileges.
3. Impact occurs when the vulnerability enables data theft, service disruption, or lateral movement into adjacent systems and identities.

NHI Mgmt Group analysis

Capacity, not character, is the dominant control failure. The article's core argument is correct: teams often know vulnerabilities exist but cannot clear them fast enough. That is a systems problem, not a morality tale. In identity governance terms, the same pattern appears when access reviews, secret rotation, or offboarding queues outrun the people and automation assigned to them. The practical conclusion is simple: measure closure capacity, not just detection volume.

Application security is increasingly a throughput discipline. Finding more issues without expanding remediation throughput creates a permanent backlog. That same lesson applies to IAM and NHI programmes where the number of accounts, tokens, and service identities scales faster than review cycles. If the operating model cannot reduce queue depth, governance becomes performative. Practitioners should treat fix velocity, not alert count, as the meaningful control signal.

Remediation backlog is the named concept here. A remediation backlog is the accumulation of known risk that remains open because the organisation has not sized the work to the available capacity. It matters because backlog turns security from a preventive function into a deferred liability. For IAM and NHI teams, the same concept explains why stale credentials, overprivileged service accounts, and delayed revocations become persistent exposure. The practitioner takeaway is to govern queue size, age, and ownership as first-class risk metrics.

Identity programmes should read this as a warning about closure latency. The article is about AppSec, but the governance model is directly relevant to IAM and NHI controls that depend on timely human action. If the workflow for access review, privilege reduction, or secret rotation is slower than the exposure window, the organisation is effectively choosing backlog over control. Teams should therefore align governance targets to actual fix and revoke capacity, not to audit expectations alone.

What this signals

Remediation latency is the real control signal. If teams can identify risk but cannot close it inside the exposure window, governance is only producing reports. That is why closure age, queue depth, and owner assignment matter more than raw finding counts, and why the same logic should be applied to secrets rotation and access revocation.

The broader trend is toward security programmes that are judged by throughput rather than tooling volume. That shifts emphasis to policy enforcement, automated validation, and the ability to retire risk before it becomes operationally visible. For identity teams, the comparable signal is whether stale permissions and credentials are disappearing faster than they are created.

This is also a warning about remediation backlog as an organisational concept. Once known issues accumulate faster than they are cleared, every downstream framework, including IAM, PAM, and NHI governance, starts to inherit deferred risk instead of controlled exposure.

For practitioners

• Measure remediation capacity, not just vulnerability count. Track how many findings each team can close per sprint, how long critical fixes wait in queue, and where validation bottlenecks appear. Use those numbers to size staffing and automation, rather than assuming more findings means better security.
• Prioritise fixes by blast radius and exploitability. Create a release rule that separates high-impact issues from background noise using environment context, authentication boundaries, and exposure path. This prevents low-value findings from crowding out fixes that actually change risk.
• Automate the repetitive part of remediation. Use scripted fixes, policy-as-code, and validation checks to shorten the time between finding and closure. The goal is to free engineers from routine correction work so they can handle context-sensitive defects.
• Tie governance to closure age. Set thresholds for how long a known issue, stale credential, or excessive permission can remain open before escalation. Age-based escalation is more useful than counting total findings because it exposes whether the programme is actually reducing exposure.
• Extend the same model into IAM and NHI workflows. Apply the same queue and throughput thinking to service account reviews, secret rotation, and offboarding. If those processes rely on the same overloaded review cycle as AppSec, the backlog will simply move to another control domain.

Key takeaways

• The article argues that vulnerable code ships because teams are capacity-constrained, not because they lack awareness.
• The evidence points to a widening gap between finding problems and fixing them, which turns backlog into an operational risk.
• Practitioners should measure closure throughput, age of open issues, and automation coverage across AppSec, IAM, and NHI workflows.

Key terms

• Remediation capacity: The amount of vulnerability, misconfiguration, or access risk an organisation can realistically validate, prioritise, and correct within a given period. It is a governance measure as much as an operational one, because discovery without action does not reduce exposure.
• Verification latency: The time between a claimed fix and independent confirmation that the exposure is actually gone. Long verification latency creates a false sense of closure and extends the period in which teams may think risk has been removed when it has not.
• Remediation Backlog: A remediation backlog is the accumulated queue of security issues that have been identified but not yet resolved. In file-centric environments, the backlog grows quickly because each object may require validation, ownership assignment, and a containment decision before risk is actually reduced.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

What's in the full article

Pixee's full blog post covers the operational detail this post intentionally leaves for the source:

• The specific survey framing behind the 81% finding and the surrounding response data from Checkmarx.
• The full breakdown of why teams ship vulnerable code, including deadline pressure and late discovery patterns.
• The remediation capacity argument in more detail, including how the article distinguishes triage from negligence.
• The related analysis links and resources that expand the AppSec backlog discussion into practical follow-up material.

👉 Pixee's full post expands the capacity argument, the survey context, and the remediation implications.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle. It gives practitioners a structured way to turn identity risk into enforceable control.