AppSec capacity limits, not negligence, drive vulnerable code shipping

At a glance

What this is: This analysis argues that vulnerable code is being shipped because AppSec teams cannot remediate findings fast enough, not because they ignore risk.

Why it matters: For IAM, NHI, and broader security programmes, the lesson is that control efficacy depends on fixing bottlenecks in triage and remediation, not only on finding more issues.

Context

Application security often fails at the handoff between finding a vulnerability and getting it fixed. The governing problem is not merely detection volume, but whether development teams can absorb and act on findings before release pressure closes the window. That same capacity constraint shows up in identity and secrets programmes when queues grow faster than remediation.

In practical terms, the article reframes vulnerable-code shipping as a systems issue. When teams face deadline pressure, late discovery, and overloaded backlogs, the security control becomes throughput, prioritisation, and automation rather than awareness alone. The pattern is increasingly typical across modern software delivery, especially where code, secrets, and identity-bound access are tightly coupled.

Key questions

Q: What breaks when AppSec teams can find vulnerabilities faster than they can fix them?

A: The control loop breaks. Detection creates backlog, backlog creates triage debt, and triage debt turns into persistent exposure windows. Once that happens, security teams lose the ability to convert visibility into risk reduction, and the programme becomes a reporting function instead of a remediation function.

Q: Why does deadline pressure increase the risk of shipping vulnerable code?

A: Deadline pressure changes the trade-off from ideal remediation to acceptable loss. When teams are already balancing features, defects, and technical debt, security fixes that require extra testing or coordination are the first to be deferred. The risk rises because the organisation is optimising for release completion under constraints, not because developers stop caring about security.

Q: How do security teams know whether Teams remediation is working?

A: They should measure dwell time, removal latency, and the percentage of malicious messages removed before any user interaction. If detection is happening but content stays visible long enough to be clicked, the control is not effective enough. Audit trails should show fast, consistent containment.

Q: Should organisations automate remediation or keep it manual?

A: Start with automated triage and low-risk fixes, then reserve manual review for high-impact exceptions. Automation is most useful when it removes unused access, highlights policy violations, and shortens time to action, but humans still need to decide on edge cases where business context changes the risk.

Technical breakdown

Why vulnerable code keeps reaching production

Vulnerable code reaches production when discovery outpaces remediation. In AppSec, scanners and review gates can surface far more findings than engineering teams can realistically resolve within a sprint, release train, or change window. That creates a triage environment where some known issues are accepted, deferred, or hidden behind feature delivery pressure. The problem is not a lack of visibility. It is the mismatch between the rate of finding problems and the organisation's actual fix capacity. Once that gap becomes routine, shipping vulnerable code turns into an operational outcome rather than an exception.

Practical implication: Measure remediation throughput against finding volume, not just detection coverage.

How late discovery changes the security equation

Late discovery means a vulnerability is identified after the code path has already become costly to change. Fixing it may now require dependency updates, test rewrites, release delays, or coordination across several teams, so the issue competes with business commitments instead of being handled during normal development flow. This is why security findings that arrive too late are often deprioritised even when teams recognise the risk. The same dynamic affects secrets exposure and identity flaws, where a late alert may arrive after the affected component has already moved through multiple environments.

Practical implication: Shift detection earlier only when remediation paths are also made faster and less disruptive.

Why prioritisation determines whether security work gets done

Prioritisation is the control that decides whether limited engineering time goes to the highest-risk issues or gets consumed by the easiest ones. Generic scores alone are insufficient because they do not account for deployment context, compensating controls, authentication boundaries, or the blast radius of the affected component. Effective prioritisation turns a large backlog into a short list that engineering can actually execute. Without that reduction, teams face a false choice between shipping insecurely or shipping nothing at all. That is why backlog quality is a governance issue, not only an AppSec workflow problem.

Practical implication: Use context-aware prioritisation to convert a large vulnerability list into a fixable remediation queue.

NHI Mgmt Group analysis

Capacity, not negligence, is the real failure mode: organisations ship vulnerable code when remediation demand exceeds engineering throughput. The article is right to push back on moralised explanations, because shame does not change backlog physics. For security leaders, the implication is clear: if the fix queue cannot be cleared, the control has failed before release.

Remediation backlog pressure: the useful concept here is not just vulnerability volume, but the backlog created when findings arrive faster than they can be retired. That backlog becomes a governance debt across AppSec, engineering, and release management, because unresolved issues accumulate in the same way across code, secrets, and identity-bound assets. Practitioners should treat backlog burn-down as a security objective, not an afterthought.

Finding more is not the same as reducing risk: detection-heavy programmes can create the appearance of progress while leaving exposure unchanged. The article's core lesson is that security value appears only when findings move to resolution quickly enough to matter. For identity and NHI programmes, the parallel is obvious: inventory without lifecycle action only enlarges the queue.

Capacity management must be part of control design: security controls that ignore operational load eventually become reporting controls rather than risk controls. Teams need a fixed view of how many issues they can actually clear, where automation can compress work, and where release policies should adapt to remediation reality. The practitioner conclusion is to design for fixability, not just visibility.

What this signals

AppSec backlog pressure: the real governance problem is not whether teams can detect vulnerabilities, but whether they can close them before release pressure locks the risk in place. For practitioners, that means remediation throughput belongs in the same conversation as risk acceptance and release approvals.

In identity and secrets programmes, the same dynamic appears when reviews, rotations, or code fixes are added faster than teams can complete them. The programme that cannot retire its own findings is building operational debt, and that debt eventually surfaces as exposure rather than control.

Security leaders should expect AI-assisted development to widen the same gap if remediation workflows do not become faster and more automated. More code, more dependencies, and more machine-generated changes will amplify the need for fix capacity, not reduce it.

For practitioners

• Define remediation capacity as a control metric Track how many findings engineering teams can actually close per sprint or release cycle, then compare that against new vulnerability intake to expose the real backlog pressure.
• Prioritise by deployment context, not severity alone Rank vulnerabilities by where they sit in the architecture, whether compensating controls exist, and how much access or data exposure they create in practice.
• Automate the lowest-friction fixes first Use automation for dependency updates, safe patching, and validation so that scarce engineering time is reserved for the cases that truly need human judgment.
• Move discovery earlier without moving blame upstream Pair earlier scanning and review with explicit fix ownership and release support, otherwise earlier alerts just arrive earlier in the same overloaded queue.

Key takeaways

• The article argues that vulnerable-code shipping is mainly a capacity problem, where remediation work cannot keep pace with the volume of findings.
• The most important evidence is the widening gap between what teams detect and what they can actually fix before release.
• Programmes that want lower risk should measure fix throughput, automate low-friction remediation, and prioritise issues by real deployment context.

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.
• Security Backlog: The queue of unresolved vulnerabilities, code issues, and remediation tasks awaiting action. In mature programmes, backlog is not just an operations metric. It is a proxy for how much known risk the organisation is carrying forward in time.
• Context-Aware Prioritization: Context-aware prioritization ranks risks using exposure, reachability, and business or identity impact rather than severity alone. It is the difference between a long list of findings and a focused remediation plan that reduces real-world attack likelihood.
• Remediation Throughput: Remediation throughput is the rate at which a team can fix validated security issues relative to the number being found. It is a practical measure of whether AppSec is actually reducing exposure, rather than merely increasing visibility into a growing backlog.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management from an independent practitioner perspective. It helps security teams connect identity control design to broader operational risk and remediation discipline.